[Release] Generic Zigbee Drivers with Presence and Recovery

[pugazhendhi.m]

With Generic Zigbee outlet Driver, it takes more than a second response and more that 2 minutes to update the dash board,

dev:8752020-07-19 10:03:18.770 infoPlug was turned off

dev:8752020-07-19 10:03:18.762 debugdescMap:[raw:F0950100060800002000, dni:F095, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:20, command:0A, value:00, clusterInt:6, attrInt:0]

dev:8752020-07-19 10:02:18.777 infoPlug was turned on

dev:8752020-07-19 10:02:18.771 debugdescMap:[raw:F0950100060800002001, dni:F095, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:20, command:0A, value:01, clusterInt:6, attrInt:0]

dev:8752020-07-19 10:01:32.591 warndescription logging is: true

dev:8752020-07-19 10:01:32.587 warndebug logging is: true

dev:8752020-07-19 10:01:32.584 warnpower reporting is: false

But with your drivers,

After moving the device closer to hubitat, it works as expected, There are no lags.

2020-07-19 09:58:04.156 debugsendOnOffEvent(onOff=true)
dev:8752020-07-19 09:58:04.153 infoON/OFF CATCHALL CLUSTER EVENT - description:catchall: 0104 0006 01 01 0040 00 F095 00 00 0000 0B 01 0100 | parseMap:[raw:catchall: 0104 0006 01 01 0040 00 F095 00 00 0000 0B 01 0100, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:F095, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[01, 00]]
dev:8752020-07-19 09:58:04.049 debugon()
dev:8752020-07-19 09:57:49.524 debugsendOnOffEvent(onOff=false)
dev:8752020-07-19 09:57:49.521 infoON/OFF CATCHALL CLUSTER EVENT - description:catchall: 0104 0006 01 01 0040 00 F095 00 00 0000 0B 01 0000 | parseMap:[raw:catchall: 0104 0006 01 01 0040 00 F095 00 00 0000 0B 01 0000, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:F095, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, 00]]
dev:8752020-07-19 09:57:49.408 debugoff()
dev:8752020-07-19 09:57:18.724 debugsendOnOffEvent(onOff=true)
dev:8752020-07-19 09:57:18.721 debugOn/Off Button press - description:read attr - raw: F0950100060800002001, dni: F095, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 20, command: 0A, value: 01 | parseMap:[raw:F0950100060800002001, dni:F095, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:20, command:0A, value:01, clusterInt:6, attrInt:0, valueParsed:1]
dev:8752020-07-19 09:56:57.963 debugdirty model = FB56-SKT17AC1.3, clean model=FB56-SKT17AC1.3
dev:8752020-07-19 09:56:57.951 debugModel Name Received
dev:8752020-07-19 09:56:57.904 infoBIND RESPONSE CLUSTER EVENT
dev:8752020-07-19 09:56:57.791 infoManufacturer Name Received
dev:8752020-07-19 09:56:57.727 debugsendZigbeeCommands(cmd=[he raw 0xF095 1 0x01 0x0000 {10 00 00 05 00}, delay 2000, zdo bind F095 0x01 0x01 0x0006 {00124B001490E735} {}, delay 200, zdo send F095 0x01 0x01, delay 200])
dev:8752020-07-19 09:56:57.724 debugrefresh cmd: [he raw 0xF095 1 0x01 0x0000 {10 00 00 05 00}, delay 2000, zdo bind F095 0x01 0x01 0x0006 {00124B001490E735} {}, delay 200, zdo send F095 0x01 0x01, delay 200]
dev:8752020-07-19 09:56:57.710 debugdirty model = FB56-SKT17AC1.3, clean model=FB56-SKT17AC1.3
dev:8752020-07-19 09:56:57.674 debugsendZigbeeCommands(cmd=[he raw 0xF095 1 0x01 0x0000 {10 00 00 04 00}, delay 2000])
dev:8752020-07-19 09:56:57.600 infoRecovery feature ENABLED
dev:8752020-07-19 09:56:57.597 debugstartCheckEventInterval()
dev:8752020-07-19 09:56:57.453 infogetDriverVersion() = v0.8.1.0718
dev:8752020-07-19 09:56:57.448 debugrefresh() model='FB56-SKT17AC1.3'
dev:8752020-07-19 09:56:57.439 infoupdated()
--- Live

