Q7 support is now merged, now onto Q10 support. please if you have a Q7 or Q10, let me know and TEST.
I installed the provided version and tested it with my two Q10. Looks good so far. Will test more in the next couple of days.
Fantastic!
Hi @Paul_Smedley ,
now I am using the new Q7/Q10 support with openHAB 5.2. It’s looking great! I started the German translation in crowdin, too. Perhaps you are able to approve my translations, but it’s still work in progress.
I won’t use many channels, but I started now for example with state-id to see what’s going on with my robot.
I can see, that you have for some of the states already a state description. But not for all of this series. I asked AI and got this mapping:
2=Ruhezustand
3=Bereit
5=Reinigung läuft
6=Rückkehr zur Ladestation
7=Fernsteuerung aktiv
8=Wird geladen
10=Pausiert
12=Fehler
14=Firmware-Update läuft
22=Staubbehälter wird entleert
29=Karte wird erstellt
99=Karte wird gespeichert
101=Position wird bestimmt
102=Saugen
103=Wischen
104=Saugen und Wischen
105=Statuswechsel
108=Wartet auf Ladevorgang
-1=Unbekannt
NULL=Unbekannt
UNDEF=Unbekannt
_=%s
| State ID | Status (EN) | Beschreibung (DE) |
|---|---|---|
| -1 | unknown | Unbekannter Status |
| 2 | sleeping | Ruhezustand |
| 3 | idle | Bereit / Inaktiv |
| 5 | cleaning | Reinigung läuft |
| 6 | returning_home | Rückkehr zur Ladestation |
| 7 | remote_control_active | Fernsteuerung aktiv |
| 8 | charging | Wird geladen |
| 10 | paused | Reinigung pausiert |
| 12 | error | Fehler |
| 14 | updating | Firmware-Update läuft |
| 22 | emptying_the_bin | Staubbehälter wird entleert |
| 29 | mapping | Karte wird erstellt |
| 99 | saving_map | Karte wird gespeichert |
| 101 | relocating | Position wird bestimmt |
| 102 | sweeping | Saugen |
| 103 | mopping | Wischen |
| 104 | sweep_and_mop | Saugen und Wischen |
| 105 | transitioning | Statuswechsel / Übergang |
| 108 | waiting_to_charge | Wartet auf den Ladevorgang |
perhaps you can confirm this mapping and also can bring the mapping directly run a future release to the binding.
Thanks for your great work!
cheers
Andreas
Don’t know if its only me, but since a couple of updates I’m having an issue sending commands. I’m on 5.2.0, Ubuntu.
My routines are all openHAB based and I send the vacuum fan power following by the mop water quantity depending of room or cleaning stage. In the past I sent the two settings followed by the clean command (directly to the command item) and I clearly hear three “dings” and the cleaning started. Now, I hear one ding for vacuum, sometimes the second ding for mop (but not always) and sometimes the routine step do not start. I had to put some sleeps between commands, but doesn’t seems to change anything, and a loop to detect the state change from 8 to 18, or keep sending the commands. Sometimes the loop does not need to trigger, sometimes it have to run 5 or 6 times. I tried adjusting the refresh times and direct communication, but as others, direct is/was unreliable (because the name of the thing?), so I returned to cloud. Oh! And sometimes the robot states ID are skipped, i.e. it goes directly from 18(cleaning room) to 8(charging) skipping 6 (returning to dock) and 22 (emptying the bin).
The debug and trace logs shown no warnings or errors… (but maybe it is murphy’s law and everything works ok when monitoring). The messages seems to be going to the robot ok, but they do nothing after that:
2026-08-05 09:03:11.175 [INFO ] [scripting.rule.roborock_dora_routine] - Dora state: 8
2026-08-05 09:03:11.176 [WARN ] [scripting.rule.roborock_dora_routine] - Dora: Falla de envío de comandos. Reintentando.
2026-08-05 09:03:11.177 [INFO ] [scripting.rule.roborock_dora_routine] - Dora: starting routine step 4
2026-08-05 09:03:11.177 [INFO ] [scripting.rule.roborock_dora_routine] - Dora Starting cleaning: mop
2026-08-05 09:03:11.183 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1785942191,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"defexx\"},\"method\":\"set_custom_mode\",\"id\":30953,\"params\":[102]}"}}
2026-08-05 09:03:11.183 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing set_custom_mode message to rr/m/i/4sxx/8cxx/3Lxxxxxxxx
2026-08-05 09:03:11.533 [DEBUG] [rock.internal.RoborockAccountHandler] - Received MQTT message for device 3Lxxxxxxxxx
2026-08-05 09:03:13.178 [INFO ] [scripting.rule.roborock_dora_routine] - Dora: Comandos de trapear enviados
2026-08-05 09:03:13.182 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1785942193,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"defexx\"},\"method\":\"set_water_box_custom_mode\",\"id\":29573,\"params\":[201]}"}}
2026-08-05 09:03:13.183 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing set_water_box_custom_mode message to rr/m/i/4sxx/8xx/3Lxxxxxx
2026-08-05 09:03:13.509 [DEBUG] [rock.internal.RoborockAccountHandler] - Received MQTT message for device 3Lxxxxxxxxxxx
2026-08-05 09:03:16.186 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1785942196,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"defexx\"},\"method\":\"app_segment_clean\",\"id\":25593,\"params\":[{\"segments\":[3,2],\"repeat\":2}]}"}}
2026-08-05 09:03:16.187 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing app_segment_clean message to rr/m/i/4sxx/8cxx/3Lxxxxx
2026-08-05 09:03:28.111 [TRACE] [orock.internal.RoborockVacuumHandler] - 3Lxxxxx: Poll: Running one-shot
2026-08-05 09:03:28.111 [DEBUG] [ernal.util.RequestCorrelationTracker] - Map correlation expired for request id 18224, method 'get_map_v1', age 121635ms
This was a defect, fixed in [roborock] Fix Q10 dynamic DPCommand channel uses incorrect case-sensitive channel type ID by psmedley · Pull Request #21252 · openhab/openhab-addons · GitHub I think it should be in 5.2.1
Updated to 5.2.1, my problem persist. I noticed that after sending the command, an mqtt message is published. When I got a “ding” I can see a log line “Received MQTT message for device wszhxxxxxxxxxx” But it is not always there after each command. It is like some commands are sent, but the robots are not getting them. I’m not able to reproduce when they get them or not. My network seems ok, as this problem appears to be exclusive to roborock devices, Any idea or suggestion to debug this?
2026-08-06 09:22:16.113 [TRACE] [orock.internal.RoborockVacuumHandler] - wszhxxxxxxxxxx: Poll: Scheduling to run in 60 seconds
2026-08-06 09:22:35.595 [INFO ] [pting.rule.oli_routine_steps_trigger] - oli State: 8 To start step: 4
2026-08-06 09:22:35.600 [INFO ] [sscripting.rule.roborock_oli_routine] - Oli: to start routine step 4
2026-08-06 09:22:35.607 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1786029755,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"ba4afd152ccce3bd7b1566534ea3a3e2\"},\"method\":\"set_custom_mode\",\"id\":30303,\"params\":[103]}"}}
2026-08-06 09:22:35.609 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing set_custom_mode message to rr/m/i/4sQNa98RldXMdGQFP0p4MN/8ceff7f9/wszhxxxxxxxxxx
2026-08-06 09:22:35.971 [DEBUG] [rock.internal.RoborockAccountHandler] - Received MQTT message for device wszhxxxxxxxxxx
[NOTE: I hear 1 DING]
2026-08-06 09:22:37.601 [INFO ] [sscripting.rule.roborock_oli_routine] - Oli: Comandos de trapear enviados
2026-08-06 09:22:37.607 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1786029757,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"ba4afd152ccce3bd7b1566534ea3a3e2\"},\"method\":\"set_water_box_custom_mode\",\"id\":13527,\"params\":[202]}"}}
2026-08-06 09:22:37.607 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing set_water_box_custom_mode message to rr/m/i/4sQNxxxxxxxxxx/8cxxx/wszhxxxxxxxxxx
2026-08-06 09:22:40.607 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1786029760,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"ba4afd1xxx\"},\"method\":\"app_segment_clean\",\"id\":12620,\"params\":[{\"segments\":[18,19,20],\"repeat\":1}]}"}}
2026-08-06 09:22:40.607 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing app_segment_clean message to rr/m/i/4sQNxxxxxxxxxx/8cxxx/wszhxxxxxxxxxx
[NOTE: The robot did not started and wait for 30s for the commands again]
2026-08-06 09:23:10.603 [INFO ] [sscripting.rule.roborock_oli_routine] - Oli state: 8
2026-08-06 09:23:10.608 [WARN ] [sscripting.rule.roborock_oli_routine] - Oli: Falla en envío e comandos. Reintentando.
2026-08-06 09:23:10.609 [INFO ] [sscripting.rule.roborock_oli_routine] - Oli: to start routine step 4
2026-08-06 09:23:10.616 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1786029790,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"ba4afd1xxx\"},\"method\":\"set_custom_mode\",\"id\":10272,\"params\":[103]}"}}
2026-08-06 09:23:10.617 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing set_custom_mode message to rr/m/i/4sQNxxxxxxxxxx/8cxxx/wszhxxxxxxxxxx
2026-08-06 09:23:10.973 [DEBUG] [rock.internal.RoborockAccountHandler] - Received MQTT message for device wszhxxxxxxxxxx
[NOTE: I Hear 1 ding]
2026-08-06 09:23:12.610 [INFO ] [sscripting.rule.roborock_oli_routine] - Oli: Comandos de trapear enviados
2026-08-06 09:23:12.615 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1786029792,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"ba4afd1xxx\"},\"method\":\"set_water_box_custom_mode\",\"id\":19730,\"params\":[202]}"}}
2026-08-06 09:23:12.615 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing set_water_box_custom_mode message to rr/m/i/4sQNxxxxxxxxxx/8cxxx/wszhxxxxxxxxxx
[NOTE: No ding]
2026-08-06 09:23:15.615 [DEBUG] [ernal.util.RequestCorrelationTracker] - Map correlation expired for request id 16870, method 'get_map_v1', age 121505ms
2026-08-06 09:23:15.616 [TRACE] [rock.internal.RoborockAccountHandler] - MQTT payload = {"t":1786029795,"dps":{"101":"{\"security\":{\"endpoint\":\"BUqmPyJg\",\"nonce\":\"ba4afd1xxx\"},\"method\":\"app_segment_clean\",\"id\":32079,\"params\":[{\"segments\":[18,19,20],\"repeat\":1}]}"}}
2026-08-06 09:23:15.616 [DEBUG] [rock.internal.RoborockAccountHandler] - Publishing app_segment_clean message to rr/m/i/4sQNxxxxxxxxxx/8cxxx/wszhxxxxxxxxxx
2026-08-06 09:23:15.967 [DEBUG] [rock.internal.RoborockAccountHandler] - Received MQTT message for device wszhxxxxxxxxxx
[NOTE: THE ROBOT STARTED CLEANING]
2026-08-06 09:23:16.114 [TRACE] [orock.internal.RoborockVacuumHandler] - wszhxxxxxxxxxx: Poll: Running one-shot
Can you give me some more details on the commands you are trying to send and the robot you are using. Q7 / Q10 support is VERY much still beta…
Sure. It is in blockly, but here is the fragment. The channels are exactly the ones the items describe. “vacuum” is the code for fan power (101,102…). One robot is an old Qrevo 2R3W from 2023, and the other is a Qrevo S5V. Both have been working fine until a couple of weeks ago. The sleeps were not there originally, but I included them when noticed that the commands were not being “processed”, when I stop listening the 3 dings from the robots.
function vacuum2() {
items.getItem('Roborock_Dora_Fan_Power').sendCommand(vacuum);
thread.sleep(3000);
items.getItem('Roborock_Dora_Water_Box_Mode').sendCommand('200'); //this changes to 201 in posterior steps
thread.sleep(3000);
console.info('Dora: Comandos de aspirar enviados');
}
... //routine. The segments have been validated an correspond to the rooms on my maps
if (step == 1) {
console.info('Dora Starting cleaning: Vacuum');
//Sala - Baño
vacuum2();
items.getItem('Roborock_Dora_Execute_Command').sendCommand('app_segment_clean,[{"segments": [3,2], "repeat": 2}]');
} else if (step == 2) {
//Comedor
vacuum2();
items.getItem('Roborock_Dora_Execute_Command').sendCommand('app_segment_clean,[{"segments": [1], "repeat": 2}]');
} else if (step == 3) {...
//Then there is a loop that check if robots changed from State ID 8 to 18. If not, call the routine again
@Paul_Smedley since a while my Qrevo Slim stopped working.
The thing has the status “Unknown” while the bridge is always online (regardless what credentials I put in after removing and re-adding the bridge).
Currently I’m on 5.2.1 release. I attached the logs.
Thanks for help!
logfile_csv.txt (221.8 KB)
I’d have to guess you got your IP blocked at some point. Pause or delete the bridge and wait at least 24 hours, then try again. I’m currently in hospital and don’t have a great deal of mental capacity to analyse the logs.
OK I asked Gemini to analyse - see https://share.gemini.google/waOTcXh6h0Ye
There’s a workaround, and a suggested code based solution. Given I have the memory of a goldfish at the moment, @CK1 are you able to create an issue for this and point to both your log and also the Gemini solution. I will try and provide a fix ASAP, I just need an hour of mental clarity - I’m just not sure when I’ll have that.
OK, I had a good nights sleep, and the brian is feeling good this morning. https://org.openhab.binding.roborock-5.3.0-SNAPSHOT.jar should fix, I’ll raise a PR shortly.
You WILL need to log back it, but it will avoid you needing to manually clear files yourself.
OK I misunderstood, I assumed your robot was a Q7 or Q10, but seems your robot is a 1.0 robot. Its possible I broke something implementing support for Q7/Q10. I’ll need to have a close look at logs. If you hear the ding from the robot it’s a good sign the command succeeded. I think I need more of a log extract to try and understand what’s going on.
The support for direct commands was done by someone else, so I no real understand of that code, but cloud I do understand. If nothing else, I will try and reproduce with my bots when I’m home from hospital, but this will be at least a week away.