No, but you didn’t like the comment that people have to play with devices to find out what the channels mean. (you said -:: “play to see what it does” dont seem like a good advice). Someone needs to do this, and if you are not wanting to do this, then it falls on someone else. I got the impression that as you didn’t like my advice, you expected me to provide better statements? If you are buying a commercial system, then I think you can expect to have this for the devices that are supported by said system, but here, we expect that people do spend some time to “play” and understand what the device does for themselves.
As I said above, the binding can’t show what it doesn’t know. If it knew there were missing channels, then, well, they wouldn’t be missing . If there is a failure in the detection, then this is printed in the logs. In the longer run, I plan to improve the management of transactions to make this more tolerant, but this is a lot of work and at the moment, it’s not quite at the top of the list (although it’s not far off). When this is done, I hope that this issue will largely go away.
Thanks, and I appreciate that. I hope that once I can get you the sniffer that we can find some of the issues that are causing you problems, so I do appreciate that you are wanting to help .
I have upgraded to M4 and the latest bindings, but I am seeing some errors in the main OH log file now. I will get those figured out and then I’ll see where my zigbee stick is at.
openhab> bundle:list -s | grep -i g.zig
285 x Active x 80 x 2.4.0.201810032130 x org.openhab.binding.zigbee.telegesis
287 x Active x 80 x 2.4.0.201810032130 x org.openhab.binding.zigbee.ember
288 x Active x 80 x 2.4.0.201810032130 x org.openhab.binding.zigbee.xbee
293 x Active x 80 x 2.4.0.201810032130 x org.openhab.binding.zigbee
294 x Active x 80 x 2.4.0.201810032130 x org.openhab.binding.zigbee.cc2531
openhab> bundle:list -s | grep -i s.zig
286 x Active x 80 x 1.1.2 x com.zsmartsystems.zigbee.dongle.cc2531
289 x Active x 80 x 1.1.2 x com.zsmartsystems.zigbee
290 x Active x 80 x 1.1.2 x com.zsmartsystems.zigbee.dongle.xbee
291 x Active x 80 x 1.1.2 x com.zsmartsystems.zigbee.dongle.ember
292 x Active x 80 x 1.1.2 x com.zsmartsystems.zigbee.dongle.telegesis
Yet PaperUI shows it as offline: Status: OFFLINE Failed to startup ZigBee transport layer
And when I start a scan it aborts right after it starts:
> 2018-10-06 17:30:37.118 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Starting ZigBee scan for zigbee:coordinator_telegesis:04003E38
> 2018-10-06 17:30:37.118 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee coordinator is offline - aborted scan for zigbee:coordinator_telegesis:04003E38
Worth noting that I see several ServiceEvent REGISTER / ServiceEvent UNREGISTERING cycles in the logs. This may have been correlated to when I check the dongle status in PaperUI, but I can’t say for sure
I believe that should do the trick… a zigbee.log file was created in /var/log/openhab2/ but its 0 bytes in size right now… But I think the zigbee binding has stopped working again. I dont get any respons from any of my devices. Could that be the reason for this beeing a 0 byte file?
@5iver
After an reboot, and activationg DEBUG level for zigbee and Zsmart systems, the zigbee-log file is still 0 byte in size…
I guess it´s not logging to this file after all… Hmprf!
These are the shortest “full” logs I’ve seen . Please can you enable debug logging - there’s only INFO in here…
I suspect it will show the same issue as previously. There was a bug introduced a while back where the initialisation method returned an error and this stopped the binding starting. I’m pretty sure this was fixed in 1.1.2 though -:
This was merged on the 22nd Sept, and 1.1.2 was released on the 23rd Sept.
Unfortunately not (sorry). I don’t see the dongle initialising at all - in fact there’s nothing in the log that I can see from the ZigBeeCoordinatorHandler class. On top of this it’s missing the zsmartsystems library debug, but I’m not sure this is “missing” as there’s nothing from the coordinator handler, so maybe it’s not being called. I’m not really sure what is happening, but it doesn’t look like the binding is even running .
This looks ok I think - at least there’s nothing obviously wrong.
I’m not sure what to suggest at the moment, but there’s something fundamentally wrong somewhere I think.
@chris
Finally with help from @5iver I have managed to log zigbee into a seperate logfile at debug level.
Zigbee is still running fine since a few hours ago, so the logfile will not show the typical problem I´ve got.
I just scanned through the logfile untill now, and there seem to be a few errors anyway. Some not supported attributes, and some managment error… I have no idea if thats important or not.
If you want to have a look, this is the logfile. logfile
Meanwhile, I´m just waiting for the communication to stop, hopefully soone, (I´ll bet within a day).
I suspect that the communications issue may not show anything useful in the log, but let’s see. It depends where the problem lies - if it’s a coordinator configuration issue, then the log won’t help (probably) - although it won’t hurt. For this, we will need a sniffer log (I’m still waiting to receive the dongles, but I hope they should be here in the coming days).
If the problem is an exception in the binding, then the log will help - either way, I’m very happy to take a look, and thanks for spending the time to get this set up.
I know. I just thought that maybe this log could provide someting, cause I saw these errors. It may have nothing to do with the failing communication, though.
Look forward to start sniffing so we hopefully can get this zigbee up running for good…
Do you mind emailing me your XML file for Zigbee - it’s in the {userdata}/zigbee folder.
Thanks.
Yep - it’s interesting and useful. I don’t think there’s anything major in the log, but I think I see one thing that is wrong, so I can fix that at least.
. If there is a failure in the detection, then this is printed in the logs. In the longer run, I plan to improve the management of transactions to make this more tolerant, but this is a lot of work and at the moment, it’s not quite at the top of the list (although it’s not far off). When this is done, I hope that this issue will largely go away.
.
