Number:Angle localCurrentWindDirection "Current wind direction [SCALE(wind.scale):%s]" <wind> { channel="openweathermap:weather-and-forecast:api:local:current#wind-direction" }
In checking the log file, I noticed the wind direction angle was reading 67.5xx. I was reading about this in the Scale help file. It looked like they were showing whole numbers only. What do you do with readings that fall in between the whole numbers? Would I have to change the %s to something like %.0f?
Thanks, Guys!!
I did go through and read the Scale docs before I tried putting the open bracket on the leading number like this ]46…67] and got a screen full of errors in the log file. I did not try putting it on the trailing number as suggested or changing the data type.
Thank you for the link to the OpenWeatherMap docs I didn’t know that was available yet.
*added note… I tried putting the opening bracket on the trailing number …67[ and it gave me no displayed wind direction. Vince, I read your reply closer the second time and I did not put the numbers together as you displayed, the 67 on both lines. That is why it didn’t work.
I implemented the daily forecast min/max ranges (temperature, pressure, humidity, wind speed) and daily sum values (rain, snow) with plain rules and by relying on a strict Item naming convention so I can use lambdas to perform the computations (saves writing lines of code). I use group-based persistence for the OWM Items.
To properly forecast the weather parameters for the current day:
use the current values as starting values for min/max
include all forecast parameters for which the forecast timestamp fits in the current day
The boundary case where the first forecast is for tomorrow instead of today, is also the only in which the free 12hour (5 day) forecast values can fully be used for generating full-day min/max/sum daily forecasts. Otherwise the 5th day will miss values (those corresponding to the forecast values that fit in the current day).
It would be great if we could use UoM for displaying the min and max values in one range Item, but I don’t think OH supports this.
I still need to correct the forecast calculation for the current day (less trivial due to odd OWM current rain/snow data that always returns 0) and for the boundary case in which the first forecast timeframe (03h) is for the day after the current day (trivial fix).
I expect that computing the total rain and snow of the current day won’t work with OWM as we don’t have access to historic data with a free account, and the current snow/rain values are always zero.
thanks for your binding supply.
There is one issue, that makes some troubles to me.
As far as I know, openweather API tags the rain value with “3h” if this value came out of the weather model. If there is a nearby weather station, the rain value is tagged with “1h” to be more precise.
And here is the problem, because the binding will not proceed with this 1h value, right? I had a short look to your code, and it seems to me, that the rain channel doesn´t support this value.
Maybe, this can be changed very easily…and this would also improve the binding.
Thanks very much in advance.
Yes, I am aware of that. There was another inquiry some days ago. I assumed the user will come up with a PR, but unfortunately he did not. Should be no big deal to change it.
From my understanding of OWM API doculmention, the “1h” is the real mesured precipitation by the local weather station, as the “3h” is the computed precipitation from model data.
So should it be not “better” to take the “1h” first, and then the “3h” if the “1h” is not present? The same should be applied to the snow volume.
Just my 2 cents…
Yes, indeed. Currently we are thinking about changing the business logic to always have an one hour estimation. Meaning devide the “3h” value by three. In that scenario it absolutely make sense to go for the “1h” value first.
Another question to think about is switching the unit to MILLIMETRE_PER_HOUR introduced recently in openhab/openhab-core#588. But that will be an API breaking change because it requires quantity Speed instead of Length .
In my books amount (expressed in SIUnits.MILLIMETRE) and intensity (SIUnits.MILLIMETRE_PER_HOUR) of rain/snow are different quantity types. I’d suggest offering either to the OWM binding as channels.
THX a lot for this Binding.
I used WU for may years, but now I switched to OWN.
The binding is Multilingual.
Did anybody had a found a list of all weather conditions in german?
I would like to use it for the icons.
I am not sure why you need them. As @fibu-freak already mentioned the API and the binding are capable of returning translated / localized weather conditions. I once started to collect the German translations because OWM seemed to have an issue with their spelling (e.g. everything was written in lower case letters) but it looks like they fixed it recently.
You should go for the condition-id. It is a fixed numerical value and independent from translation. Have a look here for a detailed description and a complete list of all weather condition codes.
After using this binding for a few months, I continue to be happy with it. I severely miss the ability to pick a specific station like I could do with wunderground. The data provided by Open Weather Map is not really accurate for where my house is located due to geography. But that is open weather map’s limitation and not something the binding can overcome.
I’m on top of a mountain. It’s giving me the generic weather for the local area, which is always more applicable to the larger valley area. So it’s always colder and windier at my house up on the mountain. With wunderground, I simply selected a neighbor’s station that was also up on the mountain and it was spot on.
I don’t think that will actually help for scenarios like mine. I can go to open weather map’s website and tell it my exact location and I get generic weather for the valley area. I asked Open Weather Map’s support about this. They said their system aggregates data and provides the user data for the area, not for any specific station. They said there is no means for the end user to identify and specify a specific station to pull data from. I don’t see it as a binding issue or something you’ve left out. It’s just not something Open Weather Map does unfortunately.
It probably works fine for 90% of the users. Geographically, weather is complicated at my house.
Where can I find this binding? Link to documentation in first post leads to 404, I registered at Eclipse Marketplace, but no binding for openweathermap to be found… Documentation at https://www.openhab.org/v2.4/addons/bindings/openweathermap/ doesn’t give any clues as to how to get it… installed market place in openHAB, but also no luck.
