OttoWinter
commented
5 years ago there is around 3-4 seconds from when motion is detected to when an action is triggered by this.
Are you sure that's all because of the MQTT connection? At least for me MQTT connection times are pretty fast (only a few TCP packets are sent). My feeling is that most of this is due to WiFi connection times, I would appreciate some data on this.
Also, while MQTT-SN is kind of a nice idea, supporting it would be a real hassle (essentially it is a completely different protocol from standard MQTT, and thus would need a whole lot of code). Plus as far as I see, MQTT-SN has very little support - certainly mosquitto doesn't support it (not even speaking of HA).
Sounds like too much work for a slight bit of enhancement to me.
A better option (speaking way in the future here) would be to get the native API to work over UDP. That was always the initial idea but of course working with UDP is a lot more work than just a simple TCP connection.
deece
Some sensors live in a low power state, and only wake up when triggered (eg. https://github.com/brandond/esphome-tuya_pir ).
The overhead of connecting to the network, then connecting to MQTT and sending data can add quite a bit of latency, in the above example, there is around 3-4 seconds from when motion is detected to when an action is triggered by this.
The connection latency can be minimised by using fast_connect in the wifi settings, and a static IP, however, there is still significant overhead to establish the MQTT connection.
Supporting MQTT/SN (http://mqtt.org/tag/mqtt-sn) will eliminate the MQTT connection latency - the device can wake up, connect to the network, fire off it's UDP packets and go back to sleep, (optionally waiting for a response if QOS is set).
Add support for MQTT/SN.