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)
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.
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.
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),
<...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
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...
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.
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?
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.
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.
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.
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.
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!
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.
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:
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.
