search

HASwitchPlate / openHASP

HomeAutomation Switchplate based on lvgl for ESP32
https://www.openhasp.com
MIT License
727 stars 185 forks source link

Safety mode #174

Closed zsamiatt closed 3 months ago

zsamiatt commented 3 years ago

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 commented 3 years ago

Ongoing discussion about this: https://github.com/HASwitchPlate/openHASP/discussions/61

fvanroie commented 3 years ago

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 commented 3 years ago

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

fvanroie commented 2 years ago

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 commented 2 years ago

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

fvanroie commented 2 years ago

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 commented 2 years ago

That sounds like a sensible way forward to me.

fvanroie commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

fvanroie commented 2 years ago

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