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).
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.
@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.
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).
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.
