Roborock goes offline at a specific time every morning and goes offline randomly during cleaning

[jay0xy]

Every morning at at 3:23am my Roborock reverses state in HA (eg: if it was offline prior to 3:23, at 3:23 it will come online, and vice versa, if it was online prior to 3:23, then at 3:23 it will go offline).

The following is seen in the log for the scenario when it is online prior to 3:23, then at 3:23 the device goes offline:

This error originated from a custom integration.

Logger: custom_components.roborock.coordinator
Source: helpers/update_coordinator.py:204
Integration: Roborock (documentation, issues)
First occurred: 3:23:25 AM (1 occurrences)
Last logged: 3:23:25 AM

Error fetching roborock data: Failed connecting to `192.168.1.11`

The roborock remains offline even though i restart the integration multiple times, i get this in the logs:

Logger: homeassistant.config_entries Source: config_entries.py:1247 First occurred: 3:23:39 AM (3 occurrences) Last logged: 7:35:51 AM Config entry 'xxxxxxxxx@gmail.com' for roborock integration not ready yet: There are no devices that can currently be reached.; Retrying in `background`

Roborock will then stay offline for the entire day (despite multiple attempts to restart the integration and even restarting homeassistant). The only thing that brings it back online is either:

1. Doing some actions in the Roborock app, such as cleaning a segment or cleaning a zone. There is like a 50% chance that home assistant will magically detect the roborock during the clean or on its way back to the dock and the device will come back online in HA, or:

2. Waiting until 3:23am the next day, when Roborock magically detects the roborock and it becomes available in HomeAssistant, until the next day at 3:23am when it becomes offline again. OR;

3. Downgrading to <v1 version (such as 0.1.2) which fixes the issue instantly (and forever with no 3:23 issue!)

In addition to this specific issue described above, i am finding that the device in HA throughout the day will randomly go offline, despite being available in the Roborock app and pingable on my network. It seems to happen during cleaning routines. This issue seems to be fixable by restarting the integration when the device will come back online in HA. I have automated this fix with an automation (ie: restart Roborock integration when device goes offline) but it is a bit of a workaround hack that i'd like to avoid using moving forward.

Currently running version 1.0.6 of the integration with a S7 MaxV Ultra. The roborock has a static IP assigned (192.168.1.11) and it is always pingable and reachable from the Roborock App. So it is not a network or device issue, it seems to be some issue with >v1 of the integration.

There is nothing else happening at 3:23 in my HA instance, no other errors in logs and no other devices go offline, just roborock! And only on versions >v1 of the integration, every version <1 the issue does not occur!

Let me know if you need any more information to assist.

Thanks!

[humbertogontijo]

v0.1.2 uses mqtt client only. v1.0.x uses local requests for everything but the map. There was an issue with mqtt client that was fixed in v1.0.6 that would make the integration fails when the vacuum starts cleaning (only when the device is not docked that it will start requesting map updates) Does your device go offline when you interact with it? Or is this just a matter of day time?

[jay0xy]

Hey thanks for the quick response!

There are two events that seem to make the device go offline in my experience:

