I’m using a ZigBee button to call an automation which notifies via Pushover and Alexa. Works fine.
I’d like to reduce latency and use a physical button. I can use a Pi, ESP32 or similar to respond to a closure and tell HA.
What’s the lowest latency input to HA? My MQTT server is separate so I’m thinking an HTTP post direct into HA might be best.
Is there anything faster? HTTP is fast enough in my testing, it’s an experiment as much as anything else.
If you can hard wire an ESP32 via Ethernet that would probably be best. You could also get better latency with an ESP32 over WiFi. However, a ZigBee button should be pretty low latency already.
Anecdotally I get perceptibly instant response from an ESP32 over WiFi.
Perceptibly instant is fast enough for me :)
What’s the method you’re using to communicate with HA?
Im guessing the latency here isnt zigbee, but the two cloud components that follow the button.
All my zigbee devices respond pretty much instantly. And that’s a 2 way trip. Button to HA, HA to lightswitch.
What happens when you trigger the same action from the dashboard? Is it faster?
It’s probably marginally faster from the dashboard. This isn’t only about the ZigBee delay though - it’s really perfectly OK. Reducing latency is as much for the fun of it than anything else. I’m interested in knowing what the fastest possible input method is.
What about binding the trigger to the device using something like Zigbee2MQTT so that it doesn’t have to pass through HA at all?
Theoretically, MQTT would be faster than HTTP; with MQTT the clients all maintain a persistent connection to the server, so sending a message is just a case of sending another packet on the existing connection, where as HTTP in the worst case would require a DNS lookup, TCP connection setup and TLS handshake before the button press could be reported.
The downside of a persistent connection is you have to maintain a persistent connection - not an issue if you are hardwired, but for things in batteries it probably isn’t practical
I have a wired device sending HTTP POST updates very regularly (often more than one per second) and if I watch those arrive, they appear almost instantaneous. If the sending device used IP (or, more likely, had cached the lookup) I guess that would be fast too.
Good point about the MQTT persistence, cheers.
Practically it doesn’t make any real difference - unless your network is ancient/massively overloaded/completely screwed or your client device is low power enough to struggle with TLS the whole connection setup process is only going to take ~100ms at most
OP asks for “lowest latency” but HTTP is fast enough, and later in the thread says “perceptibly instant” is the goal. HTTP is going to be your slowest option, almost certainly, but even the slowest solution is “instant”.
What exactly are you trying to do, OP?
(Esphome seems like the answer you’re looking for. It’s faster than MQTT and you can program parts of the automation and service management in the ESP hardware. RF is probably the only way to go faster.)
I’m interested in what other people have found to be the fastest way to deliver events into HA. It’s been a useful thread.
I don’t think that MQTT could add any perceptible latency. Maybe is the button itself that adds it. Isn’t the button able to recognize multiple pushes? If yes, there lies the delay: the button waits for a second push and if it doesn’t arrives, it sends out the command to the coordinator. What kind of ZigBee button are you using?
That’s a good point; the button does support double push, I might be able to disable that. It’s some old unit I picked up for next to nothing, I have some Aqura buttons about to try.
Zigbee is for this usecase instant and definitely faster than any ESP wifi based solution. Your slowness here isn’t for reaching HA, it’s HA itself and primarily pushover and Alexa. What is it you are trying to do? For anything that should feel instant, getting rid of pushover and Alexa will be crucial.
