Zigbee binding

[AFromD (Arno)]

This binding is made specifically for USB sticks which communicate via a COM port. So unless the Qivicon Homebase offers a COM port to communicate through, I don’t think this is the right binding for what you are looking for. I am not familiar with the Homebase, but it seems to me, that it would require a dedicated binding to integrate into Openhab.

As I understand it, Qivicon is a similar product to Openhab, so I don’t think there will be a binding soon. Just because with OH, theoretically, you wouldn’t need Qivicon.

So right now, if you want to control zigbee devices in OH, there are two routes; Either use a hub-type device from the manufacturer of the product, they mostly have dedicated bindings available. Or use a USB stick, and use this generic zigbee binding to control all devices. This binding is still a work in progress though, so it might or might not work for your specific devices. If you only use one brand of zigbee devices, I would use a hub device instead of this binding. For mixing multiple brands, this Zigbee binding might be the most suited though.

[chris (Chris Jackson)]

Sorry - I will try and look at this when I get a chance. It will be possible to use this with QHB, but I’ve not yet tried to integrate it with any of the QHB devices. If I can find some time I will test it.

[curlyel]

Hi Chris,
just trying a HUE motion sensor to discover. I’m on version 2.2.0 currently with CC2531 coordinator.
Unfortunately I can not discover the sensor.

The log is neither showing something related to some new zigbee device nor obvious error messages (while having debug for the zigbee bundles enabled of course).

I’ve tried resetting the sensor (very long press on the “setup” button til is lit green) several times, batteries out/in, short press to pair in very short distance to the dongle… nothing helped so far.

Is there something special required to discover the sensor? Should the 2.2.0 release being able to find it or have I to move to 2.3-snapshot?

Thanks in advance

[chris (Chris Jackson)]

The 2.2 release will not work with motion sensors - you need a much newer snapshot to get motion sensors of any type.

Cheers
Chris

[curlyel]

Thanks a lot Chris for the quick reply

Is just dropping a 2.3-jar of the binding into the addons-folder and uninstall the 2.2. binding via PaperUI sufficient (without bumping the whole setup to the snapshot version)?

If so - where to download a recent *.jar of the zigbee binding?

[chris (Chris Jackson)]

You should be able to install just a recent JAR, but you might need to manage the serial dependancy with the following karaf command.

feature:install openhab-transport-serial

The latest jar should be found on cloudbees.

I actually have a feeling this still may not work if there is nothing showing in the log at all…

[curlyel]

Just to confirm: On version 2.3.0.201801190819 I got the HUE motion sensor working.
Thanks again for your help!

[chris (Chris Jackson)]

Cool - thanks for the feedback… I think things are slowly improving with the binding

[Ralph69 (Ralph Backes)]

Hi @chris,
great, thanks a lot. I’m looking forward to your results.
Ralph

[Ralph69 (Ralph Backes)]

Ok, thanks Arno, looking forward if Chris can add some support…

Regarding the Qivicon, I don’t think it’s a similar product, even if it follows a similar idea. Like openHAB it shall combine devices from different vendors or systems but it uses a different strategy. So Qivicon for me is another smart home hardware hub which controls devices from multiple vendors (homematic, bitron, logitech, …).

As far as I understand openHAB is a complete software based approach and follows the strategy, to connect to specific hardware hubs (ccu2, logitech, whatever). So binding qivicon would be a huge benefit for both. OH can integrate with one concentrator different vendors…

[chris (Chris Jackson)]

@Ralph69

Regarding the Qivicon, I don’t think it’s a similar product, even if it follows a similar idea

Qivicon software is fundamentally the same system as openHAB - they are both running ESH under the hood (at least for the newer products - older products used a different system). This is why it is possible to use the ZigBee Binding on the QHB - I’m not sure if it is possible out of the box due to the PID issues, but I will see if I can find some time to test this as I have a few different QHBs here sitting in boxes…

[Ralph69 (Ralph Backes)]

@chris

Qivicon software is fundamentally the same system as openHAB

I’m aware of that. My point focusses on the hardware strategy they differ (or better which is bundled on qivicon side). And is the common ESH base a reason not to integrate qivicon2 as hardware hub to OH?

[chris (Chris Jackson)]

@Ralph69

