OpenWeatherMap Extension - Support for UV Index API

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 :wink:

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:

  1. 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?

  2. 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.

  • Thomas

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

  • Thomas

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!

  • Thomas

https://ci.openhab.org/job/openHAB2-Bundles/org.openhab.binding$org.openhab.binding.openweathermap/

Thanks. I little bit faster than me :wink: It is also possible to switch your OH 2 version to snapshot build.

1 Like

Nice. I bookmarked the Jenkins OWM url, so I’m good to go.

  • Thomas

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

I am assuming the question is aimed at @cweitkamp and just quoting me?

Thanks
Paul

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

1 Like

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.

1 Like

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.