Xiaomi Robot Vacuum Binding

Add-ons Bindings
, ,
2115

Added support for Q Revo and some new channels:

I have added support for Q Revo and also added some additional features channels:

actions#collectdust → collect dust at the station
actions#cleanmopstart → start mop cleaning at the station
actions#cleanmopstop → stop mop cleaning at the station
status#is_mop_drying → Is the mop just dried?
status#mop_drying_time → Time remaining until the mop is dry.

It would be great if owners of other Xiaomi/Roborock vacuum cleaners that have the above features could check if they work on their device.

I have made my changes in 3.4, just rename the filename to jar and upload them to your addons folder, as usual.
I appricate any feedback.
org.openhab.binding.miio-3.4.6-SNAPSHOT .jar.rename.txt (509.1 KB)

1 Like
2116

Probably some additional hints. In the log-file it is written:

2023-08-01 14:18:10.388 [WARN ] [nal.transport.MiIoAsyncCommunication] - Could not parse '{"id":4870,"result":{"life":38617,"model":"roborock.vacuum.a38","token":"xdadasdf","ipflag":1,"miio_ver":"0.0.9","uid":2345505,"uptime":38629,"mac":"xxxxx4:2%6J^F~ ��O�^AƙZ^Uo^X^Dޟ0��I.�C�[^C^D^G^N�ŵ�>R��^^/=A��WoW��������ӳ���^F�:�<eF^\%Q^G��X�^F7�J^Z�Q��X^Y�q�G��4�@冬�(�^Qk�#p�^X<PV��&+^D��^�f��9":{"ssid":"fsss","bssid":"fsadf","rssi":"-14","freq":0},"netif":{"localIp":"192.168.18.18","mask":"255.255.255.0","gw":"192.168.18.1"},"miio_times":[38f16,15,0,d8600]},"exe_time":1}' <- {"id":4870,"method":"miIO.info","params":[]} (Device: xxxx03) gave error com.google.gson.stream.MalformedJsonException: Unterminated object at line 1 column 316 path $.result.mac

any clue?

2117

Some of the newer devices have slight different way for those fields then the binding expects.

I’m not sure a GitHub issue already exist for it, but if not, would be helpful to log the issue with accompanied by a debug log that shows the vacuum response during the refresh

With some luck we can implement some smarter decoding which works for both old and new models for these field

2118

This is a not related to your above issue.

However it is rather odd response in the mac field with lot of garbage. Does this already happen?

2119

A couple of days ago my MIIO things started throwing the following error:

