Firmware 2.2.0.122 / Discover Zigbee "Found Devices" ; "Initializing..." ; never finishes

🛎️ Get Help
1

This seems to be a new issue since upgrading the firmware to version 2.2.0.122.

We are now getting what I call "Half-baked" devices upon discovery.

In the newer looking firmware Discovery page, there is a new button "Start Zigbee pairing" in the lower left, which used to be on the right as a button IIRC. I push that, our device debug says it gets onto the PAN-ID, on the hubitat a new line shows up below the "Start Zigbee pairing" button, and very quickly comes up with a "Found Devices:" line, and soon, below it is a box with

Found Zigbee Device with id F4CE3697D1494815

Initializing

... and it progresses no further until the 60s timer expires.

Watching our own device's debug log, the Zigbee chip has connected, and, a sniffer evidences the traffic to and from the hubitat to our device.

Once in this mode, these half-baked devices never end up showing up in "Devices", yet the Zigbee chips between the hubitat and our device are talking on the same PAN-ID as evidenced in the sniffer.

Once the device is half-baked, I must factory reset our own device. If it is not factory reset, as soon as it boots, it finds the hubitat coordinator and thinks it is connected. The hubitat, however, has no "Device" in it's list, so, we can never get it to talk to our device.

Previous hubitat firmware versions would continue to do their "Initializing..." in the background, and sometimes even after 3 minutes, would eventually find our device, but this version seems to stop.

1 Like
2

An update to this on what we've found.

The Hubitat will cache previously discovered short and long Device Network IDs.

If you "Remove" a device, you need to make sure your device automatically performs a Reset of itself, or, you'll see on the next connect, the Zigbee will re-join, as evidenced on WireShark, however, the fetching of the configuration will get confused with the previously held Device Network ID in the Hubitat cache.

A remedy to clearing the Hubitat cache is to power off the Hubitat, and don't use the soft reboot, since soft reboot will retain cache information.

The "half-baked" situation is Zigbee getting a previously cached long/short DNI and the Hubitat attempting to use its internal cache instead of treating it as a new discoverable device, even though it's been "Remove"d.

3

This probably should have been in the support section. But in any case, tagging @chuck.schwer to see if this is something that needs to be looked into.

Maybe @moderators would be so kind as to move it.

1 Like
4

I've moved this to ‘support’

Andy

1 Like
5

What specific device is having this issue?

7

This sounds like it is related with this:

2 Likes
8

I am glad I am not the only one experiencing this issue. Following.

9

@mike.maxwell .. I can reproduce this issue with an off the shelf device. This happened about half the time with this device.

  • Use a Sylvania Smart+ power plug Model 72922-A is what I have.
  • Reset by pushing button for over 5 seconds as you plug it in.
  • Discover and name in Hubitat.
  • QUICKLY do these next two steps:
  • Use "Remove" in the Hubitat to remove the device, leave it plugged in, do not reset it.
  • Discover, and you will see half-baked.

At this point, you can unplug, hold Reset at power up, and the device is instantly Discovered.

10

yes found the issue, we will have a hotfix for this shortly.

3 Likes
11

Been having this issue also. Had it with aqara curtain motor and now with Hue dimmer switches... In my case though, I had never paired the device with Hubitat so doubt there's a cache issue. I;m on 2.2.0.128

12

With the latest hotfix release 2.2.0.128, most of the time, all devices get fully baked, however, maybe 1 out of 20 times it gives us a half-baked situation. I found that waiting about 5 minutes sometimes evetually brings them up as baked. About 1 out of 50 times I have had one device that never bakes and will never bake no matter the retries, but then it's careful remove of everything, reset and reboot everything and reconnect it all up seems to work.

13

@mike.maxwell - I am having this half-baked problem again with a newer version of hubitats (2.2.3.148). Sequence is identical as described above. If I manually remove and rejoin a zigbee device, all is good. If I hardware reset a device that was joined, then remove the device from the devices list, and attempt to rediscover - never works and I always get half-baked device. The physical device actually shows as joined, but the hubitat never recognizes it. However, if I reboot the Hubitat, it always finds that device.

14

not having seen this before, is there a specific device that always produces this behavior?, if so I may be able to see what's going on here...

15

I had this problem when I tried adding the Lightify 4-button switches about 2 years ago when I bought my first hub. At the time I had only added what I thought were good repeaters (Peanut plugs) to the mesh. It would take multiple attempts and several minutes of discovering to create a not fully baked device that would fall off the network, require "wakeup" presses, and still have unconfigured buttons. The problem stopped when I removed the Peanuts and I still have the 9 Lightify 4-button switches that never drop off the mesh or require an initial press before they respond. So have you ruled out bad repeaters?
I forgot to mention that I got so frustrated with the switches that I deleted them and put them in a drawer. I finally decided to buy a second hub, and I joined them all to it before adding anything else. They all paired perfectly the first try and I haven't had to rejoin them once in over a year that they have been on the new hub. I added devices slowly to the hub over about a weeks time until I noticed an issue with the Peanuts.