first of all: thank you for all the effort!
I noticed the Binding and was very excited to try it out. It would really be great.
But somehow i cant get it to work.
For some context: I have Openhab 5 running in a Docker container
I installed the binding and added the account thing. So far it worked. The roborockapp even notified me about the new login.
If i press the scan button the progress bar moves and then nothing happens. In the log i see the following: “17:11:54.924”,“ERROR”,“org.openhab.core.config.discovery.internal.DiscoveryServiceRegistryImpl”,“Cannot trigger scan for thing types ‘[roborock:vacuum, roborock:account]’ on ‘RoborockVacuumDiscoveryService’!”
Aditional info:
Level
ERROR
Logger Class
org.openhab.core.config.discovery.internal.DiscoveryServiceRegistryImpl
Message
Cannot trigger scan for thing types '[roborock:vacuum, roborock:account]' on 'RoborockVacuumDiscoveryService'!
Stack Trace
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 1 column 120 path $.data.deviceListOrder
See https://github.com/google/gson/blob/main/Troubleshooting.md#unexpected-json-structure
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:520)
at
Thanks for testing. Increase logging to trace for the roborock binding and try again. I need to see the full log.
Edit: I was able to reproduce here if I hit Scan straight after creating the Account Thing. If I wait a short while after creating the Thing, the robots appear in the Inbox. I understand why this is the case - it’s a timing thing with the initAPI() function not having been run yet. I’ll fix when I get a moment.
I’m having issues right now building a .jar that’s compatible with OH 5.0
Building with just ‘mvn clean install’ results in a jar that won’t load due to not having the right gson version; building with OH 5.0 compatability is failing.
Heads up to folks, as the review process of the PR has commenced, there will be some BREAKING changes in the next build. You will need to remove the Account and Vacuum things and re-configure. Unless there are any serious bugs, I won’t do any more public releases until things are stabilised to avoid people having to reconfigure twice.
I saw this in my logs a couple days ago. I’m not sure what caused the name resolution issue, but it was only temporary. I had to restart the binding to get it working again.
First time I saw it as well. I think there was a hiccup in my Internet connection that caused a DNS lookup failure.
The question is whether this failure should cause the binding’s scheduled job to end. Since it is potentially a temporary failure, I would argue that the scheduled job should continue to run. One of two things will happen… The problem will clear on the next scheduled run, or the problem will persist causing the user to investigate the reason why the bridge thing is OFFLINE.
I don’t disagree, I’ll have to look at the code. I think I got paranoid with the roborock mqtt server banning the token and potentially the IP for repeated failed calls, that I may have gone too far the other way in going offline as a precaution.
2025-09-03 02:13:48.703 [DEBUG] [ab.binding.roborock.internal.RoborockVacuumHandler] - Bridge status changed to OFFLINE (CONFIGURATION_ERROR): Error java.net.UnknownHostException: usiot.roborock.com:
Temporary failure in name resolution
Interestingly, I’ve seen this occur in two geographically different locations. Same ISP (Comcast) but the locations are 600 miles apart.
Did you have a chance to look at this? It really is an annoying problem because the thing goes offline and requires a binding restart to get it back online?
Unfortunately not. I’ve had some health issues, so the only current priority is trying to get the PR approved, I cna focus on other fixes after that. Interestingly, I had to replace my cable modem yesterday, which causes some connectivity issues, yet my binding is still online.
note the file name difference if you’ve installed a marketplace build. As mentioned earlier, this has BREAKING changes to channel names, so you need to remove all things and re-create them.
OK I had a quick look this evening, easy enough to see why it fails, see:
I guess the question is how best to handle this, perhaps I just remove the line and just return null in the event of an error? (for the calls to update routines, home details, home)
FYI - I’ve added a switch on my sitemap for routines:
Switch item=Roborock_Qrevo_S_Vacuum_Routine_routine mappings=["3582307"="Vac followed by Mop","3582305"="Deep","3600238"="Deep+","3582309"="Intensive Sweeping"] label="QRevo S Routine"
Glad it’s working for you
There is some progress over at python-roborock for the ‘newer’ API - however, at the moment, they only have it working for local commands, not cloud commands.
At some point I want to support local commands, but I need to get my head around how best to factor this code in.
Hi, I’ve been configuring my robot in milestone version of binding and noticed few things when using Saros 10 robot:
I have following warning and status on robot not updating when I use as robot name something different than its DUID. I’m using textual configuration
Received MQTT message for unknown device destination: 3UwVu2bllGDFVBoHA75Hwq
Thing roborock:vacuum:6032cc6fc8:3UwVu2bllGDFVBoHA75Hwq - this works
Thing roborock:vacuum:6032cc6fc8:robot_01 - this will not work and status will not update
I have two issue constantly appearing in my logs related to fw-features. I guess maybe its because of newer protocol it is using?
Could not create channel 'fw-features', because channel type 'roborock:fw-features' could not be found.
Cannot find channel type: roborock:fw-features
Channels like actions#collect-dust are executing action no matter what kind of command is sent (it seems “-” would not trigger it, which I guess is not a valid state for switch unit anyway?), so you dust collection will be started even if you send command “OFF” to it. This is very annoying when using file base configuration - every time when I save file, dock starts: drying mop (clean-mop-start), stopping drying mop (clean-mop-stop) and then it collects dust (collect-dust)
It seems it was also the case in MIIO binding - previously, I had robot without docking station so I’m not sure if that was also happening over there
As a side note, app_stop_collect_dust seems to be missing from binding
Other than that, bindings seems to work. I configured routines and I was able to execute them from Openhab so kudos for the hard work! I’m also looking forward to see local control.