But if I take the device to first floor, the device stops responding and says no presense.
There is a Basiczbr3 sitting in between the hub and this outlet. Still no communications.

But Yes, with your drivers and within the vicinity of the HUB, the drives works correctly,

BASICZBR also using your drivers.

Thanks and regards,
Pugazhendhi M

[markus]

@pugazhendhi.m

There is a Basiczbr3 sitting in between the hub and this outlet. Still no communications.

These devices are using a low power Zigbee chip, even though they do a good job in repeating, they don't do so very far, certainly not between floors. Your delays are very likely due to poor connectivity within the mesh causing resends and, as a consequence, delays. I'd recommend getting a repeater with a stronger signal to create a reliable path between floors. The IKEA Trådfri Repeaters are good, the IKEA Outlets not as good. There are also others, just make sure they are NOT based on the CC2530 chip without a power amplifier (like the Sonoff one). Xbees are another good example of repeaters.

It is also a good idea to put a strong repeater close to the hub, the specs of the chip in HE says they transmit with 8dBm. The CC2530 without a PA is around 4.5dBm. Ikea Repeaters around 14.5dBm. Maximum allowed, for most channels, is 20dBm. These are all theoretical averages, but they should give you an idea about the differences in distance. Apart from transmit power there is receiver sensitivity, in general both the HE chip and the IKEA Repeaters do well there. The Sonoff one is ok, but not great in that department. It does handle MANY devices close to it though. Hope this helps in sorting this out, there is nothing more that can be done from a drivers perspective.

[bobbles]

@markus

For those that do submit fingerprints in the future, please state the full model name/version and country it is for. Just so I know what is what in my files. Can get messy. Also, the best fingerprint format to supply to me is how it is reported by my Generic Zigbee Device Toolbox driver when you press Get Info.

Here is the info when Get Info button is pressed.
The device is an Ikea Tradfri Outlet being used in the UK.

[markus]

@bobbles

The device is an Ikea Tradfri Outlet being used in the UK.

Unfortunately this is incomplete, just as the log says, if you press one more time on Get Info it would be complete. For these I prefer them in text form as, otherwise I have to manually type them in, high risk for typos. I'm updating the Get Info command to be more clear about this.

[Sebastien]

Something very odd is occurring... Since a couple of hours ago, a majority of my Xiaomi contact sensors are reporting not present, and not reporting their status.

I have tried reviving 2 of them by clicking on the button or opening/closing the window, but no success. I also tried re-discovering them and stopped after 2 were discovered, but are still reporting not present.

I initially thought it could be a problem with one of my Ikea repeaters, so unplugged it and re-plugged it, just in case. However, I have since discovered that one of the devices that was connecting directly to my hub is also not present.

It is getting late and I must get some , so I will have to resume my debugging later on tomorrow.

Any recommendations on actions to try would be appreciated and will be put to use - I will provide an update later tomorrow.

Attaching the logs from one of the devices on which I tried all the actions above and that is connected through the Ikea repeater.

Log (Screenshot)

Log (text)

