Impossible to consult weather data after device went offline

[neilswann80]

The current date/time is still written as if the update succeeded, but obviously no weather data is shown.

Do you think it's worth storing the last successful data payload received to show (rather than a blank screen) in this scenario?

Would be useful to be able to look at the 8-day forecast again when away from the internet.

[orontee]

The "refresh date" is expected to be the timestamp of the last refresh whether it was successful, or not. So, if I understand correctly, what you observe is the expected behavior. (Note that each refresh starts by a cleanup of the model that will leads to a "blank screen" in case of failure; But when it fails the refresh date is updated.) Looks coherent to me. Not very useful, I admit; at least, gives an indication that nothing nasty has happened. Also it keeps the code simple! Matthias Le mar. 10 oct. 2023, 07:36, Swanny ***@***.***> a écrit :

…

The current date/time is still written as if the update succeeded, but obviously no weather data is shown. Do you think it's worth storing the last successful data payload received to show (rather than a blank screen) in this scenario? — Reply to this email directly, view it on GitHub <#57>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPYMIVD2IT2SV2T5RZ7NLLX6TNGNAVCNFSM6AAAAAA5ZYG746VHI2DSMVQWIX3LMV43ASLTON2WKOZRHEZTINBRGM2TQOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[neilswann80]

Ah, I see.

So showing the last successful weather payload with the associated date/time would be to much of a deviation from the current code, overcomplicated etc.

[orontee]

Would be useful to be able to look at the 8-day forecast again when away from the internet

Good point.

But it should be already possible with current implementation (apart from automatic refresh that happens once per hour).

@neilswann80 Are you "quitting" the application using menu or just putting it in the background using the home key?

In other words do you want the application to dump all the weather data, in order to find them after a restart?

Plan:

• Check that data refresh is triggered by location, units or language changes or hourly timer only
• Configuration setting to disable timer (should be the default, this timer isn't that useful)

[neilswann80]

But it should be already possible with current implementation (apart from automatic refresh that happens once per hour).

@neilswann80 Are you "quitting" the application using menu or just putting it in the background using the home key?

It's fine if I leave Taranis in the background, but if I exit the app, or if the device (is set to) powers off automatically the app then needs to be launched again.

In other words do you want the application to dump all the weather data, in order to find them after a restart?

I think this could be a useful feature when travelling/commuting and temporarily away from the internet. If the date/time correlates to this "last successful" update it shouldn't cause confusion.

[orontee]

I think this could be a useful feature when travelling/commuting and temporarily away from the internet. If the date/time correlates to this "last successful" update it shouldn't cause confusion.

I understand.

There's no difficulties to implement dump/restore of all model data now that we already have the infrastructure to do it for the location history.

But, at startup, when the application is initialized, there's an unconditional refresh that is triggered; See: https://github.com/orontee/taranis/blob/main/src/app.cc#L86

With the use case you mention, one want to skip this. On what basis? Configuration?

What do you think of a new three state configuration setting, say weather_data_refresh_mode, with possible values manual, startup and hourly?

When equal to manual this would allow to skip the refresh triggered at startup and only keep the automatic refresh triggered by unit or language changes...

hourly would be current behavior. startup would disable the timer.

[neilswann80]

Tricky. I do like the autorefresh option.

Would it be feasible to launch the app with autorefresh disabled and only enable it after testing for internet?

[orontee]

At current time, each request to refresh weather data or set new location tries to ensure that the device is connected to Internet. See https://github.com/orontee/taranis/blob/main/src/http.cc#L26

In order to cover the "disconnected" use case, we could:

1. Introduce of a new boolean configuration, say preserve_offline, that will skip weather data refresh when equal to true and there's no Internet connection.
2. Dump whole model to application state when exiting, and restore when starting

In your use case, preserve_offline will be set to true. If the device is connected to Internet everything works as we're used to, but if it's not then weather data refresh will be no-ops and you'll be able to consult last fetched data.

Editing the location, will still try to connect the device: It's then up to the user to accept or not.

@neilswann80 What do you think?

[neilswann80]

Sounds great to me.

[orontee]

Experimenting the preserve_offline configuration. Looks ok to me, lets live with this for a few days...

[orontee]

...But I just realized that managing a configuration parameter for this is not necessary. Devices have a "flight mode": With last commit on this branch, the application dump/restore the weather data at exit/startup and won't try to refresh weather data when device has flight mode enabled.

I am convinced it's the right "user interface".

Summary:

• At application startup, model is restored, a refresh is requested but nothing is updated if flight mode is enabled
• When user select "Refresh data" in menu or the refresh timer is triggered, a refresh is requested but nothing is updated if flight mode is enabled or device is not connected and user cancel wifi activation
• When configuration or model changes (user change language, unit system or choose new location), the displayed data doesn't match the configuration or model, thus a refresh is requested and, if flight mode is enabled, the user is warned and display is cleared
• When application exit, model is dumped

[orontee]

Available in pre-release : https://github.com/orontee/taranis/releases/tag/v1.3.0-rc0

[neilswann80]

Tested and loving it! 👍

Noticed a slight issue though:

When flightmode is enabled, the "last updated" date/time is correct for the dump. ✔️

BUT if flightmode is disabled, WIFI disabled and you click "cancel" to the WIFI activation message the date/time eventually updates to current rather than remaining as the correct one for the dump. ❌

[orontee]

Tested and loving it! 👍

Thanks for your feedback Swanny!

Noticed a slight issue though:

When flightmode is enabled, the "last updated" date/time is correct for the dump. ✔️

BUT if flightmode is disabled, WIFI disabled and you click "cancel" to the WIFI activation message the date/time eventually updates to current rather than remaining as the correct one for the dump. ❌

Good catch!

Should be fixed in https://github.com/orontee/taranis/releases/tag/v1.3.0-rc1