ZigBee Binding

[cdjackson]

I have an initial ZigBee binding running.
Currently controlling Hue lights, but will also shortly add other devices.

[kaikreuzer]

Wow - can you already disclose some details? Are you using some library? What ZigBee dongles are supported?

[cdjackson]

I'm using a lib called zigbee4java. It's a 'port' of the ZB4O library - it's easier to manage than ZB4O and is on Git rather than (I think) a private server.
https://github.com/tlaukkan/zigbee4java

Currently it only supports a TI Dongle (USB evaluation board) which is the same as ZB4O but I want to split this section out and am discussing this with the library maintainer.

Hue lamps are now working very nicely - auto discovery and control of on/off, brightness and color. I need to add color temperature yet. I don't intend to separate out all the different bulbs, although during the discovery process I do read the manufacturer and model.

My next goal is to get my temperature sensors working, but they are less compliant it seems to some of the subscription services, and being battery devices, they sleep (which has the same, or worse, consequences as ZWave battery devices).

[kaikreuzer]

I'm using a lib called zigbee4java. It's a 'port' of the ZB4O library

Interesting to use a fork that strips out OSGi to then package it in an OSGi application afterwards ;-) But I see the point, there is no need to have devices as OSGi services, so for embedding in openHAB, a pure Java version is easier to embed.

Hue lamps are now working very nicely

This now leads to the first architectural problem with the Thing concept: It is the same device as for the hue binding, so it would actually be nice to use the existing thing type definition. But there is no easy way to say that this thing type can be used through either a hue bridge or through a zigbee stack... I will have to think about this - if you have any good solution, please let me know!

[presslab-us]

Awesome, thanks a lot!

I gave this a shot last night and I was able to get my GE Link bulb working, but my Cree Connected wouldn't work. I loaded it up in the ZB4OSGI tester and I see the Cree bulb come up ZLL profile and not HA so it's not properly detected with either library I assume. ZLL is kinda weird as a ZLL device should be usable on any HA network but I think zigbee4java isn't responding with the HA profile so the Cree thinks it's a ZLL network.

I have a handful of other ZigBee HA devices I'd be happy to add support for.

[cdjackson]

Thanks fir the feedback - I'd certainly welcome any updates to devices (things) as well as the zigbee lib itself... I am working with the maintainer of the lib to fix a frw bugs so I do anticipate some updates but im not sure it will fix the issues you report.

The lib should respond to HA cluster as thats what im using for some temperature sensors. However im still reasonably new to the zigbee world having spent a loy of time with zwave so im still learning the system.

Anyway, any updates are welcome  - my current focus is on getting my temperature and humidity sensors running and solving some of the issues with battery devices...

Cheer 
Chris 

Sent from Samsung Mobile

-------- Original message --------

From: presslab-us notifications@github.com

Date:24/02/2015 15:20 (GMT+00:00)

To: openhab/openhab2 openhab2@noreply.github.com

Cc: Chris Jackson chris@cd-jackson.com

Subject: Re: [openhab2] ZigBee Binding (#142)

Awesome, thanks a lot!

I gave this a shot last night and I was able to get my GE Link bulb working, but my Cree Connected wouldn't work. I loaded it up in the ZB4OSGI tester and I see the Cree bulb come up ZLL profile and not HA so it's not properly detected with either library I assume. ZLL is kinda weird as a ZLL device should be usable on any HA network but I think zigbee4java isn't responding with the HA profile so the Cree thinks it's a ZLL network.

I have a handful of other ZigBee HA devices I'd be happy to add support for.

—
Reply to this email directly or view it on GitHub.

[presslab-us]

After resetting the Cree bulbs they come up as a HA device ID now, 0x100 which is "OnOff Light". I think from new they are "set up" for a Wink hub. However they do have the dimming cluster (and ability), which seems like 0x100 is a bug with these new lights, sigh... The GE Link come up as 0x101 "Dimmable Light" which is correct. Maybe the best way forward is to lump these IDs into one type and then look at what clusters are supported to determine if it's dimmable.

Maybe a "Supported devices" wiki or Gdocs could be made somewhere? I've got working so far a Dresden color strip, a Centralite pluggable dimmer, GE Link bulb, and Cree Connected bulb. Next up is the thermostat. I will do a pull request when I get a few things together.

Thanks,
Ryan

[cdjackson]

Great stuff Ryan. The Dresden strip converters are something I was going to get myself, so I’m pleased to hear they work :)

