Safety mode

[zsamiatt]

If wifi or HA dead need safety mode.
We need control inbuild relay. It's hard to fix problem in the dark. And I think the screen protection should also work without network.

I have Lanbon L8 with 0.6.0 firmware.

[nagyrobi]

Ongoing discussion about this: #61

[fvanroie]

In 0.6.1 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.

[nagyrobi]

https://haswitchplate.github.io/openHASP-docs/0.6.1/commands/#batch-processinng

[fvanroie]

I have created a feature-mqtt branch that doesn't obstruct the normal GUI while MQTT reconnects.
The Connecting... progressbar is gone and the plate keeps responding as normal to local events.

This needs thorough testing though... as it involves some multi-threading and semaphores, which I'm not really familiar with.
Preliminary testing seems OK here, but just in case you want to test this branch I would not advised to put it on a production plate.

[bensuffolk]

Can you add a feature to run a cmd file when MQTT connects and when it disconnects like you do for wifi?

[fvanroie]

The main issue has been that the PubSubClient library has a blocking connect() method which locks up the UI for serveral seconds before it times-out. For this the reason the openHASP MQTT code blocks the display whenever it looses the connection... To work around this issue, I had created a bit of a hack that runs the connect() method in a separate task. That hack is in the old feature-mqtt branch but I'm not confident that this will be a good (long-term) solution.

I'm playing around now with the esp_mqtt module, which is Espressifs implementation of the MQTT protocol for their IOT devices. It seems to work well and handles disconnects gracefully without blocking the UI. My reasoning is that swapping MQTT clients would be a better long-term solution since it's Espressifs own code. There are also a lot of additional capabilities that could be used, like MQTTS or MQTT v5, etc...

I'll publish my code later for testing, but basically it would be a simple define to switch like:

#define USE_ESP_MQTT
//#define USE_PUBSUBCLIENT

[bensuffolk]

That sounds like a sensible way forward to me.

[fvanroie]

Now that I think about it... it could have an influence on the ETHSPI code. PubSub uses an Arduino WifiClient object as its underlying network protocol. I don't think that esp_mqtt supports the Arduino networking library since it's an ESP-IDF module. Probably the ESP-IDF W5500 lwip network interface needs to used...

[bensuffolk]

The ETHSPI is using the lwip network interface, so it will all just work with the WiFiClient. It's not a separate Ethernet library.

[fvanroie]

My bad! I thought it was a purely Arduino SPI library, but looking under the hood indeed reveals the ESP-IDF framework being used. This is good news and should indeed be supported by the esp_mqtt client.

I have checked in the code but now somehow the Github throws an error while I'm able to compile locally...

[fvanroie]

I've worked around the error by disabling Freetype for the time being.

[fvanroie]

I've added mqtt_on.cmd and mqtt_off.cmd scripts.