SonoffLAN WiFi devices silently goes offline

[asteinarson]

I have an issue with Sonoff devices going offline, becoming unavailable to automations.

I have recently installed Home Assistant with Sonoff LAN on an Intel Celeron NUC. I have six SR26 WiFi smart plugs on the network. They appeared as they should after configuring them with the EWeLink app.

Then I set up an automation to turn them on at a fix time in the night (cheap electricity) and turn them off in the morning. This does not work around 90% of the time (the automations are created, the devices are listed under SonoffLAN integration, but in the morning after, the automations were never kicked off, or very occasionally (the few 10% working cases) the integration went on, but then never later turned off).

In the morning when I check the system and go to one of the plugs and try to turn it on manually - I see that no entry in the "Logbook" is created. Also if I leave the page for the device and then come back, I see that its state was never changed. So the device is apparently offline (even if it was online when I created the automation).

I also note that for all Sonoff SR26 plugs I get logbook entries "SR26 House VVB became unavailable".

To "wake things up" and get the devices accessible again I need to reload the integration. Then I can turn the devices on/off and get corresponding entries in the log book - and the device remembers its state.

However, there is no automation, if the precondition is that I manually reload the integration just before the automation should be run...

My first wish is the devices should not silently go offline and become unavailable.

My second wish is that it would be more visible in the system that a device had gone offline.

There is no log entry directly from the SonoffLAN integration under System > Logs

Any help is appreciated, and I can try out fixes. Thanks.

sonoff-b923461082948bca42616200ad5a6b29-S26R2 Gussbo VVB-2274133e8c5d9da46ca3aef72fe60590.json.txt

[sipimokus]

Here too, but I found in Logs this problem:

Logger: custom_components.sonoff.core.ewelink.cloud
Source: custom_components/sonoff/core/ewelink/cloud.py:268
Integration: Sonoff ([documentation](https://github.com/AlexxIT/SonoffLAN), [issues](http://192.168.10.190:8123/api/sonoff/66bf7ac9-374e-427a-89e8-1994333dc424))
First occurred: 12:29:27 (1 occurrences)
Last logged: 12:29:27

Cloud WS Connection error: Cannot connect to host eu-pconnect10.coolkit.cc:8080 ssl:default [None]

[asteinarson]

The problem is still there. Sonoff devices works when triggered manually from the HA admin (for the SonoffLAN integration, under config > devices > device > ...).

However, when the automation (for that device) is triggered, the device itself is (often) not triggered.

For one device, the automation step On works but Off does not trigger the device. I attach screenshots below.

The first screenshot shows the device, its two automations and the Logbook. In the logbook, one can see that the automation only works one way (02.30 - turned on). The Off automation is run - but then it never finds the S26 device.

I attach LogBook screenshots of the automations traces when they are run (ExecTrace). There the difference is clear. In the Step Details - for direction On the device switch is there as a step. For off the device is never found.

To rule out any issue with configuration of the automation, I attach screenshots of those too.

For reasons to this... these are my thoughts:

• Can it be the strength of the WiFi signal ? When I download the device info - it reports rssi: -90.
• In the exec trace, once can see that runtime is much shorter for the successful one:
• GS VVB On: 0.08 seconds
• GS VVB Off: 5.07 seconds

At the moment I am quite stuck in my automation work, as I have bought these "DIY friendly" Sonoff devices to control things.

As things work nicely when manipulating these devices manually in the admin - but then very often not in automatic mode - it feels very shaky.

Any help would be appreciated - as it appears quite a few people have contributed to the SonoffLAN integration - and there are many devices out there that could be put to good use.

[rachffus]

I got this same issue probably. SonoffMini. Unavailable after some time.

2022-11-09 10:38:17 [D] SysInfo: {'installation_type': 'Home Assistant Supervised', 'version': '2021.12.3', 'dev': False, 'hassio': True, 'virtualenv': False, 'python_version': '3.9.7', 'docker': True, 'arch': 'x86_64', 'timezone': 'Europe/Warsaw', 'os_name': 'Linux', 'os_version': '4.15.0-171-generic', 'user': 'root', 'supervisor': '2022.10.2', 'host_os': 'Ubuntu 18.04.5 LTS', 'docker_version': '20.10.1', 'chassis': 'vm', 'sonoff_version': '3.3.1 (b20e33c)'}
2022-11-09 10:38:25 [D] 2 devices loaded from Cloud
2022-11-09 10:38:26 [D] 1000b57a3e UIID 0001 | {'version': 8, 'sledOnline': 'on', 'switch': 'off', 'fwVersion': '3.6.0', 'rssi': -58, 'startup': 'off', 'init': 1, 'pulse': 'off', 'pulseWidth': 500, 'swMode': 2, 'swCtrlReverse': 'on'}
2022-11-09 10:38:26 [D] 1000b1c6bf UIID 0004 | {'version': 8, 'sledOnline': 'on', 'fwVersion': '3.3.0', 'rssi': -56, 'init': 1, 'lock': 0, 'configure': [{'startup': 'off', 'outlet': 0}, {'startup': 'off', 'outlet': 1}, {'startup': 'off', 'outlet': 2}, {'startup': 'off', 'outlet': 3}], 'pulses': [{'pulse': 'on', 'width': 1203000, 'outlet': 0}, {'pulse': 'on', 'width': 1203000, 'outlet': 1}, {'pulse': 'on', 'width': 1203000, 'outlet': 2}, {'pulse': 'on', 'width': 1203000, 'outlet': 3}], 'switches': [{'switch': 'off', 'outlet': 0}, {'switch': 'off', 'outlet': 1}, {'switch': 'off', 'outlet': 2}, {'switch': 'off', 'outlet': 3}]}
2022-11-09 10:38:26 [D] LOCAL mode start
2022-11-09 10:38:26 [D] 1000b57a3e <= Local3 | {'switch': 'off', 'startup': 'off', 'pulse': 'off', 'sledOnline': 'on', 'fwVersion': '3.6.0', 'pulseWidth': 500, 'rssi': -58} | 1337
2022-11-09 10:38:29 [D] Add 11 entities
2022-11-09 10:41:46 [D] 1000b57a3e => Local4 | {'switch': 'on'} <= {'seq': 1338, 'sequence': '1667986906000', 'error': 0}
2022-11-09 10:41:46 [D] 1000b57a3e <= Local3 | {'switch': 'on', 'startup': 'off', 'pulse': 'off', 'sledOnline': 'on', 'fwVersion': '3.6.0', 'pulseWidth': 500, 'rssi': -58} | 1338
2022-11-09 10:42:02 [D] 1000b57a3e => Local4 | {'switch': 'off'} <= {'seq': 1339, 'sequence': '1667986922000', 'error': 0}
2022-11-09 10:42:02 [D] 1000b57a3e <= Local3 | {'switch': 'off', 'startup': 'off', 'pulse': 'off', 'sledOnline': 'on', 'fwVersion': '3.6.0', 'pulseWidth': 500, 'rssi': -58} | 1339
2022-11-09 10:42:48 [D] 1000b57a3e <= Local3 | {'switch': 'on', 'startup': 'off', 'pulse': 'off', 'sledOnline': 'on', 'fwVersion': '3.6.0', 'pulseWidth': 500, 'rssi': -58} | 1340
2022-11-09 10:42:54 [D] 1000b57a3e <= Local3 | {'switch': 'off', 'startup': 'off', 'pulse': 'off', 'sledOnline': 'on', 'fwVersion': '3.6.0', 'pulseWidth': 500, 'rssi': -58} | 1341
2022-11-09 10:52:05 [D] 1000b57a3e <= Local0 | {'online': False} | 
2022-11-09 10:52:21 [D] 1000b57a3e => Local4 | {'cmd': 'info'} !! Timeout 15
2022-11-09 10:52:21 [D] 1000b57a3e !! Local4 | Device offline
2022-11-09 11:00:36 [D] 1000b57a3e <= Local0 | {'online': False} | 

after integration reload it comes back online again, but after some time it goes offline again.

[AlexxIT]

Both of your problems are related to the implementation of zeroconf #839
Fast solution - not to use mode local

[asteinarson]

Fast solution - thanks. Maybe it should be a warning about this in the main docs - as it is not so easy to figure this out (this caused me to revert to eWeLink mobile app). The docs really give impression that the LAN features is operational.

Observation: Since everything works reliably, for an hour or so - after a restart of the integration - I think this points at what the issue is. What is it that changes on integration reload? Cached IP addresses?

[AlexxIT]

Problems with LAN proto is not normal situation. Libraries have been changed whose code does not depend on me. mDNS is very complicated protocol. It was invented at Apple and never works reliably :)

[asteinarson]

Can you consider the case of optionally having a user specified IP address override in the setting for each Sonoff device? That would (for what I can see) entirely bypass the whole mDNS thing and make LAN mode more or less trivial.

When I have a local control network, I basically install sensors / actuators once and after that I don't move them around - so IP addresses are fix. For extra safety one can reserve those IP:s in the local router - but that has not been needed so far.