home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
69.77k stars 28.91k forks source link

Broadlink Component - Handling Of Communication Errors #37361

Closed Silvenga closed 3 years ago

Silvenga commented 4 years ago

The problem

It appears that the Broadlink component will not process commands after the remote device is marked as unavailable.

Environment

Problem-relevant configuration.yaml

remote:
- platform: broadlink
  host: 192.168.2.144
  mac: blah
  type: rm4_mini
  name: Servers Broadlink
sensor:
- platform: broadlink
  host: 192.168.2.144
  mac: blah
  type: rm4_mini
  name: Servers Broadlink
  scan_interval: 60
  monitored_conditions:
    - temperature
    - humidity

Traceback/Error logs

cat home-assistant.log | grep broad
2020-07-01 21:19:34 INFO (SyncWorker_36) [homeassistant.loader] Loaded broadlink from homeassistant.components.broadlink
2020-07-01 21:19:34 INFO (MainThread) [homeassistant.components.remote] Setting up remote.broadlink
2020-07-01 21:19:37 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.broadlink
2020-07-01 22:01:21 WARNING (MainThread) [homeassistant.components.broadlink.device] Disconnected from device at 192.168.2.144: Control key is expired
2020-07-01 22:02:17 WARNING (MainThread) [homeassistant.components.broadlink.device] Connected to device at 192.168.2.144
2020-07-01 23:31:47 WARNING (MainThread) [homeassistant.components.broadlink.device] Disconnected from device at 192.168.2.144: Control key is expired
2020-07-01 23:32:39 WARNING (MainThread) [homeassistant.components.broadlink.device] Connected to device at 192.168.2.144
2020-07-02 01:02:10 WARNING (MainThread) [homeassistant.components.broadlink.device] Disconnected from device at 192.168.2.144: Control key is expired
2020-07-02 01:02:10 ERROR (MainThread) [homeassistant.components.broadlink.remote] Failed to send 'fan only/server ac': The device is offline
2020-07-02 02:32:25 WARNING (MainThread) [homeassistant.components.broadlink.device] Disconnected from device at 192.168.2.144: Control key is expired
2020-07-02 02:33:20 WARNING (MainThread) [homeassistant.components.broadlink.device] Connected to device at 192.168.2.144
2020-07-02 05:23:55 WARNING (MainThread) [homeassistant.components.broadlink.device] Disconnected from device at 192.168.2.144: Control key is expired
2020-07-02 05:24:51 WARNING (MainThread) [homeassistant.components.broadlink.device] Connected to device at 192.168.2.144
2020-07-02 09:10:22 WARNING (MainThread) [homeassistant.components.broadlink.device] Disconnected from device at 192.168.2.144: Control key is expired
2020-07-02 09:11:15 WARNING (MainThread) [homeassistant.components.broadlink.device] Connected to device at 192.168.2.144

Additional information

felipediel commented 4 years ago

Home Assistant cannot control the device when it is unavailable. You can check your network to identify what's making the connection slow, or you can increase the timeout to give your device more time to respond before it is marked as unavailable.

felipediel commented 4 years ago

My next update will improve this a little, as it will update availability more frequently.

Now I was thinking. Perhaps it would be better to increase the tolerance to only mark the device as unavailable after 3 attempts spread over 3 minutes. And try to recover the availability minute after minute. So it will always have a greater chance of being available.

Do you think it is a good idea?

Silvenga commented 4 years ago

I think that's a great idea. For myself at least, having any recovery attempt would be the bees knees. If say, I updated my access points or switch firmware (automated, say at 2am, takes maybe 5 minutes), I should not need to restart HA to reconnect to devices. I would also find a command to mark the device as available as a good mitigation (that way it can be automated).

In this case, the network error looks to be during the time the broadlink device was roaming between access points, so connectivity would be restored within seconds. I haven't found any other possible issues, the sensor was still responding after all, so I don't think a substantial network error occurred.

Silvenga commented 4 years ago

I'm following your #36914 pr with excitement. 😹

Is there currently any logic to recheck devices? In this case 9 hours passed without any re-attempts (commands to the device were executing every 10 minutes).

probot-home-assistant[bot] commented 4 years ago

Hey there @danielhiversen, mind taking a look at this issue as its been labeled with an integration (broadlink) you are listed as a codeowner for? Thanks! (message by CodeOwnersMention)

felipediel commented 3 years ago

Fixed: https://github.com/home-assistant/core/pull/36914. Thank you!

callifo commented 3 years ago

