Maybe useful for cross checking, debugging maybe not… Grafana can calculate the pressure trend directly as well as some other things eg Use in metrics …Difference and Moving Avg. My pressure data is updated every 5 minutes so a moving avg of 24 data points is 2hrs. This seems quite sensitive but not overly so. It also means I can display the actual rate of change in meaningful units eg hPa/hr. A scale of -2, 0, +2 hPA/hr seems sufficient so far. You can also apply the value mapping directly in Grafana too…
Possible useful feature…
If you know the outside humidity and temperature as well as the indoor humidity and temperature then its possible calculate if opening the windows will help reduce the indoor humidity or not. It deson’t always help but does let the bugs in 
You can then make a value mapping thats says for example ’ Humidty high… Opening the windows will not reduce it’. etc
I am using multiple sensors, mostly Mobile-Alerts sensors, one of which does this type of useful ventallation calculation. I aslo built a raspberry Pi barometer with a BME280 pressure sensor and stepper motor driven dials for pressure and trend.The pressure data is sent to openhab, influx, grafana via mqtt Could the mqtt barometer data work with this binding?
Thanks Mark.
Interesting ideas. That’s the sort of “intelligence” that I was thinking about when I started down the path of weather/home automation/etc. Somewhere I got sidetracked, but as an example, living in a stone clad home, changes in weather are often have a delayed impact on internal temperatures and humidity. I had hoped to put together some rules that took this hysteresis into account when setting thermostats, etc.
As to your question, the calculations binding deals with number items that provide temperature in degrees celsius and pressure in hectopascals (which if memory serves, is equal to millibars). As long as you have items like that (i.e., that’s the unit it natively provides or uses the units of measurement feature in 2.4, or you can transform it), it all of the calculations will come out correctly.
I do precisely this on my garage air fan, sucking in outside air when the dewpoint outside is less than the garage dewpoint (with some hysteresis). So yes, that is a useful feature.
Hi Bill! I guess this binding also needs to be updated.
2019-08-25 00:29:51.048 [INFO ] [s.handler.WeatherCalculationsHandler] - config:{altitude=10, stationAltitude=20}
2019-08-25 00:29:51.049 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler@444aa48': null
java.lang.NullPointerException: null
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventFilter.addItems(WeatherCalculationsEventFilter.java:19) ~[?:?]
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.addItems(WeatherCalculationsEventSubscriberImpl.java:42) ~[?:?]
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.initialize(WeatherCalculationsHandler.java:106) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.M2]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.M2]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-08-25 00:29:51.063 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'weathercalculations:weathercalculations:279fca99': null
java.lang.NullPointerException: null
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventFilter.addItems(WeatherCalculationsEventFilter.java:19) ~[?:?]
at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.addItems(WeatherCalculationsEventSubscriberImpl.java:42) ~[?:?]
at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.initialize(WeatherCalculationsHandler.java:106) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.M2]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.M2]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Hmm. My binding is working fine on 2.5.0 M1; I will try to take a look at this over the weekend.
I had this same nullpointer, is the Wind Speed Item required? Bitbucket says no, but afaik it fails without it with this nullpointer?
And one more thing, what is the difference between those two altitudes? If I’m at 200meters, and my station is further 3 meters up, should I enter 200 and 203 or 200 and 3 ?
Hi-
Sorry for not answering sooner; for some reason I’m not getting notifications on this thread.
Are you configuring this using PaperUI or such, or are you using configuration files?
Wind Speed should definitely be optional… if the value is empty or not provided, it will be skipped as a source of data. Are the other items being supplied (they’re not optional, and if any of those are empty or not provided, a null pointer error is possible)?
“Station elevation” is the ground elevation (in meters above sea level) where the station is located, that is, the elevation for the position of the weather station as indicated on a topographical map. “Station height above ground” is the height above the ground that the station is positioned, ie 2 meters.
I configured this via PaperUI and was pretty sure that this nullpointer went away after I configured Wind Speed Item
Hmm…
What version of the bundle are you using (ie, what’s reported in bundle:list)? I’m pretty sure that it’s been optional from the start, but it’s possible my memory is bad 
I went to my Weather Calculations thing, removed the setting for the wind speed item, saved it, restarted openhab and it seems to be working. I checked the wind speed item setting after restarting just to be sure it was undefined.
Everything works fine except my Pressure Trend value does NOT change. I’m using this version of the binding below:
2.4.0.201901080352 │ org.openhab.binding.weathercalculations
Item Def:
String WCalcPressureTrend "Pressure Trend [%s]" <line> (WCalc, Group_HabPanel_Dashboard) { channel="weathercalculations:weathercalculations:5d39add9:pressureTrend" }
I’ve tied 2 different Barometric Items from 2 different providers. Each of these values are moving hourly.
Number:Pressure OWMCurrentPressure "Current Barometric Pressure [%.1f %unit%]" <pressure> (OWM, Group_HabPanel_Dashboard) { channel="openweathermap:weather-and-forecast:api:local:current#pressure" }
Number:Pressure FIOPressure "Barometric Pressure [%.2f %unit%]" (FIO, Group_HabPanel_Dashboard) { channel="darksky:weather-and-forecast:api:home:current#pressure" }
I’m actually NOT using the mapping yet on the pressure trend item so I can actually see values appear right now.
Any advice?
Best, Jay
Hi-
I haven’t actually confirmed this, but I suspect that your data sources aren’t generating enough datapoints to cause a trend (that is, the binding isn’t seeing enough changes). How often do your data sources update?
My datasources provide updates once a minute; my guess is that you’d need updates at least once every 5 minutes or so for this to work.
I will be the first to admit the mechanism I’m using is not statistically sound (though I deemed it sufficient given that in this use scenario that’s not critical). I’m not sure switching the method would change things much but I’ll look around to see if maybe someone has a sliding window implementation that would work better.
Bill
This is NOT needed with v2.4 of the binding; the string values are being presented at the item level not the numbers.
Best, Jay
Hi Bill,
This binding looks exactly like what I am looking for. I did try the 2.4 version but cannot get it to work with my 2.5 installation. Any chance you could build for 2.5.
Cheers, Lawrence
Hi Lawrence-
I can certainly try to prepare a newer version, but I’m running OpenHAB 2.5.2 with the 2.4.0 snapshot version and it seems to be working properly (that I can tell). What sort of problem(s) are you having?
Bill
Hi Bill,
my mistake I had expected the thing to show up in the inbox straight away. Its all fine after I manually add the thing and configure it.
Regards
-Lawrence
Hi Lawrence-
Excellent… I will make a note to be more clear about how it’s to be used in the documentation. It doesn’t do auto-discovery because you might want more than one set of conversions. Do let me know if you run into any further problems!
Bill
Hi!
I recently installed a wemos d1mini on my balcony, flashed with tasmota firmware and installed a BME280 sensor that gives me the temperature, pressure and humidity.
So far I could link everything with openhab, but when I use the weather calculations I always get -NaN for the humidex or Feels like.
I’m using openhab 2.5.3 with the 2.4 weather calculation binding.
I first setup the thing and after added the channels corresponding to my sensors.
Any Ideas what I did wrong?
PS: never mind, the problem was the dropdown showing the channels and not the items, problem is solved!
Hi Bat_B-
Glad to hear you got it working!
I think I’m one of the few people who don’t use item files, so I’m not completely clear on the steps required to get things working in that situation. Were the correct entries present in the dropdown, or did you have to enter them manually?
Hi Bill,
Finally managed to get some time to test this and still having some config issues.
When I turn on debug for the binding I can see that it receives updates for Temp and Wind but not for Pressure and Humidity.
The items I am using as follows-
Number WindAv “Av Wind Speed [%.1f km/h]” { channel=“mqtt:topic:RTL_433:windav” }
Number ObanTemp “Outdoor Temperature [%.1f °C]” { channel=“mqtt:topic:RTL_433:temp” }
Number ObanPres “Pressure [%.1f hPa]” { channel=“mqtt:topic:RTL_433:pres” }
Number ObanHum “Humidity [%.1f %%]” { channel=“mqtt:topic:RTL_433:hum” }
They all update correctly in the sitemap but for some reason the binding does not register anything. From the openhab console:
20:58:17.490 [INFO ] [ns.handler.WeatherCalculationsHandler] - config:{temperatureItem=mqtt:topic:RTL_433:temp, altitude=10, windSpeedItem=mqtt:topic:RTL_433:windav, stationAltitude=1, pressureItem=mqtt:topic:RTL_433:pres, humidityItem=mqtt:topic:RTL_433:ihum}
20:58:59.055 [DEBUG] [ns.handler.WeatherCalculationsHandler] - Item mqtt_topic_RTL_433_windav changed to 17.136
20:58:59.824 [DEBUG] [ns.handler.WeatherCalculationsHandler] - Item mqtt_topic_RTL_433_temp changed to 4.3
The Chill Factor item calculates ok but nothing else.
Any help welcome
Thanks