But I have another question @Wolfgang1966 
Considering the weather warnings, and type/level (that now are both included in the “event” item) is there any other option than use a transformation for having split event and level of warning?
thanks
Andrea
Hi @ariela ,
I’m afraid that trying to semantically interpret the “event” wording is more that error prone. The weather alerts come from multiple sources ( One Call API: weather data for any geographical coordinate - OpenWeatherMap ). Depending on the source wording might be different, so I think a transformation based on the specific alerts you receive is the best way to handle them. The alerts API Global Weather Alerts - OpenWeatherMap provides a more detailed response with the attributes you need but unfortunately is not available for free and not (yet?) supported by the binding.
Playing with some features in the sitemap, I’ve perhaps found a good compromise
Let me know what you think
my items:
String OpenWeatherMap_Alerts1_Event "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#event" }
String OpenWeatherMap_Alerts1_Description "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#description" }
DateTime OpenWeatherMap_Alerts1_Onset "[%1$td/%1$tm - %1$tH:%1$tM]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#onset" }
DateTime OpenWeatherMap_Alerts1_Expires "[%1$td/%1$tm - %1$tH:%1$tM]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#expires" }
String OpenWeatherMap_Alerts1_Source "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#source" }
String Converted_OpenWeatherMap_Alerts1_Duration "[%s]" (gWeather)
the item “Converted_OpenWeatherMap_Alerts1_Duration” is just the result of a concat rule (onset + expires).
my sitemap:
Text item=Converted_OpenWeatherMap_Alerts1_Duration label="Moderate" icon="meteoalarm_thunder2" visibility=[OpenWeatherMap_Alerts1_Event=="Yellow Thunderstorm Warning"]
Text item=Converted_OpenWeatherMap_Alerts1_Duration label="Severe" icon="meteoalarm_thunder3" visibility=[OpenWeatherMap_Alerts1_Event=="Orange Thunderstorm Warning"]
Text item=Converted_OpenWeatherMap_Alerts1_Duration label="Extreme" icon="meteoalarm_thunder4" visibility=[OpenWeatherMap_Alerts1_Event=="Red Thunderstorm Warning"]
in this way you have enough flexibility how the “event” wording is done from the specific source of your Country.
The result is not that bad
edit: I’m using a orange/red/purple scheme for my icons, as the yellow is not visible enough
I’m sorry, but it seems the issue stands.
Not sure what I’m missing but I have always a UNDEF value for each item. But if I try to check via a normal http request (like: https://api.openweathermap.org/data/2.5/onecall?lat=45.465051&lon=9.094615&&appid=xxxxxxxxxx) I can see now data in eg. alerts.0.event (Yellow Thunderstorm Warning).
Here my items:
String OpenWeatherMap_Alerts1_Event "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#event" }
String OpenWeatherMap_Alerts1_Description "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#description" }
DateTime OpenWeatherMap_Alerts1_Onset "[%1$td/%1$tm - %1$tH:%1$tM]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#onset" }
DateTime OpenWeatherMap_Alerts1_Expires "[%1$td/%1$tm - %1$tH:%1$tM]" (gWeather) { channel="openweathermap:onecall:api:local:alerts1#expires" }
String OpenWeatherMap_Alerts1_Source "[%s]"
here my things file:
Bridge openweathermap:weather-api:api "OpenWeatherMap Account" @ "Accounts" [apikey="xxxxxxxxxxxxxxxxxxxxx", refreshInterval=10, language="en"] {
Thing onecall local "Weather And Forecast - Local" @ "Outdoor" [location="45.465051,9.094615", forecastHours=24, forecastDays=6, numberOfAlerts=5]
}
What I’m missing? 
Andrea
Now I see the first warning correctly, and matching what I can see with a HTTP request (yellow thunderstorm warning).
But, with the HTTP request I can see also the second warning … that is not visible via binding (yellow rain warning).
of course the second group of items is identical
String OpenWeatherMap_Alerts2_Event "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts2#event" }
String OpenWeatherMap_Alerts2_Description "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts2#description" }
DateTime OpenWeatherMap_Alerts2_Onset "[%1$td/%1$tm - %1$tH:%1$tM]" (gWeather) { channel="openweathermap:onecall:api:local:alerts2#onset" }
DateTime OpenWeatherMap_Alerts2_Expires "[%1$td/%1$tm - %1$tH:%1$tM]" (gWeather) { channel="openweathermap:onecall:api:local:alerts2#expires" }
String OpenWeatherMap_Alerts2_Source "[%s]" (gWeather) { channel="openweathermap:onecall:api:local:alerts2#source" }
String Converted_OpenWeatherMap_Alerts2_Duration "[%s]" (gWeather)
@ariela
I had a quick look at the code and probably found the issue.
In the following if statement it should be alerts.size() >= count instead. Otherwise, I think, the last alert in the API response is always ignored (or not updated, respectively).
@Wolfgang1966 what do you think?
I submitted a PR that should fix the issue
EDIT: seems it was just quick enough to make it into OH 3.3 M5 
Thank you guy appreciated
Andrea
@boehan unfortunately it seems not fixed yet on 3.3.M5. Now there is a warning in openweathermap, but this is not reflected in the binding
Andrea
Hmm… I will check in the evening, but I’m actually not sure if the fix really made it into the M5 release. Even though it is listed in the release notes, I can’t find it in the build summary. @Kai could you please confirm if the release notes for M5 are correct and #12697 made it into the release?
@ariela you could try to install the fixed binding manually → JAR file: JFrog
I’ll do and back to you as soon as I’ll see other warnings here
I can confirm that the release notes are NOT correct as I have just checked the listed changes on our Jenkins at openhab-milestone 3.3.0.M5 (#51) Changes [Jenkins] and this PR does not turn up there. It must have been merged slightly after the add-ons build started and just before I compiled the release notes.
I have now corrected the release notes and have to ask for your patience as the fix will then only be in M6.
Thanks for confirmation, at least we know now why binding behavior is unchanged
Actually, I wouldn’t have expected it to make it into release when I made the PR if it wasn’t merged so surprisingly fast and listed in the release notes…
I’m happy to say, 3.3.0 M6 fixed the issue, and now it works like a charm
thanks Hans for your support here
Andrea