I don’t see any device joining the network.
I’m not really sure what you mean by ghost node?
Since the device doesn’t seem to join the network, it’s pretty hard for me to comment on what is happening. Maybe it’s not being reset, or maybe there’s another issue - it’s really impossible to tell when the issue is in the network layer since there is nothing logged and no messages to the binding in this case.
By ghost device I meant the following:
As you say, no device is joining the network. But in PaperUI it seems like my unpowered device is found and joining. Thats why I used the term ´ghost device´.
How can I get rid off the Thing? It feels like it is “remembered” anywhere?
Yes, that is fine. If the device hasn’t been removed from the network, then the system will still know about it. When it is discovered again the data will be updated. This is not an issue.
To remove a Thing, just delete it.
Like where? Things should only be listed in the UI - if you remove it, then the Thing should be gone.
But as I wrote, I did remove the device before.
That is what I did. I even restarted OH after that. And it was not listet in PaperUI Things List anymore.
As I said, the device will be remembered by the network - this is similar to other protocols like ZWave. This avoids having to rediscover information about the device every time which takes time to do.
I thought deleting the thing leads to removing the node from the network.
But now I seem to have the situation that my “network” still knows the device but the device is not in the network (It shows this on the display).
I’m not sure - on older versions, this will not be the case, and I think the OH binding is running quite an old ZigBee library.
Either way, I think we’re getting off topic.
Sorry, wasn’t my intention.
I retried it with powered thermostat to get it into the network again. It is now shown as “unknown zigbee device” but it doesn’t join anymore.
The log:
zigbee_debug_log3.txt (105.8 KB)
Unfortunately I can’t see why this isn’t working. The binding receives the notification that the device has joined, and the binding starts the discovery to find out the endpoints and services, but there are no responses from the device, and the dongle returns that it cannot contact the device.
This sort of sequence where the binding sends commands to the device repeats a number of times but there are no responses. Either the network join was not really successful, and the device maybe left, or the device is simply not responding - it’s impossible to tell from logs at this level.
OK. 
Thank you for investing your time on this!
The device shows “Err” after a approx. two minutes and shows a blinking radio icon which means it has not joined a network so far.
I made another test. I have reset the device to factory defaults and did the same with the controller via PaperUI and deleted the XML file in the zigbee folder.
After that I restarted the search for Things.
The thermostat is now listed with its name and not as “unknown”.
But once again, the join process fails.
Here is a log file of this. Maybe you can see anything there?
zigbee_debug_log5.txt (194.7 KB)
Are really you sure that’s what it means? Or does it just mean that it hasn’t received some sort of communications that it was expecting? We see this on the ZWave version, and it is not related to it being on the network - it’s related to it not receiving something it expects. ZigBee may have a different meaning of course? I see the manual states “ZigBee controller not in add mode or out of reach” but clearly the device joined the network, and often manufacturers dumb down their error reports like this so I’m not really sure.
Yes, I can see this joining, and the binding requesting all the initial information required to discover the device.
What do you mean by this? It looks like the join is fine and the binding is communicating with the device.
I suspect that the device has either gone to sleep, or maybe it’s left the network as it didn’t receive something it expects - unfortunately it’s difficult to know. All the initial communications to establish the device have worked fine - the device responds quickly, but by the time you add the thing, which is where the channel discovery occurs, the device is not responding - it’s either asleep, or has left the network.
Unfortunately it’s going to be difficult to tell what’s up from here without a network sniffer and/or information from manufacturer.
Sorry, that wasn’t clear enough from my side. This happend while logging zigbee_debug_log5.txt
My conclusion was, that the join process failed. But as you wrote, it might also be that it has joined and then again left the network because of whatever.
I once again tested it with OH 2.4.0 stable and the join process runs smoothly. But then there are again no channels listed which was my original problem.
But the interesting fact is that the device joins the network successfully in this constellation.
The log of the thing search with OH 2.4.0:
zigbee_debug_log6.log (559.4 KB)
Maybe I found a trace:
In zigbee_debug_log5.txt (OH 2.5.0.M6) at 03:21:16.614 it starts to discover the attributes of the clusters. The device responds to this requests for cluster BASIC and OTA_UPGRADE. At 03:22:40.326 the attributes for POWER_CONFIGURATION are requested. This is when it stops to respond.
Now when I look into zigbee_debug_log6.txt (OH 2.4.0) I can see this attributes discovery from 23:23:24.187 on. Here it also works until attributes for cluster POWER_CONFIGURATION are requested. But here we see a response with statusCode=UNSUP_GENERAL_COMMAND 
And (not sure if it matters) in zigbee_debug_log6.txt (OH 2.4.0) after the Attributes discovery there is a ManagementBindRequest and response which can not be seen in zigbee_debug_log5.txt (OH 2.5.0.M6).
The join worked fine on the previous log (from 2.5 I think). This is not the issue. It joins, it gets discovered - that’s all fine. The issue is with the discovery of the channels and possibly that the device is expecting some sort of watchdog.
Unfortunately it’s quite hard to diagnose why it would (apparently) leave the network as this is not normal behaviour for ZigBee devices and without a sniffer log, it’s impossible to tell.
OK. I will have to get a sniffer when I want to go deeper into this.
One more little question:
What do you think about the comparison of the two log files I wrote above regarding attribute discovery for POWER_CONFIGURATION and statusCode=UNSUP_GENERAL_COMMAND?
I didn’t see that (I guess it’s in the latest log that I’ve not looked at). This doesn’t matter though - the binding has multiple ways to detect what the device supports.
Ok, thank you very much!
Hi, Chris ! Your new ZigBee magic is not ready yet ? Can we ride a SPIRIT ?
I think people are using the Spirit, but others are having problems. I don’t personally have one so it’s difficult for me to comment further at the moment.
If someone wants to send me one, or a few people want to donate a few $£€ to allow me to buy one, then I will take a look.
Though mine works most of the time, I’m willing to donate ~10€. Do you use PayPal?
One week ago, I already asked Eurotronic to support with a device for testing, but they didn’t respond. So I guess buying is the only option.
Right now (for the next ~7 hours) the Spirit seems to be on sale on Amazon for 28€.
Anybody else willing to donate?
