Xiaomi Robot Vacuum Binding

BigMountainSki · February 9, 2018, 5:49pm

Does it make sense that the Xiaomi IO Binding discovers the Xiaomi Smart Home Gateway?

I recently bought a Xiaomi Smart Home Gateway V3 to connect:

motion sensors
smoke sensors
water leak sensors …

I’ve installed the Xiaomi Smart Home Binding additionally to the Xiaomi IO Binding - which I’m using for the robot.

Now I’ve had some difficulties and confusion during auto discovery of the Xiaomi Smart Home Gateway V3.
Because the Xiaomi IO Binding discovered the gateway and the Xiaomi Smart Home Binding not.

Does it make sense that the Xiaomi IO Binding discovers the gateway?
Can I use the gateway with that binding?

marcel_verpaalen · February 9, 2018, 6:54pm

@BigMountainSki indeed it may discover it, as I believe the gateway is using the same protocol.
However, I would be very surprised it you could control the devices. (you might be able to send raw commands to it)
For controlling devices the mi home binding is developed.

marcel_verpaalen · February 9, 2018, 8:28pm

today new release

Changes:

Improved yeelights color & Yeelight LED Ceiling Lamp v4 many thanks to @Anthrax & @DaAndy
Added humidifier
Hack for fixing corrupt json from some devices

frest · February 9, 2018, 11:08pm

Thanks for the update, changing the color is now working! Saturation works as well, but if I change the Brightness, it turns blue again… (miio:generic:brightness works)

mhilbush · February 9, 2018, 11:55pm

Hey @marcel_verpaalen

I was looking at a thread dump of my OH system (using the threads command in the Karaf console), and noticed that there were a large number of these threads blocked on a datagram socket receive. My system has been up for 67 days and there was somewhere around 1650 of these threads in BLOCKED state. That’s one thread per roughly 60 minutes of uptime. Any idea why that would be the case?

"Thread-302" Id=5722 in BLOCKED on lock=java.net.DatagramSocket@4d93ddf6
     owned by Thread-5909 Id=418006
    at java.net.DatagramSocket.receive(DatagramSocket.java:729)
    at org.openhab.binding.miio.internal.discovery.MiIoDiscovery$ReceiverThread.receiveData(MiIoDiscovery.java:268)
    at org.openhab.binding.miio.internal.discovery.MiIoDiscovery$ReceiverThread.run(MiIoDiscovery.java:255)

salexes · February 10, 2018, 5:57am

Hello,

I have one question. Currently I am using the Xiaomi Mi Smart Home Binding (binding-mihome - 2.2.0) to manage my Xiaomi devices.

When I install the Xiaomi Mi IO Binding now, will they interfere with eachother or will that be no problem ?

Kind regards,
salexes

BigMountainSki · February 10, 2018, 7:19am

@marcel_verpaalen thanks for the answer.
The me home binding had some difficulties to discover.
I thought maybe there is a concurrency between these two bindings.
But if nobody else has these minor problems it’s not worth dealing with.

marcel_verpaalen · February 10, 2018, 8:33am

@mhilbush that definitely needs to be look after.
I guess it has to do that the cleanup of the receiver thread is not working well, most likely when communication errors or processing errors occur.
I’m not very skilled in such debugging, so any more info you can find where it is waiting for / stuck would be very helpful

mhilbush · February 10, 2018, 12:27pm

I took a quick look at the code last night, but I didn’t see anything obvious. I’ll look more closely this morning.

Last night I uninstalled and reinstalled the binding (by removing from addons, then putting back in addons), and the blocked threads all went away. This morning, it looks like there are 68 of them.

So, I just uninstalled again and the blocked threads went to 0.

I’ll let you know what I find out.

mhilbush · February 10, 2018, 1:08pm

It would seem interrupting a UDP socket receive is problematic.

I’ve successfully used the timeout method before (using setSoTimeout). If it can work in your situation, I actually think closing the socket is more desirable, as the effect is more immediate.

Either way, using one of these approaches should fix the issue.

Edit: Also looks like setSoTimeout is used in a number of other bindings that are receiving on a datagram socket.

mhilbush · February 10, 2018, 1:10pm

While I was looking at the code, I noticed this unnecessary line.

github.com

marcelrv/openhab2/blob/52d29f3cc32e02feb5f9d860a680ce4096ae41ee/addons/binding/org.openhab.binding.miio/src/main/java/org/openhab/binding/miio/internal/discovery/MiIoDiscovery.java#L215


    return broadcastAddresses;
}


private void sendDiscoveryRequest(String ipAddress) {
    try {
        byte[] sendData = DISCOVER_STRING;
        logger.trace("Discovery sending ping to {} from {}:{}", ipAddress, getSocket().getLocalAddress(),
                getSocket().getLocalPort());
        DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, InetAddress.getByName(ipAddress),
                PORT);
        for (int i = 1; i <= 1; i++) {
            getSocket().send(sendPacket);
        }
    } catch (Exception e) {
        logger.trace("Discovery on {} error: {}", ipAddress, e.getMessage());
    }
}


/**
 * starts the {@link ReceiverThread} thread
 */

OlivierFr · February 11, 2018, 1:58pm

Hi,
I have tried to extract my Yeelight tokens from my android device.
However, the database contains all my devices, the token column is empty.
I have also tried using MiToolkit, and it has the same result. I have the list of my devices, IP, etc but no token :

