[Release] Xiaomi / Aqara device drivers

community_driver

#586

@veeceeoh, I just received a pair of

bulbs. They seem to work properly with the built-in Generic Zigbee CT Bulb (dev) driver, so it seems no custom DTH needed.

@mike.maxwell, the only issue with this driver is that it throws exceptions sometimes (probably when those dreaded Xiaomi strings arrive):

[dev:769]2019-03-20 07:09:36.151 am [error] java.lang.NumberFormatException: For input string: "(/!a'! ! !0Àd e 3f!ú" (parse)
[dev:769]2019-03-20 07:04:09.344 am [error] java.lang.NumberFormatException: For input string: "(2!a'! ! !0Àd e 3f!ú" (parse)

And the info for fingerprinting:

Manufacturer: LUMI
Product Name: Device
Model Number: lumi.light.aqcn02
deviceTypeId: 15
manufacturer:LUMI
address64bit:00158D0002D39D81
address16bit:4973
model:lumi.light.aqcn02
basicAttributesInitialized:true
application:17
endpoints.01.manufacturer:LUMI
endpoints.01.idAsInt:1
endpoints.01.inClusters:0000,0004,0003,0005,000A,0102,000D,0013,0006,0001,0406,0008,0300,0403,0405,0402
endpoints.01.endpointId:01
endpoints.01.profileId:0104
endpoints.01.application:17
endpoints.01.outClusters:0019,000A,000D,0102,0013,0006,0001,0406,0008,0300
endpoints.01.initialized:true
endpoints.01.model:lumi.light.aqcn02
endpoints.01.stage:4

#587

It they are throwing those errors during operation, the built in driver Isnt going to work.
There is a zigbee rgbw driver in our public repo you could use as a starting point if you want to build up a custom driver for these.


#588

IMHO the exceptions are thrown when the peroidic Xiaomi "string" arrives, everything is working flawlessly otherwise (commands work, reports received without throwing exceptions).

Maybe I'll write a DTH just to see what causes these exceptions, but the built-in driver is definitely working with these bulbs.


#589

I couldn't resist, checked what causes the exception.

I assume your CT driver is quite similar to the RGBW sample, so the problem is that now, that string attributes are parsed back to binary string (since 2.0.5 I think),

Integer.parseInt(descMap.value,16)

fails on string values.

I think the log explains everything:

[dev:769]2019-03-20 03:49:50.199 pm [error]java.lang.NumberFormatException: For input string: "($!a'! ! !0Àd e 3f!ú" on line 67 (parse)
[dev:769]2019-03-20 03:49:50.189 pm [debug]parse description: read attr - raw: 49730100005601FF42270328240521170007270000000000000000082117010921000A0A2130C06420006520336621FA00, dni: 4973, endpoint: 01, cluster: 0000, size: 56, attrId: FF01, encoding: 42, command: 0A, value: 270328240521170007270000000000000000082117010921000A0A2130C06420006520336621FA00

This is how the code looks like:

<...snip...>
if (logEnable) log.debug "parse description: ${description}"
if (description.startsWith("catchall")) return
def descMap = zigbee.parseDescriptionAsMap(description)
def descriptionText
def rawValue = Integer.parseInt(descMap.value,16) // THIS IS WHERE THE EXCEPTION IS THROWN
def value
def name
def unit
switch (descMap.clusterInt){
    case 6: //switch
        if (descMap.attrInt == 0){
            value = rawValue == 1 ? "on" : "off"
<...snip...>

I think the current method causes exceptions on EVERY reported string attribute, so in this case the exception is not Xiaomi's fault. Moving rawValue parsing into case blocks would be much safer... It's a generic driver, it shouldn't fail on messages that otherwise follow the standard :smiley:

Edit: That's why I recommended to make a hexValue field in the map that contains the original hexadecimal string: that field would work even in this case...


#590

I've updated my device chart with that ZigBee model - thanks! If/when you make a custom device driver, I'll add the link in there, too.

Now, what I'm really wondering is:

  • Are all of those in/out clusters actually used?!?
  • Does the bulb work as a ZigBee router?

#591

The built-in driver is fuctionally perfect, it just fills the logs with exceptions in every 5 minutes (when the 0xFF01 string arrives). I proposed a fix for @mike.maxwell above, if they implement it (or any other solution), the built-in driver will be just fine. If they decide to keep it this way, then I'll make a new one.

I don't think so...

Yes, it does:

image


#592

Hmm quite interesting


#593

Hmm. Besides the expected Basic, On/Off, Color Control, and Level IN clusters, I see Power Configuration, Groups, Scenes, Time, Analog Output, Multi-state Output, Occupancy Sensing, Temperature Measurement, Relative Humidity Measurement, Pressure Measurement, and... Window Covering (?!?).

Are you seeing any temperature / humidity / pressure reports?

Yay! The next question is: Does it work well as a router for both Xiaomi / Aqara devices and other ZigBee devices?


#594

Btw @veeceeoh, I have a smoke sensor as well... do you want to implement (or want me to implement) sensitivity setting in your DTH? Or a test command? I have the packet dump for these features...

And... I ordered a funky little LLKZMK11LM... (who the hell is responsible for these codes?) Seems to be a useful addition to the Aqara lineup.


#595

No, nothing... most probably groups and scenes are supported, but the rest is just the result of copy-pasting firmware code from NXP's SDK. :slight_smile:

Well... this is a question I won't be able to respond... I have to confess that even though I have a pretty heterogeneous mesh, I have no routing issues with Xiaomi devices... that's why I'm quite silent in those topics, I simply cannot reproduce those issues. :slight_smile:


#596

Oh yes please! Adding any functions not in the current driver would be very welcome. Since I don't own a smoke sensor, can you either share your code additions or make a pull request in GitHub?

Another thing people have asked about is a command to manually silence the alarm, but I have not seen any evidence that it's even available when the sensor is used with a Xiaomi/Aqara Gateway.

@martyn mentioned that Aqara Relay module a few days ago, and when I checked I noticed it's rated for 50Hz.

If the relays are coil-based then using the module with 60Hz power would affect impedance and then the device would be operating out-of-spec, so I will wait to hear about the internals before ordering one to try out.

Yes, probably, but with all of that and the "dreaded" FF01 attribute string, I'd have to guess this bulb is not part of Aqara's new ZigBee 3.0 Certified device lineup.

You must not have any "incompatible" routers on your mesh, fortunately!


#597

Sorry for the bad news, but there are no plans to officially support Xiaomi devices at this time, we will review this if and when Zigbee certified 3.0 devices become available.
I would not recommend running any driver device combination that blows any errors...

The first time you log a support ticket the first thing we'll make you do is disable the device, and or potentially remove it.


Hubitat Support will not help with custom code. Why?
Hubitat Support will not help with custom code. Why?
#598

Could you test with this driver? Maybe small mods will make it work properly


split this topic #599

14 posts were split to a new topic: Why won't Hubitat Support help me with my custom


#600

Question for the Xiaomi SME's.

If a joined device sends another catchall mesaage, is that the device rejoining the mesh?

I have my driver set to log any messages that they don't handle once joined and every now and then I see this. (very infrequently)


#601

Pull request created. :wink:


#602

Some of my Aqara devices state their battery status as "-396%", for example the Xiaomi Aqara Leak Sensor with driver version 0.8 shows this:

Or the "Xiaomi Aqara Door/Window Sensor" with driver version 0.7.2:

I have reset the battery status but no luck.


#603

The percentage is just calculated from the raw voltage reading received from the sensor, which is clearly incorrect (0.522 V for your Leak Sensor, and 0.01 V for the Door/Window Sensor).

That voltage value is derived from values of specific bytes in a custom-formatted message, so what's probably happening here is that either the wrong bytes are being read, or they are in the wrong order.

The Reset Battery Replaced Date doesn't affect any of the voltage / percentage reporting. It just exactly what it named, changing batteryLastReplaced to the date when you click that button, so that a user can refer to that date for record keeping.

Since my Aqara Leak Sensor and Aqara Door/Window Sensors are all reporting correctly, and I haven't heard from other users about incorrect voltage values, my guess is that either you might either still be using Hubitat firmware 2.0.4 or older, or if using the latest Hubitat firmware, the DISABLE 2.0.5 firmware compatibility fix setting is turned on in the preferences for the devices:

If my guesses are incorrect, the only way I can help troubleshoot this is to see debug log output from the time of a battery report.


#604

@veeceeoh Keith- Have you released the update to the driver that asked for sensitivity adjustment of the vibration sensor? Thanks for everything?


#605

I'm afraid not yet. I was working out a user-friendly method to implement it (because of course, Xiaomi does it in a non-standard way!) However, I've had technical difficulties with my new ZigBee sniffer and family visiting the last few weeks. Although I can reply in the forums here in between things at workout times, any code changes and testing can only be done at home...

I hope to have an update in the next week, though.

Sorry everyone! Thanks for your patience.