Is it possible to include the uqmtt package (simple & robust) in the list of built-in modules? The ESP8266 builds include umqtt. This change would eliminate the step of installing umqtt into the ESP32 uPy filesystem from micropython-lib.
thanks!
Yes that makes sense to do. The esp32 has enough flash that it can include by default a bunch of components, to facilitate a good user experience. And there's always the option for the user to build their own firmware to freeze in other modules.
Love this, this will be very appreciated.
I wouldn't want to pollute the build, but to me, any lib that was deemed acceptable (included) for the ESP8266 should also be included in the ESP32 build.
I also found that umqtt (both flavors) were missing, but if there are other libraries that are included on the ESP8266 and not on the ESP32, they should also be included.
umqtt was added to esp32 frozen modules in 34b2f6b6fc817e2ea0e253eedbee080895b89deb
@MikeTeachman @AlexDanault @dpgeorge
For what it's worth I think the MQTT implementation is deeply broken: by assuming a perfect LAN it fails to take account of the physical limitations of a wireless link. I found it unusable in practice even over short range. It held up for a few hours at most.
See this repo for justification of this view and for an asynchronous "resilient" solution. I suspect the code could be simplified - but testing changes to it under different radio propagation conditions, along with broker fail, slow broker response and AP fail scenarios is very time consuming.
An official solution would be good.
I agree that the existing MQTT implementation is not fully industrially hardened. I've added my own attempts to recover from WiFi problems and MQTT broker outages. Typically, I use MQTT in deep sleep applications where a unit wakes, takes some sort of sensor measurement and then publishes to a broker. My recovery method is pretty weak - for all exceptions I just send the unit back to deep sleep and then it resets on the wake-up. But, that results in a missed data point. I'm looking forward to trying the async resilient solution. For Makerspace classes I teach, the built-in MQTT is convenient (in spite of shortcomings) as participants don't need to install any modules, and they only need up-time in minutes, not months.
Most helpful comment
@MikeTeachman @AlexDanault @dpgeorge
For what it's worth I think the MQTT implementation is deeply broken: by assuming a perfect LAN it fails to take account of the physical limitations of a wireless link. I found it unusable in practice even over short range. It held up for a few hours at most.
See this repo for justification of this view and for an asynchronous "resilient" solution. I suspect the code could be simplified - but testing changes to it under different radio propagation conditions, along with broker fail, slow broker response and AP fail scenarios is very time consuming.
An official solution would be good.