Sonoffs behaving badly... MppArduino now 1.11

[Mike P 4 MPP]

Had a merry old time today trying to figure out what was wrong with my older sonoff MppRelays and a NodeMCU.  Once updated to MppArduino 1.10.x (based on ESP8266 v2.6.3, espressif core 2.2.2) they refused to connect to the router, complaining of AP not found and/or beacon timeout, or just sitting in limbo and never accepting the DHCP assignment.  Oddly enough if I installed MppDevice they'd work fine, and would work ok with a few other binaries like MppSonoffTH.  Backing them up to build with 2.4.2 / espressif core 2.2.1 and they're back to stable.  I still don't understand why... but I don't have any way to figure it out or fix it anyway...

I'm going to post MppArduino 1.11 based on 2.4.2 shortly, don't install 1.10.x to the original sonoffs or older devices.

[Lone Surviver]

In my  previous life, whenever we encountered unexplainable occurrences, we would always default to "It must have something to do with why dogs bark and pigs squeal." 'Nuf said.......

[DougC]

Interesting. Mike can you define 'older'?

Because of my fiddling around with MppGateway I've got several other devices already at 1.10.x. Some of these are what I take to be Sonoff Basic R1 with MppRelay. I have seen a fair few wifi oddities along the way, but not quite what you've seen.  

[Mike P 4 MPP]

Not sure about the age, years old though, the oldest ones I have.  Definitely the Sonoff basic, almost certainly sonoff R1s.

 

The odd thing is they’ll run – connect, operate the relay - with SonoffTH, and will connect with MppDevice.  But as soon as I install MppRelay built with 2.6.3 they won’t connect and I need to put them on USB to change them back to 2.4.2.

This (from the "Info" button) works: 

  SDK:2.2.1(cfd48f3)/Core:2.4.2/lwIP:1.4.0rc2/BearSSL:6d1cefc

and this does not: 

  SDK:2.2.2-dev(a58da79)/Core:2.6.3=20603000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-16-ge23a07e/BearSSL:89454af

Very repeatable which I did many times because I couldn't believe it at first - figured my network was infected with gremlins and spent a while trying to exterminate them...  But it's an odd enough problem that I could see it differing in other devices (presumably different ESP8266 chip versions).  SonoffPOW and SonoffTH run just fine, but I have one NodeMCU 0.9 with the same symptoms.  Other devices like an ESP8285 wall switch (thank goodness, what a pain to flash with USB) run just fine too.  Luckily the sonoffs were spliced into power cords so relatively easy to get at.

Until I can figure it out, 1.11 is built on 2.4.2 except for devices using PWM (MppBulb, MppColor, and MppPWM) - 2.4.2 has a bug where wifi communication causes flickering in the PWM timing, fixed in 2.6.3.

[DougC]

I must try that out. 

[DougC]

I've tried out MppRelay 1.1.0 at version 1.10.3

I've put it on my oldest ESP-01 (no info visible) and Sonoff Basic (says 2017-5-5 on its PCB). Both items are from an order I made January 2018.

No fault found

Only thing I noticed was that displaying Info I got

SDK:2.2.2-dev(38a443e)/Core:2.6.3=20603000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-16-ge23a07e/BearSSL:89454af

which differs slightly from what you had. But I don't understand the significance

Sorry Mike, I fear you are suffering from Lockdown Induced Paranoia :-)

[Mike P 4 MPP]

LOL, I just *knew* you all would think I'm paranoid!

Actually it's not a complete surprise, problems like this can be very odd...  As soon as it worked for MppDevice.bin but not MppRelay.bin I knew I was in for a rough day...  and working with MppSonoffTH (just the relay part) really has me scratching my head (and trying the same binaries over and over).

The number difference is from trying different fix releases of the espressif SDK - the arduinio build configuration gives a choice of 4 or 5 different versions and I tried them all.

If you get a chance and don't mind, please give 10.3 a try and use "eraseConfig" from the USB command line, set the AP again, and restart - that is one difference in this latest version (it does it automatically now).

I've tried many things so far - erasing the entire chip, re-loading the wifi config bin (though I'm pretty sure that's no longer necessary), and couldn't find a way to make 3 different older sonoff basic's work with 2.6.3 :(.

[Mike P 4 MPP]

Found one of my "newer" sonoffs and flashed 2.6.3.  It acted a bit odd after the first flash, but this one I can swap back and forth and it keeps on working.  So definitely something with the very old sonoff R1s that they must have changed.

There's some sonoff basic descriptions of R1,R2,R3 here: https://tasmota.github.io/docs/devices/Sonoff-Basic/.  Mine are all R1.

The ones that aren't working came with cases with black lettering, while the one that is has amber/yellow lettering for "Sonoff" and "in->out".  I suspect a difference in chip versions but I'm not sure how to find/confirm it.

Fer sure there's something funky...  if I flash 2.6.3 into the amber version and then set the wifi SSID/pw (which now does an eraseConfig) after a power cycle there's often a hiccup in the connection ("AUTH_EXPIRE") before it connects, and it will occasionally miss incoming requests (so AM reports a timeout).  This is vs 2.4.2 which appears more solid.  I wonder if there's a difference in how the RF tuning parameters are set between the two versions?

[DougC]

Mike, I just can't create this fault. My oldest Sonoffs are definitely R1 (still  using solder traces for the HT) All the writing on the case is black. In fact the case looks identical to My R2 Sonoffs except they also have CE printed on them. I have some R3 Sonoffs and they are different again, inside and out.

So my R1 Sonoffs sound superficially similar to your ones that have the problem. Never seen one with amber lettering. Seems probably your R1s are older than mine though - but are they different?

