Problem Pairing Zigbee

One sensor of a group of 10 identical Iris V1 sensors refuses to stay connected, despite all of them sitting in a row, yet to be deployed. When re-discovering the sensor, Hubitat gets no further than "Found Previously Joined Device". The sensor keeps flashing, as if it is still trying to pair.

The logs are below. Is there a more detailed technical guide to address the detailed logs anywhere?

=-=-=-=-=-=-=-=

sys:12020-05-17 07:04:31.000 am infoIris Discovery Stopped

dev:972020-05-17 07:04:24.513 am infoskipped: cluster:0006, [raw:catchall: 0000 0006 00 00 0040 00 13CB 00 00 0000 00 00 03FDFF16C20001F000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:13CB, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[03, FD, FF, 16, C2, 00, 01, F0, 00]]

dev:972020-05-17 07:04:24.509 am debugparse: catchall: 0000 0006 00 00 0040 00 13CB 00 00 0000 00 00 03FDFF16C20001F000

dev:972020-05-17 07:04:24.507 am infoskipped: cluster:0013, [raw:catchall: 0000 0013 00 00 0040 00 13CB 00 00 0000 00 00 83CB1376B0B103006F0D0080, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:13CB, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[83, CB, 13, 76, B0, B1, 03, 00, 6F, 0D, 00, 80]]

dev:972020-05-17 07:04:24.494 am debugparse: catchall: 0000 0013 00 00 0040 00 13CB 00 00 0000 00 00 83CB1376B0B103006F0D0080

sys:12020-05-17 07:04:23.889 am infoFound Previously Joined Zigbee Device Iris V1 B076

dev:972020-05-17 07:04:23.866 am warnconfigure...

dev:1092020-05-17 07:04:14.450 am infoiris V1 9B69 adjusted temperature is 72.50Ā°F [sensor value 72.50]

dev:972020-05-17 07:04:09.410 am infoskipped: cluster:0006, [raw:catchall: 0000 0006 00 00 0040 00 F8B4 00 00 0000 00 00 02FDFF16C20001F000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:F8B4, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[02, FD, FF, 16, C2, 00, 01, F0, 00]]

dev:972020-05-17 07:04:09.407 am infoskipped: cluster:0013, [raw:catchall: 0000 0013 00 00 0040 00 F8B4 00 00 0000 00 00 82B4F876B0B103006F0D0080, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:F8B4, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[82, B4, F8, 76, B0, B1, 03, 00, 6F, 0D, 00, 80]]

dev:972020-05-17 07:04:09.404 am debugparse: catchall: 0000 0006 00 00 0040 00 F8B4 00 00 0000 00 00 02FDFF16C20001F000

dev:972020-05-17 07:04:09.400 am debugparse: catchall: 0000 0013 00 00 0040 00 F8B4 00 00 0000 00 00 82B4F876B0B103006F0D0080

sys:12020-05-17 07:04:08.785 am infoFound Previously Joined Zigbee Device Iris V1 B076

dev:972020-05-17 07:04:08.769 am warnconfigure...

dev:972020-05-17 07:03:49.640 am infoskipped: cluster:00F6, [raw:catchall: C216 00F6 02 02 0040 00 89B6 01 00 0000 FD 01 00FF, profileId:C216, clusterId:00F6, clusterInt:246, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:89B6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:01, data:[00, FF]]

dev:972020-05-17 07:03:49.633 am debugparse: catchall: C216 00F6 02 02 0040 00 89B6 01 00 0000 FD 01 00FF

dev:972020-05-17 07:03:44.318 am infoskipped: cluster:0013, [raw:catchall: 0000 0013 00 00 0040 00 89B6 00 00 0000 00 00 81B68976B0B103006F0D0080, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:89B6, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[81, B6, 89, 76, B0, B1, 03, 00, 6F, 0D, 00, 80]]

dev:972020-05-17 07:03:44.316 am infoskipped: cluster:0006, [raw:catchall: 0000 0006 00 00 0040 00 89B6 00 00 0000 00 00 01FDFF16C20001F000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:89B6, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[01, FD, FF, 16, C2, 00, 01, F0, 00]]

dev:972020-05-17 07:03:44.313 am debugparse: catchall: 0000 0006 00 00 0040 00 89B6 00 00 0000 00 00 01FDFF16C20001F000

dev:972020-05-17 07:03:44.306 am debugparse: catchall: 0000 0013 00 00 0040 00 89B6 00 00 0000 00 00 81B68976B0B103006F0D0080

sys:12020-05-17 07:03:43.524 am infoFound Previously Joined Zigbee Device Iris V1 B076

dev:972020-05-17 07:03:43.493 am warnconfigure...

sys:12020-05-17 07:03:31.039 am infoIris Discovery Running

