ESPHome Device as MQTT subscriber, detect MQTT loss without reboot

ESPHome
1

I have a ESPHome device which is a subscriber only, it is not publishing, and is not connected to Home Assistant, it is standalone.

Is there a way I can detect loss of connection to the MQTT broker and take action? As best I can tell all that happens is a reboot (and I tried an on_shutdown and it did not seem to fire). I do not really want a shutdown, I want to sound an alarm (it has a small speaker).

The device is a monitor for a telescope system, the normal alarm comes from an MQTT posting, but if somehow the MQTT broker (at the telescope) is down, I also want to sound an alarm. All I’ve figured out so far is to put an alarm on reboot – which works, but is rather annoying when you first hook it up.

Linwood

PS. It’s an esp8266 if that matters.

2

Use the mqtt.connected condition in an automation. Create a script that sounds the alarm.

on_...:
  if:
    condition:
      mqtt.connected:
    then:
      - script.stop: alarm_script
    else:
      - script.execute: alarm_script
3

Ah… and about the time you wrote that I also found the reboot_timeout: 0s, which was the other missing piece, I thought it would always reboot.

So for clarity based on some descriptions, I need to sound the alarm, and if I want it to retry the connection after the alarm, do a forced reboot to try to reconnect?

4

That is the intention of the reboot, to reconnect. If its disabled you would either need to power down or if available use a physical reset button.

Do you use the web server? You could setup a software reboot button and log into the device.

5

PS. Thank you @Mikefila

6

Will a “platform: restart” not work, done after I sound the alarm?

No, this is bare bones minimal, the idea is I’m parked at at dark site, no internet, telescope outside collecting images, and I may nap in the car. Was going to plug this into a lighter or USB socket, and its sole purpose in life is to sound an alarm if (a) the telescope system decides it should by posting to the MQTT broker, or (b) if it can no longer talk to the MQTT server.

7

So that didn’t work, at least the way I did it. I set:

mqtt/reboot_timeout:

Then did a simple timer:

interval:
  - interval: 30s
    then:
      if:
        condition:
          mqtt.connected:
        then:
          - logger.log: "Watchdog: we are connected."
        else:
          - logger.log: "Watchdog: lost Connection."

This looped and worked fine when connected, but as soon as it went disconnected:

m
m796×346 77.4 KB

The loop stopped while MQTT was disconnected, as though the attempts to reconnect were blocking other activity.

As soon as I restarted it, it reconnected and the loop fired again.

It looks like ESPHome is being very insistent that MQTT be connected for anything else to function?

Or is an interval somehow different, what kind of automation can I use that would come ahead of this reconnection attempt?

Linwood

8

Just to clarify this is with reboot_timeout: set to 0s? Esphome was never meant to be stand alone, I’ve yet to test this for myself but it’s my understanding that setting it to 0s the esp should continue to run.

9

Yes, with reboot=0s it is continuing to run, but it goes into what appears to be a blocking process trying to reconnect to MQTT where the interval timer does not fire. It does that geometrically increasing wait loop on its own, that warning message is not in my code.

I don’t see any setting telling it not to do that in the documentation.

I may have to just let it reboot and do some kind of alarm on reboot. That will work, but is not exactly graceful.

10

How are you disconnecting the mqtt server? by cutting wifi? If so the wifi component also has the same behavior. You’ll need to add a reboot timeout to that component as well.

11

No, I just stopped the mosquitto service. Though the most likely cause of it going down in the real world is likely a power failure (e.g. batteries run dead) which would take down wifi also. But it could also go down if my rPi that handles the broker goes down (it does not produce the wifi, it just consumes it).

12

This should work, you’ll probably need a separate piezo for this. You could use the status light component and connect the peizo to GPIO2. This will flash power to the pin when a warning is active.

13

You mean the reboot timer (on both) should work? It probably will, I just didn’t want the same alert for rebooting as for initial (normal) startup. And the on_reboot fires before anything else.

If you mean what I have above, the interval timer, it seems it should work – it doesn’t; any ideas how to fix it?

14

Maybe I am missing the goal. If you would like to have an audible warning but not have the esp go into a boot loop. Set the component time out to 0s. The status light component can detect the warning.

It will flash the on board led. The power to flash the led is also on gpio2, connecting a piezo type speaker would cause it to buzz every time the status light flashed. It would probably still would go off when the device restarted though.

15

Sorry, I misunderstood. I can try that, but I need a sound (the idea is to wake up the napping astronomer). But if I can light a light, maybe I can turn that into a sound. My concern is whether that will even take precedence over this “must reconnect to MQTT before I do anything else” process.

16

It won’t be enough to wake someone off the board. It would just be enough to hear. It could be amplified by using a switch/relay to send more power to the peizo.

What is the power source? Is 12v available? That voltage into a piezo would be able to wake someone.

17

Actually I’ve got a little PC internal speaker, which will be plenty loud, it already works fine, using rtttl as a player.

It’s a car, so I can either drive from 12v or USB with 5v. But since the little speaker works fine, I was hoping to have it have a “Lost contact” tune as well as a “Wake up something is wrong” tune. I can do that with the on_reboot, just that means “lost contact” and “first startup” are the same.

Unless that status light feature works for me. Getting set up now for imaging (at home) with the telescope, so will experiment in an hour or a few.

18

I found a way to make all this work, though it is a bit of a kludge.

on_loop appears to not be affected by the MQTT attempts to reconnect. So I put a little state machine up there, and:

  • It plays 3 notes when it boots
  • It plays 4 different notes when it connects to mqtt

(So on startup I get confirmation it is alive and able to connect)

  • It plays Mozart when I get an alert from the telescope (and stops if it clears)
  • It plays a continual whop/whop type tune if it loses mqtt connection

It’s a kludge to put something in a loop running at fast to monitor something slow, but that’s the only place I found that had priority over the mqtt reconnect.

It looks ugly but so far works with all the conditions I tried. A wifi disconnect (I have its reboot=0 also) should also sound the same disconnect alarm, I do not care why it disconnected just so it wakes me up.

Now I just need to find an appropriately sized box (one day I need a 3D printer).

Thank you for the help. Further advice welcomed.

Linwood

19

good afternoon, friend! I am faced with a similar task.

I want to monitor the mqtt connection on the ESP device. If disconnect occurs, what should I do to reboot the ESP device or run a script that would change the logic of the device. I tried to change the mqtt reboot_timeout: 30s in the settings, there is no reboot.

How do I solve the problem? share the code if you could solve it.