Inside, the printing on the board is

Sonoff TH_V1.1

2017-5-5

Ironically perhaps, mine don't have the QDPASS sticker

[Mike P 4 MPP]

Very odd - I'd suspect my router but it's only if I switch to 2.6.3, I can change to other routers and back to 2.4.2 and it only seems to show on 2.6.3 but on all of my routers.

The amber lettered device does misbehave, but not every time - about 1 in 6 or so restarts and it will fail to finish connecting, occasionally showing odd things like auth error and beacon timeout.

It seems to fall into two different behaviors, esp for the older sonoffs - it often takes multiple restarts to connect and/or it fails or struggles to connect once out of every half dozen or so restarts.

The other behavior is that even if connected, the 2.6.3 devices will timeout 1 to 6 or so times per hour, showing up as "SocketTimeout"s in the AM log.  The amber sonoff will do this once it connects, and I have another device running MppBulb (where I must run 2.6.3) and it drop with a timeout 1-6 times per hour too.  Both will recover after a short time and come back online.

It's like the RF is not tuned properly and doesn't see requests.  On startup the failure to connect is often that they don't get an IP even though they see and show as connected to the AP - like they're not seeing the DHCP assignment messages.

[Mike P 4 MPP]

Looks like there are a few types of R1 boards - my amber one is marked "Sonoff TH" with no date so presumably earlier.  No pass sticker on my amber either.  I think my black lettered ones had stickers and were called just "Sonoff" (no TH), but they're closed up so I can't easily double check.

[Lone Surviver]

I just read an article about changing clock speeds....and this problem seems to be having that odor.

read at your leisure

https://hackaday.com/2019/01/04/underclocking-the-esp8266-leads-to-wifi-weirdness/

My limited knowledge had me wondering about the architecture of the flash memory, and if a stack of memory cells are failing. My experience with Chinese pirating of memory always makes me suspicious.

Maybe the chips need a Neuralizer....

[MikeP 4 MPP]

I think I've figured out what's happening here with the different behaviors - I was playing around with one trying to get it to manage an access point and it wouldn't connect.  So I pulled it apart and tried to trace why on USB.  Turns out it would always connect when powered by USB but would take make tries to connect when plugged in.  Seems to suggest power supply noise (esp since I noticed on USB my RF receivers run well with a long range, but as soon as I plug them into a USB charger they struggle to hear the RF signal unless the transmitter is very close).  Could be just the older sonoffs due to the parts used, or maybe just the aging of the parts.

[MikeP 4 MPP]

This is a really tricky problem that does seem to come and go...  I did find one of my old sonoffs that just wouldn't work even on USB.  There's a feature in the ESP8266 espressif firmware where you can configure what the wifi chip does on power up - default is a partial calibration because it uses less power (better for battery devices).  They recommend for powered devices that setting be changed to "full" which I think also updates the wifi calibration settings in the flash.   The latest library supports that function - you can access it via USB using MppArduino, or using a browser with the new remote command feature:

   .../command?run=cal full 

[MikeP 4 MPP]

To clarify, to run a command you use:

  ...:8898/command?run=cal full

or whatever other console command you'd like.

[MikeP 4 MPP]

See the latest firmware and MppArduino update - you can now use MppArduino to connect directly to MppDevices running the latest firmware over wifi/tcp.  This lets you examine the output and use commands on devices even if they're not available over USB (e.g. use the "cal full" command).

[DougC]

Well these Sonoffs are a problem that refuses to go away. Or rather a whole set of problems with Wifi particularly.   I have let my firmware versions remain pretty much un-updated on many devices for a few years. But I wanted some new functions so I started to work through my devices.

I have a Sonoff basic V1 that was probably on 1.11.6 code with MppRelay 1.1.1 running. Updated the firmware which took it to 1.12.4 code and MppRelay 2.0.1.  Wifi just wouldn't stay up. Beacon timeouts etc etc. Had to connect to serial to reflash it.

I realised I had an 'identical' Sonoff that was already on 1.12.0 code and working fine, so I updated that to 1.12.4 to see if I got the same result. That was bad too, but possibly in a different way? Anyhow I ended up reflashing that one too.

So to my question then...  

It feels like I want to try 1.12.0 code on both these devices. But I don't think I ever downloaded or saved the MppPublish for that. Is there an archive repository of all this stuff that I can get access to ? Could there be?

[trogli...@gmail.com]

I just uploaded MppPublishv3.zip in the download section.  It’s the first library that had 1.12.0.  MppRelay was 2.0.0 by that time but I don’t think that’ll matter.

I have access to old versions on google drive, but they warn they’re not permanent.  It’s not something needed often enough that I’d want to bother making externally accessible.

 

FWIW I’ve tried many versions of libraries with my crappy sonoffs before giving up on them.  I think they’re just crappy…  If you take the problematic version of the binary and run it in a different device (wemos or nodemcu) I bet it works just fine.  When I take a problematic sonoff and power it through my PC/USB and monitor with MppArduino it also runs just fine.  But as soon as I put the crappy thing back together and power it from the wall, it won’t stay connected.  Frustrating…

 

Those errors from the wifi chip are coming from the espressif library, if you do suspect it’s broken in a later library you could always try building with back level espressif versions to see if that changes anything (BTDT, it didn’t).

--
You received this message because you are subscribed to the Google Groups "MppDevices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mppdevices+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/9930c090-427c-4145-bbb5-1f16180d5fben%40googlegroups.com.

[DougC]

Thanks for that Mike. I know -comparing the value of the human time spent trying to fix this vs the cost of just getting something less crappy as a replacement should be a no brainer. However that would just be too logical.