I was using an Xbee USB stick but I’ve swapped that for a CC2531 that I flashed. That’s showing online ok but all the Things are showing “UNINITIALIZED - BRIDGE_UNINITIALIZED”. Is there anything I need to do to make them use the CC2531 instead of the Xbee?
When you changed bridge, you have created a new network - have you reset all devices and joined them to the new network?
No. I think this goes deeper than that anyway. I flashed the cc2531 to use zigbee2mqtt.
I think I’ll go back to the Xbee. I just hoped the cc2531 might help with the latency issues.
When you change networks, everything changes and you will definitely need to do this…
There’s no major difference - it will work find with the zigbee binding.
It’s unlikely to - if your network has latency issues, then using an Ember or a Texas chipset is unlikely to make a lot of difference - both are good quality, although I think the Ember is better, and certainly has a faster processor (Ember chip is used in the XBee).
At this stage of the proceedings, the thought of having to pair all my devices again having just set them all up with rules and items just fills me with dread. If there’s no advantage then I’ll stick with what I have.
There’s not many ways around this. Most controllers (including TI, and XBee) don’t provide the information required to migrate the network from one controller to another. This is all related to security - both keys, and other information. I’ve provided this functionality for the Ember controller with some customers, but it’s not a straight forward issue.
Thanks. I’m still intrigued as to what’s causing the latency in the first place. It’s unusable at the moment.
Do you have a debug log? It might at least help to understand - normally it is caused by timeouts in the network - ie poor link quality.
I just turned debug off. There is LOTS happening. I’ll turn it back on and paste a snapshot in here.
In the meantime, I’ll also move the Pi. It’s currently on a low table (0.5m high) next to my SmartThings hub.
Would I be right in saying that it’s a bit like this:
Andy asks for light to switch on
Zigbee controller tries to check the health of a motion sensor and gets no response
Zigbee controller sends command to switch the light on
Log.txt (50.7 KB)
I don’t know if this is enough to see what’s going on?
Thanks for looking at this. I’m determined to get this going!
It shouldn’t be like that unless you’ve got some sort of rule that’s doing something with a motion sensor. Motion sensors will respond slowly since they are battery operated. If you are just sending a command to turn on the light, then the command should be sent “immediately”.
The binding has a few queuing mechanisms - it only allows a certain number of commands to be released at once (to avoid flooding the network or overloading the controller) and it only releases one command per device at a time. Retry within the binding is set to 7 or 8 seconds, but at a lower layer the controller itself is also performing retries a lot faster than that.
Unfortunately not. If you can provide a larger log that would be good - just capture 10 or 20 minutes (or even an hour or two). The log will be big - I can generally handle logs up to 10 or 20MB, but you’ll need to load then to dropbox or some similar file sharing system.
One issue with this log is it has some strange
\cb1 added to the start and end of all lines (see below). I’m not sure why this is happening, but if you can stop that it would be good as it stops the log display software working properly.
\cb3 2020-05-12 15:32:46.105 [DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - readSync request: 0\cb1 \
Note that this is likely linked to this discussion with @wtf911 as I see similar things in your log with respect to queing and we might want to combine the discussion if it appears it’s the same thing.
Ah, ok. No problem. I was trying to keep things small. The weird characters might be where I pasted it into the basic text editor on my Mac. I’ll fire up an FTP server on the Pi and download it that way so you have exactly what’s on the server and stick it on Google Drive.
Just had a quick look at that thermostat link. That rings little bells. Especially with dimmers and coloured LEDs. For example, I’ll set the LEDs in the garden to blue. The slider will change to blue. The LEDs will do nothing. Then at some point later - might be 1 second or 30 seconds, the slider will move on its own back to the colour they actually are. With the on/off scenario, I have seen the same happen where I turn the light on and several seconds later the switch in OH just turns off again.
Anyway, I’ll see if I can grab that log and post it here shortly.
How about this?