Now… it does not discover any of my devices, including a brand new Hue bulb I accidentally bought.
I now read that OH2 “automatically reads all devices that are set up on the ‘ZigBee controller’ and puts them in the Inbox”. ZIGBEE CONTROLLER???
Do I need a separate controller as well?
I’ll be looking to learn the development process for other devices. (Yale YRD220 Deadbolt, Salus Optima Thermostat, Centralite plugin dimmer, motion and door sensors, water leak sensor,…)
I’m an ISP network specialist by trade and I purchased a few more CC2531 for sniffing and spares.
I don’t know if Zigbee works the same as Zwave, but for Zwave one needs to pair the device with the controller (i.e. USB dongle). One way is to take the dongle to the device, press the button on the dongle, press the button on the device, and wait for the lights to stop flashing. Then when you plug the dongle back in and start up OH the devices will show up in the Inbox.
I would guess that Zigbee works in a similar way.
Also, one caution is that unlike with Zwave, there is no guarantee that two devices that use Zigbee are compatible with each other.
If you are not on OH2.2, then you have an old version of the binding, which could explain why you are having issues. If you are on OH2.2, you have a pretty recent version of the Zigbee binding. But it is still very much in development, so I suggest you start using the 2.3 snapshot version of the binding. For a lot of good info and to learn about new functionality when it is added, you can find out about it in this thread…
Best option is to enable pairing using the UI. You should then reset the device you are trying to pair - you will have 60 seconds to do this before pairing is disabled.
Every device has a different method to reset - some bulbs require switching on and off a number of times, other devices may have a button you need to hold down for 5 or 10 seconds - you’ll need to read the manual, or search the web for how to do this.
Both of these require slighly different variations of turning on and off 5 or times (from memory).in order to reset them. I have however tested Osram bulbs and Ikea bulbs personally, and many people are using these devices so there shouldn’t be any issue with them.
Probably 5 or 10 m should be ok. I’ve found the Osram bulbs to not have the best receive performance, so depending on your property (concrete, wood, brick…) it may vary a little.
Firstly, please use code fences when pasting logs - it’s a) very difficult to read without this, and b) it is very long (and even more difficult to read!).
The log doesn’t really show a lot. It shows the startup where the binding is looking for devices it knew about previously, but there are no responses.
I don’t think you’ve said, but what version of the binding are you using? Is it a recent snapshot or are you using the release version?
The link quality for the device is quite poor (only an LQI of 76) so this probably explains why some messages have no response. A value of 200 means you have around 80% chance of success - so I can guess that maybe a value of 76 means the link is pretty poor.
The LQI means that the dongle can’t receive the device very well, so it’s not a problem with the power on the dongle side. Either the dongle has poor receive performance, or the bulb has low power, or something in between is interfering (which should not be the case if they are close together).
It generally doesn’t matter. The power transmitted by these devices is very low - as required by the radio regulations. Most transmit around 5 to 8 dBm - so that’s less than 10 milli watts! It doesn’t make a lot of difference if it’s running off mains as the law limits the power.
The result is the NetworkAddres discovery always failing in the concentrator (CC2531). It seems (checked it through Z-Tool) that the CC2531 dongle is not answering to broadcast messages sent from itself.
I am using stable openhab (2.3.0) so I do not know if this is something your are already aware or even fixed in new versions. In my case, I have worked around it by replacing, in the ZigBeeNodeServiceDiscoverer class:
The workaround just replaces the broadcast destination with the coordinator address (0) when sending a network discovery message that is intended to itself.
Maybe there is a better way to fix this, or to do a CC2531 specific fix (even if sending 0 as destination address instead of broadcast when addressing the coordinator should be harmless)
I do not personally use the TI chipset very often, so I have not seen this. It’s a little strange that the device doesn’t respond to broadcasts.
My preference (if not too messy) would be to resolve this in the TI driver rather than in the common code. Coordinators should respond to broadcast messages and my guess is that this isn’t the only case where this issue exists and maybe it would be better to try and resolve it?
Please keep in mind that the local node may not always be a coordinator - so we don’t want this to break if the device is not a coordinator.
If so, this seems a bug in the z-stack, but as the version we are using is quite old, and the implementation itself is in closed code binary libraries, we cannot fix it in the firmware
Also my preference, but is there somewhere in the CC2531 specific code where we know that:
The command is a broadcast
It is for the coordinator
We are the coordinator
The message can be changed
Otherwise, this can only be fixed at “application” level. Anyway, what is the impact of not being able to complete coordinator discovery correctly? My understanding is that this must be happening to everybody using the CC2531.
Having a second look at it, can a coordinator stop being it on a network (or would this happen normally)? I guess not, but I ask because in ZigBeeNode class:
public void startDiscovery() {
// ...
// Always request the network address - in case it's changed
tasks.add(NodeDiscoveryTask.NWK_ADDRESS);
// ...
if (endpoints.size() == 0 && networkAddress != 0) {
tasks.add(NodeDiscoveryTask.ACTIVE_ENDPOINTS);
}
// ...
serviceDiscoverer.startDiscovery(tasks);
}
So the Network Address discovery should be irrelevant for a node we know is the coordinator… Could not we just:
// Always request the network address - in case it's changed, unless it is the coordinator
if (networkAddress != 0) {
tasks.add(NodeDiscoveryTask.NWK_ADDRESS);
}
This would solve the issue. The solution is again not CC2531 specific, but if a coordinator cannot change address (otherwise it would not be the coordinator anymore), there is no need to check it, stopping the whole discovery if it fails.
Would this make sense? (considering I do not see where to fix this on the CC2531 dongle specific code)
Yes - the 2531 dongle code will know all of this of course. The dongle will know better than the application code.
This is true, and I think it will work ok. In the early versions this was the only way to get the EUI, but I’ve now got a specific method and I checked that this is implemented in the 2531.