Failed to normalize configuration for thing 'miio:basic:moppiBasic': {thing/channel=Type description miio:IJAI_VACUUM_V19_actions for miio:basic:moppiBasic:actions not found, although we checked the presence before.}
Thing 'miio:basic:moppiBasic' changed from UNINITIALIZED (DISABLED) to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): {model=Der Wert ijai.vacuum.v19 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value="text-davinci-001", label="text-davinci-001"], ParameterOption [value="text-search-curie-query-001", label="text-search-curie-query-001"], ParameterOption [value="davinci", label="davinci"], ParameterOption [value="text-babbage-001", label="text-babbage-001"], ParameterOption [value="curie-instruct-beta", label="curie-instruct-beta"], ParameterOption [value="text-davinci-003", label="text-davinci-003"], ParameterOption [value="davinci-similarity", label="davinci-similarity"], ParameterOption [value="code-davinci-edit-001", label="code-davinci-edit-001"], ParameterOption [value="text-similarity-curie-001", label="text-similarity-curie-001"], ParameterOption [value="text-embedding-ada-002", label="text-embedding-ada-002"], ParameterOption [value="ada-code-search-text", label="ada-code-search-text"], ParameterOption [value="text-search-ada-query-001", label="text-search-ada-query-001"], ParameterOption [value="babbage-search-query", label="babbage-search-query"], ParameterOption [value="ada-similarity", label="ada-similarity"], ParameterOption [value="gpt-3.5-turbo", label="gpt-3.5-turbo"], ParameterOption [value="whisper-1", label="whisper-1"], ParameterOption [value="text-search-ada-doc-001", label="text-search-ada-doc-001"], ParameterOption [value="text-search-babbage-query-001", label="text-search-babbage-query-001"], ParameterOption [value="code-search-ada-code-001", label="code-search-ada-code-001"], ParameterOption [value="curie-search-document", label="curie-search-document"], ParameterOption [value="text-search-davinci-query-001", label="text-search-davinci-query-001"], ParameterOption [value="text-search-curie-doc-001", label="text-search-curie-doc-001"], ParameterOption [value="gpt-3.5-turbo-0301", label="gpt-3.5-turbo-0301"], ParameterOption [value="babbage-search-document", label="babbage-search-document"], ParameterOption [value="babbage-code-search-text", label="babbage-code-search-text"], ParameterOption [value="davinci-instruct-beta", label="davinci-instruct-beta"], ParameterOption [value="davinci-search-query", label="davinci-search-query"], ParameterOption [value="text-similarity-babbage-001", label="text-similarity-babbage-001"], ParameterOption [value="text-davinci-002", label="text-davinci-002"], ParameterOption [value="code-search-babbage-text-001", label="code-search-babbage-text-001"], ParameterOption [value="babbage", label="babbage"], ParameterOption [value="text-search-davinci-doc-001", label="text-search-davinci-doc-001"], ParameterOption [value="code-search-ada-text-001", label="code-search-ada-text-001"], ParameterOption [value="gpt-3.5-turbo-16k-0613", label="gpt-3.5-turbo-16k-0613"], ParameterOption [value="gpt-3.5-turbo-16k", label="gpt-3.5-turbo-16k"], ParameterOption [value="ada-search-query", label="ada-search-query"], ParameterOption [value="text-similarity-ada-001", label="text-similarity-ada-001"], ParameterOption [value="ada-code-search-code", label="ada-code-search-code"], ParameterOption [value="ada", label="ada"], ParameterOption [value="text-davinci-edit-001", label="text-davinci-edit-001"], ParameterOption [value="davinci-search-document", label="davinci-search-document"], ParameterOption [value="curie-search-query", label="curie-search-query"], ParameterOption [value="babbage-similarity", label="babbage-similarity"], ParameterOption [value="ada-search-document", label="ada-search-document"], ParameterOption [value="text-ada-001", label="text-ada-001"], ParameterOption [value="text-similarity-davinci-001", label="text-similarity-davinci-001"], ParameterOption [value="curie", label="curie"], ParameterOption [value="curie-similarity", label="curie-similarity"], ParameterOption [value="gpt-3.5-turbo-0613", label="gpt-3.5-turbo-0613"], ParameterOption [value="babbage-code-search-code", label="babbage-code-search-code"], ParameterOption [value="code-search-babbage-code-001", label="code-search-babbage-code-001"], ParameterOption [value="text-search-babbage-doc-001", label="text-search-babbage-doc-001"], ParameterOption [value="text-curie-001", label="text-curie-001"]]}

The log content is - apart from the name of the MIIO thing - always the same and it happens to all MIIO things.
I did try removing and re-adding the thing and also re-installing the binding, but nothing helped.

