ohhh fantastic! Any chances you could add a parameter to select the time frame the pressure trend is calculated? I find the some of the trends seem to reflect short term changes vs changes on the day/hours that I was looking for.
Erik.
Hi-
Not 100% sure I follow what youāre looking for; the trend is a single calculated value that is based on a running tally of measurements. Changing the period after startup would essentially wipe out the history window used to make the calculation.
A little more background:
The definition of pressure trend defined by NOAA (the reference Iām using for all of these calculations) defines the trend as a change in excess of a certain amount over a 15 minute period. Right now, the calculation is using a fixed window for this, but my long term goal is to use a sliding window. For reasons of trust/reliability, Iād prefer to stick with the well-accepted definitions for this particular binding.
That said, If you wanted to do more specific analysis of the data, I think Iād use the persistence framework to send the data to a time-series database like influxdb where you can very easily calculate change rates over very specific periods. I use this with grafana to do this sort of thing with other values.
Thanks Bill,
That is some interesting background. I was originally worried that the short-term trend would show some minor changes but overall, I have found the current trend calculation quite useful. Might need some more thinking to figure out a simple indicator to show if the current weather is in a low/high pressure system but I really like this weather calculation binding.
Erik.
Hi Erik-
Iād be happy to add additional calculations if you find any that might be useful. Iām sure someone has developed a method for inferring pressure systems. Even if theyāre not universally accepted, I think that would be okayā¦ weād just want to identify them as such so that folks donāt get confused.
Best-
Bill
May I ask if there is a chance to get absolute humidity calculation (best in g/kg)? That would help a lot in humidity control of rooms.
Thanks in advance!
Stefan
Iām not sure what youād use it for (usually the relative humidity is a good measure for how āhumidā it feels in a room), but while calculating the absolute humidity requires solving some thermodynamic formulas, there are empiric formulas available that come really close. Given that relative humidity is a function of temperature, those formulas require the input of relative humidity and temperature and give the absolute humidity in g/m^3. If you want the specific humidity in g/kg, youāll need to account for the density of the air, a function of temperature and pressure.
In any case, you could just create a rule that triggers on changes of temperature, relative humidity and pressure and do the calculations there.
I know, but the formulas are quite āheavyā and with the lack of reusable functions inside the rules it is cumbersome to have a rule for every room. Much more elegant to add it into this binding.
As for the use - it is very useful to control humidity - i.e. humidifier control, where you control it based on a setpoint of absolute humidity.
You could write a JS conversion script once, put it in ā/etc/openhab/transform/ā and call it in every rule.
As for the binding, it currently supports one item as input for every variable, so for multiple rooms, thatās not going to help.
That is a very good idea for the JS conversion scriptā¦ will try it outā¦
Quick question: Is there any way to stop the INFO logging for some of the items monitored by the binding? My log is full of the following:
2022-02-05 10:58:07.714 [INFO ] [nal.WeatherCalculatorEventSubscriber] - Receive Update: Item 'WindDirection' changed from 40 to 45, WindDirection, ItemStateChangedEvent
2022-02-05 10:58:07.736 [INFO ] [s.handler.WeatherCalculationsHandler] - Item <WindDirection> changed to 45
2022-02-05 10:58:07.739 [INFO ] [nal.WeatherCalculatorEventSubscriber] - Receive Update: Item 'WindAverage' changed from 7.19 to 1.08, WindAverage, ItemStateChangedEvent
2022-02-05 10:58:07.739 [INFO ] [s.handler.WeatherCalculationsHandler] - Item <WindAverage> changed to 1.08
I am using Openhab 3.2.0 and the binding version from the marketplace.
Thanks in advance for your help!
Stefan
Hi-
Sorry for not replying soonerā¦ your post got lost in the shuffle.
By default, this binding is a bit verbose. The reason is that it cuts out a number of round trips when new users are having trouble getting things working. If the verbosity is getting in the way, Iād recommend just turning the log level for this binding to āWARNā:
log:set WARN org.openhab.binding.weathercalculations
If, at some point in the future you need to troubleshoot this binding, you can undo that with the following command:
log:set DEFAULT org.openhab.binding.weathercalculations
Hope this helps!
Bill
1 Like
That did the trick, thank you very much!
Hi,
I did a first time installation of that binding and I received a couple of messages in the log:
2022-04-10 15:29:44.600 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.openhab.core.events.EventSubscriber' failed: null
java.lang.NullPointerException: null
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.toUnit(WeatherCalculationsHandler.java:257) ~[?:?]
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.eventReceived(WeatherCalculationsHandler.java:301) ~[?:?]
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.receiveTypedEvent(WeatherCalculationsEventSubscriberImpl.java:77) ~[?:?]
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.receiveTypedEvent(WeatherCalculationsEventSubscriberImpl.java:1) ~[?:?]
at org.openhab.core.events.AbstractTypedEventSubscriber.receive(AbstractTypedEventSubscriber.java:57) ~[?:?]
at org.openhab.core.internal.events.EventHandler.lambda$0(EventHandler.java:151) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
I think it happened when I loaded my item file to the system with the relevant items for the binding.
Hi-
Judging from the error youāre getting, it looks like the updated state for your rainfall item isnāt able to be converted to the correct units of measurement required by the upcoming calculations.
If youāre still getting these errors, you might be able to enable debug logging, which should print out more details about what the state actually is:
log:set DEBUG org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler
Also, what is the source of your rainfall information? Can you provide the definition for that item?
Here is again such a NPE with activated DEBUG for the handler and the item definition.
I hope it helps.
2022-04-14 19:43:16.919 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.openhab.core.events.EventSubscriber' failed: null
java.lang.NullPointerException: null
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.toUnit(WeatherCalculationsHandler.java:257) ~[?:?]
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.eventReceived(WeatherCalculationsHandler.java:301) ~[?:?]
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.receiveTypedEvent(WeatherCalculationsEventSubscriberImpl.java:77) ~[?:?]
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.receiveTypedEvent(WeatherCalculationsEventSubscriberImpl.java:1) ~[?:?]
at org.openhab.core.events.AbstractTypedEventSubscriber.receive(AbstractTypedEventSubscriber.java:57) ~[?:?]
at org.openhab.core.internal.events.EventHandler.lambda$0(EventHandler.java:151) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
2022-04-14 19:43:16.752 [INFO ] [nal.WeatherCalculatorEventSubscriber] - Receive Update: Item 'num_Weather_F24h_PrecipIntensity' changed from NULL to 0 mm/h, num_Weather_F24h_PrecipIntensity, ItemStateChangedEvent
2022-04-14 19:43:16.753 [INFO ] [s.handler.WeatherCalculationsHandler] - Item <num_Weather_F24h_PrecipIntensity> changed to 0 mm/h
2022-04-14 19:43:16.808 [DEBUG] [s.handler.WeatherCalculationsHandler] - toUnit: val: 0 mm/h, 0 mm/h, unit cm
The item definition is:
Number:Speed num_Weather_F24h_PrecipIntensity "Niederschlagsmenge [%.1f mm/h]" <rain> (gWeatherForecast, gRestoreOnStartup, gInfluxHourlyShift24, gDel1M) ["Measurement","Rain"]
There is also another one, Iāve seen that only once - first midnight after installing the binding.
2022-04-11 00:00:00.023 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at java.time.ZoneId.from(ZoneId.java:460) ~[?:?]
at java.time.ZonedDateTime.from(ZonedDateTime.java:554) ~[?:?]
at org.openhab.core.library.types.DateTimeType.<init>(DateTimeType.java:76) ~[?:?]
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.tipBucket(WeatherCalculationsHandler.java:239) ~[?:?]
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler$1.run(WeatherCalculationsHandler.java:209) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Iām pretty sure this error is caused by providing an item with the wrong type of units. The rain totaling feature expects to receive updates describing amount of rainfall, and the item youāre using is providing a rate. When the calculator attempts to convert the rainfall amount into a known (length) amount of rain, it fails because mm/h is a unit of speed not length.
This error is happening when the high and low times for the day are being recorded. Itās possible that during the initial day of operation this value canāt be determined. If that were the case, I would not expect to see it again (at midnight on successive days). If it happens again there might be a more serious problem. Iāll look into adding some more diagnostic output and maybe try to catch the problem.
Another possibility is that perhaps the time zone of your openhab installation is not set (if the problem keeps occurring).
Ok, when the binding is expecting a length. My weather supplier (tomorrow.io) provides mm/h as unit.
The measure of the intensity of precipitation by calculating the amount of precipitation that would fall over a given interval of time if the precipitation intensity were constant over that time period.
The rate is expressed in terms of length (depth) per unit time, in millimeters per hour, or inches per hour.
Letās see, if the binding will provide reasonable values when providing the value without a unit.
Ok, thatās trying to describe rainfall intensity rather than an actual measurement of accumulation. I suppose if you had one observation per hour and assumed that during that period, the intensity was constant, you could remove the āper hourā part. Iām not sure that would result in accurate results, but it would at least sum up properly.
This particular calculation is meant to provide more meaningful information when a weather station only provides observations like ā0.5mm rain has been collectedā rather than a total amount from some period (which is typically how that works, such as for tipping bucket rain gauges).
Please let me know if you get things working, or if thereās anything I can do to assist!