I suggest for the minute we stick the information in this issue - I can probably append it to the first message to build a list of devices? Until OH2 gets a bit more stable, then we can add the docs into the binding which I think is the ultimate goal…

Anyway, I do agree that the way I named the ‘things’ of using the device type doesn’t work. I’d already found this with the temperature sensors I’ve got…. I’ve just pushed an update that is hopefully a better solution - it uses a list of clusters, and to find the ThingUID it searches through the list looking for the best batch. So, to add a new thing, you can just provide the thing name, and the list of clusters the device supports, and the system ought to sort it out… I think this ought to work fine - I don’t think we should get more than one best match if we configure the clusters/things appropriately, but we’ll see :)

Cheers
Chris

[presslab-us]

I checked out your update, seems like the best way forward.

There is one issue with this that I can see though. I've got the subscriptions working but if the zigbee4java device is an "OnOffLightDevice" it cannot subscribe to the "changedCurrentLevel" callback. So either this needs to be fudged in zigbee4java (not ideal) or I think there is a different way to subscribe, I'll look into it...

I'll work on getting my additions committed/pull request. Or I can just give you a diff and you can clean it up/change it as you like and commit it.

Thanks,
Ryan

[cdjackson]

Hi Ryan,
If you just want to push your changes to Github, I can merge them into my repo and push them back - there’s no need for a PR so long as I know your repository address - I can just pull directly…

I’ve not got subscriptions working on my devices - my thermostats don’t respond to them when they are asleep, and the hue comes back with a ‘queue full’ error (is that what you’re seeing when trying to subscribe?), so I’m nt sure what’s up here. I’ve been discussing stuff with the maintainer of the library and we’re going to make some changes to some of this, but again, any thoughts or changes are welcome…

Chris

[kaikreuzer]

I suggest for the minute we stick the information in this issue - I can probably append it to the first message to build a list of devices? Until OH2 gets a bit more stable, then we can add the docs into the binding which I think is the ultimate goal…

Actually, the idea behind the thing types is to be the database of the supported devices. So instead of "DimmableLight", there should be a "GE Bulb", a "CREE bulb" etc. For "generic" devices that we might not know yet, but which should nonetheless be supported, a "DimmableLight" type could still be kept - or maybe it would be just an "unknown Zigbee device" type, which does not list any channels in the xml, but simply gets its channels when being added by the handler.
From these XMLs, we could then in future generate documentation about supported devices. And what's more, we can show the devices (maybe even with pictures in future) within the UI, incl. description texts, which might contain some specific information about them.

Would you agree that this approach makes sense or is there any reason against going down this path?

[cdjackson]

Ok, I hadn’t realised this was the idea - sorry. I do agree that it makes some sense, but I also fear this can become a maintenance nightmare and we’ll end up trying to support a ‘database’ of devices with very diverse features/requirements in the XML files… If you went down this route, can bindings add their own information into the XML files for device specific stuff? Currently I think xstream will throw an exception if there’s data in the XML that it doesn’t know about (unless you’ve managed to find some way to stop this?)… If so, it might be nice as in zwave I could merge the database with this, but the zwave database has a lot of stuff in it (not just simple names etc) so there would need to be freedom to add ‘anything’ the binding needed (somewhere), and then to be able to get it out again (somehow).

Maybe we’re getting off the topic of the zigbee binding. For now, I suggest with zigbee we leave the generic devices while the binding is still quite fluid, and once things firm up we can add more specific devices - if you’re ok with that? I’d suggest a separate discussion somewhere about the XML files though if you want to start that (or shall I - this will impact zwave when I start to port that, which I hope will be soon).

[presslab-us]

@kaikreuzer On the one hand I would vote it should be as generic as possible to ensure compatibility with future devices, this seems to be the spirit of ZigBee HA. On the other hand as I already see with my few devices that the Cree is not following standard but I'm not sure how big a problem this is. With specific devices like Nest, etc. it makes sense to have the thing strictly for the device in question. But with ZigBee I would say if possible leave it more generic and I agree with @cdjackson that for now keep it generic and see how things play out as more devices are tested.

[presslab-us]

@cdjackson Re the subscriptions I found a data type bug in zigbee4java that would trigger if the top bit of the address happened to be set. short org.bubblecloud.zigbee.network.packet.af.AF_INCOMING_MSG.getSrcAddr() should return int instead of short. The problem with changedCurrentLevel callback is that the OnOffLightDevice does not have the getLevelControl method to subscribe to this.

[cdjackson]

Thanks - I’ve just modified this to use int instead of short. I’m not sure why was a short - there were then a bunch of utility methods to print as an int, and then ultimately further up the stack it was converted to int anyway,,,

I’ve not merged this change from the library - let me know if you need this quickly, otherwise I’ll wait a couple of days as there are some library changes coming up to split out the USB driver...

[kaikreuzer]

but I also fear this can become a maintenance nightmare and we’ll end up trying to support a ‘database’ of devices

Isn't this what you have done with Z-Wave as well? I think it is nicer to have the database within the binding that just maintaining a long "supported devices list" on the wiki. The nice thing is that if a device needs some special handling, it is easy to provide a special ThingHandler for it to deal with the specialities.

And again: Yes, the idea of the ThingTypes is that they reflect a certain product/model. This is what you will find in most other bindings as well and I think all bindings should follow the same guidelines.

can bindings add their own information into the XML files for device specific stuff?

Do you have a concrete example? I think I see your point: Instead of having to implement specific ThingHandlers, you would still keep a single generic ThingHandler for all devices and have it dynamically adjust its behavior based on specific information in the thing descriptions. This is indeed not possible right now, but definitely worth to follow up upon. I have created https://www.eclipse.org/forums/index.php/m/1638625/#msg_1638625 for this.

On the one hand I would vote it should be as generic as possible to ensure compatibility with future devices

@presslab-us I agree, that's why I also said that it makes sense to keep a generic "DimmableLight" (and similar) thing type as a generic fallback option. Nonetheless, it would already give some valuable information to the user to see whether his device is explicitly supported (by having a dedicated thing type) or if it only falls in the "if it has implemented Zigbee the right way, it should in theory work" category.

[presslab-us]

Do you imagine an addition to the web GUI so that users can see what devices are supported before buying them? What would the motivation be for adding a specific Thing if the generic one works? Only for documentation?

[presslab-us]

@cdjackson What sort of problems are you seeing with battery devices? I am seeing Z_MAC_NO_ACK and timeout errors with my thermostat on battery power when directly reading/writing attributes. Sometimes it works though, and subscribe notifications work fine.

[cdjackson]

Yes - battery devices need more work. I’ve been talking with Tommi about this and we need to look at how messages ae handled (queued) to battery devices, but we’re also going to implement a save and restore feature as my battery devices disappear from the network when it’s restarted. We’ll effectively reload them into the stack on startup…

This areas needs a bit of work...

[cdjackson]

Hey Ryan,
I've just pushed an update. This updates the library to the latest with the separation of the port from the main library and also has the various other fixes (eg short/int fix).

One point to note is that I also changed the thing naming and configuration. Previously I used the IEEE address in the Discovery service, but actually in the thing I was expecting the full endpoint ID - I'd not noticed this bug before as I'd configured my things manually and obviously hadn't checked it when I added the discovery service. So, you might (likely!) find you need to modify (or remove and re-add) your things and update your items accordingly.

Cheers
Chris

[presslab-us]

Hi Chris,
How about something like this for the device naming? It would take up less space in the items file and seems more consistent with the existing naming. String thingId = device.getEndpointId().toLowerCase().replaceAll("[^a-z0-9_/]", "").replaceAll("/", "_");

[cdjackson]

Does that end up concatenating the mac address and then putting _endpoint on the end? If so, it sounds fine (as you say, it’s a little shorter than I have now).

[presslab-us]

Yes, that's right.

I've got your update merged, I'll try to get some things committed to my
repo tonight.
On Mar 1, 2015 11:57 AM, "Chris Jackson" notifications@github.com wrote:

Does that end up concatenating the mac address and then putting _endpoint
on the end? If so, it sounds fine (as you say, it’s a little shorter than I
have now).

—
Reply to this email directly or view it on GitHub
#142 (comment).

[presslab-us]

I pushed some of my changes to the repo here: https://github.com/presslab-us/openhab2/tree/zigbee

[cdjackson]

Thanks - all looks good :)

I’ve merged your changes into my branch so we can hopefully maintain a common source.

[presslab-us]

Great! Thanks.

I was thinking that it might be better to keep the light related methods all in ZigBeeLightHandler and I commited this https://github.com/presslab-us/openhab2/commit/56915899c20f97412a0798d4da9a5c4456a22d0f to show what I mean. What do you think?

[cdjackson]

I'll take a look tonight, but this sounds like a good move to keep the class sizes down and nicely distributed. Thanks.

[kaikreuzer]

Do you imagine an addition to the web GUI so that users can see what devices are supported before buying them? What would the motivation be for adding a specific Thing if the generic one works? Only for documentation?

@presslab-us: I have further contemplated about this and I guess you and @cdjackson are right - a rule such as "a thing type has to be a specific product/model" does not make sense. There are situations, where it is a good match (Z-Wave seems to be such a case), but others where mapping a thing type to a certain device category is the better option. It should be possible to both levels within the same binding as well. So having a "DimmableLight" as a generic type is fine and it can cover every bulb that behaves nicely wrt the specs. If you come across a bulb that you know that needs some special treatment and workarounds, you can define a specific thing type for this product. This also gives the possibility to assign a special thing handler (that might extend the generic thing handler) to it that holds the according specific logic. This could potentially even be added through a separate bundle, so that such a binding could be nicely extensible.
One important feature through would be that the discovery service is extendible, too: If a bundle e.g. brings a specific description and handler for the Cree bulb, it should be able to hook into the discovery to make the discovery result not a DimmableLight thing type, but a Cree bulb thing type. This could possibly be achieved through a similar construct as we have in place for the UPnPDiscoveryService, which also delegates to UPnPDiscoveryParticipants.

Does this make sense to you?

[cdjackson]

Does this make sense to you?

Hi Kai,
This makes sense - basically, the discovery needs to find the most appropriate ‘thing’ definitions - ie. it should look for specific things first, and then if nothing is found, we use the generic definition. Sounds good.

Chris

[cdjackson]

I've now updated the code to include the zigbee library as a jar (mvn) rather than having to copy in the source each time which was a pain (and wrong!) for a bunch of reasons. I've not merged it into my zigbee branch yet, but will do soon -:
https://github.com/cdjackson/openhab2/tree/zigbee-mvn

[cdjackson]

This binding is only available for OH2 - it can't be used on OH1.

Currently I'm in the process of updating this binding although looking in here it doesn't look like I've pushed my latest changes. It needs a significant update to use the latest ESH features to support dynamic instantiation. I will hopefully have time to finish this over the next couple of weeks.

[chennakeshavaSoC]

How complex is it to develop/create a binding for OH1? and What are all the jar files need to be transferred from Zigbee4Java setup to OH1 addons folder?

[cdjackson]

It's not complicated to develop an OH1 binding - it's just very different than OH2. No files are transferred from the Zigbee4java to the addons folder except the binding itself.

[cdjackson]

@kaikreuzer this PR has been updated to work with dynamic channels that are auto-generated from the cluster list. Currently I've just added the on/off, dimmer and color clusters, but I'll continue to add more shortly (I want to get the temperature/humidity clusters added soon to support my devices). I've also given it a bit of a tidy...

It might be good to look at reviewing/merging this as I think the new concept is much better and should work with a wider range of devices.

We're still stuck with the 2531 dongle though...

[cdjackson]

Hmmm - just realised this isn't a PR, but an issue :) I'll close this and create a PR.

[DuncanvR]

For the lazy: the pull request is #779

[IgorTrindadePT]

Hello to all,
I'm trying to connect one custom zigbee device to openhab. I already created the network with TI Dongle cc2531 and I can make my custom device appear in the openhab when I start searching.

But the issue appears when I try to assign my device to an openhab object. Basically it stays always in the initializing state. I dig into the code and found that it never goes throught this condition in ZigBeeThingHandler.java, in the initialize() function:

    if (coordinatorHandler == null) {
         return;
    }

After some debug, I tried to force it to initialize, so I changed the condition to this:

if (coordinatorHandler == null) {
updateStatus(ThingStatus.ONLINE);
}

With this, it sets the coordinatorHandler with the bridge handler.
After this I get this log...

2016-05-09 22:30:38.772 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - 'zigbee:generic_levelcontrol:3b886205:00124b00022edc37' updated: ONLINE
2016-05-09 22:30:38.775 [INFO ] [nt.ThingStatusInfoChangedEvent:43 ] - 'zigbee:generic_levelcontrol:3b886205:00124b00022edc37' changed from INITIALIZING to ONLINE
2016-05-09 22:30:38.787 [DEBUG] [b.z.handler.ZigBeeThingHandler:63 ] - Initializing ZigBee thing handler null.
2016-05-09 22:30:38.787 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:108 ] - null: Serializing from file userdata/zigbee/null.xml
2016-05-09 22:30:38.787 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:111 ] - null: Error serializing from file: file does not exist.
2016-05-09 22:30:38.788 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:304 ] - Error finding ZigBee device with address null/1
2016-05-09 22:30:38.788 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:304 ] - Error finding ZigBee device with address null/1
2016-05-09 22:30:38.788 [ERROR] [.b.z.converter.ZigBeeConverter:35 ] - Error opening device on/off controls null/1
2016-05-09 22:30:38.789 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:304 ] - Error finding ZigBee device with address null/1
2016-05-09 22:30:38.789 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:304 ] - Error finding ZigBee device with address null/1
2016-05-09 22:30:38.789 [ERROR] [.b.z.converter.ZigBeeConverter:34 ] - Error opening device level controls null/1
2016-05-09 22:30:38.789 [DEBUG] [b.z.handler.ZigBeeThingHandler:159 ] - null: Initializing ZigBee thing handler

It looks like that is missing some .xml file...
Can someone help with this, please?

Thanks in advance.

[kirantpatil]

@IgorTrindadePT, can you please post how did you compile and add zigbee binding to OH2 ?

Thanks.

[cdjackson]

As discussed on the forum, this will not work with the REX hardware. Do you have the CC2531 hardware or are you using something else? I just want to save you the pain of installing the IDE and getting everything working just to find that it doesn’t work with your hardware. To compile the binding, follow the instructions here (http://docs.openhab.org/developers/development/ide.html <http://docs.openhab.org/developers/development/ide.html>) to install the IDE. Then download the branch from this PR and compile using Eclipse.

[kirantpatil]

I did install openhab2-development and then downloaded and build the zigbee branch. Now how to find out that Zigbee binding is loaded and running ?

Thanks.

[cdjackson]

It’s the same as any other binding - use Karaf to see what is running. You still haven’t answered my question - are you trying to get this working with the REX hardware? it will not work and I don’t want to waste either of our time if this is what you are trying to do..

[kirantpatil]

Finally I would like to check what does it show in Karaf bundle:list.

How to Karaf when I am running app from Eclipse ?

[cdjackson]

If you are running in Eclipse, then Karaf is not running. You should use the debugger to debug. Please can you respond to the question - what hardware are you trying to get this working with. It will only work with the CC2531.

[kirantpatil]

Yes Sir, I understood that it is working with CC2531. I will not post any more questions regarding the support for REX3S device.

Thanks and appreciate for your quality time and guidance.

[cdjackson]

This was not my point. If you want to look at adding support for the REX, then we can discuss, but it will be quite a lot of work (I am currently adding other dongles). I was simply trying to understand what you are trying to do to avoid wasting both of our time!

[kirantpatil]

Sir, Please don't mind, my intention is to stop momentarily until I could get REX usb dongle to try, I understood your point. I would like to see support for REX. Since I am not a HW guy, so trying my best to understand about it.

Once again sorry, I could not convey my intention in proper way.

[mickelluiten]

HI, Trying to build the JAR file with maven for importing it in the addons folder but getting a error.
"Missing requirement: org.openhab.binding.zigbee 2.0.0.qualifier requires 'package gnu.io 0.0.0' but it could not be found"

Don't know wat i'm doing wrong? Has anybody a out of the box binding (jar) for zigbee?

Also when i doing a git clone https://github.com/cdjackson/openhab2 there is no zigbee binding anymore.
When i download it manualy there is.

Please assist me, i was trying to get zigbee binding to work. my usb CC2531 hardware is currently on the way, the ccdebugger/flasher i already have.

What is the latest status for this development?

[cdjackson]

This error is because you don't have the serial bundle included.

I will try and get a compiled binding into the OH2 marketplace over the weekend if possible.

[mickelluiten]

@cdjackson,. Did you manage tot add a compiled version for the zigbee binding in the OH2 marketplace?

Or is it another repro? How to add this repro tot OH2?

What do you.mean that i did't include the serial binding? Can you give me i bit of explemenation for my understanding and learningprocess.

Thanks in advance
Mickel

[cdjackson]

I didn't finish the binding over the weekend - I was trying to finish up the issues with the TI driver last night but had to do some work with the EM358 driver.

It will be in another repo - openhab/org.openhab.binding.zigbee.

The serial bundle - not the serial binding - is required. It's a dependency of any bundle that uses serial ports (zwave, zigbee, serial, and probably a bunch of others). The easiest way to install this might be to install the zwave binding using PaperUI - ZWave wont do anything but it will resolve the dependency.

[mickelluiten]

Hi Chris, thanks for the explenation. i'am a newbie with compiling. I dont understand what you mean to install the zwave binding, Yes i can install the zwave binding that not the problem. But i have a a RPI3 with openhab2 in my live system and also maven install(where i can install the zwave binding), also on my windows laptop i have running eclipse and also maven. Don't see the link between OH2-Zwave and maven. Can you do i little more explenation? Or is there a good tutorial beside the info on the openhab website?
Thanks again.
Mickel

[cdjackson]

Sorry - I thought you were running in the runtime, not the IDE.

To run in the IDE, you need to start the serial bundle. To do this, edit the run configuration plugins and tick the serial bundle (I forget exactly what it's called - I think if you just type serial into the filter box at the top of the plugins page, it might find it - or it might now be called nrserialjava - again, putting this into the filter box should resolve this.

The link with ZWave is that in the runtime environment, it will automatically resolve the dependencies when you install a binding. Given that ZWave has the same dependencies as ZigBee, if you install the ZWave binding, it will automatically resolve the dependencies for you. Otherwise you will need to manually find the dependencies to resolve this issue.

[tavalin]

@cdjackson an alternative is typing feature:install openhab-transport-serial into the (OSGi) console.

[Rachi87]

Can anyone provide a compiled zigbee binding? I would love to test it:)

[mickelluiten]

Hi Chris, DId you already managed to add a compiled version of your Zigbee binding.
Next week my USB CC2531 device is arriving, really want to test the binding.
Mickel

[cdjackson]

No, but hopefully next week. I’m just trying to get some initialisation stuff sorted out with the TI dongle, and add network persistence.

[mickelluiten]

Hi Chris,. I am ready to test the binding with the TI dongle. Did you manage to get the zigbee binding ready?
If so can you send it to me or set it online?
Only need tot flash the TI dongle with the zstack firmware but that i give it try tonight.
Let me know. BR Mickel

[giannello]

@mickelluiten the plugin is available in the marketplace.