lumi.gateway.v3 - Gateway - - 192.168.1.24
lumi.sensor_motion.v2 - Occupancy Sensor - -
lumi.sensor_switch.v2 - Light Switch - -
yeelink.light.color1 - Living room light - - 192.168.1.6
yeelink.light.color1 - Hallway light - - 192.168.1.48
yeelink.light.color1 - Main kitchen light - - 192.168.1.13

Did anyone have the same issue lately?

OlivierFr · February 11, 2018, 2:36pm

I had it working.
Apparently, the problem is with the last version of MiHome, which could be a problem in the future if they have decided not to store tokens in the database anymore.
I had to install MiHome 1.0.19 version from API Mirror to make it work.

If anyone knows how to retrieve the tokens with the last version of MiHome, I am still interesting as this solution is not very convenient.

ellisbjohns · February 12, 2018, 2:09am

@DaAndy. Your method of token retrieval finally worked for me. The latest mihome app does not allow for token retrieval and flole is not able to do mihome imports as before. After trying almost every option in the forum the only thing that worked was sideloading the old mihome app. Thanks again. I wish I had read your post earlier before trying all the other suggestions.
Ellis

recap:
In the end I had to side load an older version of the xiaomi home app:
(https://www.apkmirror.com/apk/xiaomi-inc/mihome/mihome-5-0-19-release/mihome-5-0-19-android-apk-download/
And then extract using the commands/instr below:

hook up debugable phone and use: adb.exe backup n- -noapk com.xiaomi.smarthome -f backup.ab
java -jar .\android-backup-tookit\android-backup-extractor\android-backup-extractor-20180203-bin\abe.jar unpack .\backup.ab backup.tar
Use 7zip to extract tar
Use sqllite browser to mine mio2.db file
Use this sql cmd to retrieve token: select token from devicerecord

ellisbjohns · February 12, 2018, 3:06am

@marcel_verpaalen I’m using openhab 2.1.0 w/ a mi robot v1 Firmware version 3.3.9_003088 and miio binding 2.3.0.201802111049. I can get updates from the vacuum but I can’t send any commands. Log displayed below. The vacuum seems to be online per paperui interface. Any ideas on where I should troubleshoot next?

21:55:28.910 [DEBUG] [nding.miio.handler.MiIoVacuumHandler] - Skipping periodic update for ‘miio:vacuum:04EB012C’. 9 elements in queue.
21:55:58.910 [DEBUG] [nding.miio.handler.MiIoVacuumHandler] - Skipping periodic update for ‘miio:vacuum:04EB012C’. 9 elements in queue.
21:56:28.911 [DEBUG] [nding.miio.handler.MiIoVacuumHandler] - Skipping periodic update for ‘miio:vacuum:04EB012C’. 9 elements in queue.
21:56:58.911 [DEBUG] [nding.miio.handler.MiIoVacuumHandler] - Skipping periodic update for ‘miio:vacuum:04EB012C’. 9 elements in queue.
21:57:28.127 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘actionControl’ received command pause
21:57:28.130 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:23,“method”:“app_pause”,“params”:[]} -> 10.10.10.250 (Device: 04EB012C token: 5175xxxxxxxxxxB323361 Queue: 10)
21:57:28.130 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 04EB012C (10.10.10.250)
21:57:28.130 [INFO ] [marthome.event.ItemStateChangedEvent] - actionControl changed from dock to pause
21:57:28.133 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 04EB012C (10.10.10.250) success
21:57:28.135 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:24,“method”:“get_status”,“params”:[]} -> 10.10.10.250 (Device: 04EB012C token: 5175505xxxxxxxxxx3361 Queue: 11)
21:57:28.135 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 04EB012C (10.10.10.250)
21:57:28.138 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 04EB012C (10.10.10.250) success
21:57:28.911 [DEBUG] [nding.miio.handler.MiIoVacuumHandler] - Skipping periodic update for ‘miio:vacuum:04EB012C’. 11 elements in queue.

Thanks for any help you can give,
Ellis

Update: I had the correct token, but I was using the openhab 2.1 distro. After upgrading to openhab 2.2 things just worked. Not sure why but I hope this helps someone else.

marcel_verpaalen · February 12, 2018, 7:39pm

@elias_gabrielsson this typically indicates a token issue.
Are you sure you are seeing true status updates and not some older status, skipping the periodic update means you are not getting anything.
There is not really any difference between sending a command vs getting an update from the device.
Your device appears online as ping is working (IP is defined well), I expect it shows configuration error in paperUI as well (due to the issue with token)

elias_gabrielsson · February 12, 2018, 7:56pm

@ellisbjohns tagging right man for previous post.

JohnD · February 13, 2018, 2:47pm

@marcel_verpaalen I just installed your binding to control philips eyecare 2 and it works great, but I noticed that when I turn on or off the lamp manually switch state in the openhab is not updated. Is it possible to fix it somehow ?

P.S. Thank you for your wonderful work

robotron · February 14, 2018, 5:02pm

Thanks allot for the binding!
I managed to turn my yeelight ceiling on & off, dimm it and control it with Alexa so far.
Unfortunately I am still a bloody beginner and am struggling with setting up everything else.
If someone could help me out with an example of his/her item and sitemap file I would be very thankful.
Thanks again .

Anthrax · February 15, 2018, 8:29am

Hey @frest,

what kind of device are you having?