Thank you @Damien, @pfalcon - you guys have evidently put in some serious work on this.
Last year I attempted a project viewtopic.php?f=16&t=2525, aiming to bring MQTT to the Pyboard via an ESP8266. I never achieved acceptable reliability in the next room from the AP; if I ventured outdoors it was hopeless. After a lot of effort I abandoned it, putting this down to my inexperience with networking. I encountered every possible error condition ranging from ESP8266 crashes to permanently blocking read and write sockets and hangs in the MQTT protocol.
Expecting a frustrating few days I revisited it, adapting it to use uasyncio. The experience is utterly transformed. It's now been running for 6 hours from our shed at the limit of usable WiFi range. My code issues a hardware reset to the ESP8266 in the event of a crash or lockup reporting back when comms are re-established: in the 6 hours this never occurred. I've only seen one ESP8266 crash in countless hours of testing over several days.
I'm still a networking novice but it seems you don't need to be a guru to use it now
ESP8266: this thing actually works now!
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
ESP8266: this thing actually works now!
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: ESP8266: this thing actually works now!
Would be interested in the code you're running if you're able to share. Thanks.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: ESP8266: this thing actually works now!
Will do, but the API requires work and docs written so it's 2-4 weeks off. I left it unfinished last summer as the MQTT link was so unreliable. It does have my full attention again
Still running at the limit of WiFi after 15 hours, publishing every 10s and accepting a subs every 5s. No auto-reboots of the ESP...
Still running at the limit of WiFi after 15 hours, publishing every 10s and accepting a subs every 5s. No auto-reboots of the ESP...
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
-
- Posts: 24
- Joined: Mon Apr 27, 2015 8:25 am
Re: ESP8266: this thing actually works now!
Thanks for this post and testing.
Very interesting experience.
Very interesting experience.
Re: ESP8266: this thing actually works now!
Glad to hear you got something working. I seem to recall reading about the mqtt issues you had a while back. Looking forward to the asyncio compatible mqtt code as well!
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: ESP8266: this thing actually works now!
I've posted some code https://github.com/peterhinch/micropython-mqtt.git. The docs are a work in progress but there's more than enough to use the library. Feedback welcome!
@tknp As it stands the project uses an ESP8266 running a binary firmware image to act as an MQTT gateway to a board running MicroPython. The MicroPython host sees an asynchronous MQTT interface. But internally the ESP8266 uses the standard umqtt library (with a trivial modification via subclassing).
A true asynchronous implementation of umqtt is a different project and something that interests me very much and I may well attempt it. This would enable event driven MQTT code on the ESP8266.
@tknp As it stands the project uses an ESP8266 running a binary firmware image to act as an MQTT gateway to a board running MicroPython. The MicroPython host sees an asynchronous MQTT interface. But internally the ESP8266 uses the standard umqtt library (with a trivial modification via subclassing).
A true asynchronous implementation of umqtt is a different project and something that interests me very much and I may well attempt it. This would enable event driven MQTT code on the ESP8266.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: ESP8266: this thing actually works now!
I've made progress with this. I have an asynchronous version of umqtt.robust which has survived testing so far. But I'd be interested to hear comments from yourself or anyone else on this issue.tknp wrote:... Looking forward to the asyncio compatible mqtt code as well!
I don't think that umqtt.robust handles qos == 1 publications in an optimal way, considering the fact that WiFi is inherently less reliable than wired networks. Currently, having published, it blocks forever waiting for a PUBACK. (My alpha version does the same, but with only the coroutine blocking). From my understanding of the spec it should periodically re-transmit the publication until a PUBACK is received. I'm keen to implement this.
A qos == 1 publication engaged in periodic retransmission and awaiting a PUBACK can be considered "pending". By definition qos == 0 publications are never "pending", and qos == 2 is unsupported.
The most likely cause of "pending" is the device moving out of range of the AP. Other causes such as a broker outage are equally drastic. So I think it's reasonable for publications and the ability to respond to subscriptions to be disabled while a publication is pending. This would enable a more efficient design. What does the team think?
Secondly, is there any view on how long to pause between retransmissions?
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.