We can speculate on all sorts of things, but it’s just that - speculation. What’s needed is the logs during the mesh update as I asked for above.
Please ensure that logging is enabled as per the binding documentation.
Ok, here is a log extract that I believe is appropriate: openhab_extract.log (119.3 KB)
At 23:10, I typed those commands in the console:
openhab> zigbee neighbors 0
Total neighbors: 2
Extended PAN ID Extended Address Network Address Device Type RX On When Idle Relationship Permit Joining Depth LQI
E5344F6F349B000F 50325FFFFE2CBEEF 64711 ROUTER RX_ON SIBLING UNKNOWN 15 254
E5344F6F349B000F A4C13816386EDEAD 28469 END_DEVICE RX_OFF CHILD DISABLED 1 254
openhab> zigbee neighbors 64711
Total neighbors: 3
Extended PAN ID Extended Address Network Address Device Type RX On When Idle Relationship Permit Joining Depth LQI
E5344F6F349B000F A4C138968575EF00 24021 END_DEVICE RX_OFF CHILD DISABLED 2 155
E5344F6F349B000F 000D6F000DBACAD0 0 COORDINATOR RX_ON PARENT UNKNOWN 0 49
E5344F6F349B000F A4C138FF87AFABBA 21990 END_DEVICE RX_OFF CHILD DISABLED 2 101
And the log shows a longer period of time during which I believe there is the mesh update as I set its period to 5 minutes.
I see quite a few Node XXX is not updated messages but they don’t seem to come from the binding itself and I’m not sure they are the source of the issues I’m seeing.
Thanks for your time.
I was not sure what I was looking for,
so I fired up Wireshark and started sniffing the zigbee mesh.
Filtering in Wireshark for “zbee_aps.zdp_cluster==0x031” (“Link quality request”)
showed only result when I requested the neigbors for a node manually in the console.
However, after restarting the zigbee-binding I now see Link quality requests from the coordinator to the nodes every five minutes (=Mesh update period).
And now zigbee_neighbors and zigbee_routes show usable content in the UI.
So, somehow the mesh update thingies did not run at the times it should run.
Restarting the whole openHAB now to see what happens…
Something is clearing zigbee_neighbors and zigbee_routes as seen in the UI after
two, three, four or five minutes…
How this is related to the mesh update routines that was not running…
Ok, I think I got it:
When I change the color temperature or the dimmer on one of my bulbs, zigbee_neighbors and zigbee_routes strings disappear from the UI.
They remain “[]” until the next mesh update run.
Thanks, but I still need to see the logs to find out what is happening. It seems like the mesh update is not running, so probably this is a configuration issue. Possibly the configuration is now wrong for some reason. From the logs from @obones it doesn’t run, but I can’t see what the setting is.
Part of log file that contains two mesh updates:
openhab-meshupdate.log.zip.txt (214.7 KB)
I had to zip the log file and then give the .zip a extra .txt to upload it here.
No, the mesh update did not run for me either, but it started to run as sceduled when restarting the zigbee-binding (in openhab-console “bundle:restart org.openhab.binding.zigbee”).
Not sure what configuration you refer to.
Mine is probably OK now, as the scheduled mesh update started as it should do after a full openHAB restart.
Also, the mesh update survived the night with 5 minute intervals.
Here is a zip (renamed to txt for upload) containing the log:
openhab_extract_restart.zip.txt (138.8 KB)
What I have done is this:
- In the ssh console, activate log
- In PaperUI, click the “pause” button for the zigbee dongle
- Wait 10 seconds
- Click the “start” button for the zigbee dongle
- Wait for the dongle to be online, as well as the zigbee socket
- Open each door in turn to “wake up” the contact sensor attached to each
- Wait for 5 minutes
There, I noticed that the routes and neighbors are available and represent the real network.
After waiting for about 10 more minutes, the routes and neighbors are gone on everything but the controller. This is when I created the log file and turned off debug mode.
Just before posting this message, I went back to look at the controller, and its routes and neighbors are now gone and it doesn’t look like they’ll come back.
I was referring to the mesh update configuration.
One thing I observed is that this config can’t be updated when the binding is running - it will only be changed on startup. So if the update period is changed to 5 minutes, it will only actually change when the binding restarts. This might explain why there was nothing in the initial logs from @obones, and might be adding to the confusion.
In general there should be no issue with running the mesh update at a high rate - it “just” creates a lot of traffic, so it can impact your “real” commands.
This was originally written for a large commercial customer for commercial building use, and they ran the mesh update at 1 minute rate - the only real downside is the traffic it generates.
What you see in the console, and what you see in the UI, are not linked. The console and binding requests the information separately.
Is your network actually working ok? From the log, it doesn’t look like it is - most of the commands are timing out -:
In your log there are 29 LQI requests (the command used to generate this data), and only 6 responses. From a quick search, it looks like all these come from the coordinator and one other device (FCC7).
So from this, I only expect the coordinator and FCC7 to show the data, and as far as I can see, this looks ok since I see messages in the log saying that the node is being updated in the binding handler. It doesn’t log the neighbour information though, but I see no reason that it should be there for FCC7, and I see no reason it would be there for other devices.
Did you check FCC7? This and the coordinator are the only devices I would expect to see as at least in this short log, only these two devices are responding, and updating the binding correctly.
I can’t comment on this without seeing the logs, but given the state of your network, I’m not surprised by this. At some point the coordinator will remove devices that aren’t responding from the neighbour tables - which seems to be most of them from what I can see in the log.
I don’t think there’s a bug here - as far as I can see from the logs, and the fact that it is working for @NilsOF I think it’s working ok. There is the confusing matter that the update rate is not changed until the binding restarts which is likely adding to the feeling that this isn’t working and I will take a look to see if this can be changed (I think it is ok to update this on the fly).
Yes, I figured that out, but all I described above was done using paperUI.
Yes, it is working just fine, the door contacts are reporting their status just fine. That being said, the network address requests are all timing out on the same device. And that one is a light bulb that was unplugged at the time I did the tests. So, to me, it’s actually logical that I get those timeouts.
Yes, and it had its routes and neighbors empty.
That’s interesting to know because the door contacts are showing offline after a few hours of not having been activated. What is the usual delay for the router/controller to empty its neighbor tables?
And actually, I believe this is the issue here, I’m coming to the same conclusion in that there is no bug here, because the tables empty themselves on a regular basis, but they get populated when the devices come back up, at least at the interval period.
But because that setting is not taken into account immediately upon validation in paperUI, it’s indeed quite confusing to unwary users like me.
If these are battery devices, then you will likely not get neighbour information from them as they will be sleeping.
Strange - I’m not sure what the issue is as the logs do show the status being updated.
This is not related to devices being offline. Devices are marked offline if they do not report within the expected time actually, twice the expected time, plus 30 seconds).
The binding defaults to 1 day, but it may depend on the firmware as I seem to recall it changed at some point, and I don’t remember exactly what is implemented in the different firmware.
Agreed - I think this is not expected and as above i will see if I can change this (should be possible as I don’t think the low level library is only set on startup, but I may not remember this well).
1 Like
@chris :
Well, This must be a bug…
Also, I notice I get a “Online” update for the Thing over the rest API when the strings zigbee_neighbors and zigbee_routes strings loses their content and turn into “[]”. (I use HABApp for this rest API watch)
Maybe it is the response that is coming back from a device after a command such as a new dimmer value that causes it?
There should be no relationship here, so the only reason for this to happen is if (for example) the device reset and returned updated neighbour information. If so, this would NOT be a bug - would it? From the log, I don’t see any problem.
I’m not sure I understand what you mean by this? Can you explain this please? What is an “Online update”? Is the NCP connection resetting - if so, then the tables would need to be re-acquired?
It shouldn’t - unless the device sends back an updated neighbour table. But again - I can only tell if you provide a log showing what is happening. From the log you provided, I can’t see any problem (which is not to say there isn’t one - just that there’s nothing showing in the logs and the neighbour tables look fine).
Personally I don’t consider this a particularly high priority since it has absolutely no impact on the operation of the system, but if you don’t provide the logs, there’s no way for me to see what is happening.
I do not think the device return updated neighbour information when it responds to a new dimmer value. At least I have not seen that when sniffing (I can be wrong of course.)
Incidentally, this is when the strings zigbee_neighbors and zigbee_routes strings loses their content and turn into “[]”
This is the rest API update of the thing status.
The only sensible time to do that is when something comes back from the device.
I have to set up a clean openHAB instance to show and log this.
(to keep the noise down)
Maybe not high priority, but as my zigbee mesh is growing it gets harder and harder to troubleshoot.
Going into openhab-console, entering the commands, cross referencing with the UI, and then mentally build a network map is just too painful…
And we can not get a graphical map before the data is available thru the rest API.
So I think I understand the issue, but for now I won’t be able to resolve this. It’'s not a new issue so for now we need to live with this.
I thought this was going to be more difficult to resolve, but I’ve found a reasonably non-invasive way around the issue (hopefully).
In the next week or two I’ll try and update the libraries.
2 Likes
@NilsOF one other thing that will be improved in the updated library is this error message. Once this is updated it would be good if you can log any errors in the issues list -:
This way I can at least see if they are known issues - some might go away as I’ve fixed some errors that were caused by invalid Silabs documentation, but there may be more and it would be good to weed them out.
1 Like
Hello everyone!
I am facing the same issue as the others here (openHAB 4.0.4, SonOff ZigBee Dongle-E, Ember). The nighbours of the ZigBee repeater are shown properly in the UI, but the neighbours of the ZigBee coordinator are empty.
Like this, no proper map can be drawn (see attachment).
Did you find a solution how to solve it?
No, my Coordinator Neighbor list is empty (Shown as “” in UI)
openHAB 4.0.4 and still running that cheap Sonof “prelease” Ember stick with 6.7.9.0 firmware.
Hi everyone,
I’ve created a new script to create a zigbee map, that is not affected by the issue discussed in this thread.
Please find the new script here.
1 Like