Im having something that looks similar to that above, since moving to 0.115. I have a rm2pro and a rm3mini broadlink on the network. The rm2pro is rock solid, whereas the rm3 mini generates tonnes of error log messsages,

2020-09-21 13:16:15 WARNING (MainThread) [homeassistant.components.broadlink.updater] Connected to the device at 192.168.100.152
2020-09-21 13:17:20 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:20:35 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:23:50 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:28:10 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:30:20 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:33:35 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:35:45 WARNING (MainThread) [homeassistant.components.broadlink.updater] Disconnected from the device at 192.168.100.152
2020-09-21 13:49:50 WARNING (MainThread) [homeassistant.components.broadlink.updater] Connected to the device at 192.168.100.152
2020-09-21 13:50:55 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:53:05 WARNING (MainThread) [homeassistant.components.broadlink.updater] Disconnected from the device at 192.168.100.152
2020-09-21 13:54:10 WARNING (MainThread) [homeassistant.components.broadlink.updater] Connected to the device at 192.168.100.152
2020-09-21 13:55:15 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 13:57:25 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 14:00:40 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 14:03:55 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 14:07:10 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 14:10:25 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline
2020-09-21 14:13:40 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline

The rm3mini has good signal strength, and pinging it from the HA pi shows no drops over a 30 minute period and latency is stable. It also works fine for blasting codes, not seen it miss any yet.

PING 192.168.100.152 (192.168.100.152) 56(84) bytes of data.
64 bytes from 192.168.100.152: icmp_seq=1 ttl=255 time=1.88 ms
64 bytes from 192.168.100.152: icmp_seq=2 ttl=255 time=1.98 ms
64 bytes from 192.168.100.152: icmp_seq=3 ttl=255 time=1.89 ms
64 bytes from 192.168.100.152: icmp_seq=4 ttl=255 time=2.23 ms
64 bytes from 192.168.100.152: icmp_seq=5 ttl=255 time=2.03 ms
64 bytes from 192.168.100.152: icmp_seq=6 ttl=255 time=2.23 ms
64 bytes from 192.168.100.152: icmp_seq=7 ttl=255 time=2.34 ms
64 bytes from 192.168.100.152: icmp_seq=8 ttl=255 time=3.44 ms
64 bytes from 192.168.100.152: icmp_seq=9 ttl=255 time=1.91 ms
64 bytes from 192.168.100.152: icmp_seq=10 ttl=255 time=1.93 ms
64 bytes from 192.168.100.152: icmp_seq=11 ttl=255 time=1.93 ms
64 bytes from 192.168.100.152: icmp_seq=12 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=13 ttl=255 time=2.73 ms
64 bytes from 192.168.100.152: icmp_seq=14 ttl=255 time=1.87 ms
64 bytes from 192.168.100.152: icmp_seq=15 ttl=255 time=3.100 ms
64 bytes from 192.168.100.152: icmp_seq=16 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=17 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=18 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=19 ttl=255 time=1.93 ms
64 bytes from 192.168.100.152: icmp_seq=20 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=21 ttl=255 time=1.63 ms
64 bytes from 192.168.100.152: icmp_seq=22 ttl=255 time=3.02 ms
64 bytes from 192.168.100.152: icmp_seq=23 ttl=255 time=4.08 ms
64 bytes from 192.168.100.152: icmp_seq=24 ttl=255 time=1.99 ms
64 bytes from 192.168.100.152: icmp_seq=25 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=26 ttl=255 time=1.93 ms
64 bytes from 192.168.100.152: icmp_seq=27 ttl=255 time=1.93 ms
64 bytes from 192.168.100.152: icmp_seq=28 ttl=255 time=1.94 ms
64 bytes from 192.168.100.152: icmp_seq=29 ttl=255 time=1.91 ms
64 bytes from 192.168.100.152: icmp_seq=30 ttl=255 time=4.56 ms
64 bytes from 192.168.100.152: icmp_seq=31 ttl=255 time=2.01 ms
64 bytes from 192.168.100.152: icmp_seq=32 ttl=255 time=1.92 ms
64 bytes from 192.168.100.152: icmp_seq=33 ttl=255 time=2.02 ms
64 bytes from 192.168.100.152: icmp_seq=34 ttl=255 time=2.21 ms
64 bytes from 192.168.100.152: icmp_seq=35 ttl=255 time=1.90 ms
^C
--- 192.168.100.152 ping statistics ---
35 packets transmitted, 35 received, 0% packet loss, time 74ms
rtt min/avg/max/mdev = 1.634/2.253/4.561/0.695 ms
felipediel commented 3 years ago

