Zigbee binding

[joshk]

Are Zigbee green power devices supported? Specifically is there support for the Hue Tap?

[chris (Chris Jackson)]

No - not at the moment.

[joshk]

Do you know if adding support for it is a matter of adding code to the
binding or whether it’s lower down in stack (ex. Zigbee firmware layer)?

I’m not (yet) familiar with openHAB development but I’m pretty comfortable
with Java, so if it’s at the binding later I’d be interested in attempting
to add support.

[chris (Chris Jackson)]

It definitely requires specific versions of firmware, but at least some versions do support this. The latest Silabs firmware supports GP proxy (5.8 or 5.9 has it) and I think the very latest TI firmware also supports it.

I bought a Hue Tap a while back with a view to adding this, but I’m suspicious that it’s not working (since my professional protocol sniffer doesn’t see it, and it should).

If you want to look at adding support for GP, then you should in the first instance look at adding support to the framework.

[joshk]

Thanks! I have the TI CC2531 and the debugger so I can flash different firmware on. My Hue Taps are definitely functional (currently talking to a Hue bridge). If you know specifically which firmware I need to flash that’d be really appreciated - in the past I’ve found hunting down TI firmware to be a real pain.

[chris (Chris Jackson)]

I don’t know the specifics of TI - I normally develop with Silabs, but I did see an announcement that their latest stack for ZB3 included GP, but I don’t have a pointer. I guess if you just go to their ZStack homepage you should be able to download the link.

One issue though is normally TI provide their stuff in a Windows installer package - not so nice if you don’t use Windoze.

[mickelluiten]

Hi Chris,

As told before i have some Xiaomi temperature devices, but they don’t work with the zigbee binding and the TI CC2531 USB.
Today after ordering it , my Xiaomi Gateway 2 arrives and with the Xiaomi binding de temperature sensor works great as expected.
I have also a cc2531 debug USB stick.
If i start a debug with the USB device and log all action when i learn the temperature sensor on the xiaomi gateway and aslo the normal operation can you take a look at it?
Maybe you can see what the problem with the zigbee binding?

It would be great if also the Xiaomi Devices will work with te binding,

Let me know, thanks in advance.
Mickel

[chris (Chris Jackson)]

I do have some Xiaomi devices here and will take a look at these when I get a chance. It’s worth noting though that the Xiaomi devices are not Zigbee compliant - they use Zigbee like communications, and 802.15.4, but that doesn’t make them compliant. I’ve seen other notes on the net that they don’t work with other Zigbee gateways such as SmartThings.

That’s not to say it’s not possible, and I do intend to see if it’s possible to make it work, but please be aware it may not be possible if the Xiaomi sensors don’t fully implement Zigbee protocols.

I’m not sure that logging USB traffic will help too much though - I’d probably need to see a sniffer log.

[5iver (Scott Rushworth)]

When changing the coordinator’s (Ember) channel in both Habmin and PaperUI, I get the following errors. Also, what is the purpose of the Reset Controller field?

2017-07-31 05:40:54.170 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Configuration received (Coordinator).
2017-07-31 05:40:54.171 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_port.
2017-07-31 05:40:54.172 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_channel.
2017-07-31 05:40:54.173 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_initialise.
2017-07-31 05:40:54.174 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_panid.
2017-07-31 05:40:54.174 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_macaddress.
2017-07-31 05:40:54.175 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_extendedpanid.
2017-07-31 05:40:54.176 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_networkkey.

[chris (Chris Jackson)]

@5iver

When changing the coordinator’s (Ember) channel in both Habmin and PaperUI, I get the following errors.

Configuration isn’t handled at that point - it only gets handled when the handler restarts. I’ll remove the log entry - but it won’t change anything.

@5iver

Also, what is the purpose of the Reset Controller field?

It will reinitialise the coordinator - this makes changes to the coordinator configuration such as the PAN Id, EPAN Id, channel, etc. Otherwise the startup will just use the existing parameters.

[5iver (Scott Rushworth)]

Correction… when I make changes in PaperUI, I get the errors above. When I do it in Habmin, I get the following whether I set Reset Controller to true or not

