search

emsesp / EMS-ESP32

ESP32 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
618 stars 106 forks source link

On ems-esp restart / upgrade old mqtt commands are re-executed (too early) #2179

Closed tp1de closed 3 hours ago

tp1de commented 4 hours ago

On restart of ems-esp gateway old mqtt commands are executed again. The execution is directly after detection of devices when not all entities are still discoverd. This leads to errors in log.

Expected behavior: On any re-start old commands should not be executed.

grafik

proddy commented 4 hours ago

Something is publishing these MQTT commands to EMS-ESP. EMS-ESP just subscribes and listens, it doesn't call mqtt commands by itself. I think you have them as retained messages so when EMS-ESP starts and subscribes, they start coming in again.

tp1de commented 4 hours ago

Something is publishing these MQTT commands to EMS-ESP. EMS-ESP just subscribes and listens, it doesn't call mqtt commands by itself. I think you have them as retained messages so when EMS-ESP starts and subscribes, they start coming in again.

I will check for retained. But every message has a timestamp which I see with mqtt explorer. Isn't it possible to check the timestamp while restarting?

tp1de commented 4 hours ago

The commands are issued from node-red workflow within ha. (my heat demand function)

tp1de commented 3 hours ago

.... and yes it does not happen without retained flag.

proddy commented 3 hours ago

ideally, you shouldn't persist in published messages. Otherwise, there's no point in having a queue.

Our MQTT client library is based on the 3.1.1 protocol and version 5.0 supports more subscription features like "Retain As Published" and "Retain Handling" which we need here.

This is not an issue in the s/w (it's been like this for 5 years) so will move this to a discussion while we explorer updating the client.