Allow offline mode

[fvanroie]

Currently the switchplate needs to be connected to wifi & mqtt, otherwise it will reboot after an extended time-out.

With local gpios connected in groups, it should be possible to use the switch in an offline mode, with only local gpio functions and GUI.

[fvanroie]

it should still let you access the page after a touch because you might have groups defined

[nagyrobi]

+1 for this. Moreover, have a way to display status/warning and perhaps a way to programatically disable or hide certain controls based on offline status.

[nagyrobi]

This could be done perhaps by letting the user create a separate page dedicated with objects related to offline functionality, like local relays in groups and some labels showing offline status etc. Maybe this could be the last page number or so.

This page should be somehow specified in config so when offline mode is detected it should automatically jump to this page. This special page shouldn't contain the items of page 0 (typically navigation info) so the user shouldn't move back to unusable objects by default. This page should be excluded from standard navigation - this could be taken care in the HA backend.

• when offline status detected, jump to this page
• when online status is back, jump to page 1

[Stupco]

+1 for this also, makes a lot of sense for functionality to not completely break.

Would recommend restoring to default jsonl state in this matter.

Using the Custom Component, you could overwrite or hide a button that says "OFFLINE" that only displays when it loses connection.

[nagyrobi]

Using the Custom Component, you could overwrite or hide a button that says "OFFLINE" that only displays when it loses connection.

You can't do that with the component since it's offline! All logic has to be local.

[nagyrobi]

Having a separate pages_offline.jsonl is a great idea indeed.

[nagyrobi]

Today I was surprised to discover that after killing my Mosquitto broker intentionally, to see how 0.6.0 handles this, the plate still reacts to touches "through" the Connecting screen.

I had this on screen (page2) while I killed Mosquitto:

On a 3-Gang Lanbon L8 with the swicthes grouped together with the local relays.

Touching the screen showing the Connecting message, in the places where the switches were, were actually toggling the relays in behind.
After a while the plate rebooted, and it returned with page1 in behind...

So the functionality is actually not bad by default. We just need to consider how to handle the display of the "Connecting..." message (could use the new Msgbox instead), and make an option (perhaps in user_config_override) not to reboot the plate and/or show the message...

Turbo version would indeed be to clear screen and load a separate pages_offline.jsonl (containing only local controls) while offline, and clear+load back the default pages.jsonl when reconnected...

[chrisweather]

Great project! Just started playing with a Lanbon L8 two days ago. The offline loop was one of the first things I ran into. So from my view the pages_offline.jsonl approach sounds like a great solution to have keep some basic control for the relays.
Happy to test and share feedback. Second L8 is on the way already.

[chrisweather]

Just an idea, I used https://github.com/arkhipenko/TaskScheduler in some of my projects to get thinks working in parallel without blocking others. The TaskScheduler works extremely smooth for that. So maybe the Wifi/MQTT reconnect could run in a separate task. So the UI can just check if it's online or otherwise switch to pages_offline.jsonl. When back online simply switch back to the online UI.
Just the message and the reboot need to be suppressed as nagyrobi already wrote.

[nagyrobi]

Needs a little check for races on the cc side then (@dgomes ), to notify back HA that connection is restored, as loading the online pages.jsonl needs val/jsonl updates from HA.

[fvanroie]

In 0.6.1-dev the automatic reboot on wifi disconnect has been removed. The plate will keep on trying to reconnect indefinitely...

/online.cmd and /offline.cmd scripts are executed when the wifi status changes. This makes it possible to disable or hide buttons, go to a special offline page, etc...

Mqtt has not yet received the same update, but will probably get a similar change.

[kquinsland]

Mqtt has not yet received the same update, but will probably get a similar change.

yes, please! I think there are a few usecases for hooks at each stage in the connection cycle:

• booted.cmd: fires as soon as power is applied
• wifi_{ok,err}.cmd: fires as soon as WiFi connection is OK or encounters an error
• mqtt_{ok,err}.cmd: fires as soon as MQTT connection is OK or encounters an error
• integration_{ok,err}.cmd: fires as soon as the openHasp instance is able to ping / get a reply back from the custom component

As soon as power is applied booted.cmd fires. This would load the default pages.jsonl and could render a basic screen that has 3 buttons for the three relays + a text label saying "Connecting...".

After WiFi connects OK, a wifi_ok.cmd fires. This could change the screen so the "Connecting..." message is replaced with the device IP address.

After MQTT successful, mqtt_ok.cmd fires. This could change the IP address color to green.

After the device is able to confirm that the integration (HomeAssistant custom component in my case) is alive and well, the integration_ok.cmd fires and loads the full set of pages and widgets.

If Home Assistant or OpenHab are shutdown, mqtt broadcast to let all the devices know that it's time to execute the integration_err.cmd which would revert back to the same state that mqtt_ok.cmd loaded.

If mqtt connection is broken (broker restart / upgrade ... etc), mqtt_err.cmd would fire and could be used to display the same thing that wifi_ok.cmd displayed.

And if WiFi wasn't available, wifi_err.cmd fires and loads up the failsafe layout.

---

I have a selfish reason for this granular level of execution hooks.
Most of the layouts that I am developing/deploying leverage templates in the HA instance to calculate position/size and appearance values for various widgets.

If MQTT or HA/the HA CC are not available, I need to display the failsafe layout. I can't display the "full" layout until the CC can be reached / confirmed that it's healthy.

[nagyrobi]

Life would be so much simpler if we would be on top of ESPHome (with their native API).

• no need for mqtt broker
• have connection status instantly in real time

It would mean to be a different product, I know...

[fvanroie]

ESPhome is also tied to HA, so it would simplify some stuff while complicating others.
It's an alternative way to go about the OS layer, but does not solve everything.
So that would involve double maintenance and testing of code changes...

Tasmota also has LVGL running on top of Berry, so that's another option.

I have started a feature-mqtt branch to make the MQTT client non-blocking in openHASP.

[nagyrobi]

Great!

[nagyrobi]

Updated documentation with an example how to configure this.

[nagyrobi]

Now one more step forward, excerpt from discord discussion:

This is not all, we also need a way to inform the plate when HA is not running but MQTT is!
https://www.home-assistant.io/docs/mqtt/birth_will/

@fvanroie could you add this feature? In theory it shouldn't be complicated:

• execute /ha_online.cmd when topic homeassistant/status topic changes to online
• execute /ha_offline.cmd when topic homeassistant/status topic changes to offline

this way we can detect the cases when Home Assistant restarts (for example because of config change).
we can handle cases when a misconfiguration of HA prevents it from starting...
...causing a prolonged offline state until fix...

[nagyrobi]

As an extra step to the above a command could be implemented to check for homeassistant/status , and that could be put in online.cmd with some kind of if/then mechanism (or simply stop execution of the script if result is false). Only thing is that by default this is not a retained message, but it can be configured to be like that by HA. That way it can be queried any time.

Use case (@RazoredRaven): if both HA and WiFi is offline then offline.cmd runs, but when WiFi goes online (and HA is still off) then online.cmd is run and pages_online.jsonl display even though HA is still offline...