[App][Pro] OpenWeather

Apps
, , ,
487

Hi ronnie

Wel sure … but it worked for years with no issue.

Also … i do not make my api calls that much ( its on 10 minutes actually ). My sunscreen FLOW checks the data every 10 secconds but inot only for windgusts but also for rain … sun position etc etc . That why the jnterval is higher in the FLOW that uses wind data

So it should not matter homey is checking a variable that refreshes every 10 minutes many more times …. It just means the fliw breaks every 10 secconds because that 10 MINUTE data is not being received.

488

Yes, that’s ok this way. I thought you are calling the API that much.

If you get the error again, you can send me a diagnostics report. Perhaps I can see some details. But I think it’s just a http connection error, but let’s hope the log has some details.

489

Thanks

Now the air quality broke :grimacing:

b5163919-e488-4523-af1d-e0b7894f4613

IMG_3571
IMG_35711320×2868 114 KB

490

It’s a network timeout.
Are you using the device tokens in your flows? And these tokens are not available if the device is unavailable (with error message)?

491

Wel i use a variable i think ( not at computer atm )

With an avarage of 3 windusts calcutaled from 3 different apps … because all give different outcomes :person_shrugging::grimacing:

when the app is down no app card can be used and the avarage is not calculated either because it does not find the data of your app

A network timeout froM my side u mean ?

492

Ok, so if the device is unavailable, the flow cards are not available. Ihave no quick fix for that. Not to show a message for an unavailable device would mean a user can’t see that something is wrong. The data just would not update.

The app get’s a timeout. You don’t know where it happens. Could be that the server is too slow or something is blocked on way there.
The app itself doesn’t use a timeout, so it’s a default timeout, I think around 60sec (just a guess).

I will check if I can add additional information to the error message…

493

I added a logging for the technical error message.
The device still get unavailable on timeout error, but I want to know the error details.
If you updated to test version and the error comes again, please send me another report. Thanks.

494

Thanks

installed and immediately an error for air quality

059ef2e7-fef0-4e13-80be-62b74a5b79ef

495

Sorry, tried to fix another small isue and broke the air quality device. New test version is online.

496

:zany_face:

Installed the new one.

Will let you know

497

Hi,

I hope someone can help me. What I would like is that at 21:00 we look at how many mm of rain have fallen in the past 24 hours. So from 21:00 the day before until 21:00 now. I don’t know which device to choose from OpenWeather and how best to set this up.

Would someone like to help me get started what exactly to set?

Thanks in advance.
Erik

498

You can use the daily summary:

grafik
grafik733×504 28.7 KB

But it’s only daily.

You can set an offset in days. 0=today. -1=yesterday.
So you can check the amount of rain for today in the evening. But not for some hours across two days.

499

When setting up Openweather 1.8.3 on Homey Pro (early 2019) as a new user, it is not possible to select OneCall 4.0. It is not there because the option is missing. This file might be the source of the problem: homey.openweathermap/drivers/owmOnecallCurrent/pair/city_geocode.html at master · RonnyWinkler/homey.openweathermap · GitHub . I can add the API-key using OneCall 3.0. When i want to adjust the settings to “OneCall 4.0” it gives me an error: “Invalid_setting_type”.

500

Thanks for the hint. Yes, the 4.0 item was missing there. It’s added now with test version 1.8.4.

It would be nice if you could test and confirm that it’s ok now. Thanks.

501

I removed the openweather app, installed your 1.8.4 test version, and confirm that:

  • I can select OneCall 4.0.
  • Am able to succesfully use the API-key from openweather.
  • The app receives weather data from openweather.
502

Small bug in the Daily Summary device: forecast_time shows a date one day earlier than the day it actually fetched.

I’m in America/Los_Angeles (UTC-7). Offset 0 shows yesterday’s date, offset 1 shows today’s. The forecast data itself is correct, it’s only the displayed date that’s wrong.

Cause is in drivers/owmOnecallDailySummary/device.js, line 270 on master (v1.8.4):

let date = new Date(data.date).toLocaleString('en-US', { ..., timeZone: tz, ... });

data.date from the day_summary endpoint is a bare date string like "2026-09-01". JavaScript parses a date-only ISO string as midnight UTC, so rendering that instant back in a negative-offset zone lands on the previous evening:

$ node -e 'console.log(new Date("2026-09-01").toLocaleString("en-US",
    {timeZone:"America/Los_Angeles",day:"2-digit",month:"2-digit",year:"numeric"}))'
08/31/2026

getOnecallDailySummaryURL() in lib/owm_api.js is correct, it derives the target date from the Homey timezone, so the right day is being requested. Only the display is off.

At UTC+0 or east of it, midnight UTC renders as the same calendar day, which is probably why this hasn’t come up before.

The other drivers aren’t affected, since they format a real unix dt value rather than a date string.

Parsing as local time would fix it:

let date = new Date(data.date + "T00:00:00").toLocaleString('en-US', { ... });

I would have opened a GitHub issue but Issues are disabled on the repo, so posting here instead.

503

Hi @bigcspecv

thanks for the hint. This way - just for copy/paste fix - is good.
A new test version is online. Can you check if it’s correct now? Thanks.

New test version 1.8.5:

  • fixed OneCall daily summary timestamp.