Zigbee binding

AFromD · July 31, 2018, 8:26am

Thanks for the hints. Putting the 1.0.13 version in the addons and then stopping the 1.0.11 seems to work. I am on the 2.3 release version, the nightly gave me problems so I rolled back for now.

Back in January, you reported on this thread you were working on the Tradfri motion sensor. According to the read.me, it was tested with the binding. I am now trying to get mine to work. It shows as “online”, shows channels for battery voltage, percent and a switch for motion. However, none of these channels show a value. Before I dive into the logging, is there anything else I can try?

Edit: it is being very flaky; After numerous tries of removing and readding, it mostly ends up as Offline-has not completed discovery or Offline-not found on network. Right now, I managed to get it online again, and it is even showing battery level (37%?). However, there is only a switch channel which does nothing and not a motion channel, so I don’t get motion sensing.

It is lying right next to the Ember module.

curlyel · July 31, 2018, 11:01am

Hi @gundark2,
your issue sounds quite similiar to some odd behaviour I’ve seen with Zigbee vs. Bluetooth binding. If I start both bindings in the right order (in my case: first Zigbee, let it open it’s serial port and then the Bluetooth binding to open it’s serial port(s)) both are working otherwise the Zigbee is failing here.

See full post:

So - If I start just one of two bindings using serial ports at the time (or both in the right order as described above), all is fine. So we can exclude the common serial port permission issues - right?

Could you check the same on your side? So, just start zigbee, verify it’s working and then stop zigbee and start just zwave to check if your udev rules and permissions are correct.

@vkolotov suspected the nrjavaserial port discovery probably causing the issue:

@chris: could you provide a version of the binding which requires excplicite serial port setting (as in pre 2.3 versions of the binding) without depending on the serial port discovery just to rule out this possible cause?
Or does it make no sense at all?

chris · July 31, 2018, 11:07am

The current binding should work fine with explicit port settings…

But…

Unfortunately, this is not so easy to remove. I do wonder if it’s possible to simply uninstall (or stop) the bundle that performs the USB discovery. I think it’s probably registered as a service, and this service is only installed on Linux computers. It should therefore be possible to stop this, and it should kill off this function.

Get a list of all the running bundles and grep for “usb” to see what shows up.

curlyel · July 31, 2018, 11:51am

Are you referring to the

210 │ Active   │  80 │ 2.3.0                  │ ZigBee Binding

or some snapshot version? The above version just let me select some serial port from the drop-down list in the paperUI. If the port is not listed there, I’m not able to manually enter it.

Indeed: If I stop the two bundles related to USB serial port discovery:

openhab> bundle:list | grep USB
205 │ Resolved │  80 │ 0.10.0.oh230           │ Eclipse SmartHome Configuration USB-Serial Discovery
206 │ Resolved │  80 │ 0.10.0.oh230           │ Eclipse SmartHome Configuration USB-Serial Discovery Linux sysf Scan
openhab>

… then both (Zigbee and Bluetooth) are starting together without the need of manually start one after the other.

But: The drop-down list in the coordinator’s configuration is still not showing the Zigbee serial port and I can not manually add it …

Kim_Andersen · July 31, 2018, 11:59am

I don´t know if it´s useable in your case. But here is something about how to set up Raspbian (Rpi) at least if you use a shield. I suspect it´s something simular with a USB dongle.

https://elelabs.com/downloads/EZBPIS_UG_4_OpenHab.pdf

chris · July 31, 2018, 12:21pm

What happens if you uninstall the second one? I expect that on Windows, and Mac etc (ie not Linux) where there is no USB detection, that this is just absent. I expect that removing this should revert the binding to work without the USB detection (I might be wrong though).

I’m a bit surprised that you can’t add your own text and you can only select what is available. That said, this is not even related to this USB detection - the USB detection checks to see if a port might be a coordinator, but the list of available ports actually comes from somewhere else completely (but I don’t know exactly where).

curlyel · July 31, 2018, 12:24pm

Thanks @Kim_Andersen!

Probably not
The system I’m dealing with currently is a VM inside a ESXi running stock Debian none RPi.

Kim_Andersen · July 31, 2018, 12:39pm

Okay, was just wondering if you could use some of the trouble shooting mentioned in the doc.

curlyel · July 31, 2018, 12:48pm

Sure. I do really aprecciate any help offered

I’ve had a quick read through the doc and the serial port troubleshooting chapter is quite helpful for any openHAB user having serial port issues (permissions, Java settings etc.). The issue we’re looking here seems not be related to the quite common serial port permission issues on Linux…

So again: Many thanks for the heads-up!

curlyel · July 31, 2018, 1:05pm

If I just stop the second bundle:

openhab> bundle:list | grep USB
205 │ Waiting  │  80 │ 0.10.0.oh230           │ Eclipse SmartHome Configuration USB-Serial Discovery
206 │ Resolved │  80 │ 0.10.0.oh230           │ Eclipse SmartHome Configuration USB-Serial Discovery Linux sysf Scan
openhab>

… then the Zigbee binding again is not able opening the coordinators serial port:

2018-07-31 14:39:48.791 [ERROR] [ding.zigbee.handler.ZigBeeSerialPort] - Serial Error: Port /dev/ttyUSB99 does not exist.
2018-07-31 14:39:48.791 [ERROR] [.cc2531.network.ZigBeeNetworkManager] - Failed to open the dongle.

When both USB bundles are stopped:

openhab> bundle:list | grep USB
205 │ Resolved │  80 │ 0.10.0.oh230           │ Eclipse SmartHome Configuration USB-Serial Discovery
206 │ Resolved │  80 │ 0.10.0.oh230           │ Eclipse SmartHome Configuration USB-Serial Discovery Linux sysf Scan
openhab>

… then Zigbee (and the Bluetooth) dongles can be opened:

2018-07-31 14:50:26.137 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:xxxxxx' changed from UNKNOWN to ONLINE

If this will not break something else, I would leave it that way for the time being.

Sure: I’d love to see how to manually set zigbee serial port without fiddling. But honestly - I can really live with it as it is now

Thanks again @chris for all your work and assistance!

chris · July 31, 2018, 1:24pm

@Kim_Andersen can you tell me what firmware version your device is running please? You should see this in PaperUI.

Kim_Andersen · July 31, 2018, 1:54pm

Nope, firmware is not visible in either PaperUI or Habmin.

These are the settings and info available:

5iver · July 31, 2018, 2:43pm

Do you see the firmware if you back up a step? Or under Attributes in Habmin?

Kim_Andersen · July 31, 2018, 3:03pm

Nope, neither:

I´m using Elelabs Rpi Shield, and zigbee binding 2.3.0 stable.

AFromD · July 31, 2018, 5:30pm

I tried to install another Tradfri motion sensor, and exactly the same problem. I had openhab on zigbee discovery when I inserted the batteries, and it showed up straight away. But again no channel for occupancy. Log a bug on Github?

chris · July 31, 2018, 5:49pm

I’m not sure why it’s not showing the properties. Can you enable debug logging and restart the binding - it will be one of the first packets that is sent when the binding starts (note you need to enable debug logging on com.zsmartsystems.zigbee).

I’m assuming it’s 6.x, but I’d like to know exactly if possible.

chris · July 31, 2018, 5:51pm

I think at the moment that it’s not supported (but you already know that now ). The Tradfri works totally differently than other devices - it’s not sending motion alerts, but instead it’s configured as a remote (effectively the same as a light switch). I’ve not worked out how to configure reporting for these devices - if you can work it out, it would be useful .

AFromD · July 31, 2018, 8:18pm

OK, that’s another three motion sensors sacrificed in the name of science (I already had Smartthings sensors which wouldn’t pair). I think I’ll stick to Hue then, at least I’ve got one of those working reliably.

In the described setup process, you have to pair them by pushing the button for 10 seconds. I guess it sets up a static link there. So if you can implement that feature request I have put on Github, I can do the testing whether it helps

Kim_Andersen · July 31, 2018, 8:57pm

I know how to enable debug logging. But how to restart the binding?

Kim_Andersen · July 31, 2018, 10:41pm

@chrisI just enabled debug log, and restarted OpenHab (rebooted my Rpi).
Is this info usefull, (it doesn´t look usefull to me)?

This is from the very first start of debugging. Tell me if you need more:

2018-08-01 00:29:47.320 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP dongle initialize with protocol ASH2.
2018-08-01 00:29:47.497 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameRst []
2018-08-01 00:29:47.503 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - AshFrameHandler thread started
2018-08-01 00:29:47.717 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue: 1
2018-08-01 00:29:48.650 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameRstAck [version=2, resetCode=11, Reset: Software]
2018-08-01 00:29:48.654 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Connected
2018-08-01 00:29:48.723 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspVersionRequest [desiredProtocolVersion=4]
2018-08-01 00:29:48.727 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=0, ackNum=0, reTx=false, data=01 00 00 04]
2018-08-01 00:29:48.919 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=0, ackNum=1, reTx=false, data=01 80 00 06 02 00 60]
2018-08-01 00:29:48.922 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=0, ackNum=0, reTx=false, data=01 00 00 04]
2018-08-01 00:29:48.970 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspVersionResponse [protocolVersion=6, stackType=2, stackVersion=6000]
2018-08-01 00:29:49.076 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=1, notRdy=false]
2018-08-01 00:29:49.079 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspVersionResponse [protocolVersion=6, stackType=2, stackVersion=6000]
2018-08-01 00:29:49.157 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EzspVersionResponse [protocolVersion=6, stackType=2, stackVersion=6000]
2018-08-01 00:29:49.159 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue: 1
2018-08-01 00:29:49.161 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspVersionRequest [desiredProtocolVersion=6]
2018-08-01 00:29:49.166 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=1, ackNum=1, reTx=false, data=02 00 FF 00 00 06]
2018-08-01 00:29:49.413 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=1, ackNum=2, reTx=false, data=02 80 FF 00 00 06 02 00 60]
2018-08-01 00:29:49.416 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=1, ackNum=1, reTx=false, data=02 00 FF 00 00 06]
2018-08-01 00:29:49.417 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspVersionResponse [protocolVersion=6, stackType=2, stackVersion=6000]
2018-08-01 00:29:49.420 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspVersionResponse [protocolVersion=6, stackType=2, stackVersion=6000]
2018-08-01 00:29:49.423 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EzspVersionResponse [protocolVersion=6, stackType=2, stackVersion=6000]
2018-08-01 00:29:49.427 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=2, notRdy=false]
2018-08-01 00:29:49.431 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue: 1
2018-08-01 00:29:49.436 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspGetConfigurationValueRequest [configId=EZSP_CONFIG_ADDRESS_TABLE_SIZE]
2018-08-01 00:29:49.439 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=2, ackNum=2, reTx=false, data=03 00 FF 00 52 05]
2018-08-01 00:29:49.585 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=2, ackNum=3, reTx=false, data=03 80 FF 00 52 00 08 00]
2018-08-01 00:29:49.587 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=2, ackNum=2, reTx=false, data=03 00 FF 00 52 05]
2018-08-01 00:29:49.651 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspGetConfigurationValueResponse [status=EZSP_SUCCESS, value=8]
2018-08-01 00:29:49.672 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=3, notRdy=false]
2018-08-01 00:29:49.672 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspGetConfigurationValueResponse [status=EZSP_SUCCESS, value=8]
2018-08-01 00:29:49.674 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue: 1
2018-08-01 00:29:49.694 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspGetConfigurationValueRequest [configId=EZSP_CONFIG_STACK_PROFILE]
2018-08-01 00:29:49.696 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=3, ackNum=3, reTx=false, data=04 00 FF 00 52 0C]
2018-08-01 00:29:49.804 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=3, ackNum=4, reTx=false, data=04 80 FF 00 52 00 00 00]
2018-08-01 00:29:49.806 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=3, ackNum=3, reTx=false, data=04 00 FF 00 52 0C]
2018-08-01 00:29:49.807 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspGetConfigurationValueResponse [status=EZSP_SUCCESS, value=0]
2018-08-01 00:29:49.809 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspGetConfigurationValueResponse [status=EZSP_SUCCESS, value=0]
2018-08-01 00:29:49.811 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=4, notRdy=false]