API vs MQTT

ESPHome
1

This weekend I finally got around to changing all my ESP sensors from mqtt to the api and discovered a case where esphome mqtt is superior to the esphome api.

It takes at least three times as long using the api as it does using mqtt to wake and report the state of a binary sensor. Using the api this regularly results in missed sensor states, even allowing for filters like this:

    filters:
      - delayed_on: 100ms
      - delayed_off: 10s

With mqtt and the above filter I never miss a sensor state that wakes the device.

I tried upping the off time to 45s and while this did allow the api to report the state that woke the device it caused other problems.

So it’s back to mqqt for my sleepy ESPs.

1 Like
2

Interesting, especially given what is said here https://esphome.io/components/api.html#advantages-over-mqtt

@OttoWinter, any comment?

3

I believe he is on holiday at the moment but has said this in the past:

…deep sleep is not really compatible with native API (#174)

HA only checks if a given ESP is connectable every 60s (with an exponential backoff).

So you need to a) increase deep sleep run duration (and use more energy) or use MQTT.

See also esphome/feature-requests#46

Problem with current native API is that the ESP is the server. That was an intentional decision that makes setup much easier (and so the default will stay that way).

However, for things like deep sleep the api needs to be turned around: A central server (kind of like MQTT broker) that all ESPs connect to. Current plan is to incorporate this new server directly into HA.

1 Like
4

Come to think of it, I think I have read those comments before. Makes sense now.

5

If only I had read it before changing everything over. Would have saved a bit of mucking about and restarting to remove …_2 and …_3 copies of the sensors.

6

But then you wouldn’t have had anything to do in the weekend.