dev:8382020-07-19 23:13:49.228 infobuttonPushed(button=1)
dev:8382020-07-19 23:13:49.221 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-19 23:13:45.751 infobuttonDown(button=1)
dev:8382020-07-19 23:13:45.729 infosendOpenCloseEvent(openClose=false) invertContact=false
dev:8382020-07-19 23:13:42.132 infobuttonPushed(button=1)
dev:8382020-07-19 23:13:42.114 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-19 23:13:40.719 infobuttonDown(button=1)
dev:8382020-07-19 23:13:40.713 infosendOpenCloseEvent(openClose=false) invertContact=false
dev:8382020-07-19 23:13:39.068 warnEvent interval normal, recovery mode DEACTIVATED!
dev:8382020-07-19 23:12:56.712 infoRecovery feature ENABLED
dev:8382020-07-19 23:12:56.628 infogetDriverVersion() = v0.8.1.0718
dev:8382020-07-19 23:12:56.594 infoReset button pressed/message requested by hourly checkin - description:read attr - raw: 37560100002C050042126C756D692E73656E736F725F6D61676E6574, dni: 3756, endpoint: 01, cluster: 0000, size: 2C, attrId: 0005, encoding: 42, command: 0A, value: 126C756D692E73656E736F725F6D61676E6574 | parseMap:[raw:37560100002C050042126C756D692E73656E736F725F6D61676E6574, dni:3756, endpoint:01, cluster:0000, size:2C, attrId:0005, encoding:42, command:0A, value:lumi.sensor_magnet, clusterInt:0, attrInt:5]
dev:8382020-07-19 23:12:55.564 infoRecovery feature ENABLED
dev:8382020-07-19 23:12:55.507 infobuttonPushed(button=1)
dev:8382020-07-19 23:12:55.493 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-19 23:12:55.489 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 37560100003002FF4C0600100121F90B21A8012400000000002138002062, dni: 3756, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121F90B21A8012400000000002138002062 | parseMap:[raw:37560100003002FF4C0600100121F90B21A8012400000000002138002062, dni:3756, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[true, 3065, 424, 0, 56, 98], clusterInt:0, attrInt:65282]
dev:8382020-07-19 23:12:55.449 warnUnhandled Event PLEASE REPORT TO DEV - description:read attr - raw: 3756010000080100200A, dni: 3756, endpoint: 01, cluster: 0000, size: 08, attrId: 0001, encoding: 20, command: 0A, value: 0A | msgMap:[raw:3756010000080100200A, dni:3756, endpoint:01, cluster:0000, size:08, attrId:0001, encoding:20, command:0A, value:0A, clusterInt:0, attrInt:1, valueParsed:10]
dev:8382020-07-19 23:12:55.358 infogetDriverVersion() = v0.8.1.0718
dev:8382020-07-19 23:12:55.321 infoReset button pressed/message requested by hourly checkin - description:read attr - raw: 37560100002C050042126C756D692E73656E736F725F6D61676E6574, dni: 3756, endpoint: 01, cluster: 0000, size: 2C, attrId: 0005, encoding: 42, command: 0A, value: 126C756D692E73656E736F725F6D61676E6574 | parseMap:[raw:37560100002C050042126C756D692E73656E736F725F6D61676E6574, dni:3756, endpoint:01, cluster:0000, size:2C, attrId:0005, encoding:42, command:0A, value:lumi.sensor_magnet, clusterInt:0, attrInt:5]
dev:8382020-07-19 23:12:55.190 infoRestoring bind settings
dev:8382020-07-19 23:12:55.181 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 700 (maximum expected 90)
dev:8382020-07-19 23:12:55.166 infoMULTISTATE CLUSTER EVENT - description:catchall: 0000 0013 00 00 0040 00 3756 00 00 0000 00 00 FA5637617D5A04008D150080 | parseMap:[raw:catchall: 0000 0013 00 00 0040 00 3756 00 00 0000 00 00 FA5637617D5A04008D150080, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:3756, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[FA, 56, 37, 61, 7D, 5A, 04, 00, 8D, 15, 00, 80]]
dev:8382020-07-19 23:06:52.086 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 23:06:52.081 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 694 (maximum expected 90)
dev:8382020-07-19 22:10:02.071 warnNo event seen from the device for over 3 hours! Something is not right... (consecutive events: 3)
dev:8382020-07-19 22:06:52.084 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 22:06:52.080 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 634 (maximum expected 90)
dev:8382020-07-19 19:10:02.172 warnNo event seen from the device for over 3 hours! Something is not right... (consecutive events: 2)
dev:8382020-07-19 19:06:52.073 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 19:06:52.067 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 454 (maximum expected 90)
dev:8382020-07-19 18:06:52.067 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 18:06:52.061 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 394 (maximum expected 90)
dev:8382020-07-19 17:06:52.146 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 17:06:52.139 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 334 (maximum expected 90)
dev:8382020-07-19 16:10:02.073 warnNo event seen from the device for over 3 hours! Something is not right... (consecutive events: 1)
dev:8382020-07-19 16:06:52.078 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 16:06:52.074 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 274 (maximum expected 90)
dev:8382020-07-19 15:06:52.075 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 15:06:52.070 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 214 (maximum expected 90)
dev:8382020-07-19 14:06:52.070 warnEvent interval INCORRECT, recovery mode (Normal) ACTIVE! If this is shown every hour for the same device and doesn't go away after three times, the device has probably fallen off and require a quick press of the reset button or possibly even re-pairing. It MAY also return within 24 hours, so patience MIGHT pay off.
dev:8382020-07-19 14:06:52.065 warnOne or several EXPECTED checkin events have been missed! Something MIGHT be wrong with the mesh for this device. Minutes since last checkin: 154 (maximum expected 90)
dev:8382020-07-19 00:30:18.901 infobuttonPushed(button=1)
dev:8382020-07-19 00:30:18.893 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-19 00:30:18.890 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100121F90B21A8132401000000002137002065, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121F90B21A8132401000000002137002065 | parseMap:[raw:169A0100003002FF4C0600100121F90B21A8132401000000002137002065, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[true, 3065, 5032, 1, 55, 101], clusterInt:0, attrInt:65282]
dev:8382020-07-18 23:30:03.413 infobuttonPushed(button=1)
dev:8382020-07-18 23:30:03.399 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-18 23:30:03.388 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100121F90B21A8132401000000002137002066, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121F90B21A8132401000000002137002066 | parseMap:[raw:169A0100003002FF4C0600100121F90B21A8132401000000002137002066, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[true, 3065, 5032, 1, 55, 102], clusterInt:0, attrInt:65282]
dev:8382020-07-18 22:29:49.623 infobuttonPushed(button=1)
dev:8382020-07-18 22:29:49.596 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-18 22:29:49.588 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100121F90B21A8132401000000002137002066, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121F90B21A8132401000000002137002066 | parseMap:[raw:169A0100003002FF4C0600100121F90B21A8132401000000002137002066, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[true, 3065, 5032, 1, 55, 102], clusterInt:0, attrInt:65282]
dev:8382020-07-18 21:29:30.681 infobuttonPushed(button=1)
dev:8382020-07-18 21:29:30.602 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-18 21:29:30.577 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100121F90B21A8132402000000002137002064, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100121F90B21A8132402000000002137002064 | parseMap:[raw:169A0100003002FF4C0600100121F90B21A8132402000000002137002064, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[true, 3065, 5032, 2, 55, 100], clusterInt:0, attrInt:65282]
dev:8382020-07-18 20:47:23.472 infobuttonPushed(button=1)
dev:8382020-07-18 20:47:23.450 infosendOpenCloseEvent(openClose=true) invertContact=false
dev:8382020-07-18 20:29:42.244 infobuttonDown(button=1)
dev:8382020-07-18 20:29:42.195 infosendOpenCloseEvent(openClose=false) invertContact=false
dev:8382020-07-18 20:29:42.179 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100021F90B21A8132401000000002137002063, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100021F90B21A8132401000000002137002063 | parseMap:[raw:169A0100003002FF4C0600100021F90B21A8132401000000002137002063, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[false, 3065, 5032, 1, 55, 99], clusterInt:0, attrInt:65282]
dev:8382020-07-18 19:29:22.624 infobuttonDown(button=1)
dev:8382020-07-18 19:29:22.611 infosendOpenCloseEvent(openClose=false) invertContact=false
dev:8382020-07-18 19:29:22.605 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100021F90B21A8132401000000002137002062, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100021F90B21A8132401000000002137002062 | parseMap:[raw:169A0100003002FF4C0600100021F90B21A8132401000000002137002062, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[false, 3065, 5032, 1, 55, 98], clusterInt:0, attrInt:65282]
dev:8382020-07-18 18:29:03.378 infobuttonDown(button=1)
dev:8382020-07-18 18:29:03.320 infosendOpenCloseEvent(openClose=false) invertContact=false
dev:8382020-07-18 18:29:03.288 infoKNOWN event (Xiaomi/Aqara specific data structure with battery data - 4C - hourly checkin) - description:read attr - raw: 169A0100003002FF4C0600100021F90B21A8132401000000002137002062, dni: 169A, endpoint: 01, cluster: 0000, size: 30, attrId: FF02, encoding: 4C, command: 0A, value: 0600100021F90B21A8132401000000002137002062 | parseMap:[raw:169A0100003002FF4C0600100021F90B21A8132401000000002137002062, dni:169A, endpoint:01, cluster:0000, size:30, attrId:FF02, encoding:4C, command:0A, value:[false, 3065, 5032, 1, 55, 98], clusterInt:0, attrInt:65282]

