This sequence confirms changing the panID in the UI has no effect
As a matter of interest, what equipment are you using, and how is it configured? I see something interesting in this log during the initialisation - the scans are failing as the device is unable to send. In the past when I’ve seen this it is caused by interference since the dongle will perform an RSSI check before sending, and will not send if the channel is busy. This might be the cause of your issue and why we are not seeing any data sent. I also see similar failures later in the log.
I seem to recall an issue in the past where someone had something like an RPi which a crappy USB hub, or just put out a lot of EMC, and that was causing a lot of interference. I would suggest to put your dongle on a USB cable to get it away from your computer to see if that helps. Please provide the log again once this is done so I can see if this issue gets resolved (unless of course everything starts working 
).
Well that was it. The HUZBZB-1 was on a hub in an equipment closet and I placed it directly on the Mac’s USB bus away from any other devices, and the light was discovered. I now have the color channels as well.
15:51:40.915 [INFO ] [openhab.event.InboxUpdatedEvent ] - Discovery Result with UID 'zigbee:device:66e197be19:84fd27fffe697231' has been updated.
How true the old adage - shut down, remove all peripherals, reboot, and reconnect the device …
By the way - is there a recommended hub for this? I actually need to move the HUZBZB-1 off the Mac due to port count limitations.
Thank you for looking into this
2 Likes
Great! I’m pleased we got there - thanks for persevering. It’s one of those very strange issues - I might see if I can detect this during initialisation and provide some feedback. It doesn’t occur very often, but as we’ve seen, when it does it’s not a simple issue to spot.
By “hub” - you mean the computer on which this is running? If so, then there’s not really a recommended hub. Many people will use an RPi or other such single board computers - others might use an NUC, or old computer of some description.
Flipping awesome gents!!! 
No, I mean an external usb expansion hub - better that the crappy one causing this problem. I’m running OH3 on a Mac Mini and only have 2 USB ports available.
There is this aspect as well, both what kind of closet and who’s sharing the space.
Purpose designed equipment closets usually work hard to keep radio out, which makes 'em pretty good at keeping it in as well.
My “equipment closet” is actually part of a regular house closet so there is no special treatment. I have a 15’ active USB cable from the Mac in the closet which runs to a more central location in the house. At the end of that I have the problematic USB hub where also I have a ZStick and RTL-SDR dongle and antennae, both of which work fine. It’s the HUZBZB-1 that’s not happy with the hub. For testing though I moved the hub next to the Mac with a short USB cable.
Just for the record, I’ve now added this check to the low level libraries. A check is now performed during the scan to see if at least one channel has a background noise level that is lower than the CSMA level. If not, an error is thrown.
This isn’t 100% foolproof in that the network might still initialise of a channel is available during the energy scan as noise, by its nature, will vary. However I also now log how many channels violate the CCA level, so this issue should be more easily identifiable at least.
In this case, this would have identified the issue here since all channels were noisy. The CCA threshold is set to -75dBm by default, and as can be seen below, all channels are well above this level (generally around 20dB - which is 100 times exceedance!) -:
2 Likes
When this is ready I’d be happy to use this update on the crappy USB hub I have and run the log for you.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.