Glad it’s working for you. I did make a minor change a while back that should detect trends more quickly, but it’s still a very simplistic algorithm (which I think is intentional).
Hi,
I would loke to translate in Italian pressure trend with transformation, can you please let me know all values that pressure trend can display in english so I can made my transformation file.
Kindly Regards
The values are -2, -1, 0, 1 and 2
Hi,
I need to know numeric values at witch trend correspond
Thanks
My pressuretrend.map
-2=Rapidly Falling
-1=Slowly Falling
0=Steady
1=Slowly Rising
2=Rapidly Rising
Ok Thanks
I’ve posted a new version of the Weather Calculations binding built for OpenHAB 2.4.0 to the download site above. I’ve been running it for about 2 weeks and it seems to be stable.
There are no new features from the previous release in September, this is just a recompile against the 2.4.0 release.
This is basically the level of functionality that I’d hoped to achieve when I started working on this binding. If anyone has any further feature requests, please let me know.
As always, feel free to let me know if you have any questions or comments!
Bill
1 Like
Thank you, have you considered publishing the binding in the market place?
I have been trying to decide what the best approach is: continuing to prepare builds myself and use the marketplace, or contribute the binding directly to OpenHAB (assuming they’d have it). The latter is probably the best approach but I don’t really have much time to devote to that process and the inevitable changes that would be required before it could be contributed.
Bill
I have an implementation of dew point implemented in rules, is this something that can be done with this binding? I consider code for calculating stuff like this library functionality, but maybe that is most easiest implemented as a binding? I don’t know.
But in addition to calculating dew point from temperature and humidity sensors, I also calculate entalpy, specific entalpy and mixing ratios, in Python with help from the metpy.calc module. This might also be something the binding could support?
Hi,
The Weather calculations binding includes dew point calculation, so you’d be able to use it directly.
The idea of this binding is to have a centralized place to generate derived weather calculations so that weather station bindings don’t individually have to recreate these data points; they can simply focus on providing the sensor data they have access to. When you set this binding up, each of the derived calculations (like dew point, or sea level pressure) becomes available as an item you can use in any way you want. The values are updated only when one of the values that are used to calculate it are updated, so the experience is very seamless once you set everything up.
Right now, these are the calculations that are available (assuming you have temperature, pressure humidity and optionally wind speed items):
Humidex
Heat Index
Wind Chill
Feels Like
Dew Point
Sea Level Pressure
Pressure Trend
I don’t see any problem with adding additional calculations, provided that there’s a good reference for how the calculation is made. Suggestions are welcome!
Bill
I like the sound of this - looking to exploit dewpoint calculation. It’s in a storage business, monitoring separate warehouse spaces. For example, internal humidity + external temperature tells us when there’s a risk of condensation on metal walls.
More normal OH users may want this kind of thing for e.g. garage and greenhouse spaces.
For this (ab)use, I’d want multiple Things (“stations”) which may not be what you have in mind of course 
Also no pressure sensor channel, i.e. that should be optional for me.
It’s moving away from the original weather station concept but I think has utility for OH users with common temp/RH sensors.
In my particular use, there are “alarm” thresholds of course. Such things can be done by rules fairly easily, and the user then gets to choose the tuning like hysteresis. It’s just a thought to incorporate high/low alarms.
1 Like
I think right now that pressure is a required field; I can look into making it optional, though that may take a little time for me to get around to. Alternately, you can create a dummy pressure item to satisfy the requirement that there be one… since it’s not used in the dew point calculation, the fact that it isn’t a real value and never changes shouldn’t be a problem.
It should certainly be possible to support multiple stations: just create a weather calculation thing for each station and assign that station’s sensor items to the proper weather calculation thing.
Once you have a dew point item, you can do any of the normal things you want with the data (i.e. have rules against the value). I like the idea of pre-canned rule triggers, but I’m not sure the infrastructure is in place to make that happen easily. For now, making your own rules is probably the way to go.
Aha, I should give it a try with multiple Things then
Yup, it was just a future idea. There would be a fair amount of overhead setting it up, because folk would inevitably want adjustable hysteresis as well as adjustable target in-flight, more targets than just max/min levels, etc.
I’ll make an Enhancement Request for pressure to go optional. At any future tinkering - as you say, easily circumvented for now.
Actually, I think that sort of triggering is interesting for lots of scenarios. Also, being able to specify a time-length of excursion before triggering, and hold-offs before re-triggering might be nice, too… sort of a “power trigger” against an item value. Not having to hand code that in a rule would be awesome.
Will ponder that idea for a bit…
Hi, Thank you for the binding, I’m having some trouble getting values in the items.
Here is the Thing config in PaperUI:
These channels are also linked to items, and they have a value.
Here are the channels:
Here is the Item config in an .items file:
Number Feel_Temperature "Gevoelstemperatuur [%.1f °C]" (gAstroWeather) {channel="weathercalculations:weathercalculations:a9cd945f:feelsLike"}
Number:Temperature Dauw_Punt "Dauwpunt [%.1f %unit%]" (gAstroWeather) {channel="weathercalculations:weathercalculations:a9cd945f:dewPoint"}
Number:Temperature Wind_Chill "Windchill [%.1f %unit%]" (gAstroWeather) {channel="weathercalculations:weathercalculations:a9cd945f:windChill"}
Number:Temperature Heatindex "Heatindex [%.2f %unit%]" (gAstroWeather) {channel="weathercalculations:weathercalculations:a9cd945f:heatIndex"}
When it didnt work at first, I have put the binding log in DEBUG:
When I restart the binding:
2019-01-22 08:58:18.857 [DEBUG] [.openhab.binding.weathercalculations] - BundleEvent STOPPING - org.openhab.binding.weathercalculations
2019-01-22 08:58:18.875 [DEBUG] [.openhab.binding.weathercalculations] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.events.EventSubscriber, org.openhab.binding.weathercalculations.internal.WeatherCalculatorEventSubscriber}={service.id=150, service.bundleid=246, service.scope=bundle, component.name=org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl, component.id=50} - org.openhab.binding.weathercalculations
2019-01-22 08:58:18.895 [DEBUG] [.openhab.binding.weathercalculations] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=152, service.bundleid=246, service.scope=bundle, component.name=org.openhab.binding.weathercalculations.internal.WeatherCalculationsHandlerFactory, component.id=51} - org.openhab.binding.weathercalculations
2019-01-22 08:58:18.943 [INFO ] [al.WeatherCalculationsHandlerFactory] - unbindEventSubscriber: org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl@f0b51b
2019-01-22 08:58:18.969 [DEBUG] [.openhab.binding.weathercalculations] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.core.ConfigOptionProvider, org.eclipse.smarthome.config.core.ConfigDescriptionProvider}={service.id=254, service.bundleid=246, service.scope=bundle, component.name=org.openhab.binding.weathercalculations.ConfigDescription, component.id=53} - org.openhab.binding.weathercalculations
2019-01-22 08:58:18.987 [DEBUG] [.openhab.binding.weathercalculations] - BundleEvent STOPPED - org.openhab.binding.weathercalculations
2019-01-22 08:58:18.992 [DEBUG] [.openhab.binding.weathercalculations] - BundleEvent STARTING - org.openhab.binding.weathercalculations
2019-01-22 08:58:19.065 [DEBUG] [.openhab.binding.weathercalculations] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.events.EventSubscriber, org.openhab.binding.weathercalculations.internal.WeatherCalculatorEventSubscriber}={service.id=436, service.bundleid=246, service.scope=bundle, component.name=org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl, component.id=277} - org.openhab.binding.weathercalculations
2019-01-22 08:58:19.086 [INFO ] [al.WeatherCalculationsHandlerFactory] - bindEventSubscriber: org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl@342b0b
2019-01-22 08:58:19.092 [DEBUG] [.openhab.binding.weathercalculations] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=437, service.bundleid=246, service.scope=bundle, component.name=org.openhab.binding.weathercalculations.internal.WeatherCalculationsHandlerFactory, component.id=278} - org.openhab.binding.weathercalculations
2019-01-22 08:58:19.148 [DEBUG] [.openhab.binding.weathercalculations] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.ConfigOptionProvider, org.eclipse.smarthome.config.core.ConfigDescriptionProvider}={service.id=438, service.bundleid=246, service.scope=bundle, component.name=org.openhab.binding.weathercalculations.ConfigDescription, component.id=280} - org.openhab.binding.weathercalculations
2019-01-22 08:58:19.159 [DEBUG] [.openhab.binding.weathercalculations] - BundleEvent STARTED - org.openhab.binding.weathercalculations
2019-01-22 08:58:19.287 [INFO ] [s.handler.WeatherCalculationsHandler] - config:{temperatureItem=openweathermap:weather-and-forecast:home:local:current#temperature, altitude=-2, windSpeedItem=openweathermap:weather-and-forecast:home:local:current#wind-speed, stationAltitude=1, pressureItem=openweathermap:weather-and-forecast:home:local:current#pressure, humidityItem=openweathermap:weather-and-forecast:home:local:current#humidity}
For the rest there are no references in both openhab.log or events.log to items or events of the binding.
This is the result in BasicUI:
And in PaperUI it says “NaN” where the value should be.
Can you see something wrong?
The thing isn’t configured.
You need to fill in the Data source fields to tell the binding which items it should get the information from
This is mine:
1 Like
But there is a dropdown t choose from known channels? I did that.
I really thougt that was the way to configure
I now pasted in my own Items names, now Dewpoint is filled in. Probably the rest will follow.
thanks for the help.
Yes, that’s changed… The binding needs items in there not channels…
@hww3, this is odd behaviour, the drop down should show a list of items, instead it’s listing ALL available channels, even the ones I don’t have items linked too!!
The approach I used to populate the dropdown works well for managed items but not so well for items that you define yourself (such as in an items file). The pick list widget does allow entries to be typed manually.
I’ve looked at populating the pick list directly from the item registry, but then it’s not possible to know how items may be related to things, and the list gets very confusing quickly… when testing, I had 5 items all named Temperature; which one is the temperature reported by my weather station?!?
The whole point of providing a picklist is to make configuration easier, and that’s obviously not what’s happened for some folks, so I will spend some time looking into alternative approaches.