MicroPython Forum (Archive)

In the last days I adquired three itead sonoff devices. I managed to flash one of them with the following procedure:

esptool.py --port COM5 erase_flash
esptool.py --port COM5 --baud 460800 write_flash --flash_size=detect 0 esp8266-20170823-v1.9.2.bin

after rebooting I got the REPL prompt over Serial COM5 with no issues.

On the apparently identical two other sonoff I followed the same flashing procedure and flashed them with no errors. However, after rebooting, I couldn't get the REPL prompt over serial and no wifi network was published.

I ran the verify_flash option of esptool.py and got:

esptool.py v2.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Flash params set to 0x0020
Verifying 0x92c30 (601136) bytes @ 0x00000000 in flash against esp8266-20170823-v1.9.2.bin...
-- verify OK (digest matched)
Hard resetting...


I also tried several baud rates, several binaries (old ones) and always flashed correctly with zero success.

Finally, I ran the command flash_id (esptool.py --port COM5 flash_id) on the working device and I got:

esptool.py v2.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Manufacturer: e0
Device: 4014
Detected flash size: 1MB
Hard resetting...

However on the non working devices I got:

esptool.py v2.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Manufacturer: 5e
Device: 4014
Detected flash size: 1MB
Hard resetting...

The manufacturer is different!

Sooo apparently micropython works on devices with manufacturer e0 but not on devices with manufacturer 5e?

Any hints on this? Might be posible that some sonoff devices cannot be flashed with Micropython?


Thanks in advance,

ok, after long investigation I managed to make it work using these parameters to flash.

esptool.py --port COM5 write_flash -fs 1MB -fm dout 0x0 esp8266-20170823-v1.9.2.bin

It looks that the "-fm dout" made the magic.

Hope this can help to others...

I would be very interested to hear more of your experiences with these devices. I've spent a considerable amount of time trying to get them to work reliably with MicroPython and failed miserably. I've concluded that they have a hardware issue.

A simple script to flash the LED will run indefinitely. But code which periodically uses the WiFi will run for perhaps 10-15 minutes before crashing. Typically my application will first behave as if WiFi had failed. Occasionally it will behave as if connectivity was restored. But then it will lock up completely before 15 minutes is up. The same code, running under the same firmware build, will run indefinitely on the reference board.

To eliminate all possibility of a coding fault on my part I ran my simple LED flashing script and pinged the Sonoff from a PC for 30 minutes. I repeated the test with the reference board. The Sonoff average response time was 29 times longer than that of the reference board The worst-case response was 3 times longer at 1.77s.

These tests were done with the Sonoff running from 240V mains power with no other physical connections.

I did a good deal of electrical testing. I can find no fault with the Sonoff power supply but I suspect an RF problem. Run times are improved if the 0V is connected to mains earth and the unit is run on an earthed groundplane. But even in this configuration reliability is hopeless. To eliminate the possibility of PSU problems I tried powering it from a 2A bench supply to no effect. I've used two Sonoff units; both are equally bad.

However another user (@torwag) has experienced none of these issues and can run my code https://github.com/peterhinch/micropyth ... /sonoff.py indefinitely without issue.

This is all very puzzling but I've reached a dead end and can't see any way to use these units.

Hi,

as Peter mentioned, we invested a lot of time into these units (Peter much more then me).
My last investigation was about the ping times, since Peter mentioned considerable long reply times.

On my unit, which worked without issues, running the unit on REPL (thus, it was not occupied with any CPU-intensive task), I observed very long ping times too.

EDIT:
64 bytes from 192.168.3.17
100 packets transmitted, 56 received, 44% packet loss, time 99784ms
rtt min/avg/max/mdev = 5.074/47.972/103.324/25.348 ms

48ms in average is rather long


What I still remember is a packet loss of about 40-50%. This surprised me. The connection to the router was not the best, distance was about 20m with walls in-between. But I was expecting a better result. Esp. as my experience with the ESP showed good connection quality.

However, that still does not explain, why my units run stable for hours whereas Peter's unit crash within a few minutes...

Would be good to get a third reference here.

torwag wrote:...Would be good to get a third reference here...

It would indeed.

It's interesting that we're both seeing a difference in ping response between the Sonoff and other ESP8266 modules. This is another hint at hardware issues. I'm not experiencing packet loss but the testing was done in the same small room as the AP.

Alas I'm completely stumped by this issue and find the Sonoff unusable. So I've moved on to other things but I'm very interested to hear other peoples' experiences.

Two attempts of 100 pings, Wemos D1 mini.

--- 10.0.0.162 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99126ms
rtt min/avg/max/mdev = 1.844/2.415/6.839/0.806 ms