[markus]

@Sebastien

but are still reporting not present.

When this happens to all devices at once it is most likely due to a PAN id change. The PAN id doesn't update in the HE UI until after reboot(!), so I suggest checking the PAN id at "http:///hub/zigbeeInfo" and then reboot and check again. If it has changed, you know why your devices dropped. How to troubleshoot and work around this is something I'm working on. HE is very quick to make a PAN id change, I have reported this and do hope they fix this behaviour, it is very much unnecessary to do the way they do, it only causes issues.
I feel for you, I've had this issue plague me for almost 2 weeks now. All due to ONE faulty packet sent by one of my Xiaomi devices about once every 24 hours. Very unnecessary to change PAN id and kill the mesh over something like that.

[Sebastien]

Is the ParentNodeId the same as the PAN id?

Here is what I am getting. Will reboot...

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

Child Data
child:[Den Window - Right, 249A, type:EMBER_SLEEPY_END_DEVICE]
child:[Den Window - Left, 5542, type:EMBER_SLEEPY_END_DEVICE]
child:[Solarium Window - Right, 86E6, type:EMBER_SLEEPY_END_DEVICE]
child:[Solarium Window - Center Right, F1A5, type:EMBER_SLEEPY_END_DEVICE]
child:[Solarium Window - Center Left, A3FC, type:EMBER_SLEEPY_END_DEVICE]
child:[Solarium Window - Left, 8C14, type:EMBER_SLEEPY_END_DEVICE]
child:[Master Bathroom Window Sensor, 26D2, type:EMBER_SLEEPY_END_DEVICE]

