All Entities become "unavailable" after approximately 1 hour
Opened this issue · 16 comments
Describe the bug
Every Dreame integration (v2.0.0b16) entity becomes unavailable after approximately 1 hour.
To Reproduce
I wait for approximately 1 hour. The integration must be reloaded in order for the entities to be refreshed or made available.
I have deleted the integration and re-installed it and I have the same issue.
Expected behavior
Entities to be available.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional Information (please complete the following information)
- Model Name: Dreame XL30 Ultra r9316k
- Firmware Version [e.g. 1156]: 4.3.9_1726
- Home Assistant Version: Core 2014.9.1 O/S 13.1
- Configuration Type [With or without map support]: Dreame Account
- Errors or warnings shown in the HA logs (if applicable):
Edit:
Strange... the following error has shown up in the Core log. It has only shown up once. Below this error are the DNS errors.
This error originated from a custom integration.
Logger: custom_components.dreame_vacuum.dreame.protocol
Source: custom_components/dreame_vacuum/dreame/protocol.py:567
integration: Dreame Vacuum (documentation, issues)
First occurred: 5:29:10 PM (1 occurrences)
Last logged: 5:29:10 PM
Error while executing request: Read timed out. (read timeout=3): {"did":"521426587","id":82,"data":{"did":"521426587","id":82,"method":"get_properties","params":[{"did":"0","siid":2,"piid":1},{"did":"1","siid":2,"piid":2},{"did":"2","siid":3,"piid":1},{"did":"3","siid":3,"piid":2},{"did":"5","siid":4,"piid":1},{"did":"10","siid":4,"piid":6},{"did":"11","siid":4,"piid":7},{"did":"39","siid":4,"piid":35},{"did":"24","siid":4,"piid":20},{"did":"29","siid":4,"piid":25},{"did":"121","siid":15,"piid":3},{"did":"122","siid":15,"piid":5},{"did":"21","siid":4,"piid":17},{"did":"34","siid":4,"piid":30},{"did":"51","siid":4,"piid":47}]}}
The only errors I see by default are the following DNS errors.
[INFO] 127.0.0.1:55527 - 27810 "NS IN . udp 17 false 512" REFUSED qr,aa,rd 17 0.000061683s
[INFO] 127.0.0.1:36837 - 18322 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.001261635s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:40178 - 5771 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.001261698s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 172.30.32.1:40755 - 33633 "A IN us.iot.dreame.tech. udp 36 false 512" - - 0 8.002630949s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: read udp 127.0.0.1:60776->127.0.0.1:5553: i/o timeout
[INFO] 172.30.32.1:40755 - 33810 "AAAA IN us.iot.dreame.tech. udp 36 false 512" - - 0 8.002917648s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: read udp 127.0.0.1:45978->127.0.0.1:5553: i/o timeout
[INFO] 127.0.0.1:51032 - 31159 "NS IN . udp 17 false 512" REFUSED qr,aa,rd 17 0.000081415s
[INFO] 127.0.0.1:54682 - 45305 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000378569s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:37568 - 45407 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000378553s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:32845 - 29181 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000201887s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:60006 - 16969 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000152291s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:57831 - 33500 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000334348s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:41216 - 8150 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000385717s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:53766 - 16539 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 19.431556798s
[INFO] 127.0.0.1:44538 - 4678 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 19.431571704s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: connect: network is unreachable
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.0.0.1:853: connect: network is unreachable
[INFO] 127.0.0.1:50688 - 36599 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000244126s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:37031 - 17691 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000150386s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:51653 - 48859 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.00098477s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:45282 - 9292 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.001699655s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:37340 - 7260 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000363634s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:50953 - 60302 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000362694s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:38433 - 46687 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 21.66733183s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: read tcp 172.30.32.3:53422->1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:49765 - 29561 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000985441s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:51819 - 53524 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000906347s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:60278 - 43903 "AAAA IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000856317s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:60835 - 62115 "A IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000856304s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. A: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:41375 - 28445 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000899684s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:37798 - 15745 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000984844s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:48107 - 2520 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000370637s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:38474 - 6718 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000370647s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:57905 - 1993 "A IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000942313s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:60115 - 55861 "AAAA IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000883206s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:32920 - 39228 "AAAA IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000412402s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:50505 - 37890 "A IN us.iot.dreame.tech. udp 47 true 2048" - - 0 30.000343704s
[ERROR] plugin/errors: 2 us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:41550 - 52477 "AAAA IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000415663s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:37411 - 58318 "A IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000329174s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:49673 - 15388 "AAAA IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.00077641s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. AAAA: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:36497 - 32539 "A IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000812839s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:37815 - 14543 "AAAA IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000470814s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. AAAA: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:37474 - 36886 "A IN 10000.mt.us.iot.dreame.tech. udp 56 true 2048" - - 0 30.000611751s
[ERROR] plugin/errors: 2 10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
Same issue on my side 😅
10000.mt.us.iot.dreame.tech is the mqtt server adress and if it disconnects that means you dont have a stable intermet connection.
Without mqtt connection integration cannot get updates therefore all entities become unavailable.
Actual bug is that the entities will stuck unavailable even after mqtt is reconnected and I am aware of that issue for a long time.
10000.mt.us.iot.dreame.tech is the mqtt server adress and if it disconnects that means you dont have a stable intermet connection. Without mqtt connection integration cannot get updates therefore all entities become unavailable. Actual bug is that the entities will stuck unavailable even after mqtt is reconnected and I am aware of that issue for a long time.
I do not think it is because I do not have a stable internet connection. I have many devices in my home that "talk" and I do not see any issues at the time the integration becomes unavailable. Also after checking my router logs there is no service interruption at all during the same time period. I suspect it may be the latency around the travel time to the mqtt server environment. I have also run pings simultaneously to both 10000.mt.us.iot.dream.tech (47.254.33.232) and 1.1.1.1 and I see packets being dropped going to 47.254.33.232.
@mikedrews
10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
this tells me otherwise, how do you explain mqtt client disconnect and timeot on reconnect?
I have the same issue. After some time (a few hours), the app goes offline, and all entities become unavailable. It needs to be reloaded, and everything starts working again. With this behavior, it becomes unusable. (v2.0.0b16)
I downgraded to the previous version (v2.0.0b15) , and for now, the anomaly has not reoccurred. After a few hours, the problem reoccurred even with the old version... It's necessary to reload the app to resolve it.
Hello,
Same for me I need to reload integration to fix that (I think it's due to my network connection).
Temporary fix in automation :
alias: Recharger Dreame si indisponible
description: ""
triggers:
- entity_id:
- sensor.l10s_ultra_status
to: unavailable
trigger: state
for:
hours: 0
minutes: 4
seconds: 0
conditions: []
actions:
- action: homeassistant.reload_config_entry
data: {}
target:
device_id: b84b28646457bc6761e0edd0af560be3
mode: single
It's reload dreame device if status is unvailable for 4 min.
Hello,
Same for me I need to reload integration to fix that (I think it's due to my network connection).
Temporary fix in automation :
alias: Recharger Dreame si indisponible description: "" triggers: - entity_id: - sensor.l10s_ultra_status to: unavailable trigger: state for: hours: 0 minutes: 4 seconds: 0 conditions: [] actions: - action: homeassistant.reload_config_entry data: {} target: device_id: b84b28646457bc6761e0edd0af560be3 mode: singleIt's reload dreame device if status is unvailable for 4 min.
As someone with a networking background I have proven it is not my network (refer to my comments above). But even though I present facts that can be backed up by data it seems to fall on deaf ears. It seems everyone experiencing this issue has a "bad" network".
@mikedrews you haven't responded my question on my previous comment...
10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
How do you explain mqtt client disconnect and timeout on reconnect if you have a stable network?
Mqtt is a socket based connection with built in keep alive packet mechanism. If you loose your network connection even for fraction of a second that socket will be closed and trigger an mqtt disconnected event and causes the integration to think that the device has been disconnected.
When have I first implemented mqtt api of the dreame cloud I though it is a connection to the device over cloud but now I know that it is a relay api hosted on the cloud just to inform the app about changes. So even if your vacuum is disconnected from the internet integration still be able to connect to the mqtt server. Now I need to fully refactor availability detection of the device from integration but don't have to do that right now.
I always knew that there may be some issues with the dreamehome api implementation, that is the whole reason it is still supported only with the Beta so you should also consider that you are using an experimental project that has fully released yet.
@mikedrews you haven't responded my question on my previous comment...
10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeoutHow do you explain mqtt client disconnect and timeout on reconnect if you have a stable network?Mqtt is a socket based connection with built in keep alive packet mechanism. If you loose your network connection even for fraction of a second that socket will be closed and trigger an mqtt disconnected event and causes the integration to think that the device has been disconnected.
When have I first implemented mqtt api of the dreame cloud I though it is a connection to the device over cloud but now I know that it is a relay api hosted on the cloud just to inform the app about changes. So even if your vacuum is disconnected from the internet integration still be able to connect to the mqtt server. Now I need to fully refactor availability detection of the device from integration but don't have to do that right now.
I always knew that there may be some issues with the dreamehome api implementation, that is the whole reason it is still supported only with the Beta so you should also consider that you are using an experimental project that has fully released yet.
Is it possible to prove that the client is closing the connection as a result of not getting a cloud response in the allotted time period?
You should be more supportive than complainant if you want me to solve this problem.
This whole project completely relies on my motivation and If I loose that you will loose control of your vacuum...
You should be more supportive than complainant if you want me to solve this problem. This whole project completely relies on my motivation and If I loose that you will loose control of your vacuum...
I am trying to be supportive. I am not point fingers at your work but at the "dreame" cloud infrastructures capability to respond properly. I just don't think that everyone having this issue should be thrown into a "you have a bad network" bucket.
I have spent many hours utilizing your work and creating a dashboard card below that my family can be happy with. You have inspired me !
I have 200mbit fiber network and did nothing to make it stable but I cannot reproduce the issue even with 12 devices connected to my test HA at the same time.
Devices are always connected and mqtt connection never disconnects except if I open a VPN connection or disable my internet for a fraction of a second. I can reproduce the exact issue happening to all of you only if I intentionally break my internet connection for a very short period, that's why I am asuming this is a WAN issue.
I am not saying it's not integrations fault because I know there is a bug and I will fix it when I have the time but that bug only happens if you have an unstable network and I can prove that on my test setup.
You should also consider that this might be an ISP thing because since there are too many connections to those single iot server points might have require some optimization from their end. For instance; I am always having trouble sending requests to CN Xiaomi servers with a lot of timeouts but it never happens if I switch to my 5G cellular network.
Hello,
Same for me I need to reload integration to fix that (I think it's due to my network connection).
Temporary fix in automation :
alias: Recharger Dreame si indisponible description: "" triggers: - entity_id: - sensor.l10s_ultra_status to: unavailable trigger: state for: hours: 0 minutes: 4 seconds: 0 conditions: [] actions: - action: homeassistant.reload_config_entry data: {} target: device_id: b84b28646457bc6761e0edd0af560be3 mode: singleIt's reload dreame device if status is unvailable for 4 min.
Can you share history of this automation like how many times it triggered and with how much intervals between so I can get more idea about the issue?
The error says
10000.mt.us.iot.dreame.tech. A: dial tcp 1.1.1.1:853: i/o timeout
I suspect that your issue is DNS related.
1.1.1.1 is cloudflare, 853 is DoT (dns over tls) and the 'A' means A-Record (ipv4) for '10000.mt.us.iot.dreame.tech'
Edit: Oops you mentioned DNS. The discussion was going elsewhere so I thought I highlight that 🙂
Hello,
Same for me I need to reload integration to fix that (I think it's due to my network connection).
Temporary fix in automation :alias: Recharger Dreame si indisponible description: "" triggers: - entity_id: - sensor.l10s_ultra_status to: unavailable trigger: state for: hours: 0 minutes: 4 seconds: 0 conditions: [] actions: - action: homeassistant.reload_config_entry data: {} target: device_id: b84b28646457bc6761e0edd0af560be3 mode: singleIt's reload dreame device if status is unvailable for 4 min.
Can you share history of this automation like how many times it triggered and with how much intervals between so I can get more idea about the issue?
Hello,
Since I create this automation never... I got the issue 2 times at 7 o'clock, I create automation and for now problem never occur again....
I have the same issue with x40 ultra.
The only solution I found was to create an automation that executes the action dreame_vacuum.vacuum_request_map every hour.
Till now i never had a disconnectin again