How many total Zigbee devices do you have, and how many are repeaters? If you're not sure about the first question, Settings | Zigbee Details will given you a list. The second question is something you just have to know, but in general, most powered decices like smart plugs and switches (if Zigbee, of course) are. This includes most smart bulbs, except many or those are also bad repeaters and could be causing problems like this.

Also, are you sure the device didn't actually re-pair? Normally it would tell you what previously-joined device it found and re-associated with (for Zigbee), but I figure it's worth asking anyway. Constantly "falling off" is still a problem. Knowing the above maybe help figuren that out based in general Zigbee guidelines. Iris v1 sensors have the added complication of just being wonky for some people, possibly depending on the firmware version of the sensor, but there's no way to update them with Iris being long gone. I'd recommend avoiding buying them "new" and using them only if you previously used them with success on Iris.

1 Like

There is one Zigbee repeater, and under 30 total zigbee sensors, most of them Iris 3320-L. There are perhaps a half dozen Z-Wave devices.

The "last seen" date/time stamp does not update in the device list, and more important, the sensor keeps blinking like it is trying to pair. So, I conclude that it is not pairing, as it also does not report open/close events.

But the hope here was to find a secret decoder ring for interpreting the logs. One assumes that this is documented somewhere, and that it would be of help.

I am aware of the general advice to install lots of repeaters, but I want to understand what is going on from the point of view of the Hubitat and its debug logs, which should explain in detail.

Still looking for some documentation on the log entries, the message fields in the various messages, and more specifically, the expected debug logs when a device is (a) pairing; (b) rediscovered; (c) in the strange twilight where the Hubitat reports "Found Previously Joined Device", but the sensor keeps flashing, as if it is still trying to pair, and has not succeeded.

I'll tag @mike.maxwell here, Hubitat's Zigbee guru, to see if anything in the logs might be of use to him (though I'll warn you he prefers screenshots of the logs to copy and paste :slight_smile: ) or if he discovered anything about your device's "symptoms" above during the testing I assume they did when Hubitat added support for these devices a year plus back.

1 Like

it would seem that the device isn't being reset.
delete the device from Hubitat, then factory reset it.
If the device still doesn't work, throw it out.

5 Likes

Those are fine suggestions, but I hope to get a copy of the actual documentation that would allow one to read and comprehend the logs. Where is that documentation?

That's really a Zigbee question and would require personal familiarity with the protocol and profile being used, along with probably the stack (looks like it might be Ember Znet?). That is an...endeavor but nothing you'll find in the Hubitat docs in any case. This can help with some basic concepts (really intended for the HA 1.2 profile on another system, but the AlertMe profile in question here, used by Iris v1 , is probably similar enough that there would be significant overlap):

https://docs.smartthings.com/en/latest/device-type-developers-guide/zigbee-primer.html

Beyond that, I suppose the Zigbee docs from the Alliance and Silicon Labs, paying particular attention to anything common to the protocol itself, ZHA 1.2, and Zigbee 3.0 that more or less subsimes HA 1.2, would be the most useful. Perhaps some of these:

https://zigbeealliance.org/developer_resources/

Oh, and whatever you can find documented about AlertMe, a proprietary, mostly reverse-engineered profile the Iris v1 vendor used to create these products for Lowe's. :slight_smile:

1 Like

This is not an iris v1 device this is a standard zigbee Zha 1.2 device made for Lowes by centralite.

1 Like

@mike.maxwell ...

I'm sorry, I called them "Iris 3320-L" because that is what the labels on the back call them, I should have clarified that they are mainstream "generic zigbee", devices, as opposed to the old-skool Iris devices that must be paired with the specialized "Iris V1" button.

As for the logs, the Hubitat is then simply echoing some number of messages received from devices that it may not care about or know what to do with?

The debug logs that you see aren't going to tell you if you have enough repeaters or not.
For 30 devices, unless they are all in the same room, one repeater isn't going to cut it.
I would have a read of this:
https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Zigbee_Mesh

For alertMe, there is no documentation available for the alertMe profile clusters.

1 Like

Oh golly, no - - 30 zigbee devices in the entire house!

Thanks for the link...

Hey @james.fischer

Your post about the zigbee devices that keep flashing after being detected and added to the HE hub is from 2020.

Iā€™m facing the same problem, not with endpoint devices, but with repeaters. (Such as eWelink zb Switches and LED controllers).

The tricky thing is that buttons and sensors are added normally and work fine!

Did you come up with a solution to this?

I added a few Ikea Tradfri outlets as zigbee repeaters, and all my zigbee issues faded away. The bottom line here is that the Tradfri seems to be more forgiving in "supporting" oddball zigbee protocol variants than the Hubitat itself, as distance was never an issue in my problems, nor did reducing distance to only a few feet make things any better.

I also added "battery backup" to each Tradfri so that I would not lose zigbee devices that seemed to depend on the Tradfris if power failed.