Its actually really easy to wake up…press any of the 4 buttons . The similarity to the ZW096 is that once the device is included it can take over 2 hours to finish discovery with me waking it up randomly about every 15 to 30 minutes. If discovery finishes, it will work for about 24 hours and then slip back into discovery again which is where it is now with init_neighbors. Fortunately this time it’s still working, but during previous attempts OpenHAB has stopped receiving scene commands when it enters this state. Mostly what I’m hoping you can help me with is to confirm that this isn’t a systemic issue and that both devices are simply misbehaving on their own. The attached log is me switching on a light while the remote is in the state init_neighbors. Even after the node goes back to sleep init_neighbors remains in Habmin.
Which node am I looking for? There are a couple of nodes sending wakeup messages. One of them is also apparently a listening node, so something might be wrong there (that’s node 10).
In either case, both nodes are already completed initialisation, so everything looks fine in this log.
I don’t see this in this log - the two devices sending wakeup messages are finished initialisation. Also, why does it go back to init_neighbours - are you restarting the binding? I think that’s the only reason it would go back to the start of initialisation - or maybe there’s another way that I can’t think of at the moment…
The other possibility is that HABmin is not displaying this correctly, but that seems unlikely I think as HABmin is just getting the information from the binding, and the binding is clearly stating the initialisation is DONE -:
NODE 10: Application Command Request (ALIVE:DONE)
At this point I really need to thank you for helping me with this. I haven’t had to troubleshoot devices before so this has been a learning experience.
Node 19 is the Nodon. Node 10 is a ZW100 running on USB power that has never been added on battery.
That’s exactly the problem, shouldn’t there be a flurry of discovery activity after the device wakes up if it’s truly waiting for discovery to finish? I did restart the binding at one point or another during my troubleshooting. There is an XML for node 19 so it should finish discovery easily which is why I don’t understand why its been sitting on init_neighbors. My wife has been using it constantly too so its had plenty of wake ups.
I think its safe to say that the Nodon and the Aeotec issues are unrelated. Given that I’ve had several days now of stable behavior I’m ok with ignoring the init_neighbors message and seeing if it resolves itself in future builds. I hate to give up but this issue has been so intermittent.
Ok, that makes sense then.
I thought the problem was the initialisation was stuck getting the neighbours?
Ummm - yes, but once it’s finished discovery, then it will stop, right? The state shown in the log is DONE - this means the binding is no longer initialising the device - it’s complete. Presumably earlier, this state would have been different, but I don’t see that in the log.
Sorry - this doesn’t make sense. If there’s an XML, then it means discovery has been completed. The discovery state (ie DONE) also shows that it has been completed - it is not sitting on init_neighbours according to the logfile. I don’t really see how the log can show something different to the UI - maybe it’s possible, but I think they should show the same thing.
As above, the log shows a wakeup, but since the device has finished initialisation already (according to the binding), it doesn’t do anything.
It sounds like there’s a disconnect between what’s in the logs and what is being reported by Habmin/Paper UI. Despite being completely discovered Habmin still shows the following:
Strange - I’m not sure how that’s possible, but I will take a look. Is this coincident with the logs showing done (ie this image is definitely taken when the logs are showing (Alive:Done) for the status)?
Yes, nothing has changed since the logs I sent you yesterday showing no discovery activity after a wakeup. Are there any logs I can pull related to how Habmin queries the binding?
HABmin doesn’t query the binding - it gets the data from ESH. When the binding updates the state, it tells ESH the current state. There’s nearly no way that I can see for these to be out of sync.
Have you refreshed the browser (I guess so if it’s been running for a long time, but just thought I’d ask).
The only other thing I can suggest is to reinitialise the device (there’s an option in HABmin to do this) then wake it up a bunch of times, and then send me the log. I can see if things look ok from that…
This is the log after reinitializing. Now Habmin says:
This is caused by the controller reporting that the device is DEAD.
There is a test version of the security binding that bypasses this as this test seems to cause problems. The idea is to refactor this out before merging the security binding into master…
You might want to give it a try - it should avoid this problem at least.
That solved it! All of my devices came right up after installing the testing version. I’ll patiently wait for the merge to master.