1. Time Based - The Device will go offline specifically at 3:23am every morning (only if it's prior state was Online). If it was already offline prior to 3:23am, then it will come back online at 3:23. Ie: it reverses states at 3:23am. This happens 100% of the time on every version >v1 (including the latest v1.06). No matter how many times i reload integration or restart HA after this time based event occurs, it will never reverse its state until 3:23am the next day, OR if situation 2 happens below during the day which can reverse the state.

2. Cleaning/Doing Something - The Device will go randomly offline when it is doing something, for example when it is cleaning throughout the day (assuming it was previously online in HA). If it was previously offline in HA, then it randomly comes online during cleaning. This is not consistent like the Time Based behaviour above. This is more random. Usually a longer clean in the day means there is a greater chance the state of the device will reverse in HA.

Hope this answers the question?

So in summary, it is a combination of both time of day (specifically 3:23) or interacting with the device (eg: cleaning) that can/will cause a reverse in state in HA.

[humbertogontijo]

What is your timezone? Also, have you seen item 2 happening in v1.0.6?

[jay0xy]

Timezone is GMT +11 which is configured in HA (config/general)

Yes i have observed item 2 happening in v1.0.6. I updated to v1.0.6 yesterday morning around 10am maybe my local time as soon as i saw it was available in HACS.

I did a clean after that in the morning and it remained online no problem.

Then at 4pm that afternoon during another clean, it went offline in HA (the first time it went offline since v1.0.6)

This error originated from a custom integration.

Logger: custom_components.roborock.coordinator
Source: helpers/update_coordinator.py:237
Integration: Roborock (documentation, issues)
First occurred: June 1, 2023 at 4:58:09 PM (2 occurrences)
Last logged: June 1, 2023 at 4:58:57 PM

Error fetching roborock data: id=23742 Timeout after 4 seconds
Error fetching roborock data: id=11348 Timeout after 4 seconds

Logger: roborock.local_api
Source: runner.py:179
First occurred: June 1, 2023 at 4:59:14 PM (1 occurrences)
Last logged: June 1, 2023 at 4:59:14 PM

id=1 Timeout after 4 seconds

At which point my automation detected the device was offline and restarted the integration, which fixed the issue and the device came back online again.

This automation which restarts the integration only fixes the issue when the device goes offline during the day as a result of a clean/wash mop etc, such as in the example above at 4:59pm.

It does NOT make the device available again in HA if the cause of the device going offline was due to 3:23am.

The device is currently offline in HA because this morning it went offline at 3:23am.

The only way to bring it online now is to a) wait tomorrow until 3:23am or b) do some interaction like cleaning/washing mop and randomly it might decide to come online, although it wont be guaranteed like waiting until 3:23am tomorrow. Another thing i can do to bring it back online right now is downgrade to <v1 and it will come back online in HA, but as soon as i upgrade to >v1 it will go back offline until a) or b) occur.

Thanks so much!!

[humbertogontijo]

Thank you When the device is unavailable, have you tried restarting HA instead?

[jay0xy]

Yep i've tried restarting HA, reloading the integration, completely turning off my HA intel nuc from the power and turning it back on again after waiting a few minutes.

I always get "Retrying setup: There are no devices that can currently be reached." in the integration.

None of these restarting/reboot attempts of HA will bring the roborock back online, IF the cause of the roborock was going offline was the 3:23am issue. Only a) or b) will bring the device back online (or downgrading to <v1) when it's in this state.

The only situation when restarting HA or reloading the integration brings the roborock back online is IF the cause of the roborock going offline was due to cleaning/washing the mop etc, and not the 3:23am issue.

It's really weird! I don't know whats so special about 3:23am but i identified the pattern and it is absolutely consistent!

[humbertogontijo]

I also have a S7 MaxV (not Ultra), but I'm not having this issue I'll investigate it further Thank you for all the clarifications

[jay0xy]

Thanks so much.

Let me know if I can give any more specific information or provide more detailed or different logs that might help further.

I suppose besides my specific 323am issue, there is also the other issue of the robot going offline during cleans/other activities (that I think is more common with other users), but either way it'd be good to get both of these issues fixed!

Happy to provide any more info as required

Thanks

[jay0xy]

Strangely it didn't reverse state at 323am this morning. So it has been offline since yesterday 323am and nothing seems to bring it back online in HA except downgrading to 0.1.2. Edit: it briefly came online but after some time during cleaning and docking and then it went offline again.

[jay0xy]

Hey @humbertogontijo because 0.1.2 is stable for some (like me) is there any thought to make the mqqt only method an optional option that people can turn on if that works better for them? 0.1.2 is pretty stable and I'd be using it but of course it doesn't support lots of advanced functions like segment cleaning that came in >v1 Cheers

[jay0xy]

Another edit, it's now been online for >24 hours after randomly coming online during a mop clean and hasn't been disconnecting at 323am anymore. It has been randomly going offline during cleans still but the automation to restart integration fixes that issue instantly. The only thing I changed was not to use my main account in HA but to share it with another email and use that email to login. This way roborock app is logged in as main user and HA is logged in as shared with user. Not sure if this changed anything. Will keep monitoring.

[Regressor]

I have this issue too. I have Roborock S7 MaxV Ultra and its HA items became unavailable during cleaning. Restarting integration bring them online for some time, but they move to unavailable state again and again.

Here is the log:

