Zigbee binding

Thanks for the hint, I will try this when I’m back home. I just found several errors in the dmesg log. I don’t know if they are related to the problems with the z-stick:

cdc_acm 1-1.4.2:1.0: failed to set dtr/rts

My Zwave usb stick also appears as acm device, so the errors also could be from this usb device. Or could this be the problem why the device is not initializing?

And by the way, I’m always getting several errors in the log when trying to change the settings of the thing using paper ui:

2017-07-04 11:10:14.730 [ZigBeeCoordinatorHandler  ] - null: Configuration received (Coordinator).
2017-07-04 11:10:14.732 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_port.
2017-07-04 11:10:14.733 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_channel.
2017-07-04 11:10:14.734 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_initialise.
2017-07-04 11:10:14.734 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_panid.
2017-07-04 11:10:14.735 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_znp_magicnumber.
2017-07-04 11:10:14.736 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_extendedpanid.
2017-07-04 11:10:14.736 [ZigBeeCoordinatorHandler  ] - null: Unhandled configuration parameter zigbee_networkkey.

The settings are not saved after that. I had to edit the json file directly to change them.

Edit: I also just tried to use the zsmartsystems java console lib on my Raspberry Pi using the same command line as on my Mac and got the same error:

11:54:39.696  INFO   ZigBee network key defined by command argument.
Initialising console...
11:54:40.391  DEBUG  CC2531 transport initialize
ZigBee network state updated to UNINITIALISED
11:54:40.709  DEBUG  ->  SYS_RESET (Packet: subsystem=null, length=1, apiId=41 00, data=FE 01 41 00 01 41, checksum=41, error=false)
11:54:45.719  WARN   Dongle reset failed. Assuming bootloader is running and sending magic byte 0xef.
11:54:50.720  WARN   Attempt to get out from bootloader failed.
11:54:50.721  INFO   Serial portName '/dev/ttyACM1' closed.
^CException in thread "Thread-0" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.console.ZigBeeConsole$5.run(ZigBeeConsole.java:190)
        at java.lang.Thread.run(Thread.java:748)

My guess would be that this maybe a problem with the kernel serial port driver. What do you think?

Interesting. I think that the 2531 handler doesn’t use RTS but I’ll check since it might be a hangover from the Ember driver which does use RTS/CTS flow control.

I’m trying to use the HUSBZB-1 as well. I’m on windows 10. The zigbee part (COM3 on my system) shows up under “things” as “initializing”. The zwave part (COM4) shows up as “online”. I’m going to get a zigbee light bulb at home depot today to see if the zigbee controller can find it.

When I was trying to use some other software to use the zigbee controller it wouldn’t work until I used a slower baud rate. Not sure if that makes a difference though. It seemed sensitive to flow control configuration.

I need to read up and see how I can get the logging info that I see in previous messages here.

But wouldn’t these commands be after the serial port is established? Because it looks like that’s where the log stops. I’ve tried on a Windows laptop with the same results, except that OH does not crash when the binding is stopped. However, I can consistently get the following NPE by stopping and restarting the binding:

openhab> bundle:stop 9
openhab> bundle:start 9
openhab> Exception in thread "AshFrameHandler" java.lang.NullPointerException
        at com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler$1.run(AshFrameHandler.java:151)

Yeah… I took a chance. At least I have a spare zwave controller!

Exactly - this is what I want to see - what happens after the serial port is opened.

What do you mean? The serial port is opened - we see that in the log. I want to see if commands are sent.

The error indicates an error probably in the low level serial.

In the Karaf console, enter:

log:set DEBUG org.openhab.binding.zigbee
log:set DEBUG com.zsmartsystems.zigbee

or configure your org.ops4j.pax.logging.cfg as in this post:

I’m assuming/guessing that the last log entry received means that there are communication issues with the port, preventing commands from being sent:

2017-07-04 11:59:00.470 [INFO ] [andler.ZigBeeCoordinatorEmberHandler] - Serial port [COM4] is initialized.
2017-07-04 11:59:00.486 [WARN ] [bee.dongle.ember.ash.AshFrameHandler] - Trying to send when not connected.

I edited the zigbee controller and sent the reset. This was the log output:

12:42:42.647 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: Configuration received (Coordinator).
12:42:42.648 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_port.
12:42:42.649 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_channel.
12:42:42.649 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_initialise.
12:42:42.650 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_panid.
12:42:42.650 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_extendedpanid.
12:42:42.650 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_networkkey.
12:42:42.654 [INFO ] [smarthome.event.ThingUpdatedEvent   ] - Thing 'zigbee:coordinator_ember:5e8eb4cd' has been updated.

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 :disappointed:.

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?

//Mattias

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 :confused:.