Cannot pair anymore my 4ch pro r2

[draffa]

Hi All,
I can not pair anymore my 4ch pro r2. When I turn it on, the wifi led flashes very fast for about 2 seconds, then goes off for about one second, then resumes blinking and so on endlessy (blink-blink-blink-blink-blink-pause-blink-blink-blink-blink-blink). After power switching on, keeping pressed any button on the left side for 2 seconds (or more) does not cause anything, It always remains in the state just described. Is it broken ?? Any suggestions ??? Thank you !!

[Philip Knowles]

It sounds like it’s in AP mode. Try looking for a Sonoff-xxxx as a wifi access point.

 

Sent from Mail for Windows 10

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

[draffa]

Thank you for reply !

No any wifi SSID...

The blinking sequence is very strange (blinking very fast: FIVE blinks-1_sec_pause-FIVE blinks)

Pressing any R1-R4 keys have no effect. Holding down (for 2 seconds or more) R4 key (or any other key)  have no effect. The keys look stuck and WIFI led keeps blinking as described, RE-powering on, same as described...
Maybe it is broken...

[Phil]

hook it up to and power it from your flashing device, then you can connect a terminal emulator and read any serial output from the device.

Is this after a firmware update?  if when hooked up so you can monitor any serial output  do you get behaviour similar to attempts to connect to wifi without correct credentials followed by a 20-30 second attempt to establish a config AP which fails and prompts a restart and the cycle begins again?.  If so  then you may have fallen foul of the CFG_HOLDER config issue.

this can be fixed with a small edit to change the CFG_HOLDER property (its numeric so add 1 deduct 1 .. just change the number ) rebuild and flash again, Then to stop this happening again change the CFG_HOLDER property back to its original value rebuild and again reflash the sonoff.