After reboot
--- 10.0.0.162 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99138ms
rtt min/avg/max/mdev = 1.925/3.403/7.449/1.435 ms

For comparison: ESP32 Thing with the mp.org ESP32 build:
--- esp32 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99141ms
rtt min/avg/max/mdev = 3.171/6.048/20.212/2.503 ms

Lopy with the Pycom.io build:
--- lopy ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99145ms
rtt min/avg/max/mdev = 2.158/2.830/23.923/2.263 ms

Edit: Some more tests:

ESP12:
100 packets transmitted, 100 received, 0% packet loss, time 99138ms
rtt min/avg/max/mdev = 1.411/3.654/58.398/5.670 ms
The 58 ms was the first ping. All following ones were in the range of 1.3 to 7 ms

ESP01:
100 packets transmitted, 100 received, 0% packet loss, time 99146ms
rtt min/avg/max/mdev = 3.267/7.376/93.913/13.094 ms

Huzzah Feather 8266:
100 packets transmitted, 100 received, 0% packet loss, time 99139ms
rtt min/avg/max/mdev = 1.776/6.536/107.307/15.267 ms
The first five Ping responses were between 50 and 107 ms, the in a range of 2 - 10 ms.

Assuming your tests were all in the same location the Sonoff evidently has issues, especially the 44% packet loss. It has dramatically worse average response time than the other ESP8266 platforms. ESP32 results are interesting but I rather discount them for benchmarks as the firmware still has development status.

My results remain worse in terms of average/max response time, although I had minimal packet loss doubtless because the boards were so close to the AP. My problems running code which actually uses the WiFi remains a mystery.

To add to this miracle:

Other projects seem to happily use the sonoff units. I searched but could not find any similar issues or threads for that matter.
E.h. espeasy seems to supports them. However, the sonoff units had several hardware releases. I believe I still use an early version and I know Peter has two early versions.
Maybe the newer versions dealt with this problems.

On the other hand. The stock firmware does not much difference compared to what we are doing (establish a wifi connection, send and receive a minimal amount of data with dedicated server). If this would result in hangups and crashes, there would be a huge shout-out in the communities and they would have been abandoned already. Thus, indeed it reminds to be a miracle ....

It's entirely possible that it's only me who has a problem. However I've done a great deal of work over the last six months with MicroPython on a variety of ESP8266 boards with no hint of fundamental stability issues. A WeMos D1 Mini will run my code indefinitely while the Sonoff running the same firmware and application code is unusable. If I have a site-specific problem it seems to be aimed with laser precision at that one hardware platform.

I've given the Sonoff my best shot as I'd really like to see them working reliably. I've taken the utmost care with my experimental technique, tried everything that's been suggested plus ideas of my own; I honestly can't see what more I can do. Short of building my own Sonoffs from D1 Minis which I'm considering.

Incidentally I never did get a REPL from the two new ones I bought.

My position is to await feedback from other people running MicroPython on Sonoff units.

tl;dr New design Sonoff units can work reliably.

I decided to give some time to the two new Sonoff units which I'd largely ignored to date. Getting a REPL proved straightforward. I powered the unit from a 3.3V bench PSU, linked it to a PC with a 3.3V FTDI converter and issued the following: Note the -fm dout - this was essential.

My asynchronous MQTT library https://github.com/peterhinch/micropyth ... /README.md needed a minor fix to enable the Sonoff to recover from a WiFi outage. For some reason the loop which waits for is_connected() status needs a utime.sleep_ms(10) delay. A uasyncio delay (which works on other ESP8266 platforms) sometimes yields an indefinite hang waiting for DHCP. There is evidently an issue with yielding to the vendor stack; I wonder if this differs between units with a bare chip and those with a metal-cased ESP8266 module?

There remains a big difference between old and new units. I cannot get remotely reliable results from the old units which have various instabilities while running my code. I can see one minor difference in the hardware but without access to old schematics it's hard to comment. I wonder if there is also an issue with the old vendor stack. Does this ever get updated?

The new units still suffer from occasional - about once an hour - WiFi dropouts. The driver code ensures automatic reconnection within under a minute (so far). It's possible these dropouts could be fixed by issuing further explicit yields to the vendor code but figuring out where to put them is largely guesswork Yields are not required on other platforms I've tested.

So I now have Sonoffs which work with MQTT. The LED and relay respond independently to incoming commands. Button presses, long presses and double-clicks send MQTT messages. An IR decoder chip can be added. This enables buttons on a remote control to transmit MQTT messages. https://github.com/peterhinch/micropyth ... /sonoff.py This rather lacks documentation and it may be a week or so before I can address this.