2017-08-01 04:03:14.596 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Configuration received (Coordinator).
2017-08-01 04:03:14.596 [ZigBeeCoordinatorHandler  ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_channel.

@chris

It will reinitialise the coordinator - this makes changes to the coordinator configuration such as the PAN Id, EPAN Id, channel, etc. Otherwise the startup will just use the existing parameters.

I’m not sure I have this yet. If Reset Controller is false, will changes to the coordinator be saved and applied after the next startup… and if it is true, then the coordinator will restart immediately and apply the changes?

[chris (Chris Jackson)]

@5iver

Correction… when I make changes in PaperUI, I get the errors above. When I do it in Habmin, I get the following

That’s just because PaperUI always updates every parameter, and HABmin only sends updates to parameters that have changed. This is one reason I don’t suggest to use PaperUI for this on ZWave - you can easily end up with 50 to 100 configuration updates being sent to the device when you change the device name (ie nothing actually changed, but now you have a LOT of configuration to send).

@5iver

If Reset Controller is false, will changes to the coordinator be saved and applied after the next startup… and if it is true, then the coordinator will restart immediately and apply the changes?

The configuration is only applied at the startup of the thing handler. What I can’t remember is if I restart the thing handler at this point in which case it would be immediate. It should restart immediately - I just have a feeling it might not…

[5iver (Scott Rushworth)]

@Tetragramm

Are there any steps I might not have done, or information that would help figure out why it’s not working?

If you can see the ports in the system but OH can’t, then my guess would be permissions. This may help:

Serial Error: Port /dev/ttyACM0 does not exist

Had the same issue. You need to add also group ‘tty’ to your openhab user. I added both, dialout and tty to all my Raspberry-Pi users (pi, root, openhab) and then the problem suddenly vanished. Quite annoying that the error message does not really point to the right direction. See. e.g.

[5iver (Scott Rushworth)]

@chris

That’s just because PaperUI always updates every parameter, and HABmin only sends updates to parameters that have changed.

That is a very handy thing to know, thank you!

When Reset Controller was false, none of the configuration changes were being saved in Habmin or PaperUI. When Reset Controller was true, PaperUI did not save the changes and did not restart the controller (or thing handler). Habmin did try to restart it, but then the binding was stuck in a loop of errors. I’m packing up the logs for you. Looks like the same errors I was seeing when restarting the binding. After I restarted OH, the changes to the settings I’d made were not applied. So, configuration changes did not save when Reset Controller was true or false.

I don’t think Reset is the best word to use here. And it’s a little scary too. Maybe changing Reset to Restart would work better?

[chris (Chris Jackson)]

@5iver

PaperUI did not save the changes

Strange - I don’t know why there would be any difference, and I can’t see any way that the configuration won’t be saved. The method in the binding is very short and unless there’s an exception thrown, there’s no exit point that doesn’t save the configuration.

@5iver

I don’t think Reset is the best word to use here. And it’s a little scary too.

Well, it resets the controller if you change the parameters. It’s likely that it will scrub the network and all associations (it might depend slightly on the stick used - TI I’m sure will completely reset - Ember might save some configuration).

It is scary stuff - avoid doing it . If there’s some configuration that needs to change outside of this then we could look at it - channel might be a valid need, but anything else WILL need to reset the stick as you can’t change the PAN ids, mac address etc on a running network.

[5iver (Scott Rushworth)]

@chris

Strange - I don’t know why there would be any difference

Neither PaperUI nor Habmin is saving the changes for me, so there’s no difference. I’ve tried now many times, but with no success. The binding only seemed to try to restart (but crashed) the one time (I opened a ticket and sent you the log).

@chris

channel might be a valid need

The only setting I’m trying to change is the channel . The EZSP_ENERGY_SCAN in the log shows a better channel than what I’ve selected, so I thought I’d try it to see if my bulbs would stop dropping.

[chris (Chris Jackson)]

@5iver

Neither PaperUI nor Habmin is saving the changes for me

I expect the configuration is being saved - I can’t really see how it can’t be saved assuming it’s getting into the binding. However, when the binding starts it reads the configuration from the stick, and updates it so that the configuration you see in the UI is consistent with the stick configuration.

[Tetragramm (JH)]

Excellent. That worked, but now I can’t get anything to join.

I’m using the Paper UI, and when I set the “Enable Joining” toggle and save, it just comes back as zigbee_permitjoining=false. And it’s not just the UI, the lightbulbs won’t join.

18:47:58.807 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_port.
18:47:58.813 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_channel.
18:47:58.829 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_initialise.
18:47:58.834 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_panid.
18:47:58.849 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_macaddress.
18:47:58.870 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_extendedpanid.
18:47:58.880 [WARN ] [bee.handler.ZigBeeCoordinatorHandler] - 000D6F000B1311ED: Unhandled configuration parameter zigbee_networkkey.
18:47:59.026 [INFO ] [smarthome.event.ThingUpdatedEvent   ] - Thing 'zigbee:coordinator_ember:40ee21c9' has been updated.

I don’t suppose this is related to the latest posts?

[5iver (Scott Rushworth)]

PaperUI should work for discovery, but I think Habmin is better organized for it. Try starting discovery for the Zigbee binding from Habmin…

Or the big blue button in Paper UI…

[Tetragramm (JH)]

Ah, there is apparently a blink pattern not mentioned in the bulb manual that does not mean ready to join.

Thank you for all your help.