Ok. Thanks. Iàve also tried on 3.10 and it was not working. I could try to install a second instance with 3.0 on another PC and check if it works.
No need if you have time to wait. I used another binding as a starting point and probably haven’t removed this requirement.
1 Like
as I received a donated gateway unit (thanks @rvalle), last week I spend some time in making the existing miio binding ready for the gateways. See the preliminary results here
[miio] implement lumi devices support for gateways reading only
Adding (experimental) support for the following models:
- Aqara LED Light Bulb (Tunable White) (modelId: lumi.light.aqcn02)
- IKEA E27 white spectrum opal (modelId: ikea.light.led1545g12)
- IKEA E27 white spectrum clear (modelId: ikea.light.led1546g12)
- IKEA E14 white spectrum (modelId: ikea.light.led1536g5)
- IKEA GU10 white spectrum (modelId: ikea.light.led1537r6)
- IKEA E27 warm white (modelId: ikea.light.led1623g12)
- IKEA GU10 warm white (modelId: ikea.light.led1650r5)
- IKEA E14 warm white (modelId: ikea.light.led1649c5)
- Door lock (modelId: lumi.lock.v1)
- Aqara Door Lock (modelId: lumi.lock.aq1)
- Aqara Door Lock S2 (modelId: lumi.lock.acn02)
- Aqara Door lock S2 Pro (modelId: lumi.lock.acn03)
- Mi Temperature and Humidity Sensor (modelId: lumi.sensor_ht.v1)
- Aqara Temperature and Humidity Sensor (modelId: lumi.weather.v1)
parrallel I submitted some PRs that build the necessary functionality to also control lumi devices.
As @moody_blue shared some of his devices in the mihome app, I hope to add those next week as well.
2 Likes
Ok I’ll wait. Thanks for advice…
1 Like
For those that want to try the binding with lumi/gateway support, please find it here
https://verpaalen.com/openhab2/org.openhab.binding.miio-3.2.0-SNAPSHOT.jar
Adding support for the following models:
* Aqara LED Light Bulb (Tunable White) (modelId: lumi.light.aqcn02)
* IKEA E27 white spectrum opal (modelId: ikea.light.led1545g12)
* IKEA E27 white spectrum clear (modelId: ikea.light.led1546g12)
* IKEA E14 white spectrum (modelId: ikea.light.led1536g5)
* IKEA GU10 white spectrum (modelId: ikea.light.led1537r6)
* IKEA E27 warm white (modelId: ikea.light.led1623g12)
* IKEA GU10 warm white (modelId: ikea.light.led1650r5)
* IKEA E14 warm white (modelId: ikea.light.led1649c5)
* Door lock (modelId: lumi.lock.v1)
* Aqara Door Lock (modelId: lumi.lock.aq1)
* Aqara Door Lock S2 (modelId: lumi.lock.acn02)
* Aqara Door lock S2 Pro (modelId: lumi.lock.acn03)
* Mi Smart Plug (Zigbee) (modelId: lumi.plug.mmeu01)
* Mi Temperature and Humidity Sensor (modelId: lumi.sensor_ht.v1)
* Mi Window and Door Sensor (modelId: lumi.sensor_magnet.v2)
* Mi Motion Sensor (modelId: lumi.sensor_motion.v2)
* Water Leak Sensor (modelId: lumi.sensor_wleak.aq1)
* Aqara Temperature and Humidity Sensor (modelId: lumi.weather.v1)
Source here
Notes:
- If you already had the gateway in the miio binding, it needs to be removed first (otherwise it won’t be detected as ‘bridge’ and lumi devices cannot communicate)
- Most devices are readonly for now, except for the lumi plug, which can be fully controlled.
- For now, the lumi devices need to manually connected to the gateway in the thing configuration. So after discovery go to the thing page and select your gateway (see screenie below)
- If you have a lumi device that is not on the list yet and you want it supported. You can share the device in the mihome app and we can probably figure out how to read/control it. (contact me with a pm)
For the device logs, you can use the below code to render the log similar as the images in the previous post (in the developer tools menu (in the right side navigator), click widget and add widget. There paste below code in the widget editor)
uid: datatab
tags: []
props:
parameters:
- context: item
description: Log Item
label: log
name: logArray
required: false
type: TEXT
- default: Events
description: An item to control
label: Header Text
name: header
required: false
type: TEXT
- default: '{"event.plug_detection": "Appliance Event","prop.channel_0": "Power","event.leak": "Leak", "event.no_leak": "No Leak", "event.motion": "Motion" , "event.open": "Open" , "event.close": "Close"}'
description: Mapping of values
label: Mapping
name: mapping
required: false
type: TEXT
- default: '{"on": "f7:power","off": "f7:power"}'
description: Mapping of icons to values
label: Icons
name: icons
required: false
type: TEXT
timestamp: Jul 19, 2021, 8:33:12 PM
component: f7-card
config:
title: =props.header
slots:
default:
- component: oh-list
slots:
default:
- component: oh-repeater
config:
for: eventLines
in: =JSON.parse(items[props.logArray].state)
fragment: true
slots:
default:
- component: oh-list-item
config:
icon: '=(JSON.parse(props.icons)[loop.eventLines[1][1]] == undefined ? "f7:calendar_today" : JSON.parse(props.icon)[loop.eventLines[1][1]] )'
title: =dayjs(loop.eventLines[0]*1000 ).format("DD-MM-YYYY HH:mm") + " " + (loop.eventLines[1][1] == "" ? " " :JSON.parse(props.mapping)[loop.eventLines[1][0]] )
badge: '=(loop.eventLines[1][1] == "") ? JSON.parse(props.mapping)[loop.eventLines[1][0]] : loop.eventLines[1][1]'
badgeColor: '=(loop.eventLines[1][1] == "on") ? "green" : (loop.eventLines[1][1] == "off") ? "red" : "blue"'
after: =( JSON.parse(props.mapping)[loop.eventLines[1][0]] == undefined ? loop.eventLines[1][0] :null)
tooltip: =loop.eventLines[1]
style:
--f7-list-item-after-font-weight: bold
1 Like
@Murazor If you are still interested - I’ve compiled it for 3.1.0 Release beta - v04 · hubaksis/org.openhab.binding.xiaomigatewayv3 · GitHub
@marcel_verpaalen You’ve done a great job implementing miio binding, so probably it’s a good place to continue development there.
A couple of questions:
- How it is possible to find Device ID to be able to setup a new “Xiaomi Mi Lumi Gateway subdevice”? I have device ids from my previous research for my devices , but I don’t have an easy way to find them.
- I suppose that you use miio protocol to communicate with devices. If so - does it immediately inform of the event happened (like the door was opened)?
Also I have an issue setting up the door sensor.
I set up the bridge - gateway (by entering the token and IP address) - it works fine. Then I tried to setup a door sensor (lumi.sensor_magnet.v2).
I tried using Device ID in different formats: 158dxxxxxxxx59, 0x00158dxxxxxxxx59 - and received errors in logs: {"code":-5015,"message":"device not found"}.
Then I modified code a bit to get device list by binding and got this response (part of it):
{"did":"lumi.158dxxxxxxxx59","model":"lumi.sensor_magnet.v2","num":1,"total":5}
I used the string lumi.158dxxxxxxxx59 for the Device Id - and now I receive an error
{"code":-4003,"message":"prop or action not exist"}
Any ideas why this is happening and how to fix it?
1 Like
I use the cloud discovery for that purpose as the newer gateway don’t provide this info via the local (miio) interface.
This is something I (still) don’t fully know. I’m sure the device does not provide an event directly via the miio interface (as I think it does with the telnet interface?), but it seems possible to somehow subscribe to the events via the cloud.
I can imagine we merge indeed your telnet interface somehow so we can get to the events in an easier way (without neededing the cloud)
Yes, as you may have seen, in the recent changes in the miio binding I changed to the did as it is provided from Xiaomi, hence the full string lumi.158dxxxxxxxx59. If it does not directly discover it, you can look at the /userdata/miio folder to the json files.
I did not see the {"code":-4003,"message":"prop or action not exist"} do you know which is the problematic property that gives this error? Maybe there is a difference between the various gateways, as the one I have always seem to give a response, even if the requested property is actually invalid
Telnet is used for enabling MQTT, then everything works with MQTT. So it’s immediate notification about status changes.
I think it’s possible to use both approaches and have new settings for some devices something like ‘mqtt support’ with parameters.
Property 'open'
received miio:gateway:xiaomi-gateway-v3 command from miio:lumi:xiaomi-gateway-v3:4axxxx347 : get_device_prop_exp - [["lumi.158dxxxxxxxx59","open"]]
Command added to Queue {"id":1347,"method":"get_device_prop_exp","params":[["lumi.158dxxxxxxxx59","open"]]} -> 192.168.1.168 (Device: 40xxxxx65 token: 73545250XXXXXXXXXXXXXXXX577A6B6A Queue: 1).
Error received for command '{"id":1349,"method":"get_device_prop_exp","params":[["lumi.158dxxxxxxxx59","open"]]}': {"code":-4003,"message":"prop or action not exist"}.
By the way, should device ids be kept secret? Token for the gateway should definitely be, may be there is no reason to hide deviceIds?
Yes fully agree. Does it require a modded gateway or any gateway model has this? ( I was under the impression it requires specific models/firmware mods)
Once I’m back from holidays and some time, ill give your binding a try to understand what/how it is communicating.
To my knowledge there is nothing one could do with just the deviceId, I’m not keeping mine secret.
In the miio logs I don’t show the token as the combination of did+token MAY allow for some level of control over the device.(even that I’m not confident, if it allows remote control, just local I think. Normal remote control requires the device being shared with you in the mihome app, but in that case no need for the token)
Everything I’ve done is based on this home assistant project. It has some requirements regarding the version but not sure if it’s strict. After enabling telnet on the device it’s possible to do everything automatically (enable public MQTT, install updated bluetooth module, etc. if required).
What is the latest code I can use? Is it only in the miio-lumiGatewayDevicesv3 tree or somewhere in the main branch?
The miio-lumiGatewayDevicesv3 is indeed the last published one.
As you can see it mainly reuses existing code from the binding. But did require some structure changes (like did format) that in the meantime have been merged
I’m just trying this. I get that “AutoDiscovery: model lumi.sensor_motion.v2 is not yet supported” so it is sad for me as I have 3 of this.
And also my 3 ‘miaomiaoce.sensor_ht.t2’ are not yet supported
I have 3 ‘miaomiaoce.sensor_ht.t2’ that are not yet in the database. And also my ‘lumi.sensor_motion.v2’ is not working well… I didn’t get changes for log or movement.
Is it “Xiaomi Motion Sensor RTCGQ01LM” or “Aqara Motion Sensor RTCGQ11LM”?
To be able to get log or movement immediately after it happened some changes need to be made to the system. Working on it.
Hi there, they are “Xiaomi Motion Sensor RTCGQ01LM”.
Hi,
I have been using the Xiaomi Mi IO binding for a while now and I love it. I also had Dexter’s binding working, but since moving to 3.2 this is not working anymore as it’s only compiled for 3.1.
The Xiaomi Mi IO binding detects all my devices, but there’s no token (not a problem as I can get that), but more importantly, there’s no ip address. This is because they are linked to my new Xiaomi gateway 3. Is there anyway I can get these to work?
For some others I do have an ip address, but the token is wrong (ab1bffb355b721ac02160cfd). When I replace it with the one I have got using ibackup, it still says it’s wrong (91254407cce963577825093a0cd837e63770482038666e1c250e57508bb0f975).
Any help or pointers would be greatily appreciated 
Thanks,
Pim
Can you please check the error message in logs?
I’ve just upgraded my installation to 3.2M2 and didn’t have to replace the binding - everything works as it was before.
Just in case - I’ve compiled it once again - binaries are here
I’ve also added support for Xiaomi Motion Sensor RTCGQ01LM.
Still trying to figure out how to merge my binding with miio. Takes much more time than I expected, so I will be adding new devices by request to my binding.
1 Like
I didn’t get any errors as the inbox items where created.
They just show up without token or IP address or like this.
Sorry, I meant this part of the issue.
Secondly, please describe what devices you have, which are found/working and what is not working as you expect.
Is this the screenshot of the gateway or a connected device to the gateway? In either case they should have a different type like ‘Xiaomi Mi Gateway Device’ or ‘Xiaomi Mi Lumi Gateway subdevice’ if you are using the latest binding from marcel_verpaalen
Also please try to REPLACE the binding with this one.
I have added a direct request to the gateway to receive all connected devices. It will show up in the logs like this after the binding installation:
2021-09-24 09:53:19.707 [INFO ] [internal.handler.MiIoAbstractHandler] - Found devices count: 5
2021-09-24 09:53:19.709 [INFO ] [internal.handler.MiIoAbstractHandler] - Devices: {"code":0,"result":[{"did":"lumi.158d00015a9347","model":"lumi.sensor_magnet.v2","num":1,"total":5},{"did":"lumi.158d0001df4c87","model":"lumi.sensor_motion.aq2","num":2,"total":5},{"did":"lumi.158d000288ce59","model":"lumi.sensor_magnet.v2","num":3,"total":5},{"did":"lumi.158d000288cee1","model":"lumi.sensor_magnet.v2","num":4,"total":5},{"did":"lumi.158d00028a13c4","model":"lumi.sensor_magnet.v2","num":5,"total":5}],"id":3607}
It will show what Zigbee devices the gateway is aware of.