Maybe you can use OWM but instead of comparing the whole description you might be able to check only a part of it (and if it contains rain) then do something.
Beware tough, that I use something like this and one of the descriptions is “dry after rain” which obviously includes the word rain, so I made a check with IS NOT exactly “dry after rain”.
There is a bug in the conditions based on the description/condition codes, they do not trigger reliably in case of changing conditions. Once fixed you don’t have issues with the sometimes strange descriptions as they are based on the numerical condition code, and not on the textual description.
However in the meantime using the rain value should work. You can use the ‘Rain has changed’ condition, and then use tag which contains the nr. of mm of rain, and a logic condition if ‘rain’ > 0 or something like that (the issue with OWM returning emtpy rain values is fixed).
What you can do is set up a couple of different flows for testing (just let them send a notification) to get an idea of the accuracy.
2 Likes
Thanks, seems to be the most stable approach.
Hello Anne,
with the last weeks of rainy weather I reactivated my OWM flows.
The old bug seems to be already there…
I have these flow conditions:
So the message should only be sent on these conditions.
But I get messages on other conditions (here: Clouds):
The OWM-API ist returning this:
Please can you take a look at the conditions?
Is it possible to add the main condition as a new tag for flows? Perhaps the condition from you app in addition? So it’s possible to compare these values.
Thanks and regards
Ronny
Hi Ronny,
That’s right, I haven’t had time to fix the bug yet. See my previous post for a workaround.
Hi Anne,
I’ll try to get this to work. But I already tested it some months ago.
The problem is, that OWM most times gives useless values.
E.g. “rain has changed” is triggered with rain value >0, but most times 0,0x mm for a low rain probability (most times while cloudy conditions). So the flow is triggered, but it won’t rain.
Tanks for investigating the problem. Perhaps it would be possible to pass the OWM main condition in a tag for using in flows?
Regards
Ronny
I do not know what i am doing wrong. i set the api key but not get any updates about the weather.
lokes like tje weather data its self is not accurate. when i want to upper screens ac case of sudden wind it is rather tricky because the inacurate data.
thanks for any sugestions
Leo
In case you have filled in a location, try it using Homey’s location (the default when you do not enter location details).
There are indeed limits to the accuracy of the weatherdata. Even the ‘current’ data can be up to 3 hours in the past… And it is based on extrapolated/modelled observations of the nearest weatherstation which may be miles away…
thanks i changes the configuration and see wat it is doing now
leo
Cool app so to say!
But would it be possible to implement custom language of description option?
https://openweathermap.org/current#multi
The API can provide output in quite a lot of languages, which can be subsequently used with ie. Google TTS, independently of a few languages officially supported by Homey.
Hello @anne ,
so first I was trying to use the 16 day forecast device for tomorrow’s weather and I was going crazy as it didn’t pull any data. Then I found out that the starting 16 day API subscription costs $40 per month, which is a bit expensive only to get tomorrow’s forecast. 
Does anyone even use the 16 days device? 
Then I figured out that the 5 day forecast is free, and I can use 8 x 3-hour intervals to get to tomorrow. But, the question is: will this pull new data depending on current time? i.e. in the morning, the data is shown for tomorrow morning and in the evening for tomorrow evening (so 8x3= 24h ahead)?
The thing is, I’d like to get data for a fixed time point in a day (let’s say 12:00), not a rolling forecast changing every three hours.
Maybe the app behaviour / API response is already set in such a way. If not, it would be a nice feature to have! Don’t get me wrong, both the rolling and fixed time stamps would be very useful, I’m just not sure which one is being used / is possible.
Thanks in advance!
edit: I found in the available flow tags that the date and time setting is rolling ahead every three hours, so a fixed time request is not possible without several additional flows (one for every three hours if you want to stay precise) and one separate device for each flow which would then update custom variables in predefined times during the day. Therefore, a suggestion for the next update if possible: it would be great to enable the call for a fixed time in a day.
If anyone has achieved this without additional flows, devices and variables (and $40 monthly ), I would appreciate the feedback. Thanks!
It seems that the 16 day forecast is still available for free for API keys which were generated before it became a paid service. But indeed, the subscription prices are ridiculous for private use.
I see your point about getting data for a fixed point in time, I will have a look at that.
@piotro I actually did this in an earlier version of the app. However, it breaks the conditions based on the description, and I don’t like having a mix of languages… The way to go would be to add the language properly so everything is in the same language.
If you want you can have a look at creating a pull request for the app (see https://github.com/abaretta/nu.baretta.openweathermap) with the additions required to add support for your language (Polish?) and I will then integrate it in the app and publish it.
@RonnyW I think I may have fixed the bug with the condition cards based on the weather condition. I am testing it at the moment (waiting for weather changes ;-)). Update: it seems to work for me, today I have seen the weather change from mist to drizzle, to heavy drizzle, light rain, back to mist… 
.
You can try the new release by installing the test version here: https://homey.app/nl-nl/app/nu.baretta.openweathermap/OpenWeatherMap/test/.
For all other users: new in the test version is snow data. If you want to have snow data in the app, it is unfortunately necessary to re-include the OpenWeatherMap ‘devices’ in Homey.
2 Likes
Hello Anne,
yes, it seems to work. Just changed to “Rain”. Flow started with right condition. Checked with OWM Api.
Thanks 
Hi, in the condition « when » i can’t change the tag or write anything. Is this normal?
It’s the same for all cards (wind, temperature. Cloudiness…)
@sebyldino the ‘WHEN’ triggercard sets the tags, you can use the tags in the ‘AND’ condition cards as explained in @Rocodamelshekima’s link. 
Yes , i tried this tonight and it works. thanks for your answers. 
Dear anna
I have checked in openweather and it’s possible to have the dew_point.
Dew_point will be fine to define an alert for Frost on the car windshield
Can it be possible to implement it?
Regards
Do you
It seems it is possible to upload dewpoint data from weather stations, however, I don’t see dewpoint data in any of the non-subscription tables (https://openweathermap.org/api)?
Hi Anne
Is there an issue with the 24-hour format of the time? The sun set today at 17:02 (5:02 PM), but this is shown as 17:2, as you can see in the screencap. Formatting ## used instead of 99?
I use this value in a notification to check for lights on/off. Looks a bit funny this way.
