SONOFF 4CHPRO R3, V1.0

[M*I*B]

Hello again...

due of the lack with the messurement-chip of the DualR3 I just try to flash the 4CHPRO R3... But I'm lost^^

I try to flash "ESP_Easy_mega_20230508_energy_ESP8266_4M1M.bin" with the DownLoadTool and have set it up shown in the screenshot. But I ever get a error "5-chip efuse check fail"... What ever that means

What I'm doing wrong?!?


EDIT:
My fault! This thingy got a ESP8285 and not a 8266

So is it right that the 8285 aren't supportet since some time?

[Ath]

ESP8285 is supported by all ESP8266 1M builds, the firmware autodetects that it's running on an ESP8285 and configures the GPIO pins accordingly.

If the ESP.Easy.Flasher won't comply, you can use the Espressif flasher that's also included in the download, or use the online flash tool at https://TD-er.nl/ESPEasy/latest (using Chrome or Edge).

[M*I*B]

ESP8285 is supported by all ESP8266 1M builds, the firmware autodetects that it's running on an ESP8285 and configures the GPIO pins accordingly.

Ahhh, good to know... So the BIN I try is the right one?

If the ESP.Easy.Flasher won't comply, you can use the Espressif flasher that's also included in the download, or use the online flash tool at https://TD-er.nl/ESPEasy/latest (using Chrome or Edge).

I don't use the ESPeasy-Flasher anymore; makes to much trouble. And as you can see in the screen shot I use the Espressif flasher. Not the newest one but never got problems with them...

[Ath]

Ahhh, good to know... So the BIN I try is the right one?

No, you have tried to use a 4M with a 1M file-system, but the ESP8285 has a built-in flash of 1MB, so you need a 1M .bin file. The naming is explained in the README.md on Github.
Not sure if that's already available in the last available release, but it sure is available in the web-flasher, linked above.

[M*I*B]

img-2023-06-10-21-06-21.png (149.97 KiB) Viewed 2915 times

[M*I*B]

Ok... As soon as you do it right, it works...

In this context, I noticed that the mapping of the GPIO's to the buttons and relays is slightly different than specified on the Tasmota website, for example. There seem to be differences between the mapping of the 4CH and 4CHPRO, maybe in different revisions.

I now have the mapping like this:

Code: Select all

Button/Relay1 = GPIO-0/12
Button/Relay2 = GPIO-9/5
Button/Relay3 = GPIO-10/4
Button/Relay4 = GPIO-14/15
LED = GPIO-13 inverted

I entered the buttons as "PushButton active LOW" and set the internal pull-up.

As a rule I now have the following:

Code: Select all

on BTN#BTN1 do
      GPIO,12,%eventvalue%
endon
on BTN#BTN2 do
      GPIO,5,%eventvalue%
endon
on BTN#BTN3 do
      GPIO,4,%eventvalue%
endon
on BTN#BTN4 do
      GPIO,15,%eventvalue%
endon