And is the common ESH base a reason not to integrate qivicon2 as hardware hub to OH?

No - I didn’t say it was did I? The bindings here should run on QHB as I said. I was merely commenting on your point that openHAB and Qivicon are not similar products when clearly they are running very similar server software.

[Ralph69 (Ralph Backes)]

Ok, just missunderstanding You never said so, I’m just trying to understand why a binding for qivicon seems to make less sense to others than to me

[chris (Chris Jackson)]

@Ralph69

I’m just trying to understand why a binding for qivicon seems to make less sense to others than to me

I don’t think anyone said it was a good, bad, or other, idea to have a binding to connect to a Qivicon system…

However, personally I don’t see the need given it’s a very similar system - it’s like saying “let’s have a binding for openHAB”. Effectively you would have two instances of ESH running which can be easily connected together with MQTT if that’s what you wanted to do.

[curlyel]

Hi Chris,
after playing a bit with the HUE motion sensor some wishes regarding the LED indicator and the battery level have arisen

LED indicator
When paired to a HUE bridge, the LED on the sensor is configured to just blink in case of battery is low or empty (orange==low, red==almost empty, steady red==no connection to coordinator).

When connected to the Zigbee binding, the LED flashes every time when motion is detected.
This is somehow distracting/annoying.

It seems, that Philips has some attribute in the basic cluster

0x0000/0x0033* config.ledindication

which likely is intended to set the “LED mode”.

Battery level
Currently, there is no battery level channel. From some post in another forum:
https://developers.meethue.com/content/philips-hue-motion-sensor-and-zigbee-attributes

I got, that Philips has implemented the power cluster, so probably reading the

u8BatteryPercentageRemaining

could be possible to fill a battery channel.

Here is the list somebody has sniffed from the communication of the sensor with the HUE bridge:

From your sniffer, you should see that the Hue bridge sets up bindings to the bridge for the following clusters on endpoint 02:

- 0x0000 (Basic)

- 0x0001 (Power)

- 0x0400 (Illuminance Measurement)

- 0x0402 (Temperature Measurement)

- 0x0406 (Occupancy Sensing)

Then, it sets up attribute reporting for the following attributes:

- 0x0000/0x0032* config.usertest

- 0x0000/0x0033* config.ledindication

- 0x0001/0x0021 config.battery

- 0x0400/0x0000 state.lightlevel

- 0x0402/0x0000 state.temperature

- 0x0406/0x0000 state.presence

- 0x0406/0x0030* config.sensitivity

*) these are manufacturer specific attributes.

So would it be possible to make the LED configurable, or switch it off completely, or initialize it just similar to Philips (just blink if battery is weak)?

Is a battery channel possible (useful for all battery powered nodes)?

[chris (Chris Jackson)]

@curlyel

So would it be possible to make the LED configurable

Since this is a custom attribute, there’s no nice way to do this right now. One of the things I will be working on over the next month or two is to add device definitions into the binding so we can define custom functionality like this. This is something that is currently on my todo list, but it will be a month or so away. Hopefully you can live with it till then (or find a piece of sticky tape to cover it over ).

@curlyel

Currently, there is no battery level channel.

The battery level channel is implemented already in the binding, but if I remember correctly, this attribute is not implemented in the Hue (but it was a while ago when I implemented this so I might be wrong - either way, it didn’t provide the information when I checked it in early December when this was implemented).

I’m currently working on the Tradfri motion sensor which does implement this attribute so I will double check it works there and then have another look at the Hue implementation. I’ll do this in the next day or so.

[curlyel]

@chris

Hopefully you can live with it till then (or find a piece of sticky tape to cover it over ).

Sure

@chris

I’m currently working on the Tradfri motion sensor which does implement this attribute so I will double check it works there and then have another look at the Hue implementation. I’ll do this in the next day or so.

As always - you’re already on it
Thanks a lot for all your dedication!

[chris (Chris Jackson)]

@curlyel

As always - you’re already on it

Actually, can you raise an issue for the LED parameter and either reference your post above, or (preferably) paste the info into the issue - then I won’t forget this when I implement the device definitions, and I’ll easily be able to find the info

[curlyel]

Done: https://github.com/openhab/org.openhab.binding.zigbee/issues/100