Weird thing is that happened pretty much “out of the blue” - I did update to OH4 a couple of weeks ago, but this only happened a couple of days ago.
There’s already a discussion on this as some other bindings run into those issues as well (see at openHAB 4.0 Milestone discussion - #278 by glen_m), maybe @marcel_verpaalen you have an idea what’s causing this and/or how it can be fixed.

Thanks in advance

2120

Yes indeed, this seems to be something recently introduced, not specific related to the binding.

It is unclear how (from the binding side) I could do anything to prevent this. The dynamic creation of channels is rather fundamental to be able to support the over 350 different miio devices

I have not seen it with my devices yet, but will keep eye on it

2121

Same thing happens when I create the thing via text file… I have no idea how I can use my Xiaomi devices in OH at this point :confused:

2122

Miio Binding crash my openhab after upgrade to OH4. I have uninstalled everything and started new. Seems to be running now. But i get everytime a new device in my inbox. Is there only a way to ignore? Why will this find again and again when it’s created?

2123 
23-08-12 22:20:31.162 [WARN ] [core.thing.internal.ThingManagerImpl] - Chan
nel types or config descriptions for thing 'miio:generic:RobbyBubble' are mis
sing in the respective registry for more than 120s. In case it does not happe
n immediately after an upgrade, it should be fixed in the binding.
2023-08-12 22:20:31.346 [WARN ] [core.thing.internal.ThingManagerImpl] - Fail
ed to normalize configuration for thing 'miio:generic:RobbyBubble': {thing/ch
annel=Type description miio:DREAME_VACUUM_MC1808_vacuumaction for miio:generi
c:RobbyBubble:vacuumaction not found, although we checked the presence before
.}

Openhab stops working again and after restart I get this into my log.

2124

Have a look at the two reference implementations of the storage based thing/channel type provider. Essentially, you need to create a provider for the thing/channel types, so that they are available when the thing manager tried to initialize the things.

2125

Thank you Marcel. I hope it is not stupid, but how to log? What is the prefered message? The above mentioned log isnt enough?
Shall I open a thread in GitHub?

2126

Think it is in the readme, but in summary:
In the console type log:set DEBUG org.openhab.binding.miio

Log a minute or so, then you normally have a full refresh fully captured

Indeed, pls make a GitHub issue as then it is tracked.

2127

Hi guys, i just got today a SmartMi circulation fan 2 .I tried everything but i cant connect it to Mi Home app (china server,it is not available to eu server yet…)I find it in the app ,i reset the fan,the app scans but nothing is found.The fan’s accesspoint wifi name is all chinese letters…I just want to control it ,even for on/off from my openhab.What can i do?I own 2 other Smartmi fans and they work great with openhab…

The fan only connects normally with SmartMi Link App.Any ideas?

2128

Hi Marcel,

I created a githup-ticket. Hope the log-file is enough?

Thanks in advance.

2129

Sorry, I didn’t see your reply in reference to the issue. Is that something I can do or would @marcel_verpaalen implement it within the binding?

2130

hallo @shuo ,

Thanks for the logfile, it indeed clarifies at least why the data is not visible: the decoded data is corrupt and therefore not recognized as json. As it requires valid json for the further processing to fill the data that fails.

Note that is very different from earlier reports about not populated fields, as that issue has to do with different versions of the robot provide different values in the status json, and the binding is not smart enough to process all of the versions well.

The more intriguing question is how is it possible that the data is decoded partially right. I would either expect total garbage (which points to errors in the decryption method or key) or a valid json. Yours is something in between readable decoded characters and garbage.

Likewise the place in the string where it becomes garbage is inconsistent… I have no clue yet what is going wrong at your install.
On what sort of device are you running it? What java are you using? Is it persistent, when you restart openhab?

2131

@mancer I saw your issue in my dev environment.
It was related to items that were defined in openhab, but no longer had a json config file associated with them and/or the channel name was changed causing some misgrief.

Can it be that this is similar for you, something like a renamed channel…
What happens if you remove the linkage to the channel and restart OH?

2132

@marcel_verpaalen hello friend!
Two quick questions: is this topic only for the vaccums or for all devices that use MI Io?
And
Are you aware of the rate limit imposed to the polling rate and what value do you suggest I should put so that I don’t get soft banned by xiaomi again :slight_smile:

Loving your work!

2133

hall @Pedro_Liberal the aim for this topic is vacuums, for other devices I suggest to open a different topic.

but answering your question:
Yes, I am aware of the rate polling, but would not know the exact value hat is set by Xiaomi.
For miio binding the polling is typically set conservative ~30 seconds. Which for most devices works okay. The mihome app is depending on the task quite network intensive, e.g. during vacuuming it requests update every 2nd second.

The main challenge is with the newer devices some with 50 different channels, if you pull all of those and /or you have several of those devices and/or you have several devices set to cloud instead of direct local communication you can imagine you get hundreds of requests each minute, I think you will exceed the limits.

My suggestion:

  • ensure you only select cloud communication if really needed (there is only handful of devices that require this)
  • for devices with very high amounts of channels, decrease the refresh rate, or enable less channels. Note: if you still want both high refresh rate and loads of channels you can try the following: go to github and fetch the file of your device from org.openhab.binding.miio/src/main/resources/database and increase the value in "maxProperties": 3, e.g. to 5 or 10. My setting there is conservative many devices accept a much higher amount. This will also reduce the number of requests.
1 Like
2134

@marcel_verpaalen thanks for your reply. So I did the following:

  • Removed all channel linkings for 1 thing, rebooted OpenHABian → no change (still “HANDLER_CONFIGURATION_PENDING” and all the follwing text for that thing
  • Removed a thing I created via text file and added it to the inbox via MainUI with no channels linked at all → thing instantly goes into HANDLER_CONFIGURATION_PENDING state

Could one “bad” linking in 1 thing cause this for all the things / the whole binding?
If you think this might be the case I’d remove all the things, otherwise I’d refrain from that for now…