It actually works, but I don't like the rule. So one more question:
Is it possible to use a wild card so that the event query pulls for all keys? Something like this (which of course doesn't work...)?

Code: Select all

on BTN#BTN* do
      GPIO,12,%eventvalue1%
      GPIO,5,%eventvalue2%
      GPIO,4,%eventvalue3%
      GPIO,15,%eventvalue4%
endon

[M*I*B]

... because it's Sunday, so the right time to find a problem...

This morning (the 4CH is on the table with 12V supply but nothing other connected) I saw that the LED flashes pumpingly.
The 4CH can no longer be reached via the GUI. He has said goodbye to the WLAN and can no longer be pinged. Other SONOFFs also no longer display the unit.
It can still be switched with the buttons on the device, so it hasn't crashed.
The amazing thing is that FHEM still declares the 4CH as "present", although no more commands can be transmitted from FHEM either.

I restarted it once and now it works again.
In the "Advanced Settings" I have set it to restart the WLAN in the event of a connection error, but this does not seem to work (see attachment).
The other (old) SONOFF have never done anything like that.
Is there anything known about WLAN problems in this firmware and/or with the 4CHPRO

[Ath]

Code: Select all

on BTN#BTN1 do
      GPIO,12,%eventvalue%
endon
on BTN#BTN2 do
      GPIO,5,%eventvalue%
endon
on BTN#BTN3 do
      GPIO,4,%eventvalue%
endon
on BTN#BTN4 do
      GPIO,15,%eventvalue%
endon

It actually works, but I don't like the rule. So one more question:
Is it possible to use a wild card so that the event query pulls for all keys? Something like this (which of course doesn't work...)?

Code: Select all

on BTN#BTN* do
      GPIO,12,%eventvalue1%
      GPIO,5,%eventvalue2%
      GPIO,4,%eventvalue3%
      GPIO,15,%eventvalue4%
endon

Well, as you have named all your button tasks with the same name, that is actually unsupported*, btw., you can probably have 1 rule to handle all buttons:
(Untested!)

Code: Select all

on BTN do
      GPIO,12,[btn#btn1]
      GPIO,5,[btn#btn2]
      GPIO,4,[btn#btn3]
      GPIO,15,[btn#btn4]
endon

*Duplicate tasknames are usually signalled on submit, but depending on the build this check may be left out for size reasons.
*Duplicate names can cause issues when addressing task-values.

[Ath]

Is there anything known about WLAN problems in this firmware and/or with the 4CHPRO

Sonoff units, especially the long(er) available models like yours, have a really bad reputation in the power-supply department, causing all kind of issues, most notably with WiFi. You can find a lot of evidence for that in this forum.
TD-er has made long strides (read: months!) in trying to work around these issues, f.e. by delaying the start of WiFi after boot, just to let the PSU stabilize and let WiFi connect successfully. The major cause for these issues is the poor quality of some of the components, and 'sub-optimal' design and board layout. More recent Sonoff devices have shown improvements in this area like the POWR3xx and THR3xx series using ESP32, but don't expect any hardware design updates on older models.

[M*I*B]

... yes, I know about the bad design of the SONOFF's... But my old ones are all stable, like the S20 where I use many of them in productive.
I have think that the 4CHPROR3 is much younger then the S20 are... Or am I wrong?

[TD-er]

Another issue with 'old' Sonoff devices is that their capacitors are often of bad quality and also under-dimensioned for their task.
So if those caps age, their capacitance typically will degrade and cause stability issues.

One thing you can do here is to enable ECO mode and also make sure "Send With Max TX Power" is unchecked.
This will try to match WiFi TX power based on the signal strength of the access point and thus reduce power consumption.
With "ECO" mode enabled, it will also try to reduce power consumption of the ESP itself.

However, since this unit has relais, it may need quite a bit more to activate those, compared to the possible power consumption reduction you get from turning on ECO mode.

But reducing the TX power also has effect on units with a badly tuned WiFi antenna.
So it might still improve things on your unit.

[M*I*B]

Well, as you have named all your button tasks with the same name, that is actually unsupported*, btw., you can probably have 1 rule to handle all buttons:
(Untested!)

Code: Select all

on BTN do
      GPIO,12,[btn#btn1]
      GPIO,5,[btn#btn2]
      GPIO,4,[btn#btn3]
      GPIO,15,[btn#btn4]
endon

*Duplicate tasknames are usually signalled on submit, but depending on the build this check may be left out for size reasons.
*Duplicate names can cause issues when addressing task-values.

Ok, I have testet it. Doesn't work like that Looks like that the simple BTN do don't create an event... I don't know...

The idea behind this was to form a group and then, especially for FHEM, get a single device "BTN" with 4 readings "BTN1...BTN4". But unfortunately that doesn't work either.
In connection with FHEM there are some oddities anyway.
FHEM creates a total of eight readings from the designations that are noted in "Values" (BTN1 ... BTN4, RLY1 ... RLY4), but if I do it the other way around and put the designation under "name" consecutively (BTN1 . .. BTN4, RLY1 ... RLY4) and "Values" all set to "val", for example, then nothing works anymore...
It seems that FHEM interprets "Name" and "Values" the wrong way round...
EDIT:
An other problem is that FHEM only interprete the 1st three signs from "Values". So if you set Values i.e. to "BTNx" FHEM only see "BTN" insteed of "BTNx"... I just crash full into that


Another thing is also a bit mysterious:
Yesterday I was able to change the status of the button from FHEM with e.g. "taskvalueset BTN BTN1 1", which subsequently also affected the relay due to the rule.
For some reason this no longer works. The status of the button is changed from 0 to 1 or vice versa, but the connected relay does not follow, since obviously no event is triggered that triggers the rule...

Another issue with 'old' Sonoff devices is that their capacitors are often of bad quality and also under-dimensioned for their task.

Yes... That's why I have replaced all the Cap's in the S20 with high quality 105°LowESR and also double the capacity. All run well since them...

One thing you can do here is to enable ECO mode and also make sure "Send With Max TX Power" is unchecked.
This will try to match WiFi TX power based on the signal strength of the access point and thus reduce power consumption.
With "ECO" mode enabled, it will also try to reduce power consumption of the ESP itself.

Ok, good hint, thx. I will try that... And also take a deeper look what Cap's are build in; have some left from the S20 project...

[M*I*B]

... because it's Sunday, so the right time to find a problem...

This morning (the 4CH is on the table with 12V supply but nothing other connected) I saw that the LED flashes pumpingly.

Just an update:
A few minutes ago the same problem appeared again.
Now I was sitting next to it and noticed that I got an alarm on my smartphone at the same time that the Raspberry of the heating was not in the network (FHEM presence (ping)).
And just exactly the same Alarm from FHEM and then flashing of the 4CH, which then does not find the WLAN again (really, really bad!)
So it looks as if my WLAN (FritzBox 7590AX and three 1750E3 repeaters) sporadically shits for a very short moment.

At the moment I have no idea what's going on. Can it be that the FritzBox got a problem if there are so many devices logged in?

[TD-er]

I'm having my entire network running on Fritzbox units.
5530Fiber as router + some Fritz repeaters all setup as access points via LAN: 3x 1750E, 1x 3000, 2x 1200AX

The 1750E in my office is currently serving 13 WiFi devices of which 11 are ESPEasy nodes.
But I know I have had a lot more connected to them a few weeks ago when testing 12 units I made for someone.
Not sure if I every had over 32 simulaneous connected devices, but at least I never have run out of 'slots' for WiFi devices here.

The 1750E units are quite old. At least 2 of them I got around start of 2015.
So those could technically show effects of ageing capacitors. But so far I haven't seen any issues with them.

Maybe you have some other networking issues here, like hosts sharing the same IP address?
Or some network switch acting a bit flaky?
I know I once had an unmanaged TP-link 16 port switch which was acting very unstable. And even though those TP-link managed switches are hardly more expensive and working without issues, that one was absolutely horrible.
I've also seen some PoE-switches causing strange issues on the network.
So maybe you should take a look at the rest of the network?

Could it be you have some 'loop' in your network?
When a switch detects those, it might sometimes also cause funky issues.

Also link aggregation can cause strange issues on network switches.

As far as I know, Fritzbox doesn't have an option for IGMP snooping. But some switches have it.
For ESP's it is best to turn this off as this may cause funky issues in your network.

[TD-er]

A small update as I did look a bit more into the Fritz logs here.

Apparently the Fritzbox does actually have "band steering" enabled as some of my nodes (supporting 5 GHz WiFi) have been suggested to switch bands in my network.

So if you have your 2.4 and 5 GHz WiFi networks setup with the same SSID, you may want to try configuring ESPEasy to use "802.11b/g" (tools->Advanced page in ESPEasy)
This way you essentially tell the router your device doesn't know about band steering as that didn't exist before 802.11n was introduced.

Make sure your access point does allow devices to connect using 802.11g and not 802.11n only. (on 2.4 GHz)

[M*I*B]

hmmm...
The FritzBox is right over my head where I'm working on the SmartHome- stuff. So all thingys I work on are logged in direktly at the Box-WLAN.
All systems get the IP via DHCP from an ISC-DHCPd (except the DHCP- server itself ) so loopbacks and/or doublettes are nearly impossible.
As switch I use an GS748Tv3 but that only counts for LAN. Meanwhile all repeater works like the other way; connected via WLAN to the Box and offer LAN wher the repeater are placed.

I will take a deeper look at that. For now I have disabled all automatics in the Box like Autochannel and Powermanagement... We will see...

EDIT:

So if you have your 2.4 and 5 GHz WiFi networks setup with the same SSID, you may want to try configuring ESPEasy to use "802.11b/g" (tools->Advanced page in ESPEasy)
This way you essentially tell the router your device doesn't know about band steering as that didn't exist before 802.11n was introduced.

Yapp, good hint also. Let me see if some changed after disable the Autochannel. Then I will follow up with the next and set the ESP's to use only 802.11b/g

[TD-er]

That switch does look like a 'managed' switch.
So make sure it hasn't IGMP snooping enabled somewhere.

[M*I*B]

good hint...

img-2023-06-11-13-22-48.png (10.05 KiB) Viewed 2849 times

Have disabled it now... Haven't know about that option in my switch before so have to search a while

[TD-er]

IGMP snooping used to be a good idea to protect devices that have no idea what to do with loads of multicast traffic.
Like 10 Mbps printer servers when IP-TV was introduced.

But it also causes a lot of strange issues on your network when you don't have a querier (or however it is called, forgot the name) on your network to keep those multicast streams alive.

It for sure has a bad effect on ESPs WiFi behavior and other uses like playing online with a playstation for sure does cause lots of issues as my neighbor found out...

[M*I*B]

Good morning all together...

... it looks like the problems are gone. the 4CHPROR3 and the DUALR3 are still online this morning and don't cause any problems.
That seems to have worked before; Thanks so much!!!

In this context something else again something OT; maybe who knows?
On the DUALR3 I had Tasmota on it for a short time to see if it worked with the energy chip... It didn't, so EasyESP on it again.
However, since then I still have topics from Tasmota on the MQTT server?! Since I don't have any Tasmota devices on the network, I can't explain how that can be. And yes... The topics definitely come from the DualR3 (SH-SN-DS1) and are silent when it's off..

[TD-er]

I doubt they get updated. So then those must have been sent using the retain flag set.
This tells the broker to keep that topic including the last message sent to it.
So anyone subscribing to that topic (or using a wildcard matching that topic) will receive the last message as soon as they subscribe.

[M*I*B]

... ahhh ok. So that means that it will stay forever also if the client gone?!
Sorry if I ask that maybe stupid Q but I'm not well into MQTT

Update:
Meanwhile I have enabled the "Domoticz MQTT" on the DualR3. Now it looks like that the old messages are gone. I now have LWT from it (that I have enabled)...

[TD-er]

All I know about MQTT I have learned from this site:
https://www.hivemq.com/mqtt-essentials/
Part8 is about retained messages and part9 about the LWT

[M*I*B]

... thank you. I will store that. Who knows where or when I need that.
At the moment I only use MQTT to send some status (on/off) from my zentral-heating-controller to fhem...

[M*I*B]

Good morning all,

in the meantime everything is going as expected. Only the 4CHPROr3 still causes problems with the WLAN.

If the WLAN or the AP is gone for a short time (power failure, reset FritzBox, ...) he can't find the AP again. Unfortunately, this is 100% reproducible.
I'll open it again and use the terminal to see what it outputs as a message in this case.
I found that enabling "Restart WiFi Lost Conn:" and "Force WiFi No Sleep:" and "CPU Eco Mode:" and "Use Last Connected AP from RTC:" individually or in combination ensures that it reconnects by itself when the AP is lost. Unfortunately he doesn't.
But since this is absolutely necessary...
Could I use a rule to ensure that it simply resets after a time X in the event of a lost WLAN?

(It just occurred to me to cut out the ESP and put an ESP32 in it...)

[TD-er]

What about the 2 new options at the bottom of tools->Advanced page?

- Extra Wait WiFi Connect
- Enable SDK WiFi Auto Reconnect

Especially the 1st one is intended to fix some issues with Fritzbox: https://espeasy.readthedocs.io/en/lates ... fi-connect

[M*I*B]

... the extra wait I have testet with no result and the other I haven't touch due I don't know what that means. SDK sounds like a coder- thing...

[TD-er]

It calls a function in the SDK which is much more low-level compared to what I can do.
So it is not like it requires specific in-depth knowledge, more like I couldn't think of a better name for it.

When the SDK code detects a WiFi connection is lost, it will send out an event which I then handle in ESPEasy.
Problem is that this might take some time before it is handled.
So with this flag set, I let the SDK code handle it immediately and not even notify ESPEasy about it.

The reason why this isn't enabled by default is that it might act a bit strange when you have multiple SSIDs configured and you need to switch over to the other one.
Simply because ESPEasy itself doesn't get notified and probably only will find out when trying to send some data via the network.

[M*I*B]

Ahhh ok, thanks for the Explanation.
I will try it and let it run some days...

[M*I*B]

Nope, that don't help.
Have try it right now in different combinations... Here is a record of the output if that problem occure... and that's it. They don't get the ass up again...

EDIT say:
Can't I use a rule to determine whether the WLAN is still there or ping something and react to it (Timer -> WLAN present? > No -> Reset)?

Code: Select all

132207 : Info   : WD   : Uptime 2 ConnectFailures 0 FreeMem 17336 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init<\r><\n>
162206 : Info   : WD   : Uptime 3 ConnectFailures 0 FreeMem 18368 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init<\r><\n>
162651 : Info   : EVENT: Clock#Time=Wed,9:59<\r><\n>
181569 : Info   : WIFI : Disconnected! Reason: '(200)' Connected for 2 m 50 s<\r><\n>
181770 : Info   : WIFI : Disconnected! Reason: '(1)'<\r><\n>
181871 : Info   : Reset WiFi.<\r><\n>
190701 : Info   : WIFI : Disconnected! Reason: '(1)'<\r><\n>
190802 : Info   : Reset WiFi.<\r><\n>
199631 : Info   : WIFI : Set WiFi to OFF<\r><\n>
200048 : Info   : WIFI : Set WiFi to STA<\r><\n>
209131 : Info   : EVENT: WiFi#Disconnected<\r><\n>
209146 : Info   : EVENT: WiFi#Disconnected<\r><\n>
209226 : Info   : WD   : Uptime 3 ConnectFailures 0 FreeMem 20024 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
209269 : Info   : EVENT: WiFi#Disconnected<\r><\n>
222227 : Info   : WD   : Uptime 4 ConnectFailures 0 FreeMem 20088 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
223202 : Info   : EVENT: Clock#Time=Wed,10:00<\r><\n>
252237 : Info   : WD   : Uptime 4 ConnectFailures 0 FreeMem 20088 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
282236 : Info   : WD   : Uptime 5 ConnectFailures 0 FreeMem 20088 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
283181 : Info   : EVENT: Clock#Time=Wed,10:01<\r><\n>
312225 : Info   : WD   : Uptime 5 ConnectFailures 0 FreeMem 19456 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
342225 : Info   : WD   : Uptime 6 ConnectFailures 0 FreeMem 19456 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
342904 : Info   : EVENT: Clock#Time=Wed,10:02<\r><\n>
372234 : Info   : WD   : Uptime 6 ConnectFailures 0 FreeMem 19456 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
402216 : Info   : WD   : Uptime 7 ConnectFailures 0 FreeMem 19536 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
402651 : Info   : EVENT: Clock#Time=Wed,10:03<\r><\n>
432210 : Info   : WD   : Uptime 7 ConnectFailures 0 FreeMem 19536 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
462215 : Info   : WD   : Uptime 8 ConnectFailures 0 FreeMem 19536 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
462641 : Info   : EVENT: Clock#Time=Wed,10:04<\r><\n>

[TD-er]

You could act on the WiFi#Disconnected and WiFi#Connected events to start/stop a timer.
When the timer expires you can call the "wifidisconnect" command. (or "reboot")

But the "Connection Failure Threshold" parameter on the tools->Advanced page is doing almost the same.
You just set a value there like "50", which implies that after N failed connection attempts ESPEasy will turn off WiFi and retry again.

N.B. when trying giving a reboot command, make sure not to give the "reset" command as that's a poorly chosen command to do a factory reset

[M*I*B]

hmmm ok. I will try the "Connection Failure Threshold:" 1st and if that also don't work I try a rule then...
I will report soon...

[M*I*B]

Nope. I have set "Connection Failure Threshold:" to 3, kreate a WLAN drop out and ... same as before...
Later then I will try a rule. It looks like that there is no other way to solve that...

EDIt say:
Lunch break... Just placed the following into rules... Brutal and simple

Code: Select all

on WiFi#Disconnected do
      timerSet,1,30
endon

On Rules#Timer=1 do
      reboot
endon

Code: Select all

2372473 : Info   : EVENT: Clock#Time=Wed,11:33<\r><\n>
2383028 : Info   : WD   : Uptime 40 ConnectFailures 0 FreeMem 18192 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init<\r><\n>
2385388 : Info   : WIFI : Disconnected! Reason: '(200)' Connected for 39 m 33 s<\r><\n>
2385590 : Info   : WIFI : Disconnected! Reason: '(1)'<\r><\n>
2385691 : Info   : Reset WiFi.<\r><\n>
2394519 : Info   : WIFI : Disconnected! Reason: '(1)'<\r><\n>
2394620 : Info   : Reset WiFi.<\r><\n>
2403449 : Info   : WIFI : Set WiFi to OFF<\r><\n>
2403865 : Info   : WIFI : Set WiFi to STA<\r><\n>
2412807 : Info   : EVENT: WiFi#Disconnected<\r><\n>
2412821 : Info   : EVENT: WiFi#Disconnected<\r><\n>
2413026 : Info   : EVENT: WiFi#Disconnected<\r><\n>
2413072 : Info   : WD   : Uptime 40 ConnectFailures 0 FreeMem 18824 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
2413105 : Info   : EVENT: BTN#T1=0<\r><\n>
2413108 : Info   : ACT  : GPIO,12,0<\r><\n>
2413110 : Info   : GPIO : port#12: set to 0<\r><\n>
2413156 : Info   : EVENT: BTN#T2=0<\r><\n>
2413159 : Info   : ACT  : GPIO,5,0<\r><\n>
2413161 : Info   : GPIO : port#5: set to 0<\r><\n>
2413208 : Info   : EVENT: BTN#T3=0<\r><\n>
2413211 : Info   : ACT  : GPIO,4,0<\r><\n>
2413213 : Info   : GPIO : port#4: set to 0<\r><\n>
2413247 : Info   : EVENT: BTN#T4=0<\r><\n>
2413251 : Info   : ACT  : GPIO,15,0<\r><\n>
2413252 : Info   : GPIO : port#15: set to 0<\r><\n>
2413287 : Info   : EVENT: RLY#R1=0<\r><\n>
2413311 : Info   : EVENT: RLY#R2=0<\r><\n>
2413346 : Info   : EVENT: RLY#R3=0<\r><\n>
2413392 : Info   : EVENT: RLY#R4=0<\r><\n>
2431914 : Info   : EVENT: Clock#Time=Wed,11:34<\r><\n>
2443032 : Info   : WD   : Uptime 41 ConnectFailures 0 FreeMem 19720 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
2473031 : Info   : WD   : Uptime 41 ConnectFailures 0 FreeMem 19720 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
2491883 : Info   : EVENT: Clock#Time=Wed,11:35<\r><\n>
2503029 : Info   : WD   : Uptime 42 ConnectFailures 0 FreeMem 18872 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
2533029 : Info   : WD   : Uptime 42 ConnectFailures 0 FreeMem 18872 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED<\r><\n>
2552601 : Info   : EVENT: Clock#Time=Wed,11:36<\r><\n>

[M*I*B]

Lunch break... Just placed the following into rules... Brutal and simple

Code: Select all

on WiFi#Disconnected do
      timerSet,1,30
endon
On Rules#Timer=1 do
      reboot
endon

Good morning everyone on this beautiful sunny Sunday...

... this morning the RCD blew out twice, probably an error current in our fully automatic coffee machine... not good

At the same time, of course, the FritzBox and the 4CH went offline and had to restart, twice in quick succession.
The other WLAN systems are all back (Sonof, Shelly & Co.), but not the 4CH.

My brutal version (see above) doesn't seem to work...

What's wrong with that?

[TD-er]

If it never got a new connection, it will also not get disconnected.
And I assume the Sonoff was also powered off when the RCD cut the power?

So you should probably start a timer at boot and reset the timer when it has a WiFi#connected event.
The rest can probably be as you already implemented.

[M*I*B]

If it never got a new connection, it will also not get disconnected.

... when I think about it (think... think...)... you're probably right. I didn't even get the idea! Thanks for the push

I'll build one in right now...