Neither. The broadcasts is a network level activity so it’s handled at the network level. The binding is mostly working at the application level.
The dongle is clearly communicating with the binding - you can see this in the log you provided above. As I’ve said earlier, it seems the dongle is not communicating on the network as you are seeing nothing in Wireshark.
I’m using 2 Macs for this:
One running OH3 (MacOS 11.5.2), the ZigBee binding (3.0.1 and set to the default Ember settings per the binding readme) and a HUSBZB-1, and
Another (MacOS 11.5.2), a HUSBZB-1 and Wireshark sniffing with the ZigBee sniffer,
The results are:
The OH3 log shows that the Zigbee binding is communicating with the HUSBZB-1
The sniffer Mac shows that it receives the broadcast from the Innr bulb.
The firmware of both dongles have been updated - 5.4.1.0 > 6.7.8.0
I have switched the dongles and obtain the same results.
Per the ZigBee binding readme page, Innr bulbs (some??) should work.
It appears that the dongle on the sniffer Mac is receiving network traffic as indicated by the receipt of the Innr bulb’s broadcast.
Since both Macs are using the same OS, it doesn’t appear to be an OS or Mac issue, and because I have the same results switching dongles, it doesn’t appear to be a dongle issue.
But, the dongle on the OH3 Mac is not communicating with the network.
The sniffer java app resets the dongle to a mode to allow it to be used as a sniffer. Per the docs:
“Note that when used as a sniffer, the dongle is not running in its standard mode and is not used as a node on a ZigBee network. It will normally either run different firmware, or be configured into a specific mode to provide the low level data required.”
Maybe this is a dongle issue which is not being set up correctly with the binding?
In the binding settings, the PAN ID, Extended PAN ID, the Network Security Key and Link Security Key are all auto-completed. The Install Code is blank. Other than that, the binding appears to be ONLINE.
Is there somewhere else I need to look?
I’d like to use ZigBee just for the color bulbs and would like to get this figured out before dropping another $50 on a Hue bulb if compatibility is an issue.
It doesn’t really “reset the dongle into a mode” that allows it to be used as a sniffer. It just uses certain commands to get low level data. As soon as the dongle is reset (which happens every time the dongle starts) this will be gone.
I don’t think that’s possible. We can see that the dongle is communicating with the binding. That said I’ve only seen a short log so can’t confirm what is happening. We can see the dongle is going online though, but you don’t see any traffic on the sniffer which is strange as the binding doesn’t have to do anything for there to be traffic.
So I’m stuck now … I would like to purchase another ZigBee device known to work with the OH3 binding, but the items I need for my system listed as compatible in the binding readme are either gone or European (I’m in the US).
The Innr bulbs work fine - I use them here.
Your problem is not there - the issue is that for whatever reason, the coordinator is not working. You are seeing no data being sent by the coordinator in your sniffer - until that changes, no devices will work, so getting another device will not help.
Zigbee devices are not region specific - they use the same bands etc everywhere.
If the issue is in the coordinator (which I believe the Nortek HUSBZB-1uses the Ember coordinator), to isolate the cause of this, the ZigBee Binding versions I am using is 3.0.1. Maybe this is a mismatch with OH3 version and the binding? Is there anything here that seems suspect (using openhab> list)?:
347 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee
348 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.console
349 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.console.ember
350 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.console.telegesis
351 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.dongle.cc2531
352 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.dongle.ember
353 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.dongle.telegesis
354 │ Active │ 80 │ 1.3.8 │ com.zsmartsystems.zigbee.dongle.xbee
355 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Binding
356 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee CC2531 Bridge
357 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Console
358 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Console Ember
359 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Console Telegesis
360 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Ember Bridge
361 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Serial Driver
362 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee Telegesis Bridge
363 │ Active │ 80 │ 3.0.1 │ openHAB Add-ons :: Bundles :: ZigBee XBee Bridge
OH3.0.1 will work fine with the Ember dongles. This is the main dongle that we use commercially with thousands (or more) of installs using this. Again - we can see that the dongle has configured the network from your log.
Can you confirm that the firmware version for the HUSBZB-1 to version 6.7.8.0 is appropriate? From this log is does look like the serial port for the dongle is being accessed, but is not capturing any data:
16:06:10.692 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:11.695 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:11.695 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:11.695 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:12.696 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:12.697 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:12.697 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:13.699 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 11 bytes available
16:06:13.700 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 11 at offset 0
16:06:13.700 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 11 of 11 at offset 0
16:06:14.699 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:14.699 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:14.699 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:15.704 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:15.704 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:15.705 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:16.709 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:16.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:16.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:17.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:17.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:17.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:18.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:18.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:18.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:19.710 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:19.711 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:19.711 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:20.711 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:20.712 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:20.712 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:21.712 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:21.712 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:21.712 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:22.717 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:22.717 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:22.718 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:23.718 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:23.718 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:23.718 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:24.722 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:24.722 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:24.723 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:25.724 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:25.724 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:25.724 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:26.728 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:26.729 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:26.729 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:27.731 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:27.731 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:27.732 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:28.733 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:28.734 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:28.734 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:29.734 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:29.735 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:29.735 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:30.734 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:30.735 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:30.735 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:31.739 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:31.739 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:31.739 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
16:06:32.740 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: have 10 bytes available
16:06:32.741 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: try read 10 at offset 0
16:06:32.741 [TRACE] [inding.zigbee.serial.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: did read 10 of 10 at offset 0
I the Innr bulb is transmitting its broadcast and the dongle is communicating with the binding, I’m wondering if the radio may be misconfigured.
The firmware is fine. It’s hard to tell what is happening with this as you have only shown the trace point. However from the previous log I can definitely see commands being sent to the dongle at the ASH layer so the communications was fine in the past.
The really strange thing about this log is there is no processing of any data - just these TRACE messages. I really would have expected to see data being received - similar to what was logged earlier, so I would say there is definitely something wrong here given this log spans around 8 seconds, and no data is processed even though the logs show there was data read from the port.
Very strange.
I set the log to just log the Zigbee items, shutdown OH3, and re-started OH3 to show the entire boot process from the line
2021-09-19 11:43:16.817 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Starting ZigBeeDiscoveryService
through several of the data read attempts. The log is over the character limits for this forum (161k characters). Is there a way to post that extended log for comment?
But that is why it’s strange that the only messages logged are the ones above. You must have filtered the logs? If so, please don’t do this as it’s impossible to know what is happening from a single line of logging - even if it is repeated multiple times!
So you mean you have another log? If you want to post logs etc you need to host them somewhere - eg dropbox - and provide the link.
Here is the log:
What does it show? Is it just meant to show the initialisation, or are you also trying to get a device to join? In general if it’s just showing the initialisation (as I assume) then it looks fine - the dongle is communicating ok, and the network is up. That said, it does seem that communications stops after a while - again though I don’t know what this log shows so maybe this is something you did to disable logging or something?
This shows the log level I am using.
I restarted the system and immediately issued a.openhab> log:tail command. at 15:19:43:551 I started discovery using the UI Scan button. I ten turned the bulb on. At about 15:27:53 the scan was completed and the balance is the read attempts with no data.
If my logging settings are too limiting, I can add additional settings.
The only thing that I can see that looks a bit strange is that the PANId is set to FFFF. In theory, this should be auto configured to something else, so you might like to try and reinitialise the system, and use a random PAN Id to see if that works. I’m not sure what the dongle will do if the PAN is set to this as I’m pretty sure it’s invalid - even though it says the network is UP.
They are ok, and you probably don’t need TRACE level logging as it just adds to the size.
No - it wasn’t. This isn’t something I’ve seen before.
You are referring to an issue where the UI was displaying a different PAN ID than the coordinator was actually set to if I remember correctly? In this case, the coordinator is actually set to FFFF.
Yes, that is what I am refering to.
And yes, the coordinator did use a valid PanID under 3.0.1 in my case, but was shown as 0xFFFF (in decimal) in the UI.
Ok, so yes, this issue was just the copying of the PAN ID the coordinator used into OH - not the actual setting of the PAN ID and I don’t think that’s the issue here.