-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roborock S4 stopped working after upgrading to 2022.8.1 #76381
Comments
Hey there @rytilahti, @syssi, @starkillerOG, @bieniu, mind taking a look at this issue as it has been labeled with an integration ( xiaomi_miio documentation |
Looking at the diagnostics data you gave, it looks like that the device was (at least) initialized correctly as some data was obtained from the device. Could you clarify what exactly is not working? Are you not getting any state updates after the initial update? Are the commands working? |
Thanks for your swift reply! Yes correct, the device has worked fine over the last few years with this integration. Nothing is working at the moment. No state updates, no service calls to the device etc. |
My roborock S7 vacuum stopped working with 2022.8 as well. |
my S6 stopped working as well. The status of everything became "Unavailable" |
Is there anything else useful in the logs? If you enable debug logging for |
it turned out that in my case, due to multiple changes in the same day(Upgrade + Roborock IP Change) the issue was that the integration was still looking for old Roborock IP. I have deleted the integration, then re-added it and it detected my Roborock immediately. Also, the automations and scripts are still linked to my Roborock... so it's "config-safe" to delete and re-add the Xiaomi Miio integration. Since delete + re-add Integration is config-proof, I suggest that the others who have problems after upgrade to give a try, it could work. |
Not in the 'warn' logs for sure. (Only log that I've seen is in the opening post) Enabled debug logging for:
Got the following (very detailed! 🚀) logs back:
|
I just re-added the vacuum manually like @mccasian suggested. Thanks! The vacuum entity is now visible along with the other sensors. Although the vacuum got initialized without a unique ID and now it's called an unnamed device: |
I think your vacuum is blocked from the internet (or is otherwise not responding to the info query properly), so there's no unique id to be had. There is a hack that uses IP address for that, but it doesn't work unless the device is initialized using the As I'm currently working on restructuring the library (rytilahti/python-miio#1495), I haven't had time to look into fixing that. Anyway, when rytilahti/python-miio#1328 gets done it should start working. If someone wants to tackle that specific problem earlier, I'm open for PRs :-) |
Yes that's correct, I'm blocking outgoing the internet connection for the vacuum. (Always had it configured like this) I can also remove the block, re-add the vacuum and put the block back in place. Would that help? |
I wouldn't work, the root cause why the dummy IP-based, unique_id is not being set to the vacuum's config entry should be figured out and fixed. In any case, if the vacuum gets initialized once with the real mac address, it wouldn't match with the dummy one after cutting the cloud connectivity so that's not a working solution. |
Aaah, I didn't think about that. Thanks! |
Removing and re-adding the integration just fixed it for me in 2022.8.5, but I am not blocking the vacuum to the internet. it's documented that it won't work if you do. I do have HA on a separate network with IP masquerading for the traffic going from HA to Vacuum. |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
Good bot, but still an issue AFAIK |
also still an issue on 2023.01.1 |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
The problem
My Roborock S4 stopped working after upgrading to 2022.8.1. This integration worked for several years. The log shows a time-out. I can still control the vacuum with the
mirobo
tool:What version of Home Assistant Core has the issue?
core-2022.8.1
What was the last working version of Home Assistant Core?
core-2022.6
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Xiaomi Miio
Link to integration documentation on our website
https://www.home-assistant.io/integrations/xiaomi_miio/#xiaomi-mi-robot-vacuum
Diagnostics information
"coordinator_data": "VacuumCoordinatorData(status=, dnd_status=, last_clean_details=<CleaningDetails area=0.28 complete=False duration=0:00:16 end=2022-08-07 13:49:47 error=No error error_code=0 start=2022-08-07 13:46:27>, consumable_status=<ConsumableStatus filter=6 days, 5:31:35 filter_left=0:28:25 main_brush=12 days, 13:20:07 main_brush_left=-1 day, 22:39:53 sensor_dirty=4 days, 17:03:27 sensor_dirty_left=-4 days, 12:56:33 side_brush=12 days, 13:20:07 side_brush_left=-5 days, 18:39:53>, clean_history_status=<CleaningSummary count=1006 dust_collection_count=None ids=[1659872787, 1659872519, 1659731122, 1659646905, 1659599758, 1659559533, 1659510859, 1659475844, 1659392092, 1659300162, 1659211123, 1659076950, 1659037499, 1658951995, 1658813241, 1658780606, 1658693883, 1658599350, 1658525677, 1658435476] total_area=21299.49 total_duration=12 days, 12:44:20>, timers=[], fan_speeds={'Silent': 38, 'Standard': 60, 'Medium': 77, 'Turbo': 90}, fan_speeds_reverse={38: 'Silent', 60: 'Standard', 77: 'Medium', 90: 'Turbo'})"
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
Could be similar to #75835, although I have the S4 and I've added the integration before.
The text was updated successfully, but these errors were encountered: