ESP8266: this thing actually works now!

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
User avatar
pythoncoder
Posts: 3651
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

ESP8266: this thing actually works now!

Post by pythoncoder » Mon Jun 12, 2017 5:19 pm

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 ;)
Peter Hinch

slzatz
Posts: 92
Joined: Mon Feb 09, 2015 1:09 am

Re: ESP8266: this thing actually works now!

Post by slzatz » Mon Jun 12, 2017 6:48 pm

Would be interested in the code you're running if you're able to share. Thanks.

User avatar
pythoncoder
Posts: 3651
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: ESP8266: this thing actually works now!

Post by pythoncoder » Tue Jun 13, 2017 3:26 am

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...
Peter Hinch

photoacoustic
Posts: 24
Joined: Mon Apr 27, 2015 8:25 am

Re: ESP8266: this thing actually works now!

Post by photoacoustic » Wed Jun 14, 2017 4:06 am

Thanks for this post and testing.
Very interesting experience.

tknp
Posts: 5
Joined: Sun Feb 19, 2017 6:26 am

Re: ESP8266: this thing actually works now!

Post by tknp » Sun Jun 18, 2017 5:30 am

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!

User avatar
pythoncoder
Posts: 3651
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: ESP8266: this thing actually works now!

Post by pythoncoder » Mon Jun 19, 2017 8:28 am

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.
Peter Hinch

User avatar
pythoncoder
Posts: 3651
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: ESP8266: this thing actually works now!

Post by pythoncoder » Fri Jun 23, 2017 10:27 am

tknp wrote:... Looking forward to the asyncio compatible mqtt code as well!
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.

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

Post Reply