No. Some commands are still sent in order to perform the initial connection.
I see this too and I think I saw it reported further up the thread. I found that if the coordinator Thing is deleted and recreated, the settings will save the first time. Although, I am only changing the port and channel (to stay away from wifi)… the other settings will auto populate.
BTW, which serial driver are you using? For Windows 10, I downloaded this driver from SiLabs and configured the port to use Silicon Labs Dual CP2105 USB to UART Bridge: Enhanced. I’m waiting on a response from Nortek to driver and port configuration questions, but I’ve had the same results with all settings I’ve used. You may want to hold off on buying zigbee bubs… it looks like you are also in the same nonworking state that I am .
I don’t think I would worry about this. Given that there is no communications with the stick, you will have some problems (hence the null as the stick hasn’t returned its address).
I was able to find out my EPANID. I just started the packet capture in Ubiqua and completeley removed one of my lights from the soket. After reconnecting the EPANID was shown in Ubiqua.
I was also able to use the coordinator directly using console app on my Rasperri Pi. I just unplugged the coordinator, plugged it back in and waited until the green led did shut off. After that the console app started up and began recognizing my lamps. I tried the same with the OH addon but still got the “Dongle reset failed. Assuming bootloader is running and sending magic byte 0x01.” error. There must be something different in the addon as in the console app.
The “cdc_acm 1-1.4.2:1.0: failed to set dtr/rts” did appear again in dmesg, but not directly on the start of the addon. It appeared a few seconds later. So I still don’t know if this is related to the problem.
Any ideas what could cause this problem?
I note in the manual ->
HubZ is designed to support firmware upgrades via the USB port.
Maybe you want to find out how and I might be able to provide some firmware?
I’ve misconfigured the magic number, although I’m not sure this will really matter as it’s sent separately anyway. I’ll fix this though.
Would it help if I changed the magic number in the configuration or is this config ignored at the time? And what would be the correct magic number?
It’s ignored - I clearly didn’t finish off this feature! I’ve just created a PR for the fix…
I saw something about that earlier also, but did not have time to investigate it properly! The values do not seem to be saved, and there is something hardcoded here?
This line is fine - it’s why I don’t think that the bug elsewhere matters as it’s sending the correct byte anyway.
I just copied the zsmartsystems lib’s from your zigbee repository to the lib folder of the console application and now I also get the error. Maybe the solution is to use the latest lib’s? Or is this the wrong repository where I copied the lib’s?
What error is that? Sorry - there’s too many emails now to know what the error is .
I mean the “Dongle reset failed. Assuming bootloader is running and sending magic byte 0x01.” and “Attempt to get out from bootloader failed.” error. I now get exactly the same error in the console app.
I tried the CP210x USB to UART Bridge VCP Drivers from silabs but I couldn’t find one that would work with my stick.
The windows 10 driver was very hard to find. The company that makes the driver has changed names a couple of times. The current version is buried in this installation:
The file you need is:
C:\Program Files (x86)\AxialControl.com\Axial Server\drivers\hubz\HUBZ_VCP_Installer_x64.exe
You have to install the driver manually. The Axial Server will try to install but will fail with a cryptic and useless message. Windows 10 won’t let you install it because it is unsigned. You have to go through a manual process to let windows 10 install unsigned drivers and install this one by hand.
Once installed you should see the zwave controller on one COM port and the zigbee controller on another COM port.
I ran the zsmartsystems zigbee code from inside eclipse. I had to reduce the baud rate before it would talk to the zigbee controller but it did eventually spit out a bunch of log messages about the controller. It seemed to be able to communicate with it but I haven’t dug any deeper yet.
This is an issue in the binding - it should now be fixed. The binding was setting the magic byte to 1 and not fe, but it’s not linked to the library.
Let me know if it helps or not…
Care to elaborate ;). What rate was required?
I suppose I should have said earlier
57600 is the only one that seems to work for me. I found that number in some pdf for the uart chip. I’m looking for it now.
Thanks. I think this UART chip goes a lot higher, but something I noticed earlier is that the Ember chip inside this stick is the EM3581 which doesn’t support USB natively. So, it probably has a fixed UART speed programmed into the NCP code. I tend to use the EM3588 here which has USB internal to the Ember and therefore the baud rate doesn’t matter.
I’ll add an option to change the rate on the Ember.
( and nice find ).