I encountered this issue with both a 4chpro and a 4chpro2 (i ordered the 4chpro2 to replace the 'broken 4chpro. DOH!.)  and i have no recollection of ever making any edits to the cfg_HOLDER property in the user_config.h file whatsoever??  and as a few others have had a similar issue since i suspect a rouge source file found its way into distribution at some point ?? 

a google search using the terms "boot loop" and "sonoff tasmota" should point you at the wiki write up on this subject.

[Michael Ingraham]

A couple of words of caution...

1. Completely disconnect your device from mains power. 
   
2. If your flashing device (e.g., FTDI) connection still gives you issues, and your version of Sonoff 4Ch has an external DC power input, try using that to power your device rather than the power from the flashing device. Sometimes the current draw from 4Ch devices is too large for the flashing device to supply reliably.
   

If you decide to upload a new firmware file, first erase the flash memory.

esptool.py -p <comPort> -b <baudrate> erase_flash     

Michael Ingraham
Spartanburg, SC

[draffa]

Phil,I think you addressed me well!

I never flashed my sonoff (although I thought I'd do it soon). But I think the problem is just what you described: CFG_HOLDER config issue.

It all started when I tried to make it pair up with a new wifi network, perhaps by mistaken password or blank password.

Since then he has always shown the strange sequence of blinking wifi at power up.

I think then to proceed so not having a TTL / USB converter. I will use my raspberry to connect it and read the serial output to try to understand what happens.

So I will make a backup copy of the original firmware and make the necessary changes and then will reflash again.

If I can not make changes to the original firmware I will use the tasmota firmware.

Tomorrow I should have a NodeMCU module and I could try that too

I'll search more infos by a google search.

Thank you!

[draffa]

Excellent advice. Thank you !!

[Phil]

If your 4chpro is running the stock sonoff firmware then the cfg_holder config is NOT your problem, It can only become a problem for tasmota flashed devices that have had their source files edited namely the user_config.h file. 

I dont know if the stock sonoff firmware other than the RF bridge and SC versions makes any ise of the serial interface?

if running the stock firmware there is a forum hosted by itead that may be more help?

http://support.iteadstudio.com/support/discussions

to avoid further confusion what firmware is currently installed on your 4chpro?

[draffa]

Hi Phil,

thanks for the clarification and I'm sorry for the confusion I've created.

My 4chpro R2 (brand new) runs stock firmware but I can not tell you which version because I deleted the device from ewelink imagining that I should add it again to solve the wifi pairing issue. Now I do not know how to get firmware version info...

Yesterday I tried to access my 4chpro through the ESP or STM headers on the PCB. I used the two RX / TX pins ONLY and the 4chpro was powered normally (12V DC). I do not get any output from either the ESP or the STM header. Is it normal ?

I would like to understand why that infinite blinking wifi LED loop occurs at power-up and why it is not possible to reset the sonoff by holding down for 2 seconds one of the keys on the left when it is powered on. I was hoping to get some logs by accessing the headers on the PCB.

I guess there is a problem with the boot but I do not know how to proceed now...

[Michael Ingraham]

Even if you are powering the 4Ch via its DC power jack, you may need to connect ground for proper signal reference for the serial interface.

Not really knowing how the Sonoff factory firmware is set up, they could very well do something funky with the serial interface. Thus, even if the serial interface is properly connected, the firmware may set up the Tx/Rx for something else or simply "disable" them altogether.

Here are my notes on pairing with the eWeLink app back when I first started using Sonoff devices. Perhaps this will give you some ideas or options.

The first "long press (7 seconds)" mode of the device is referred to as "Quick Pairing" by the eWeLink app. The LED pattern is blink-blink-blink-pause-blink-blink-blink-pause... . The app will find the device (notification says something to the effect "found second generation device"), and then notify that it is registering the device.

If Quick Pairing fails, you can attempt "Compatibility" mode. To get the device into this mode (continuous fast blink), long press (7 seconds) the button until the blink-blink-blink-pause-blink-blink-blink-pause... pattern, release for a brief moment, then long press (7 seconds) again until it goes into continuous fast blink and release the button.

The DeviceID is the ID printed on the label on the relay inside the case. The DeviceID is also used in the device SSID ("ITEAD-<DeviceID>"). The DeviceID is a string like "1000xxxxxx". The eWeLink app default name is "MyDevicexxxxxx".

The device name announced to the router uses the MAC address in the naming - ESP_O4O5O6 (for MAC O1:O2:O3:O4:O5:O6), all upper case.

The only "hack" I've ever tried with the Sonoff firmware is to get it into AP mode, connect to it and then communicate with it using http websocket payloads. See:

https://github.com/mdopp/simple-sonoff-server

http://blog.nanl.de/2017/05/sonota-flashing-itead-sonoff-devices-via-original-ota-mechanism/

https://blog.ipsumdomus.com/sonoff-switch-complete-hack-without-firmware-upgrade-1b2d6632c01

I abandoned this method because ITEAD made changes to their firmware that is believed added some sort of encryption keys for some configuration fields. To my knowledge, that was not ever resolved. I mention this though because if you can get the device into AP mode, you may be able to see if it at least is communicating.

After all the "roadblocks" ITEAD kept putting up (and changing along the way), it was more foolproof for me to just flash the devices with TASMOTA. That gave me lots more options on interfacing and controlling the devices.

Regards.

Mike

Michael Ingraham
Spartanburg, SC

On Fri, Nov 9, 2018 at 2:33 AM draffa <dc.r...@gmail.com> wrote:

Hi Phil,

thanks for the clarification and I'm sorry for the confusion I've created.

My sonoff (brand new) runs stock firmware but I can not tell you which version because I deleted the device from ewlink imagining that I could add it again to solve this problem. Now I do not know how to get that information...

Yesterday I tried to access the sonoff through the ESP or STM headers on the PCB. I used only the two RX / TX pins and the sonoff was powered normally (12V DC). I do not get any output from either the ESP or the STM header. It's normal ?

I would like to understand why that infinite blinking loop occurs at power-up and why it is not possible to reset the sonoff by holding down for 2 seconds one of the keys on the left when it is turned on. I was hoping to get some logs by accessing the headers on the PCB. I imagine there is a problem with the boot but I do not know how to proceed

Il giorno giovedì 8 novembre 2018 22:36:23 UTC+1, Phil ha scritto:

If your 4chpro is running the stock sonoff firmware then the cfg_holder config is NOT your problem, It can only become a problem for tasmota flashed devices that have had their source files edited namely the user_config.h file. 

I dont know if the stock sonoff firmware other than the RF bridge and SC versions makes any ise of the serial interface?

if running the stock firmware there is a forum hosted by itead that may be more help?

http://support.iteadstudio.com/support/discussions

to avoid further confusion what firmware is currently installed on your 4chpro?

On Thursday, 8 November 2018 14:50:54 UTC, draffa wrote:

Phil,I think you addressed me well!

I never flashed my sonoff (although I thought I'd do it soon). But I think the problem is just what you described: CFG_HOLDER config issue.

It all started when I tried to make it pair up with a new wifi network, perhaps by mistaken password or blank password.

Since then he has always shown the strange sequence of blinking wifi at power up.

I think then to proceed so not having a TTL / USB converter. I will use my raspberry to connect it and read the serial output to try to understand what happens.

So I will make a backup copy of the original firmware and make the necessary changes and then will reflash again.

If I can not make changes to the original firmware I will use the tasmota firmware.

Tomorrow I should have a NodeMCU module and I could try that too

I'll search more infos by a google search.

Thank you!

Il giorno giovedì 8 novembre 2018 10:18:01 UTC+1, Phil ha scritto:

hook it up to and power it from your flashing device, then you can connect a terminal emulator and read any serial output from the device.

Is this after a firmware update?  if when hooked up so you can monitor any serial output  do you get behaviour similar to attempts to connect to wifi without correct credentials followed by a 20-30 second attempt to establish a config AP which fails and prompts a restart and the cycle begins again?.  If so  then you may have fallen foul of the CFG_HOLDER config issue.

this can be fixed with a small edit to change the CFG_HOLDER property (its numeric so add 1 deduct 1 .. just change the number ) rebuild and flash again, Then to stop this happening again change the CFG_HOLDER property back to its original value rebuild and again reflash the sonoff.

I encountered this issue with both a 4chpro and a 4chpro2 (i ordered the 4chpro2 to replace the 'broken 4chpro. DOH!.)  and i have no recollection of ever making any edits to the cfg_HOLDER property in the user_config.h file whatsoever??  and as a few others have had a similar issue since i suspect a rouge source file found its way into distribution at some point ?? 

a google search using the terms "boot loop" and "sonoff tasmota" should point you at the wiki write up on this subject. 

--

[Phil]

Dont worry about the mix, up with a name like SonoffUsers your not the first to ask about stock sonoff firmware issues and wont be the last. (Its how we attract folk to the 'dark side' hehe)

Hopefully Mikes post will help you re-establish contact with your device, you may want to try using a 2nd phone with the ewelink app freshly installed, or at least check for ewelink updates on your phone, and if you dont have too many devices perhaps reinstall the app.  Also have you made any recent security changes to your network with respect to wifi access, some routers allow you to mac filter and stop wifi access to devices you have not expressly given permission to for example. (when in doubt, reboot the router..)

With the stock firmware from sonoff on the device, there should be some coms over the serial interface between the esp soc and the RF STM, however i am far from expert in this area and i am basing this guess on reading other peoples work with sonoff SC and sonoff RF bridge devices.  However at what baud rate, parity, and if any encryption or encoding is used is all unknown to me at least.  So not hitting the target when blind isnt a solid indication of death imho. 

But now we have your attention check out the tasmota wiki and see what you can achieve without reliance on remote brokers and servers.  While i dont think the current issue of not being able to use the app to connect to your device is related to server service failure there have been periods of days here in the UK where itead/sonoff server failure has resulted in loss of app-scene execution.

 

[draffa]

Hi Michael,

thank you very much for reply and very interesting info.

1 - I'll use correct grounding for proper signal reference for the serial interface.

2 - I cannot pair (neither fast mode nor AP mode) with the eWeLink app. 4ch pro seems stuck at boot, wifi led blinking as described. So no wifi activity.

3 - I cannot find any DeviceID printed on the label on relays inside the case (tech data only about the relay..)

If I can not solve this issue I will try to flash 4chpro with tasmota image (something that I still intended to do).

Greetings,

Diego

[draffa]

Hi Phil,

thank you very much for reply and very interesting observations.

I'm already in the "dark side" ;). I will try to flash 4chpro soon with tasmota image

Greetings.

Diego

[Michael Ingraham]

Diego,

Regarding DeviceID - likely Sonoff manufacturing procedures changes. The label was just an easy way to know what to expect. Short of knowing the AP name to look for, I use my mobile to scan for Wi-Fi networks. When the device is in AP mode, you should see an ITEAD-xxxxx or Sonoff-xxxxx (ignore my specific case and number of digits, just a pattern similar to those).

And, good luck with your new TASMOTA adventures ;-)

Mike

Michael Ingraham
Spartanburg, SC

--

[Phil]

https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-4CH-and-4CH-Pro

[draffa]

Hi Phil,

I bought a second 4chpro and this one works fine (ewelink registration and amazoon alexa integration, all ok).

I also installed the tasmota firmware on a micro board based on the ESP8266, the heltec wifi kit 8 with oled display, using once platformio  and once arduino IDE. Everything works well. The "dark side" gives great satisfaction !!

I thought, as if to practice, before installing the tasmota firmware on both 4chpro, to recover the original sonoff firmware from the new 4chpro, which works well, and to install it again on the first sonoff that always seems to be in booting loop. By the way, I report the miserable support from the sonoff technical support....

Do you think there may be a firmware-encoded device-id? Or is the device-id connected to the mac address, and then is generated on-the-fly?

In practice, the firmware of the second working 4ch pro, installed on the first "dead" one, could give problems or should it work?

Greetings,

diego

Il giorno lunedì 12 novembre 2018 15:51:11 UTC+1, Phil ha scritto:

https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-4CH-and-4CH-Pro

[Michael Ingraham]

Diego,

Welcome to the dark side ;-)

Yes, the firmware in each Sonoff is encoded for the particular device. You can read off the firmware in each device and save each one separately. I have not done this myself but have found others that have saved their binaries and then been able to restore them back to the corresponding device.

Mike

On Friday, November 16, 2018 at 2:45:46 AM UTC-5, draffa wrote:

Hi Phil,

I bought a second 4chpro and this one works fine (ewelink registration and amazon alexa integration, all ok).

[Phil]

Good to hear that the new box works ok,  In my limited experience sonoffs are generally very sturdy devices.  they have to be with the likes of me poking about with a soldering iron..  

Sorry afaik you cant restore the sonoff firmware from a copy lifted off a similar device due to some device id or address restrictions as you suspect.   iirc there are details in the wiki for using cli tools to clear/copy/wipe the systems but in order to restore a device you would first need to have a backup from that device to restore. 

When you hit the feature limit, or get sick of server outages, just host your own local mqtt broker and go tasmota ;) 

[draffa]

After sweating for a whole afternoon I managed to flash tasmota, (via raspberry and esptool), to my first 4chpro with booting issue. Now works fine !!!!

[Phil]

great news..  wonder what went Phutt with the original system??  so now you have 2 x ??  so whats in store for the 'new' tasmota toy??  

fwiw i use a £10 raspberry-Pi-0-W headless to host both my local mqtt broker (mosquitto) and Node Red the s/w I use to add further control and rules to my tasmota devices.

Other people use OPENHAB or Domoticz both of which are mature and established home automation systems..

While tasmota surpasses the stock firmware in features and access and can stand alone. You have far more capacity for control and interaction with other devices if you also replace the itead/sonoff servers and brokers to facilitate message passing and provide instruction too. 

Have fun..