Hey,
didi you find a solution?
I’m at a similar situation. I used to have two S5 over years. One of them is going to be replaced by a q revo.
It looks like the new one is using a ne protocol, and app_zoned_clean is not working anymore.
My guess is, that cleaning a zome can by done with “in” and “out” on e.g. “vacuum-start-sweep-mop”. But as far as I can figure out these params just for room, not for segments!?
yes, those use indeed different protocol (miot). Most likely also the map will not work for those.
Finding the exact format for your zone cleaning will be tricky indeed. You need to examine the source code of the device and try to understand how the coordinates are determined.
So, okay.
Is that the first one with the new protocol?
What about the s7 max? Or the s8?
Thx
Hello. I installed the biding and my Q7Max and most of the items are working fine. Except following:
history#total_clean_area, history#total_clean_time oder history#total_clean_count
cleaning#last_clean_start_time, cleaning#last_clean_end_time, cleaning#last_clean_area, cleaning#last_clean_duration, cleaning#last_clean_error und cleaning#last_clean_finish
Does anybody has an idea what I am doing wrong?
Thanks in advance
Any idea? I assume I am not the only one having this issue?
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)
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?
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
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?
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
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
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 
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?
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.
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.
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?
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.
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?
Hi Marcel,
I created a githup-ticket. Hope the log-file is enough?
Thanks in advance.
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?