@Bloodtick_Jones Thanks for this! I have installed and tried on and off only at this stage with a Roborock Q Revo and it seems to work. Many thanks!
2 Likes
I think you need to name the rooms for that data to populate. This is how one of my maps look with the names. I had a older unit that was the same (and oddly the rooms are still in the homeData).
2 Likes
Honestly, no idea. I just got this working a couple of days ago. At least with the appRoomClean which is just the "app_segment_clean" under the hood. It seems to follow whatever you have designed in the map function.
There are lots of questions on how to execute the "routines" that are new in the mobile application. That seems to allow a lot of these custom questions.
Sorry I don't have more answers this time.
2 Likes
Ahhh. I forgot i was editing the map and i don't think i ever renamed the rooms.
I see 'fanPower' set as 106, found some obscure reference that is "custom", and will update. Does your UI show it as anything different?
Here is the next code drop enum:
@Field static final Map fanPowerCodes = [
101: "Quiet",
102: "Balanced",
103: "Turbo",
104: "Max",
105: "Off",
106: "Custom",
108: "Max+",
]
I'm not even sure where in the app you can set your fan speeds. Always seemed dynamic to me...(though I've never really paid attention)
This pulled in my Q7 Max+ without issue, but I have two vacuums. It seems to ignore my S5.
Is there any way to specify the robot it pulls in? This looks great but I really wish it could control both of my Roborocks. Still, I guess one is better than none...
How does it decide what vacuum to pull in when there are two? It seems like there should be a preference for robot name so two instances of the driver can be installed for two robots, and pull one robot into each driver.
Wait, I just saw you have the App Select Device command available. Well, I guess I tested it, and it works. I hit the button and it switched over to the S6 vacuum, bringing in the rooms and all!
Nice work! Now I can create two instances of the driver and App Select one to be the other vacuum.
I had been using the Alexa Skill with Echo Speaks voiceCmdAsText from Hubitat to send commands to clean rooms. This is so much better. Thanks for this.
1 Like
If anyone figures a way of vacuuming without washing... that be nice. 
What model do you have? I assume you have your rooms set in the mobile app to wash carpets? On my S8 it has multi-floor capability which means you can set up the same rooms again and 'not' enable the carpet washing modes in those rooms.
Hello,
I just found a bug, if you find some time to look at it, as my automations depend on getting a correct state update to know when vacuuming is done.
I have two vacuums, so I have two devices, but I just found that state is getting updated to the wrong device for some states.
Specifically, it updated the correct vacuum state to "room cleaning" when it started, but when it got done it updated the OTHER vacuum device with the "returning dock" and then "charging" states. It updated the S5 device with the Q7 Pro+ state data.
It also updated the S5 device with "room cleaning" as well when the Q7+ started cleaning. So it updated both as "room cleaning".
My App received these state updates while the Front Vac (Q7+) was cleaning a room.
2024-04-23 11:22:01.580 AM[warn]Roborock Scheduler - Back State received room clean
2024-04-23 11:22:01.562 AM[warn]Roborock Scheduler - Front State received room clean
2024-04-23 11:27:17.619 AM[warn]Roborock Scheduler - Back State received charging
2024-04-23 11:26:25.687 AM[warn]Roborock Scheduler - Back State received charged
2024-04-23 11:26:20.484 AM[warn]Roborock Scheduler - Back State received returning dock
Also, to get the updated states, I was refreshing the vac device every 10 seconds while vacuuming, to catch the state updates (driver only updates every 30 min). This worked up until I got the wrong states update when cleaning was complete, now I am getting an error for that vac when getting status.
Did I exceed the number of request allowed by Roborock per day or something by refreshing?
2024-04-23 11:53:45.543 AM[error]org.eclipse.paho.client.mqttv3.MqttSecurityException: Not authorized to connect (method connect)
2024-04-23 11:53:44.448 AM[info]Roborock Q7+ connecting mqttUser:497500af to ssl://mqtt-us.roborock.com:8883
2024-04-23 11:53:41.449 AM[info]Roborock Q7+ executing execute(command:get_consumable, param:)
2024-04-23 11:53:41.447 AM[info]Roborock Q7+ executing execute(command:get_room_mapping, param:)
2024-04-23 11:53:40.936 AM[info]Roborock Q7+ executing execute(command:get_prop, param:[get_status])
Edit: I think something got confused between the devices, possible from when I was first setting them up. I deleted the Q7+ device and recreated it. I no longer get the update error and it updated to current state of charging when it pulled in data. I will test if it gets the correct state updates now.
Well I finally got a chance to test this and it does not seem to work on my S7+ to change the mop mode.
2 Likes
I dropped some new code 1.0.1 today to help with more than one device. It 'shouldn't' be reporting with two devices on the same device since the subscription to the mqtt is device specific, but ... yes please test since I am guessing how it works without having multiple robots.
I actually had already grabbed the update this morning.
So, recreating the device fixes it, but there is no getting it back otherwise.
I tried a back cleaning using the S5, I changed to a 30 second refresh to get state updates this time, It started refreshing the Q7+ device in addition to the S5 when hitting the S5 refresh, and again I got the error on the Q7+ device when cleaning ended and I had to recreate it again.
So refresh() on one device appears to refresh both. I'm still not clear why the Q7+ device is going offline with the error. I will test without refreshing, as I'm not even sure that is the cause yet.
Edit: I did a room cleaning with the S5 without refreshing and the Q7+ device did not go offline. It seems to be something with refresh while cleaning causing the error. I manually hit refresh() when the S5 got done, and it updated the state to charging. I really just want to be able to capture the state changing while cleaning so I know when it is done by state changing to charging.
Could there be a simpler button to just update state instead of doing a full refresh to just grab the current state value of the actual vac? That is the only attribute that I need to know when it changes. Can refresh be updated to only refresh the device from where the refresh() is pressed?
Thanks. I see what is happening and will be able to patch that quickly.
Thanks for sending the debug. Update line 560 adding this:
if(deviceId!=state.duid) return
and please retest.
Edit: I pushed patch 1.0.2 to github if you want to just test that. It was obvious in your debug!
Yes, that stopped the double refresh! I was staring at the parse() method trying to figure out how to fix it, now I see it is being called multiple times on refresh(), so your fix is to just bail on the vac that was not the vac id that called it.
I set my refresh() timer to every 1 minute while cleaning, I did a room clean with the S5, and the Q7 stayed online without refreshing, and I got the charging state within a minute of cleaning done. I even caught the return to dock at a refresh, though I'm not concerned with catching that state.
A one minute refresh while cleaning seems to be enough to capture end state I need. I'm capturing the clean time at finish, so I can add it up and get a rough estimate of when the bin is full based on cleaning minutes and what I have observed for how long it takes for the bin to fill. After a clean it adds the minutes, calculates the % full to target, and then if full it does a bin empty after cleaning and resets the counter. I also turn off the 1 minute refresh when cleaning ends.
I need to try the reverse, clean with Q7+ while refreshing, but someone is in the front rooms working so I need to wait to test it. I will let you know when I get that test done. The Q7+ was the one going offline while refreshing while cleaning, hopefully it was just related to the double refresh, not just refreshing in general.
Again, thanks for the time taken to write this driver, and the quick response for bug fixes!
I do a full device refresh for every 1% of battery change on the unit automatically if you don't want to have an external refresh solution.
Ah, that is good to know. I don't think that would work in this case since I need to capture it changing to the charging state, and after that point the battery is rising. Now, if you could refresh on every 1% of battery rise as well, I could use that as it would gain 1% fairly quickly after docking and it would update the state to charging at that point.
Wouldn't you need to refresh() first see that the battery dropped? Or is that one thing that gets polled separately from all the other refresh data?
