I just started fresh now. When adding the coordinator, I tuned on initialization and entered the PAN ID I used with zigbee4java. I also selected channel 11. I didn’t enter a encryption key or the extended PAN ID.
When trying to change the config, a different PAN ID I entered (but a random key and an extended PAN ID, init is disabled again).
From the logs:
2017-05-05 23:02:33.489 [ThingAddedEvent ] - Thing ‘zigbee:coordinator_cc2531:b689b918’ has been added.
2017-05-05 23:02:33.565 [hingStatusInfoChangedEvent] - ‘zigbee:coordinator_cc2531:b689b918’ changed from UNINITIALIZED to INITIALIZING
2017-05-05 23:02:33.646 [ThingUpdatedEvent ] - Thing ‘zigbee:coordinator_cc2531:b689b918’ has been updated.
2017-05-05 23:02:33.672 [ThingUpdatedEvent ] - Thing ‘zigbee:coordinator_cc2531:b689b918’ has been updated.
2017-05-05 23:02:33.700 [ThingUpdatedEvent ] - Thing ‘zigbee:coordinator_cc2531:b689b918’ has been updated.
2017-05-05 23:02:33.746 [ThingUpdatedEvent ] - Thing ‘zigbee:coordinator_cc2531:b689b918’ has been updated.
2017-05-05 23:02:33.761 [hingStatusInfoChangedEvent] - ‘zigbee:coordinator_cc2531:b689b918’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): ZigBee transport layer not yet initialized
2017-05-05 23:02:42.453 [hingStatusInfoChangedEvent] - ‘zigbee:coordinator_cc2531:b689b918’ changed from OFFLINE (BRIDGE_OFFLINE): ZigBee transport layer not yet initialized to ONLINE
2017-05-05 23:02:42.492 [ThingUpdatedEvent ] - Thing ‘zigbee:coordinator_cc2531:b689b918’ has been updated.
2017-05-05 23:02:35.116 [INFO ] [ndler.ZigBeeCoordinatorCC2531Handler] - Serial port [/dev/ttyACM0] is initialized.
It’s displayed as online now, but when trying to pair a sensor, it doesn’t seem to work. Currently, I’m only seeing the packets from the sensor, but not the coordinator. RF seems to be a bit bad here (openhab server isn’t located at my desk…). But I don’t see the status update packets from the sensor, therefore I guess the pairing didn’t work.
Any ideas how to debug this further?
When zigbee4java worked, I used a specific PAN ID and network key was all zeroes. Setting this PAN ID somehow didn’t work…
If you want to use the existing network, then you don’t need to configure anything. I think this point is linked to the first question - ie what does “tuned on initialization” mean? Are you trying to initialise the dongle complete (ie setting the Reset Controller to true)? If so, then it will reset everything.
So, to try and explain a bit more - if you select “Reset Controller” - it will “Resets the Controller and sets the configuration to the configured values.”. This will use the values you enter. If you don’t set it to reset, then it will use the existing data on the dongle.
“Tuned on initialization” should have meant “turned on”, sorry for the typo. Anyway, I started all over again now that I realized what the “reset controller” option is meant to be.
Before I started again, I entered the parameters that the addon generated into the zigbee4java gateway, just to make sure the sensors work with that config (and that I have the right firmware). That works; I can see the notifications from the sensors.
So, back to openhab2: I installed a fresh snapshot on my workstation and your zigbee addon. I started up karaf with the “debug” argument. I added a thing, selected “reset controller”. That’s what my config ended up being:
The logs seem to indicate that everything went fine and the coordinator is online in the GUI.
But the communication with the sensors fails. Do you need a packet dump from the TI sniffer? Or is there anything more to enable debugging besides “karaf debug”?
That’s all I get in the logs:
==> userdata/logs/openhab.log <==
2017-05-07 14:00:19.756 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at /start
2017-05-07 14:00:20.007 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-05-07 14:00:20.098 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-05-07 14:00:20.139 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
==> userdata/logs/events.log <==
2017-05-07 14:00:20.242 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:977a2a62' changed from UNINITIALIZED to INITIALIZING
2017-05-07 14:00:20.244 [ThingUpdatedEvent ] - Thing 'zigbee:coordinator_cc2531:977a2a62' has been updated.
2017-05-07 14:00:20.256 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:977a2a62' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): ZigBee transport layer not yet initialized
==> userdata/logs/openhab.log <==
2017-05-07 14:00:21.357 [INFO ] [ndler.ZigBeeCoordinatorCC2531Handler] - Serial port [/dev/ttyACM0] is initialized.
==> userdata/logs/events.log <==
2017-05-07 14:00:27.338 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:977a2a62' changed from OFFLINE (BRIDGE_OFFLINE): ZigBee transport layer not yet initialized to ONLINE
2017-05-07 14:00:27.346 [ThingUpdatedEvent ] - Thing 'zigbee:coordinator_cc2531:977a2a62' has been updated.
Sorry, I guess I mentioned them in a different thread. I’m trying out the Xiaomi Mi Smart Home Wireless Switch, Door/Window Sensor and Temperature/Humidity Sensor. As mentioned earlier, they send Attribute Reports with the Secure_LinkKeyJoin.hex firmware from TI’s Z-Stack Home 1.2.2a.44539.
Ah - ok, sorry, I reply to so many messages on here about different sensors etc that I loose track.
The log looks a bit strange - like it’s running some old code so I might have linked with an incorrect version of the libraries in this version. I’m flicking back and forward between the Ember and TI dongle at the moment which is a bit of a nightmare…
Never mind. I’m still not sure where I mentioned those sensors in the first place.
Are you planning on building a new snapshot build then? Please don’t feel forced to do so. I can see how much hassle it is to debug two different dongles at the same time! Btw: On some startups I can see that the binding fails to reset the dongle and tries to send the magic packet to the bootloader, but can’t recover from there. Unplugging the dongle and restarting helps.
Yes - I’ll take a look at it a bit later. It’s definitely running the wrong library - ie before I (hopefully!) fixed the TI startup issue.
Yeah, but that’s why I need to get the TI working properly so we’re only having to deal with common parts of the code…
Yes - this was the problem I had. The startup wasn’t configuring a couple of parameters and it crashed the dongle. This is fixed now so hopefully it’s just a case of sorting out the libraries and recompiling the binding.
@chris > A small word of warning though - these TI dongles may not come with appropriate firmware loaded, and getting this loaded can be painful.
Oh yes, that’s quite true. Thanks for this warning. Without this I would have given up sooner
Anyway. I’ve finally flashed the firmware on the CC2531 and it is recognized by the binding.
For the first tests, I resetted one of my Osram Lightify bulbs and started zigbee discovery through PaperUI->Inbox->Search for things → Zigbee
Unfortunately, the bulb isn’t found. That’s the debug output of it:
Osram bulbs should work ok if they are ZLL bulbs - of course they might need resetting before they will join (I don’t have one to test with, but this is normal).
The response to this is not processed by the binding - the response looks like it’s probably correct, but it’s using a different frame than my dongle responds with.
So, if we go back to your first point -:
What version of ZNP/ZStack are you using? Mine is probably a year or two old - I’m guessing your might be newer and it might have different configuration/defaults.
The response your device is using looks very interesting but it’s not fully documented in the doc version I was using when I wrote this so I’ll see if the later docs have it.
It looks like your dongle is also returning the same as @curlyel. I dont think this is impacting associations, but it is certainly an issue. Can you tell me what version of ZDP you are running.
In future, can you provide logs as a file please - not an image.
Hi Chris,
I’ve had just little time this and last night, but also failed binding the Xiaomi sensors. Z-Stack is 1.2.2a.44539 (pretty old, I guess), with the Secure_LinkKeyJoin.hex firmware. Is this combo expected to work?
I do also see a lot of unhandled 0x45ff packets. I haven’t had time to look further into the logs.
Tonight I got the ccsniffer python script (USB<->wireshark) work in case you need packet captures. Or is just the openhab.log enough for debugging?
These are ZDO messages - my dongle doesn’t seem to send the ZDO messages in this packet.[quote=“mwick83, post:54, topic:15763”]
Or is just the openhab.log enough for debugging?
[/quote]
Yes - until I work out the issue with the 45ff packets it’s not going to work. It’s strange that my system isn’t sending these - it sends specific ZDO messages. I’d actually much prefer the way your system is sending them as it looks like it’s a global message for all ZDO which is much preferred.
I’ll look to update my dongle (if I can find my programmer ).
Interesting - both you guys are running the same version. it’s been so long since I programmed my dongle I don’t remember what version it has. I might try programming a stick with the latest ZNP3.
I’ll post another update tonight hopefully - this will add a log entry that reads back the version. Then we can avoid relying on remembering what versions we loaded (well, hopefully!).
The version string will look like this -:
CC2531 version is Software=2.5 Product=0 Hardware=1 Transport=2
Thanks for looking into it @chris.
Here is my version:
CC2531 version is Software=2.6 Product=0 Hardware=3 Transport=2
btw.: Meanwhile, I’ve resetted some HUE bulb too just to check if it’s different - It’s the same as the Osram - not found during discovery. Since you suspect the issue to be related to the ZNP firmware version, I guess this is expected result…
As above, it won’t work until we solve this issue. At the moment the stack isn’t receiving the ZDO messages - until this is resolved pretty much nothing will work and changing devices won’t help I’m afraid.
I’ll take a look at this later - I’ll try and add a handler for this based on your logs. Can you also post the hex file that you used so I can look to program a stick with this version for testing?