Neighbor Table Entry
[Upstairs Corridor Zigbee Repeater, 48FD], LQI:254, age:4, inCost:1, outCost:1
[Family Room Zigbee Repeater, C205], LQI:245, age:6, inCost:5, outCost:5

Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [Upstairs Bathroom Window, E04E] via [Upstairs Corridor Zigbee Repeater, 48FD]
status:Unused
status:Unused
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Downstairs Bathroom Window, 6DB4] via [Upstairs Corridor Zigbee Repeater, 48FD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Family Room Zigbee Repeater, C205] via [Upstairs Corridor Zigbee Repeater, 48FD]
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused

[markus]

@Sebastien

Is the ParentNodeId the same as the PAN id?

No, this is what you need to look at:

[Sebastien]

@markus

No, this is what you need to look at:

Oh... I was looking at the wrong thing then... I have started the reboot, so I suspect it will be impossible to see if the number changed now... ?

[markus]

@Sebastien

number changed now..

Yes, probably, not sure what happens if you restore a previous backup. You could try to roll back to a previous backup, maybe that will show the old PAN id. Not sure, never tried. The only other way would be to use a Zigbee sniffer and look at the packets from your sensors in Wireshark as they try to check in.

[Sebastien]

@markus

not sure what happens if you restore a previous backup.

Good question! I've tried it and I can confirm that the PAN id remains the same before and after restore.

I assume it is normal that the devices are still listed?

Here are before and after restore screenshots:
Before

After

I checked out your post on the PAN issue, sounds like I just need to wait until the mesh heals itself?

Really need to go now... back tomorrow!

