Xiaomi & Aqara Devices - Pairing & Keeping them connected

[bertabcd1234]

@aaiyar

I took off info reporting?

That's got to be it.

I guess veeceeoh would know for sure, but looking at the driver, the "Enable info message logging" preference just disables logging of the events when they happen. The actual events still get created and should count as activity (and actually, logging alone would not not count).

You should be able to generate a log entry, if debug logging is enabled, from the device by short-pressing the "reset" button. In some cases, it looks like this will also create a battery event. (If it doesn't, it's just a log entry, which, again, won't count as activity.) So if you want to manually check that it's working without getting it wet, that would be one way (but unlike stock drivers and Hubitat tradition, debug logging won't ever automatically disable itself, so you'd have to do that if you care). I'm still not sure why yours wouldn't be doing the hourly checkins, which should create an event for at least the battery level--obviously that would be great so you could automate the whole thing with Device Watchdog or similar.

[vjv]

I use device watchdog for my xiaomis

I know every day if something dropped off, worked fine, I have an humidity sensor that is dropping off after I replaced the ikeas outlets for the repeaters....

[jtmpush18]

Which "reset" button are you referring to?
"reset battery date"
"reset to dry"
"reset to wet"

Every morning , I "press" the "reset battery date" - but that doesn't result in any additional reporting of battery levels.

[bertabcd1234]

@jtmpush18

Which "reset" button

The one on the device itself that you use to pair or reset it if you hold it in (don't hold it in this case).

[gavincampbell]

@jtmpush18

Please look at the screen shot that I uploaded earlier. It shows that from Dec 4 to Dec 20, the only activity was me sending "battery replaced date", NO other reporting. Yet the physical test shows that this sensor still worked.
Why?

Look at the "Last Activity At" date/time. Is it in the last hour or two?

Anytime a driver sends a sendEvent command and something is updated that time should be updated. If that time is getting updated then the device should be active and running. Unfortunately by sending the reset battery date command as well triggers this. I'm not sure though why you do this. It does not trigger anything on the device itself. All it does is create that event in the device event log and log that it did that.

I'm looking at the driver and the device doesn't have a reset or a poll command so you can't do that. Basically you just wait and watch the last event at field or there are also attributes called lastCheckinTime or lastCheckinEpoch that you can monitor as they get updated with new events. I don't know if you can monitor those with device watchdog though. The 'last event at' should work fine though.

[jtmpush18]

Another question, from the same time of device, another location.
The following is a screen shot from another Aqara Leak sensor. It shows that the last checkin date/time was: Dec 20, 1:48pm. Since it hasn't reported in the last day, I'm ready to declare this sensor as "off the ranch".

However, look at the following screen shot from my logs, (filtered with just that device):

Can anyone tell me why all those battery events weren't reported in the device status page?

[bjcowles]

@jtmpush18

Can anyone tell me why all those battery events weren't reported in the device status page

My guess would be that there isn't an event created because the battery reports are unchanged.

As to the first part, I don't know why the last checkins would stop. Are they still selected in the preferences?

[jtmpush18]

Preferences page screen shot:

[bjcowles]

OK, so that is really weird. You have a recent checkin on the device page but not in the event log. I'll turn it on for my leak sensors and see what happens.

[peter]

Decided to reset the ZigBee radio, went round and first connected the Ikea Outlets then the Aqara wired switches (these have never been an issue) and then the wireless switches. All working flawlessly...well for 24 hours then the wireless switches did not respond but tap them a few times and they spring back to life, sometimes you have to press them 10 plus times but they always come back to life and then will stop responding after an indeterminate time, tap them again and they are back on. I decided to put a single switch onto my smartthings hub using veeceeoh's driver and this has not dropped once whereas the same switches are dropping on the Hubitat. Interestingly since going back to a lower update the Ikea's have remained solid. The switches when detected by the hub after dropping off still come up with the strange behaviour I posted about earlier then work until they don't respond again. Could they maybe trying to route through some other device? The only other ZigBee kit I have are Philips bulbs and a switch oh and a Philips hub.

Pete

[peter]

I have spent the Holiday Season having a reconfigure, I have removed the Philips Hue hub and reprogrammed the Hubitat with the Hue bulbs and app sequances. So far (3 days) everything has stayed connected and quick, the wireless switches have shown no tendency to fall off or show the strange behavior before removing the Philips Hue hub. My thoughts are the wireless switches were repeating through the Hue bulbs and being corrupted, whether the Hue bulbs repeat I am not too sure about but things are loking up. i would be interested as to how we can understand the get child and info command, this is what mine is showing at the moment

Parent child parameters
EzspGetParentChildParametersResponse [childCount=1, parentEui64=0000000000000000, parentNodeId=65535]

Child Data
No information for Child 0

Neighbor Table Entry
[Table light upstairs bedroom, 01E0], LQI:255, age:3, inCost:1, outCost:5
[repeater, 0F98], LQI:255, age:3, inCost:1, outCost:5
[Hallway Light, 1FE5], LQI:251, age:3, inCost:3, outCost:2
[Office Sidelight, 4579], LQI:255, age:4, inCost:1, outCost:4
[Living room 1, A4C0], LQI:205, age:4, inCost:5, outCost:4
[Conservatory Side Light, A604], LQI:6, age:7, inCost:7, outCost:0
[Ikea TRADFRI Control Outlet, E045], LQI:255, age:3, inCost:1, outCost:5
[Living room 2, F195], LQI:255, age:3, inCost:1, outCost:1

Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [Conservatory Side Light, A604] via [repeater, 0F98]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Office Sidelight, 4579] via [Office Sidelight, 4579]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, 9951] via [repeater, 0F98]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Philips Dimmer Button Controller, 42D4] via [Office Sidelight, 4579]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Conservatory Door Sensor, E29B] via [repeater, 0F98]