v >= 0.115.1?

felipediel commented 3 years ago

I am working on this. The problem is with discover() and your subnetwork.

callifo commented 3 years ago

Yes 0.115.2

Subnetwork? I do run multiple VLANs, for internal and IoT but I didnt mention that above :) The HA pi has a trunk to it, multiple IPs and it can access both subnets.

felipediel commented 3 years ago

Yes. This issue is related to https://github.com/home-assistant/core/issues/40267.

felipediel commented 3 years ago

I will make this better. I am trying to solve this, but I don't have the environment to reproduce the conditions. Do you want to help me test the new version of the library?

callifo commented 3 years ago

Sure

felipediel commented 3 years ago
python3 -m venv venv
source venv/bin/activate
pip3 install git+https://github.com/felipediel/python-broadlink.git@the-generator
python3
import broadlink as blk
for d in blk.xdiscover():
    print(d)

print(blk.hello("192.168.0.17"))  # Device IP address

Do you see your devices?

callifo commented 3 years ago

Seems to be intermittent, I can get a good run and get like 50 of them in a row, but then sometimes I still get a bunch that dont work,

>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/testvenv/venv/lib/python3.8/site-packages/broadlink/__init__.py", line 131, in hello
    raise exception(-4000)  # Network timeout.
broadlink.exceptions.NetworkTimeoutError: [Errno -4000] Network timeout
>>> print(blk.hello("192.168.100.152"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/testvenv/venv/lib/python3.8/site-packages/broadlink/__init__.py", line 131, in hello
    raise exception(-4000)  # Network timeout.
broadlink.exceptions.NetworkTimeoutError: [Errno -4000] Network timeout
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/testvenv/venv/lib/python3.8/site-packages/broadlink/__init__.py", line 131, in hello
    raise exception(-4000)  # Network timeout.
broadlink.exceptions.NetworkTimeoutError: [Errno -4000] Network timeout
>>> print(blk.hello("192.168.100.151"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/testvenv/venv/lib/python3.8/site-packages/broadlink/__init__.py", line 131, in hello
    raise exception(-4000)  # Network timeout.
broadlink.exceptions.NetworkTimeoutError: [Errno -4000] Network timeout
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/testvenv/venv/lib/python3.8/site-packages/broadlink/__init__.py", line 131, in hello
    raise exception(-4000)  # Network timeout.
broadlink.exceptions.NetworkTimeoutError: [Errno -4000] Network timeout
>>> print(blk.hello("192.168.100.152"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/testvenv/venv/lib/python3.8/site-packages/broadlink/__init__.py", line 131, in hello
    raise exception(-4000)  # Network timeout.
broadlink.exceptions.NetworkTimeoutError: [Errno -4000] Network timeout
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.151"))
<rm: Broadlink RM pro (0x272a) at 192.168.100.151:80 | 34:ea:34:c7:95:00 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
>>> print(blk.hello("192.168.100.152"))
<rm: Broadlink RM mini 3 (0x2737) at 192.168.100.152:80 | 78:0f:77:4e:7c:f5 | 智能遥控 | Unlocked>
felipediel commented 3 years ago

This is a problem in your environment. Packets are not reaching their destination. But we are sending them. There is nothing else we can do but display an error message to make you aware of what's going on.

felipediel commented 3 years ago

One thing that I could do to alleviate your problem is to increase the interval between updates, so we won't spam your log with these messages. I was already thinking about this, now I am convinced that it is necessary.

callifo commented 3 years ago

Its strange, as prior to 0.115 I didn't have any issues, and I can leave a ping going on the two units and I'm not getting any dropped packets. The other thing is despite the almost cosmetic error messages in my log, I don't appear to be missing any IR blasts from them.

If you can produce a replacement broadlink module, I can attempt to overwrite the inbuilt HA one and run it for a few days and see what it looks like.

felipediel commented 3 years ago

We were not polling your device for state before 0.115, this is why you never got these messages.

litinoveweedle commented 3 years ago

Just to shine some light to this issue, all RMs are constantly disconnecting/reconnecting to wi-fi IF they don't have connection to internet. It seems to be some weird way of theirs watchdog implementation. As many users for obvious reason don't allow smart home components used locally by HA to communicate to internet, this together with newly introduced feature is very annoying and seems to affect many users

Looking to my Mikrotik WLAN log, these reconnect attempts are rather short, about 3-5sec. It surely depend AP to AP, but I would like to propose on improvement of polling device state schedule.

felipediel commented 3 years ago

@litinoveweedle What are the device types and firmwares? I cannot reproduce this issue with my Broadlink RM mini 3 (0x2737) and RM pro (0x2787). They work fine locally, no error messages in the logs.

felipediel commented 3 years ago

I will make the updates optional, so users who are having problems can disable them.

litinoveweedle commented 3 years ago

All my Broadlink devices, that include RM3 mini, RM pro+ and Beok and Floureon thermostat.

it looks like this:


2020-10-21 00:49:31 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: [Errno -4000] Network timeout
2020-10-21 00:51:32 WARNING (MainThread) [custom_components.floureon] Thermostat 192.168.3.57 read_status error: [Errno -4000] Network timeout
2020-10-21 00:51:37 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: [Errno -4000] Network timeout
2020-10-21 01:00:51 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline```
felipediel commented 3 years ago

If you disable all the custom components, does the problem persist?

felipediel commented 3 years ago

I just realized that you are using an outdated version of this integration. Please update to see how the new version works for you.

litinoveweedle commented 3 years ago

Do you mean if devices stop disconnecting from wi-fi? Or do you mean log entries?

litinoveweedle commented 3 years ago

I just realized that you are using an outdated version of this integration. Please update to see how the new version works for you.

I am on the latest HA stable. I am sorry, but I am not going to beta, last several HA releases were terrible experience for me, regarding stability of my home automation.

felipediel commented 3 years ago

In the latest stable the error messages are different. You are using an outdated version.

litinoveweedle commented 3 years ago

I did grep from all manifests from custom_integration for broadlink, only one using it is this, which was already fixed by your PR to:

floureon/manifest.json: "requirements": ["pythoncrc", "broadlink>=0.15.0"]

I did used automated upgrade method to HA 0.116.4 and I have no idea, what could prevent python_broadlink from upgrading. And when checking inside the HA docker container it seems to be version 15.0., which is supposed to be latest one.

/ # find / -name broadlink
/usr/local/lib/python3.8/site-packages/broadlink
/usr/src/homeassistant/homeassistant/components/broadlink
find: /share/mopidy/media/share: Symbolic link loop
/ # cd /usr/src/homeassistant/homeassistant/components/broadlink
/usr/src/homeassistant/homeassistant/components/broadlink # ls
__init__.py     __pycache__     config_flow.py  const.py        device.py       helpers.py      manifest.json   remote.py       sensor.py       strings.json    switch.py       translations    updater.py
/usr/src/homeassistant/homeassistant/components/broadlink # cat manifest.json
{
  "domain": "broadlink",
  "name": "Broadlink",
  "documentation": "https://www.home-assistant.io/integrations/broadlink",
  "requirements": ["broadlink==0.15.0"],
  "codeowners": ["@danielhiversen", "@felipediel"],
  "config_flow": true
}
felipediel commented 3 years ago

Ah, sorry for my mistake, I read "The device is offline" and thought it was an old error message, but I just realized that this message still exists for the RM mini 3.

felipediel commented 3 years ago

Anyway, I was not able to reproduce the problem here, even blocking the internet access of my devices. So I think it's probably something else. Do you have two WiFi networks with the same SSID?

litinoveweedle commented 3 years ago

No problem.

@litinoveweedle What are the device types and firmware? I cannot reproduce this issue with my Broadlink RM mini 3 (0x2737) and RM pro (0x2787). They work fine locally, no error messages in the logs.

Regarding your info, I had to recently temporarily disable firewall rule blocking my "smart devices" LAN subnet from internet. It is possible that RM were pushed FW upgrade. :-(

It is definitely not WiFi - signal are OK, and other devices connected to same virtual AP are not disconnecting. ONLY Broadlink devices ara disconnecting and they are doing it exactly after 5min. Hardly coincidence. All my devices have static DHCP lease. There is also information from other user about this behavior when Broadlink devices could not connect to cloud.

03:06:18 wireless,info CX:XX:XX:XX:XX:X1@wlan4: disconnected, received deauth: sending station leaving (3) 
03:06:22 wireless,info CX:XX:XX:XX:XX:X1@wlan4: connected, signal strength -49 
03:06:30 wireless,info CX:XX:XX:XX:XX:XA@wlan4: disconnected, received deauth: sending station leaving (3) 
03:06:33 wireless,info CX:XX:XX:XX:XX:XA@wlan4: connected, signal strength -58 
03:07:51 wireless,info CX:XX:XX:XX:XX:X6@wlan4: disconnected, received deauth: sending station leaving (3) 
03:07:54 wireless,info CX:XX:XX:XX:XX:X6@wlan4: connected, signal strength -52 
03:11:23 wireless,info CX:XX:XX:XX:XX:X1@wlan4: disconnected, received deauth: sending station leaving (3) 
03:11:27 wireless,info CX:XX:XX:XX:XX:X1@wlan4: connected, signal strength -47 
03:11:35 wireless,info CX:XX:XX:XX:XX:XA@wlan4: disconnected, received deauth: sending station leaving (3) 
03:11:38 wireless,info CX:XX:XX:XX:XX:XA@wlan4: connected, signal strength -54 
03:12:56 wireless,info CX:XX:XX:XX:XX:X6@wlan4: disconnected, received deauth: sending station leaving (3) 
03:13:00 wireless,info CX:XX:XX:XX:XX:X6@wlan4: connected, signal strength -56 
03:16:28 wireless,info CX:XX:XX:XX:XX:X1@wlan4: disconnected, received deauth: sending station leaving (3) 
03:16:32 wireless,info CX:XX:XX:XX:XX:X1@wlan4: connected, signal strength -49 
03:16:40 wireless,info CX:XX:XX:XX:XX:XA@wlan4: disconnected, received deauth: sending station leaving (3) 
03:16:44 wireless,info CX:XX:XX:XX:XX:XA@wlan4: connected, signal strength -56 
03:18:02 wireless,info CX:XX:XX:XX:XX:X6@wlan4: disconnected, received deauth: sending station leaving (3) 
03:18:06 wireless,info CX:XX:XX:XX:XX:X6@wlan4: connected, signal strength -52 
03:21:33 wireless,info CX:XX:XX:XX:XX:X1@wlan4: disconnected, received deauth: sending station leaving (3) 
03:21:37 wireless,info CX:XX:XX:XX:XX:X1@wlan4: connected, signal strength -47 
03:21:45 wireless,info CX:XX:XX:XX:XX:XA@wlan4: disconnected, received deauth: sending station leaving (3) 
03:21:49 wireless,info CX:XX:XX:XX:XX:XA@wlan4: connected, signal strength -53 
03:23:08 wireless,info CX:XX:XX:XX:XX:X6@wlan4: disconnected, received deauth: sending station leaving (3) 
03:23:12 wireless,info CX:XX:XX:XX:XX:X6@wlan4: connected, signal strength -52 
03:26:38 wireless,info CX:XX:XX:XX:XX:X1@wlan4: disconnected, received deauth: sending station leaving (3) 
03:26:42 wireless,info CX:XX:XX:XX:XX:X1@wlan4: connected, signal strength -49 
03:26:50 wireless,info CX:XX:XX:XX:XX:XA@wlan4: disconnected, received deauth: sending station leaving (3) 
03:26:54 wireless,info CX:XX:XX:XX:XX:XA@wlan4: connected, signal strength -59 
03:28:14 wireless,info CX:XX:XX:XX:XX:X6@wlan4: disconnected, received deauth: sending station leaving (3) 
03:28:17 wireless,info CX:XX:XX:XX:XX:X6@wlan4: connected, signal strength -54

Anyway it seems that RMs work OK, except these 3-5sec disconnect periods exactly each 5min. If it would be possible to set higher timeout on Broadlink integration in HA, I would better to wait for device to reconnect if my command will fall into this disconnected time, than to allow these black beans to connect to some # cloud.

felipediel commented 3 years ago

Ok, let's do a test. Go to Configuration -> Integrations -> + -> Broadlink. Now you enter the host and a select a timeout of 10s. Does the problem persist?

litinoveweedle commented 3 years ago

Is there any chance to change timeout for existing devices? I do not see such options, in the past in the configuration.yaml it was very simple.

felipediel commented 3 years ago

☝️

litinoveweedle commented 3 years ago

I dislike GUI as I have no idea what it will do when I will try do add already existing devices as suggested. But IMHO editing core.config_entries file shall do same job...

felipediel commented 3 years ago

Those steps update the configuration without the need for a restart.

litinoveweedle commented 3 years ago

no problem, timeout updated on all devices, HA restarted. Even after this there is again error int he log:

2020-10-21 04:22:57 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching device data: The device is offline

felipediel commented 3 years ago

Could this be a firmware issue? Are you using the latest version? Maybe a firmware update will work, but I can't guarantee. I don't understand why my devices that are the same as yours work normally even with internet access disabled.

litinoveweedle commented 3 years ago

I do not think so - there are 4 devices of 3 types, but all behave same, including that Beok thermostat. So it would be really surprising to be 'same' firmware issue. Is there any easy way to get FW version out of the device? BTW: Are you sure you have correct rules in your firewall? Do you Drop or Reject connections? (in my case it is Reject)

felipediel commented 3 years ago

You can check the firmware version by clicking on the device in the Devices page.

This update is a candidate to fix your problem. I think you should wait for a release. If it doesn't work, I'll come back to help you.

felipediel commented 3 years ago

About the firewall, mine does not have the option to reject, I can only drop the packets. So maybe this is why I’m not able to reproduce the issue. How about you change yours to drop for now?

I think it would be much less harmful to your device. I don't think it is healthy to be reconnecting every five minutes. Even if we ignore the problem in Home Assistant, this is something that should concern you.

litinoveweedle commented 3 years ago

Well it should not concern only me as it seems I am not only one having this issue Other users reports of this behavior exist as well.

I did changed rule to Drop and then restarted all RM, but behavior is completely same. After 5 minutes disconnect -> reconnect.

12:04:05 wireless,info CX:XX:XX:XX:XX:X1@wlan4: disconnected, received deauth: sending station leaving (3) 
12:04:08 wireless,info CX:XX:XX:XX:XX:X1@wlan4: connected, signal strength -52 
12:04:10 wireless,info CX:XX:XX:XX:XX:XA@wlan4: disconnected, received deauth: sending station leaving (3) 
12:04:13 wireless,info CX:XX:XX:XX:XX:XA@wlan4: connected, signal strength -59 
12:04:27 wireless,info CX:XX:XX:XX:XX:X6@wlan4: disconnected, received deauth: sending station leaving (3) 
12:04:31 wireless,info CX:XX:XX:XX:XX:X6@wlan4: connected, signal strength -49

And for the night I got about 20 new messages in HA reporting Broadlink device offline.

regarding FW versions:

RM mini 3: Firmware: 55 RM mini 3: Firmware: 55 RM pro+: Firmware: 43

One additional question. How did you provision RMs to the network (i.e. set Wi-Fi SSID and secret)? Maybe it is something what was set during that. I used Broadlink mobile app to do that (but I am not using this app for any control).

felipediel commented 3 years ago

I used the python-broadlink library to provision my devices.

Now I set them up with the Broadlink app and the US cloud to test. IP and MAC addresses are blocked for external access. They are working fine, no errors in the logs.

Firmwares: RM pro: 20025 RM mini 3: 57

litinoveweedle commented 3 years ago

The only difference is that I used EU app, but I would not suppose this is the issue. Maybe the IPs of the cloud server will be different, due to GDPR my RMs are trying to connect to EC2 Amazon EU servers.

Still the behavior is same - RM disconnect/reconnect each 5min. The rest of other smart devices on the same Wi-Fi AP have connection times from the last AP restart. Just to prove my theory, I did only changed existing rule in my firewall from Drop/Reject to Accept traffic to internet and from that time - no more Wi-Fi disconnects/reconnects. But that is something I would not like to have permanently - that is precisely reason I am into HA. And when Reject rule is restored - 5minutes later all RM devices disconnects and reconnects again.

Is there any simple way of upgrading / downgrading RM firmware to test with your version?

felipediel commented 3 years ago

You can upgrade the firmware with the official app. Downgrading is not so simple. You need to contact their support team and ask for a URL pointing to the latest stable.

I use v57 without problems. I don't think you will need a downgrade.

felipediel commented 3 years ago

I checked their version history: v57: Fix the problem that the device cannot connect to some routers

So this is definitely your problem. A firmware upgrade will fix.

litinoveweedle commented 3 years ago

So this is definitely your problem. A firmware upgrade will fix.

well, than you are first person I know, who believe in vague info in Chinese app changelog. :-) On top of that it definitely can connect and function without issue, disregarding constant reconnections. But I am on upgrade and I will let you know.

felipediel commented 3 years ago

That's how I solve problems here. Okay, now I have to work. I can't babysit you all day. Good luck with v57.

litinoveweedle commented 3 years ago

There was definitely smiley missing in my original reply, so please there were no bad intentions from my side. :-) And I am definitely happy for any help, especially when as documented I am not only one affected by this, thank you for all.. ;-)