es8266 (itead sonoff) hanged after flashing

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
torwag
Posts: 220
Joined: Fri Dec 13, 2013 9:25 am

Re: es8266 (itead sonoff) hanged after flashing

Post by torwag » Wed Sep 27, 2017 2:30 pm

Hey Peter,
sorry for being quit on this for a longer period.
Nice to hear you had more success with the new modules. I will go an order some to compare your findings.
Would be really nice to see what is the exact difference between the different generations.
We might be able to ask the vendor. Sometimes they are responsive within their product comment sections.
However, I believe that a schematic does not help us a lot, unless they notice a problem by them self and fixed it. The detailed problem description you gave us sounds like it was not a missing or defect component but more a problem of placement, tracks and noise levels.
If I get the new units I will let you know my findings.

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

A final report

Post by pythoncoder » Sun Oct 01, 2017 5:36 pm

Unless someone else makes a breakthrough I'm shelving the Sonoff. Some of the following is a repetition of observations I've reported before, but I thought it worth gathering the key observations in one place before moving on. This is the current state of play.
  • I abandoned the old units as I couldn't achieve stable operation. Comments below are for my two newly purchased units.
  • Testing was done under 230VAC power with no other electrical connections to the units.
  • Both units ran identical code and firmware. Code is at https://github.com/peterhinch/micropyth ... ter/sonoff.
  • The key asynchronous MQTT library is here https://github.com/peterhinch/micropyth ... mqtt_as.py. This library has been extensively tested on various ESP8266 modules using the metal-cased chip. On such modules it is tolerant of wifi and broker outages recovering gracefully when connectivity resumes. It has some unpleasant Sonoff-specific hacks described below.
  • One unit was unreliable even when in the same room as the AP, registering and recovering from spurious WiFi outages before eventually crashing.
  • The other "good" unit was stable in the same room as the AP, running for 45 hours until physically unplugged. Note that this unit never reported a WiFi outage in that location.
  • The "good" unit's range was very poor, failing to connect in many rooms where other devices have no problem.
  • The "good" unit completely failed to connect in my kitchen, a location I've used for much testing because of the presence of an excellent Faraday Cage in the form of a microwave oven. The WiFi signal there is so strong that it was hard to force the other boards to disconnect. Putting them in a metal tin was inadequate. Only the microwave with door locked closed would force a disconnection. Yet this heap of ordure never saw a signal.
This means that for my purposes even this "good" unit is unusable :( Further observations:
  • Early units were sensitive to grounding arrangements, working better when the isolated gnd line was connected to mains earth and when the unit was mounted on a groundplane. I have not repeated these tests with the new units.
  • The above and the abysmal range of the new units are suggestive of hardware design issues.
  • To get even this level of reliability required changes to the asynchronous MQTT library. These consist of issuing delays to yield to the underlying vendor code. This is a repulsive, ad hoc and arbitrary hack. In the course of a great deal of work with boards like the reference board and the WeMos D1 Mini such delays were never required; the code for standard ESP8266 devices, though rather involved, can be justified. I'm unwilling to write code involving empirical hacks but would welcome a PR with Sonoff specific hacks if it achieves reliability.
  • The sharp-eyed will notice similar hacks for the ESP32. These were done to provide the developers with some clues as to how to improve the port (reported on GitHub issues #166 and #167). I hope to remove the hacks as the (experimental) port improves.
I intended documenting this code but I'm loath to encourage anyone to use the Sonoff unless they are prepared to invest a great deal of time on an uncertain outcome.

There ends a long and sorry story. I hope others have more success.
Peter Hinch
Index to my micropython libraries.

chrismas9
Posts: 152
Joined: Wed Jun 25, 2014 10:07 am

Re: es8266 (itead sonoff) hanged after flashing

Post by chrismas9 » Mon Oct 02, 2017 11:13 pm

Hi Peter,
I had a look at the PCB photos on the itead website. The Sonoffs seem to have very poor power routing and bypass cap location. The bypass caps are too far from the chip and connected with long thin tracks. I imagine the power pins are noisy, especially during RF bursts. I can't see a way to fix them.

Chris Mason

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

Sonoff basic R3

Post by pythoncoder » Sat Nov 30, 2019 8:20 am

This is Itead's new WiFi inline mains switch. At last Itead seem to have fixed the design. The electronics have been radically redesigned with the ESP8285 on a mezzanine board - the changed dimensions requiring new plastic mouldings. The fact that they went to these lengths suggests they knew the design was unsatisfactory.

This version has good WiFi range and reports RSSI values similar to a Pyboard D/ESP8266. So far it's clocked up ~24 hours running asynchronous MQTT with no WiFi outages or MQTT retransmissions.

I have written a brief guide to connecting an FTDI adaptor and installing MicroPython (requires soldering).

Given that this device uses mains voltages please avoid it unless you have the requisite skills/qualifications.
Peter Hinch
Index to my micropython libraries.

Post Reply