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.
-
Why is the vacuum cleaner added 2 times?
If you remove the miio:generic, it appears again. -
Philips Zhirui is defined as a generic (it works), is that correct?
-
How does it work miio:generic:05743055:switchscene (Philips Zhirui)?
-
How to use miio:generic:05743055:dv (Philips Zhirui)? If you set a value, it is immediately reset to zero.
-
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:
- with wireshark log the communication between your phone and the monitor, than decode it.
- 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…
- 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 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
@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).
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