the addon is broken? i don’t get the f2a code
i tried to logout and login from the app too and i got the code without problem
Are you using SMS notifications or app notifications for the 2FA code?
app notification? i get email notification when i tried to login from the phone, i didn’t set a phone number, is that the problem ?
i don’t know if italy have a different server or what
I’ll take a look at the HA code for authentication, I know SMS works, but maybe there is a different call to request 2FA where no SMS is set.
now it worked (found a mail when i was sleeping, removed the thing and made a new 1 and got the mail) maybe api problem or something else 
@Paul_Smedley do you happen to remember what was the reason for using connOpts.setKeepAliveInterval(0) ? When working on local protocol, I noticed that MQTT is kind of constantly disconnecting and reconnecting again. Reconnect seems to be very fast but not sure why, it causes map refresh to fail for some reason.
I’ve seen this python-roborock/roborock/mqtt/health_manager.py at b658ef1c125ef5c321513e7c22bd99af814a2934 · Python-roborock/python-roborock · GitHub so I was thinking to perhaps use this approach instead - keep connection alive and reconnect once it is stall only.
In any case, here is JAR file if someone wants to give local protocol a go on their end - I tested it on Saros 10, I still have Roborock S6 and I might try to turn it on to see how it behaves.
I would be also curious to hear some feedback about the exposed options. Home Assistant for instance seems to have hardcoded times for refreshing map depending on few conditions (which protocol is used, if connection is local or cloud, is robot currently cleaning and so on). UX wise, hiding options seems easier for user since amount of combinations can get bit overwhelming. Because of that, I’m not certain if exposing everything is right way of doing things but perhaps I’m overthinking. Below is pic showing all advanced options.
I’ve also added option in this JAR to easily download RRMap, which can be then used with Xiaomi Vacuum Map Viewer (to find coordinates for zone cleaning) . Personally I use it to create dynamic no go zones depending on tasks (so i.e. when going to corridor, it avoids certain area of apartment, which most likely will have some obstacles for robot) and some simple go to tasks. It allows also to find coordinates for zone cleaning without relaying on RR app, so it another plus.
I was having a lot of issues with mqtt disconnecting after a period of time, and this seemed to help keeps things stable. I think I also found that one of the other roborock implementations was doing something similar, but I could be wrong (it’s been a while)!
Hi,
It has been some time but I finally figured out what my problem was. Maybe this helps others.
The whole thing seemed odd to me – especially since I appeared to be the only one with this problem. I am not a Java programmer myself, so feel free to correct me if I’m wrong about what’s really going on.
As stated in my post from August '25(yeah i know its qwuite some time), I was not able to scan for devices due to the following error:
The TRACE log shows directly before the error:
so the error seems correct. but noone else seems to have it.
Since i am not a Java Person i asked Claude to have a look on the binding. It basically told me
Fix: Change
deviceListOrderinHome.HomeDatafromStringto a proper DTO class:
public class HomeData {
...
public DeviceListOrder deviceListOrder;
}
public class DeviceListOrder {
public long homeId;
public String type = "";
public java.util.List<ListOrderItem> listOrders;
}
public class ListOrderItem {
public String source = "";
public String did = "";
public int order;
}
So i gave it a try and build a new jar file and it worked.
The error makes sense looking at the log – but nobody else seemed to have it. My theory: Roborock is rolling out a new API response format gradually, and my account already received it. The deviceListOrder field is now returned as a JSON object instead of a string, which causes Gson to throw an exception.
it is (as far as i understand) not used anywhere else in the binding code, there appear to be no side effects.
Greetings
Thanks for investigating. I’ll admit I forgot all about this. I’ll raise a PR to fix this, my solution will be simpler, I’ll just remove deviceListOrder
https://smedley.id.au/tmp/org.openhab.binding.roborock-5.2.0-SNAPSHOT.jar should fix.
@borderbridge were you able to confirm that my build fixes your issue?
I have a Q7 Max. Managed the login process, and Account thing is now online. However, the Robot Vacuum thing is UNKNOWN and does not seem to work..
I’ve added duid to thing file after using python-roborock to find it. My thing file looks like
Bridge roborock:account:account [ email="xxx", password="yyy", twofa="zzz" ] {
roborock:vacuum:QrevoS [ duid="aaa", refresh=5 ]
}
Any tips?
Roborock Q7 and Q10 robots use a different protocol which is not yet supported in openHAB. I need to find time and motivation to investigate the required changes.
Sorry it took me so long to answer…
I just now tried your Build. It works
Thanks
Saw this in my logs… Looking through my logs, it’s happened 4 times in the past 2 months.
2026-04-18 03:24:06.832 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: Cannot read field "devices" because "homeData.result" is null
at org.openhab.binding.roborock.internal.discovery.RoborockVacuumDiscoveryService.discover(RoborockVacuumDiscoveryService.java:115)
at org.openhab.binding.roborock.internal.discovery.RoborockVacuumDiscoveryService.startScan(RoborockVacuumDiscoveryService.java:126)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
You check homeData for null here, but you don’t check homeData.result for null.
I want to look into adding support for the Roborock Q7 and Q10 series. I can get a Q7B for $A199 from Amazon (roborock Q7B).
I don’t NEED another vac… but I’m thinking that having one available locally would make development much easier. Anyone willing to chip in to help fund it?
Hi @Paul_Smedley, I have a Q7 vacuum.
I can’t get the item information in OH; I have linked the vacuum Thing, and linked new items to the needed channels, but I end up getting NULL values. E.g.:
roborock:vacuum::status#batteryroborock:vacuum::cleaning#map
System information below:
- OpenHab: openHAB
5.1.4, on Debian 13 (Trixie) - Roborock binding:
5.1.4 - Model:
roborock.vacuum.sc01(Q7 BF, Model RRA0TAC, firmware 03.01.74)
Thanks!
Hi @Paul_Smedley, thank you for your work!
I have a Q7 vacuum. I can’t get the item information in OH; I have linked the vacuum Thing, and linked new items to the needed channels, but I end up getting NULL values. E.g.:
roborock:vacuum::status#batteryroborock:vacuum::cleaning#map
System information below:
- OpenHab: openHAB
5.1.4, on Debian 13 (Trixie) - Roborock binding:
5.1.4 - Model:
roborock.vacuum.sc01(Q7 BF, Model RRA0TAC, firmware 03.01.74)
Thanks!
Hi Igor, per my message (the one that you quoted) “I want to look into adding support for the Roborock Q7 and Q10 series” - that is - the current code explicity DOES NOT support Q7 and Q10 vacs.
There is a fair bit of work to be done to revise the code to support this. It’s planned, but there is no timeframe.
Over the weekend, I got a Q7B mostly working - see the Q7/Q10 thread. There’s a new binary - https://smedley.id.au/tmp/org.openhab.binding.roborock-5.2.0-SNAPSHOT.jar