Thanks for your help and input on this @markus!!! I really appreciate how you always have such great insight!

[markus]

@Sebastien

Really need to go now... back tomorrow!

Yes, sleep well! Good night!

It probably was the PAN id, hard to know now, but if it ever happens again (let us hope not!), then you know where to look. It should heal, at least most devices, T&H devices might need a push on the button. Contact sensors might need LOTS of opening/closing (until they blink blue a few times). Instead of opening closing you can also use a magnet and trigger the open/close state with. Healing can take up to 24 hours.

[Sebastien]

@markus

Healing can take up to 24 hours.

I understand that shutting down my hub for 20 minutes may speed that up? I might give that a try too...

@markus

Instead of opening closing you can also use a magnet

Good idea! I’ll give that a go too.

Thanks again! I would have never found the issue without your help...

[markus]

@Sebastien

I understand that shutting down my hub for 20 minutes may speed that up? I might give that a try too...

Yes, for most other types of rebuilds, but I've not seen it have much effect on this one. It won't hurt though.

@Sebastien

I would have never found the issue without your help...

This has been an illusive issue for a long time, I couldn't nail it down exactly without Wireshark. I still have some theories on how to minimize the risk until they fix it for real on HE, but give me a few more days to verify that what I think can be done actually works. If this happens again, tell me and I will let you try some other things.

@Sebastien

Thanks again!

You're welcome

[Sebastien]

Here's my update:

This morning, more than half my sensors had come back on their own. Of the remaining ones, I ended-up multi-clicking the reset button of two of them and they eventually came back. The others came back on their own after a couple open/close cycle.

Your driver did an awesome job at bringing them back! Thank you again!

Everything is now back on-line. I did do a 20 minute shut down on the hub to allow the routes to be cleaned-out.

[proffalken]

Thanks for this plugin, can I request that you add the following fingerprint:

fingerprint model:"SP 222", manufacturer:"innr", profileId:"0104", endpointId:"01", inClusters:"0000,0003,0004,0005,0006,0008,0B05,1000,FC82", outClusters:"000A,0019", application:"10"

Manufacturer: INNR (www.innr.com)
Model: SP222
Country: UK

This is for the INNR SP222 Smart Plug that is frequently on offer on Amazon.co.uk

(It works perfectly with the driver as far as I can tell BTW!)

[markus]

It will be included in the next release. Thank you for the fingerprint!

[BrunoVoeten]

My device is an Ikea Tradfri Outlet being used in Belgium.
Thx for all the work you are doing

Get Info

dev:4542020-07-25 11:43:47.641 infoCOPY AND PASTE THIS ROW TO THE DEVELOPER: fingerprint model:"TRADFRI control outlet", manufacturer:"IKEA of Sweden", profileId:"0104", endpointId:"01", inClusters:"0000,0003,0004,0005,0006,0008,1000,FC7C", outClusters:"0005,0019,0020,1000", application:"20"
dev:4542020-07-25 11:43:47.638 traceApplication: 20
dev:4542020-07-25 11:43:47.635 traceModel: TRADFRI control outlet
dev:4542020-07-25 11:43:47.632 traceManufacturer: IKEA of Sweden
dev:4542020-07-25 11:43:47.627 debugGetting info for Zigbee device...

[BrunoVoeten]

@markus, since you live in China and has many devices, do you have experience with an wall thermostat like this or something similar?

[markus]

@BrunoVoeten

have experience with an wall thermostat like this or something similar

Unfortunately not, I have nothing I could control with those in my home. They wouldn't be hard to write a driver for if I had one, but I don't have anything to connect them to.

A bit about my heating/cooling:
My heating and cooling is something that is not automated in a good way yet. When I moved in here late last year the multi-room AC and electric heaters were already installed. The AC is ducted but only has IR remotes (it's Haier though so I can probably connect a controller). The heaters use the X3D protocol and the bridge for that is not sold here. Even if it was, I'm not sure how easy it would be to connect to it locally. With that said, if I find a good Zigbee product for my Haier AC I will get that. For my heating I don't know yet.