[veeceeoh]

@jtmpush18

(As you can tell, every morning, at 6am, I update the "battery date")

The batteryLastReplaced attribute is a custom one I added to the driver to help users keep track of when the battery of each of their Xiaomi / Aqara devices was last replaced. The way it works:

• While viewing the Xiaomi / Aqara device in the Hubitat web UI, click the Reset Battery Replaced Date command button
• The batteryLastReplaced date under States will be updated to the current date

The Battery Replaced Date feature is completely internal to the driver, and has absolutely no
bearing on the operation of the Xiaomi / Aqara device in question. It does not send any commands to the device at all. However, it does create an event.

Bottom line: there is no reason to create an automation to automatically create a batteryLastReplaced event every day.

@jtmpush18

Please look at the screen shot that I uploaded earlier. It shows that from Dec 4 to Dec 20, the only activity was me sending "battery replaced date", NO other reporting. Yet the physical test shows that this sensor still worked.

@jtmpush18

Can anyone tell me why all those battery events weren't reported in the device status page?

The default for all built-in Hubitat device drivers is to not generate a new event for any value-based attribute which has not changed in value. This includes temperature / humidity / pressure / battery readings.

Put another way, the only events that will be seen is when an attribute value has changed. Again, this is the default and standard behavior of all Hubitat device drivers, and a good number of users much prefer this behavior (I can search for the Forum Discussions regarding this if desired.)

However, if the user has enabled info / debug log messages in the Xiaomi / Aqara device driver, then evidence of the repeated temperature / humidity / battery / etc. values will be seen live logging page.

Also, every time the Xiaomi / Aqara device checks in, both the custom attributes lastCheckinEpoch and lastCheckinTime will be updated. Those are the attributes a user should look to as proof that the device is still online. They should both be updated every 50-60 minutes, and if they aren't then the device has likely gone offline. I have seen cases where a Xiaomi / Aqara device doesn't checkin for 2 hours, though, so 120 minutes is probably a safe amount of time to use in an automation.

Device Watchdog works just fine with all the Xiaomi / Aqara device drivers, using the "activity' watch feature.

[jtmpush18]

Thanks for clarifying that matter.
A Happy New year to you and yours.

[peter]

As an update, well things were going great. All switches stayed online and responded instantly, that is until I rebooted my HUB then back to normal. Switches failed to respond but after a few presses came back on line and worked, looking at the driver log you get this:

dev:7522020-01-07 07:35:51.149 pm debugSingle Light Button by Bedroom 2: Battery parse string = 1F0121110D0328130421A8430521F60006240600030000082108140A21E51F

dev:7522020-01-07 07:35:51.147 pm debugSingle Light Button by Bedroom 2: Message payload: 1F0121110D0328130421A8430521F60006240600030000082108140A21E51F

dev:7522020-01-07 07:35:51.144 pm debugSingle Light Button by Bedroom 2: Parsing message: read attr - raw: 25C90100004401FF421F0121110D0328130421A8430521F60006240600030000082108140A21E51F, dni: 25C9, endpoint: 01, cluster: 0000, size: 44, attrId: FF01, encoding: 42, command: 0A, value: 1F0121110D0328130421A8430521F60006240600030000082108140A21E51F

dev:7522020-01-07 07:35:49.786 pm errorjava.lang.NullPointerException: null (parse)

Obviously the NullPointerException has to be the unusual message from the switch which I will hesitate to guess means that the switch is now being repeated and corrupted. Does anybody know whether the Philips bulbs repeat?

Pete

[bobbles]

From reading lots of different posts, bulbs are notoriously bad repeaters if indeed they do repeat.

[aaiyar]

@peter

Does anybody know whether the Philips bulbs repeat?

The general recommendation is to keep bulbs on their own zigbee network for the reasons indicated by @bobbles.

[peter]

Since Dec 30th these my WXKG03LM and 02 switches have been rock solid, instantly turning on and off. This is since removing the Philips hub and reconfiguring the Philips bulbs ino HE, changing channel and resetting all zigbee. Set back up with the Ikea plugs first and then the wired Aqara no nuetral switches and the wireless switches then the philips bulbs all working perfectly (8 days). Then I lost a zwave device and rebooted the hub, since then it's back to the switches dropping off and the strange behaviour from the switches sending a null first but then working for for an indeterminate time. I think I'll have to look at mapping the zigbee and try and understand what is being routed where, the built in table seems next to useless as it doesnt even show the wireless switches. So frustrating !!

[aaiyar]

Here's my guess as to what happened. When you initially setup your HE, your Xiaomi devices were routing directly to HE or through the Tradfri devices. After reboot, the bulbs became available as zigbee repeaters, or devices started using them as repeaters.

Either way, it's unfortunate.

[peter]

So if the bulbs are connected via the philips hub, is it possible for the switches to still use them as repeaters?

[vjv]

Nope, the bulbs will be using HUE, the switches will stay in HE