Well, if you want to try a test, then look at line 383 in ZigBeeCoordinator - this should be a return statement - change this to a break statement and (hopefully!) it should work (you might also need to comment out the updateStatus in line 382 - at least it won’t hurt to do this as well).
This is not the right solution, but it is a workaround without having to compile the libraries. Let me know how this goes…
@chris I tried that, re-added the stick and as expected, it doesn’t show the “Bad response” error anymore, but it remains in the UNKNOWN state and does not seem to discover any devices. I ran two discovery sweeps but it didn’t find the bulb. Log is here:
From a quick look, it looks ok, but the dongle has not come up for some reason. I would try to restart to see if it helps as I have seen some issues with the dongle initialising (although I thought this should be resolved already). If that doesn’t fix it, I’ll take another look at the log in the morning.
I tried quite a few things now, rebooting, reattaching the stick, resetting the stick, unfortunately nothing helped. I also explicitly selected a channel because the log seemed to indicate that it considered the channel invalid, but that didn’t help either, the stick remains in UNKNOWN state.
I’ll wait for your advise then and check back tomorrow 
@chris Fwiw, I managed to bring the device online, but only by hacking around in the source further. First of all, I manually selected a channel (11) and restarted the device. That seemed to do something different and in the logs I then found more, including this:
2018-09-20 01:56:04.746 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspFormNetworkRequest [parameters=EmberNetworkParameters [extendedPanId=9718C936F401670F, panId=65535, radioTxPower=255, radioChannel=11, joinMethod=EMBER_USE_MAC_ASSOCIATION, nwkManagerId=65535, nwkUpdateId=0, channels=00000800]]
2018-09-20 01:56:04.749 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=1, ackNum=4, reTx=false, data=93 00 1E 0F 67 01 F4 36 C9 18 97 FF FF FF 0B 00 FF FF 00 00 08 00 00]
2018-09-20 01:56:04.860 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=4, ackNum=2, reTx=false, data=93 80 1E 70]
2018-09-20 01:56:04.864 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=1, ackNum=4, reTx=false, data=93 00 1E 0F 67 01 F4 36 C9 18 97 FF FF FF 0B 00 FF FF 00 00 08 00 00]
2018-09-20 01:56:04.868 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspFormNetworkResponse [status=EMBER_INVALID_CALL]
It seems that panID was always being set to 65535, even though I entered different values. I made a change in ZigBeeCoordinatorHandler.java around line 147 to set it to 0xfffe instead because the logs showed it was executing that branch and using 0xffff there though. That was just a guess, but the right one apparently: It seems that the device does not like 0xffff as a panId.
After I made that change and yet again reinitialized the device, the device came online. I then searched for the bulb (the Innr one) and it was found, colors, switching, etc. all works!
I think we just need to figure out now what steps are required to properly initialize this stick from the start. I’ll be happy to help with that tomorrow and investigate further, for now I need some sleep 
I will try and find some time to look through the log properly. The initialisation procedure in the libraries I’m very confident of as it’s exercised regularly, and used in a number of solutions. I don’t tend to initialise through the binding very often though, so the setting of the options could be incorrect here… I’ve just noticed that the binding isn’t setting the random PANID if set to 65535, which is the AUTO setting - I’ll change this to 0 in the XML and this would also solve your issue with the PANID.
This may then be the only issue by the looks of it.
If you fancy trying this all again from scratch, I’d suggest to delete the coordinator thing and add it back. I think this will likely work straight away as the default for the PANID is 0, but I guess you changed it to AUTO when things weren’t working initially?
Thanks for spending the time to help with this - as I say, it’s an area I don’t tend to test so often within the binding as most of my low level testing is done directly on the libraries with a console application .
For reference -:
@chris Thanks for taking the time. In fact, I tried to set PANID to various values (0, Auto and values chosen by fair dice roll) through the UI but it would ignore them and always use 65535 which is why I started modifying the source. It might be a UI problem of course.
PANID was not the only problem though. Before that, the channel was not explicitly specified and that also caused an error until I set it to channel 11 (this is the ember3 log). I also noticed another potential error source: When I set the Power mode from “Normal” to “Boost” it also gave me an error (again on the EzspFormNetworkRequest) until I switched it back to “Normal”. If I remember correctly, “Boost” was the default selected in the UI.
I can do some more testing next week, but this weekend I need the lights to work It sounds to me like it is mostly a UI/default value issue though and that the stick I have is sensitive to some values and refuses to work when any of the parameters don’t seem ok.
Are these problems unique for Ember coordinators? I think it could explain some of my problems.
Yes, I also fixed the default on the channel in the PR I referenced earlier.
If you have an error with the boost mode then please can you post this here?
Thanks
What problems specifically? If I remember correctly, your system was initialising fine, and coming online? If so, it’s not related to this.
Hi -
Would like to start testing the Zigbee binding with an Orbit hose timer I have. Where can I get the latest build?
I skimmed through this post but didn’t see anything. The one link I found was broken.
Thanks
Dave
The latest is in the snapshot builds.
It did/does initialise (partly)
But as mentioned a coupple of days back, it breakes communication after a few days (latest it ran for aprox 12 day, where I was on a vacation. Normally it manage to run for 2-4 days then all Zigbee communication seems to stop).
After rebooting (cold start of the Rpi, warm reboot does not work) the coordinator comes back to live, and lately also found my Philips Hue devices as well. But the Trust motion sensor is still offline . And I have not been able to get it back online again.
Why I ask if this could be related, is because I use an Ember coordinator as well, (Elelabs Rpi Shield). And I really have a feeling there is something wrong somewhere, either with the shield itself, the binding or something. It can´t possibly be the intention, that I would have to restart (could start) the Rpi every few days, just to make sure it continues to work?
This is what I thought, and in this case it DOES initialise, and it works. Then the issues discussed above are in no way related since these prevent the device being used at all.
Ok, but just because you use the same hardware does not mean it’s related 
. The issues are completely different - as mentioned, the issues we were discussing above relate to the initialisation of the dongle - setting the channel, and setting the PANID - this is not an issue that you had.
I’m not saying that you don’t have issues, and it would be really useful if you could provide sniffer logs as mentioned some time back as this is really the only way to see what is happening in your system.
I did see you message regarindg a sniffer log, but honestly, I have no idea how to make this sniffer log. I may have missed some messages though. But since I´m using the Elelabs Rpi Shield, I would probably need some help/guide on how to anyway.
Found the message about the Sniffer log. And as far as I understood, Wireshark runs on mac or windows.
But, if I get this correctly, the sniffer log part (the actual sniffer jar) can run in Linux (openhabian) and can log to a wireshark compatible logfile… (option -w). I guess I could use that, log the communication and send you this log or?
I really do want to participate in eliminating all kinds of issues there may be.
Yes - that would be perfect. Note though that you need an extra dongle - ie you can’t use the sniffer at the same time as the coordinator/binding.
There is a new option in the sniffer as well that I’ve probably not documented yet, and this allows the file to be truncated at a certain length (eg start a new file every 10MB). With this it should be possible to log permanently without files getting too big.
If you don’t have another stick, I might be able to send you one to borrow while we debug this.
It really would be appreciated. Silabs were not very useful - they agreed the documentation is not usable, and said they would have to look at the sourcecode to work out how it works, but have not come back to me to tell me what the options mean (despite me asking a number of times now). If we can get some logs, then I can use this to prompt them to look at this issue again.
Thanks.
Hmm I dont have another stick… I use the Elelabs Rpi Shield, remeber 
I have thought about getting an USB stick, since this Rpi shield cant be moved to another platform, if I want to. And it was mainly bought for testing Zigbee only.
It´s really bad silabs isn´t answering your requests. One would have thought they would be interessted in this community as well.
It would be great if you could get one so we can start to debug this
I will. Just need to figure out which one. Tried searching for the Telegesis, but couldn´t fine anyone in europe.