The app polls the current weather as well as the 5 and 16-day forecast data of the OpenWeatherMap API and offers a host of flow triggers and conditions.
To use the data a freely available API key is required. Note that with the free API key the data of the current weather table can be delayed by up to three hours.
To use the data, you can add ‘device’ (as many as you like, with data from different tables or locations for instance) like you would add a powerplug.
Finally note that the max and min temperature data refer to different things in the ‘current’ table compared to the ‘5-day forecast’ table. In the 5-day forecast table the meaning of the temp_min/temp_max parameters is different, and probably not really relevant… You may see some very small differences (e.g. “temp”:21.87,“temp_min”:21.87,“temp_max”:22), but it does not refer to the maximum or minimum temperature in the interval. OpenWeatherMap states the following on this:
“Please, do not confuse min/max parameters in current weather API and forecast API. In current weather API temp_min and temp_max are optional parameters mean min / max temperature in the city at the current moment to see deviation from current temp just for your reference. For large cities and megalopolises geographically expanded it might be applicable. In most cases both temp_min and temp_max parameters have the same volume as ‘temp’. Please, use temp_min and temp_max parameters in current weather API optionally.”
Strange with no more comments. I found this very useful, however, it seems not compatible with v2.0. The weather data has not been updated since that release.
Hi, I can’t test this myself, however other users on V2 report that the OpenWeatherMap app is working, it does not seem to be a general issue with the app.
V2 is in the experimental phase at the moment, I guess its a case of ‘your mileage may vary’ as they say.
Yes, I think might be good to just wait and se what turns v2.0 will take when we go forward. I hope this is wrong though, otherwise I fear that I am dead and was not let in to heaven.
Wow! Ok, so you are getting data, but it is waaay off… That’s weird… I can image something could go wrong with Homey’s lat/lon coordinates (which are the basis for the forecasts), however I don’t think it is that hot anywhere on earth, even in Fahrenheit
You need to fill in your (Homey’s) latitude/longitude and the API key. You can also try to add another OWM instance for a City nearby, that takes out the lat/lon uncertainty.
But again, I do not even have a theory on how you can get data like 275.15 degrees…
I removed the device and created a new one. Now it fetches the correct value, but it only does this the first time, up on creation. It does not update the weather for me.
Well, not really logical… The app uses the internationalization settings in Homey, and as far as I am aware there are only two options: “metric” or “imperial”, and neither use Kelvin.
The problem is that so far various issues have been reported, ranging from issues with the cron job in the app, with flows, triggers, adding devices as well as receiving weird data. I do not run the experimental Homey V2, so I can not do anything about this at this point. And even if I did run V2 I probably couldn’t fix all these issues.
I am afraid it will be a matter of waiting until V2 is officially released and the issues are either fixed in V2, or I can address them in the app once I have upgraded my Homey as well.
It is unfortunate, but this is exactly what ‘experimental’ entails I am afraid.
You are correct, it should not be Kelvin, but it is logic that the temperature was presented in Kelvin, since 275K equals 1.85 degrees.
But no worries Anne, let’s wait and see what future enhancements of V2.0 will bring and take it from there. I will probably survive without your terrific app for the time being. But I do hope we can mend it later on, I really like it!!
Im having a issue where the sensor card dont want to update. I have tried the weblink to see that i would get a set of data and i did. So im wondering what could be wrong. Any idea?
It was just a minor bugfix (correcting the ‘sunrise/sunset’ time), nothing to do with Homey V2. Release notes can be found on github through link appstore if interested.
I did notice that a cron related bug was fixed in v2.0.0-rc8, and indeed the app has been reprorted to work in this release
No idea, it is not a common (or known) problem. Have you tried restarting the app? (Settings -> apps -> OpenWeatherMap -> stop/start or something like that).
Have you done a PTP (‘pull the plug’) yet? Possibly Homey’s cron process is stuck.
I know this is a crude approach, unfortunately I don’t have better suggestions. Besides, PTP-ing is a common procedure used for just about all Homey related issues under the sun…