2023-06-26 15:24:35.093 ERROR (MainThread) [roborock.cloud_api] id=27755 Timeout after 4 seconds 2023-06-26 15:24:35.095 WARNING (MainThread) [custom_components.roborock.camera] Unable to retrieve map data 2023-06-26 15:24:40.094 ERROR (MainThread) [roborock.cloud_api] id=17274 Timeout after 4 seconds 2023-06-26 15:24:40.098 WARNING (MainThread) [custom_components.roborock.camera] Unable to retrieve map data 2023-06-26 15:47:59.102 ERROR (MainThread) [roborock.cloud_api] id=11575 Timeout after 4 seconds 2023-06-26 15:47:59.105 WARNING (MainThread) [custom_components.roborock.camera] Unable to retrieve map data

-- Here all items was online ---

2023-06-26 15:48:04.107 ERROR (MainThread) [roborock.cloud_api] id=22570 Timeout after 4 seconds 2023-06-26 15:48:04.110 WARNING (MainThread) [custom_components.roborock.camera] Unable to retrieve map data 2023-06-26 15:48:04.693 WARNING (MainThread) [roborock.api] [Errno 104] Connection reset by peer 2023-06-26 15:48:04.695 WARNING (MainThread) [roborock.api] [Errno 104] Connection reset by peer 2023-06-26 15:48:06.454 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback Future.set_result((None, None)) Traceback (most recent call last): File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run self._context.run(self._callback, *self._args) asyncio.exceptions.InvalidStateError: invalid state 2023-06-26 15:48:13.484 ERROR (MainThread) [roborock.local_api] id=1 Timeout after 4 seconds 2023-06-26 15:48:13.488 ERROR (MainThread) [roborock.local_api] id=1 Timeout after 4 seconds 2023-06-26 15:55:38.934 ERROR (MainThread) [custom_components.roborock.coordinator] Error fetching roborock data: id=25981 Timeout after 4 seconds

And then all items became unavailable at 15:55:38

[jay0xy]

Hey @Regressor I'm still getting that same issue too but using an automation to restart the service when the device becomes unavailable so not really noticing the issue anymore as it resolves within a few seconds of going offline

[Regressor]

Hey @Regressor I'm still getting that same issue too but using an automation to restart the service when the device becomes unavailable so not really noticing the issue anymore as it resolves within a few seconds of going offline

Could you share this automation ? You are restarting integration to get it online ?

[kbrown01]

I too would like to see the automation, my attempts do not trigger

[lukas-kraus]

Same issue with my S6 MaxV. It always becomes unavailable at 03:58 for a few seconds

[osnwt]

Same issue here with S7 Pro Ultra. Seems after automatic firmware upgrade it goes offline, still being online via App... Same was with Xiaomi App, today reconfigured for Roborock one. Exactly same behavior.

[Mazoku01]

every day, same time, same error, S7+, robot works fine without problem

Logger: homeassistant.components.roborock.coordinator Source: helpers/update_coordinator.py:322 Integration: Roborock (documentation, issues) First occurred: 03:54:53 (1 occurrences) Last logged: 03:54:53

Error fetching roborock data: Failed connecting to xxx.xxx.xxx.xxx

Logbook: Mazlik changed to Docked 03:55:23 - 3 hours ago Mazlik became unavailable 03:54:53 - 3 hours ago

Mazlik changed to Docked 03:55:51 - Yesterday Mazlik became unavailable 03:54:47 - Yesterday

[seyu77]

I also have an s8 pro ultra. And the device goes offline after a certain period of inactivity. It gets fixed when I reinstall the service. What is the solution to this? Can I do an automatic reload? For example, it currently goes offline again every 1 minute. Making an automation that runs every minute is ridiculous

[Jouke-87]

Same here... every night the RoboRock disconnects and 1 minute later it connects again.

[giejay]

One year later, still same issue it seems in the core integration. For me, with the Q-Revo S. Randomly goes offline and online again. I have an automation to automatically reload it:

- alias: Vacuum - Reboot when roborock issues appear
  trigger:
    - platform: state
      entity_id: sensor.robot_livingroom_dock_error
      to: 'unavailable'
    - platform: state
      entity_id: sensor.robot_livingroom_dock_error
      to: 'unavailable'
      for: 
        hours: 1
  action:
    - service: rest_command.reload_robo

rest_command:
   reload_robo:
    url: http://192.168.2.106:8123/api/config/config_entries/entry/xxxxx/reload 
    method: POST
    headers:
      authorization: "Bearer eyJ....."
      content-type: 'application/json'

But that also doesn't always work.