Xiaomi Robot Vacuum Binding

I just received my wemax USL projector. How can I find the commands and submit them for the binding?

Copied the binding file to the add-ons folder.
In the inbox 2 Philips Zhirui and a vacuum cleaner of the second version were automatically added.

  1. Why is the vacuum cleaner added 2 times?
    If you remove the miio:generic, it appears again.

  2. Philips Zhirui is defined as a generic (it works), is that correct?

  3. How does it work miio:generic:05743055:switchscene (Philips Zhirui)?

  4. How to use miio:generic:05743055:dv (Philips Zhirui)? If you set a value, it is immediately reset to zero.

  5. When reloading OpenHAB, there are such lines in the log file, is this normal?

2018-10-28 14:58:32.783 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'power' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.786 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'brightness' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.786 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'power' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.794 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'brightness' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.795 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'cct' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.796 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'scene' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.797 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'dv' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.798 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'switchscene' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.797 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'cct' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.799 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'scene' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.800 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'delayoff' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.802 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'toggle' for thing miio:generic:05743055 already exist... removing
2018-10-28 14:58:32.802 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'dv' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.803 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'switchscene' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.811 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'delayoff' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.814 [INFO ] [inding.miio.handler.MiIoBasicHandler] - Channel 'toggle' for thing miio:generic:044825EB already exist... removing
2018-10-28 14:58:32.939 [INFO ] [ing.miio.handler.MiIoAbstractHandler] - Mi IO model philips.light.downlight identified as: Xiaomi Philips Downlight (philips.light.downlight). Matches thingtype miio:basic
2018-10-28 14:58:32.962 [INFO ] [ing.miio.handler.MiIoAbstractHandler] - Mi IO model philips.light.downlight identified as: Xiaomi Philips Downlight (philips.light.downlight). Matches thingtype miio:basic

Why are these channels removed?

Those are good questions, let me try to answer them…
There are actually 2 methods in use to discover the miio devices, not all devices can be use both, but many do.
One method gets the information from announcing of the devices via mDNS. The model is send along, so the right thingtype can be created at discovery right away. This method is not suppoeted sometimes e.g. Philips’ bulbs, and the vacuum when not connected to the Internet.

The 2nd one that creates the ‘generic’ entry is the one that almost all devices use, the unfortunate is that the device model is not known at the time of discovery. Only once the token is entered, the thingtype can bet determined. Once determined, it updates the thingtype to the right one (e.g. vacuum for your vacuum, and basic for the others).

Internally both end up in the same thingtype, hence it does not matter which of the 2 you accept. You should avoid creating things for both at the same time.

This binding, unlike most bindings, creates the channels at runtime as it takes the information from database.
This is done to be simply support many different devices withou the need for coding.
This is why you see the entries for the channels being removed than created again. This is indeed fully normal and expected behavior.

Wrt to your Philips Zhirui lights… The database entry for that light was largely copied from other Philips lights and updated based on comments from various users may not be 100% correct yet.
As far as I recall switchscene cycles through various scenes that are defined. Each time the command is issued, it cycles.
for the dv channel, I believe it depends on the mode the light is in. Hence, if i does not respond to the command well, you may try a different mode, or look in the debug log what is the response the light gives after the command. (if not supported, there will be an error like ‘method not supported’

First thing to test is if it used the same protocol as the miio devices… e.g. does it show up in the discovery?
If the answer to that is yes, you find your token and add the thing… it will define it as a unsupported device.

than try some of the commands e.g. on-off probably works. In order to find more commands, there are 2 options:

  1. with wireshark log the communication between your phone and the monitor, than decode it.
  2. extract the apk plugin for your device (typically found in) \files\plugin\install\mpk\ and run it through a disassember… than try to understand the code and what it is sending…
  3. Search the internet to see if others already found the commands for it.

The 2nd option is slighly easier than the 1st as far as I have experienced.
PM me the logs if you have working communication, than I can take a look as well.
anyway, once you find

Yes it shows up and I have the token. How do you send a command?

see here

Thanks for the quick response!
As soon as I can understand your information, I will answer.
Now there is no time and this is made difficult by the complete lack of knowledge in English :slight_smile: Google translates, it is very difficult to understand)))))

How can I declare a Yeelight in the .things file? (with token, ip etc.)

Hello guys. I’m trying to send a Telegram message when Vacuum finish to clear my house. Telegram binding works, so what’s wrong?

rule "Clean finish"
when
    Channel "miio:vacuum:05C17112:cleaning#last_clean_finish" triggered
then
    sendTelegram("house", "Finish")
end

Hi @BobMiles
May I ask on which FW version you are and where you can see the option to save/store the Map?

Regards
Matt

@marcel_verpaalen

I am not clear about the mop options. Is this supported?

Thx

@smhgit no, not yet. See this post…

Dear Matt,

I don’t have it yet (US Server) - but I heard about an update being rolled out on the chinese Server…

So we’ll see!

Edit: The version will be 3.3.9_001632

My version is 3.3.9_001780, I don’t find option to save map (although I am not sure if this is newer version).

@marcel_verpaalen

Do you know if the binding supports xiaomi mijia aqara Smart Lock ?

Thx

@marcel_verpaalen

Any idea what can cause this exception?

 2018-10-31 00:42:13.339 [me.event.ThingUpdatedEvent] - Thing 'miio:vacuum:04EFCDCA' has been updated.

2018-10-31 00:42:13.418 [me.event.ThingUpdatedEvent] - Thing 'miio:vacuum:04EFCDCA' has been updated.

==> /var/log/openhab2/openhab.log <==

2018-10-31 00:42:14.254 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception

java.lang.NullPointerException: null

	at org.openhab.binding.miio.internal.Utils.hexStringToByteArray(Utils.java:40) ~[?:?]

	at org.openhab.binding.miio.handler.MiIoBasicHandler.initializeData(MiIoBasicHandler.java:221) ~[?:?]

	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

@smhgit wrt to the mobbing… try to set the fanspeed to 105 that may also be the mob mode.

Smart lock…m aqara devices are typically ZigBee devices. You need to check the mihome binding.

Your reported error smells like a token issue. If it is reoccurring can you send a larger log incl start of the binding

From what I heard both a new app version and the robot update are required.
How did you upgrade to your version?

My MiHome app version is 5.4.19. I think I updated the latest version of the roborock via the FloleVac app.

I think I saw that moping is the minimal fan speed. Does 105 means minimal in this case?

Thx, will take a look

It is not a token as after reboot (and cache cleanup and deleting mapdb data), it is back to work. don’t know why :thinking: