Good question. It is listed as
list.main.temp_kf
Internal parameter
in their documentation. No further explanation.
Good question. It is listed as
list.main.temp_kf
Internal parameter
in their documentation. No further explanation.
so if it’s “internal parameter”, it’s not for us
Thanks for creating the extension. I installed it and got it working, including the new UV data. FYI, the uvindex example has a typo. Specifically, the time-stamp channel ID is shown as timestamp.
I’m a new OWM user. Some basic questions about the binding:
I manually installed the 11.0 snapshot (Dec-26-2018) binding on Openhab2 using the linked file from this announcement post. But I’ve read that OpenWeatherMap can be found on the Eclipse IoT Market. But I cannot find it on the IoT market web repository site and it is also missing from my OpenHab-2.4 addons listing. Is there an alternate place to find the latest update?
I see a persistent warning in my Openhab2 logs that I cannot solve, as follows:
Could not update element with key openweathermap:uvindex:api:local in ManagedThingProvider, because it does not exists.
Everything works fine, but I would appreciate any advice on how to solve that warning.
Hi Thomas,
Thank you very much for your feedback.
Nice catch. I will fix it.
wrt 1. The binding was available on the Eclipse Marketplace before my initial contribution has been merged. I deleted it over there because I do not see any reason to maintain several version in different locations.
wrt 2. See my comment above.
BR
@cweitkamp, Thanks for the info. I will ignore OpenHab’s log warning message. Would be great if someone found a way to prevent it.
Do you have an official repository for future updates to the OpenWeatherMap extension? It would be nice to be able to visit a dedicated place and check for updates.
BTW, I just read that the eclipse smarthome community site has an uncertain future. I’m not sure what it means to developers like you that share code there. Hopefully there’s a happy ending.
https://www.eclipse.org/lists/smarthome-dev/msg00195.html
No worries. openHAB will continue without restrictions. We decided to move the ESH code into openHAB Core and all ESH add-ons to openHAB 2 Add-ons.
If you like to follow what is going on I would suggest to subscribe to this topic.
The official repository for the binding is openHAB 2 Add-ons.
@cweitkamp, I appreciate the link. Subscribed.
Blockquote
The official repository for the binding is …
I had previously seen OWM’s source code at the OH github add-ons area. But the compiled jar is not found there, so that is why I asked about an official place to download the latest release (compiled). However, from reading the details in the link you provided it sounds like that will be taken care of when the ESH code is fully migrated over to the OH core.
Thank you again for creating the OWM binding!
Thanks. I little bit faster than me It is also possible to switch your OH 2 version to snapshot build.
Nice. I bookmarked the Jenkins OWM url, so I’m good to go.
Please, can you explain me why you create a item this way?
It seems it doesn’t really match with the reference in the sitemap counterpart definition (Text item=localCurrentTemperature) and and the value never shows in fact.
But removing :Number or referencing it instead of “localCurrentTemperature” for example make the expected result to come out
Searching for the Item reference documention I didn’t discovered anything about the semi colon assignement but the Group type only
Onestly I was referring to the informations example you quote inside your replay (6/7 jan)
Isn’t it?
Defining your items in this way, means to use UoM-System see here and here.It should work quite fine if your setup is ok. I’m using it in the same way.
.items
Number:Temperature localCurrentTemperature "Current temperature [%.1f %unit%]" <temperature> (gOWM,gOWMOutlook) { channel="openweathermap:weather-and-forecast:api:local:current#temperature" }
String localCurrentCondition "Current condition/Wetterlage[%s]" <sun_clouds> (gOWM,gOWMOutlook) { channel="openweathermap:weather-and-forecast:api:local:current#condition" }
Number:Pressure localCurrentPressure "Current barometric pressure/Luftdruck [%.1f %unit%]" <pressure> (gOWM,gOWMOutlook) { channel="openweathermap:weather-and-forecast:api:local:current#pressure" }
Number:Dimensionless localCurrentHumidity "Current atmospheric humidity/Luftfeuchtigkeit [%d %unit%]" <humidity> (gOWM,gOWMOutlook) { channel="openweathermap:weather-and-forecast:api:local:current#humidity" }
.sitemap
Text item=localCurrentTemperature
Cheers Peter
Thank you Peter, you make me discover something new about OH structure and capabilities
And I got it
Please, can you update the download reference?
Hi @Brignoud,
Thanks for the he reminder. The feature has been merged and is part of the last milestone build (OH 2.5.0 M1). Have a look at the official documentation for an example.
Thanks for replying, this is my actual release of OH indeed
Only I thought this way to be able to upgrade the bindin to the latest staging release
I see a reference to Jenkins, can I addresse myself over there?
In general, system provided binding are they dynamically upgraded or not?
There is a way to use newer binding versions with an older realease. But unfortunately that is not working very well at the moment. The bindings will be updated every time you upgrade your OH2 setup. You cannot subscribe to Jenkins. Only to GitHub where our source codes are hosted.
Hi Christoph,
thanks a lot for the OpenWeatherMap binding, which I have installed and set up in the last days. Since I think there is an inconsistency with the example uvindex.scale
transformation I’m replying to this older thread, as it is the most prominent when searching for OpenWeatherMap UV index, with your initial instructions.
Since #uvindex
gets returned as a float Number and UV index reporting rounds up, much the same as when you display the #uvindex
item with %d in the sitemap, shouldn’t the uvindex.scale
be
[..2.5[=Low
[2.5..5.5[=Moderate
[5.5..7.5[=High
[7.5..10.5[=Very high
[10.5..]=Extreme
or with individual steps, as I have implemented myself
[0..0.5[ = 0 - Low
[0.5..1.5[ = 1 - Low
[1.5..2.5[ = 2 - Low
[2.5..3.5[ = 3 - Moderate
[3.5..4.5[ = 4 - Moderate
[4.5..5.5[ = 5 - Moderate
[5.5..6.5[ = 6 - High
[6.5..7.5[ = 7 - High
[7.5..8.5[ = 8 - Very High
[8.5..9.5[ = 9 - Very High
[9.5..10.5[ = 10 - Very High
[10.5..] = 11+ - Extreme
This the gets consistent UV index values as when displaying the item with %d, and will also make it equal with the UV index being displayed on the OpenWeatherMap website.
Many thanks again for a very enjoyable binding.