Zigbee binding

Add-ons Bindings
,
1024

The message this comment links to is from February, so I would say yes… 2.3 was pretty up to date with the libs etc.

I don’t recall the round version working very well. This is the first version (not the Aqara I thought?) and I think they were problematic. The square versions work better (if not great!).

I’ve not tried it with the TI, but it should work ok. Yes, you need to press the button regularly - I think I read every 5 seconds on the SmartThings forum. This stops it going to sleep while the binding discovers the services.

1025

The square Aqara temperature/humidity sensor works for a short time for me and then drops communication after about an hour. Pairing is not a problem. I’ve since switched to using the Xiaomi gateway binding and it works fine with them although I’d much prefer to use it without that gateway.

1026

Hey Pedro,
This all makes sense to me and looks good - thanks for tracking this down. I’ll create a PR for this in a couple of days (just to give you a bit more test time :wink: ).

Cheers
Chris

1027

Will this find its way into a nightly build soon? Haven’t seen a PR so far. I think it would help with my issue which is no more within the hour (it improved once binding started caching device properties), but still once every few days.

1028

There was further refactoring done to hopefully improve this issue and it’s available in 1.0.13. If you want, you can use the latest libraries by downloading them from bintray. You just need to manually install the library and uninstall the existing version. For this change, the only file that is required is the main com.zsmartsystems.zigbee JAR.

I will create a PR in the near future to try and get this into the nightly build but I might add a few more things first.

1 Like
1029

Yesterday, I tried moved 8 Osram Recessed Lights and 3 GE Link bulbs over to OH2 and I am running the latest 2.4 Binding per Build 1304

Yesterday all 11 bulbs worked nicely and had Alexa controlling them as well.

But today, all 11 bulbs are non responsive in OH2. Habmin shows them all Online and I just did a reboot of OH2 as well.

Is there an easy way to wake the bulbs back up and get OH2 to control them? It becomes frustrating when having to unpair and repair multiple bulbs.

EDIT. Possibly/likely unrelated, but I just noticed my Philips Hue bulbs are also non responsive in OH2. I can control them via the Hue app. And Habmin shows the Bridge and bulbs all online. And I see the commands sent in the logs. But Bulbs not respond.

I may do a system reboot here and see if it helps any.

EDIT 2 :slight_smile: Seems a full system reboot, not just a stop and start of OH2 fixed things. Not sure why both my zigbee and Hue lights were both unresponsive when zwave and other items still worked. But a full system reboot and things seem back to normal.

1030

I assume your Hue lights are not included in your ZigBee network - ie they are linked to the Hue gateway and not the ZigBee stick? If so, I don’t know why both would have gone down as they should be totally unlinked.

1031

That is correct, and frustratingly its happened again today and I can’t seem to get OH2 to control either my Hue Lights or the Lights paired to OH2, even after stopping and starting OH2, and also even a system reboot.

The Hue app will still control the Hue lights, but I can’t seem to control any light either paired with HUE or paired directly with the zigbee binding with OH2 at the moment.

I think there must be something in my OH2 setup causing an issue? I think I should see an entry in the logs on system start that the Zigbee and Hue binding started and I see neither of that in logs. Although all items have nice green checkmarks.

And I just noticed this towards the top of my logs after a system reboot and OH2 start. I wonder if this could be part of the issue?

2018-07-02 20:47:40.286 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-misc-myopenhab': Error restarting bundles:
Unable to acquire the state change lock for the module: osgi.identity; type="osgi.bundle"; version:Version="0.10.0.201806271317"; osgi.identity="org.eclipse.smarthome.model.script.runtime"; singleton:="true" [id=132] STARTED [STARTED]

Well, a reboot and the error above went away and I seem to have control of the Hue lights again with OH2. But still can’t control those that paired directly to OH2 via the binding. Unsure what could be causing OH2 to not control and respond to them.

1032

Hi @chris,

Is there a specific thread to discuss on CC2531 firmware changes?

I had several issues with the stock CC2531 ZNP-Pro-Secure firmware (mostly locking out after adding ~20 devices), some irresponsiveness that seemed related to routing discovery storms and, specially the dongle running out of memory (I had to enable TRACE debugging to see the MEM error) making it unable to send anything after some time (probably being this also part of the issues when adding more devices).

So I have compiled a custom firmware that apparently works now quite stable (~30 IKEA lights, ~5 Osram plugs, some FLS-pp led strips, several IKEA remotes…), and I am quite sure it can make life easier for people using the cc2531. No code changes to the firmware: just tweaking configuration parameters through the provided defines.

Edit: I have removed the details from here and created a dedicated post: Optimizing the cc2531 firmware for OpenHAB and the Zigbee binding. It contains an up-to-date version of the defines, and will allow for a separate discussion not to jam the general Zigbee binding discussion :slight_smile:

Happy to discuss / change / adjust before my IAR workbench trial license expires :slight_smile:

Pedro

1033

I don’t think so (of course you could start one :wink: )…

Since IAR workbench costs something like $3000, I don’t expect too many people will have it. Are you able to provide a pointer to the binary?

Another question - are these parameters only configurable at compile time, or can they be changed at runtime? If so, we could look to configure them at startup. I know the Ember allows most of these parameters to be adjusted at runtime so the firmware doesn’t need to be compiled.

1034

Hi @chris,

I am checking the license for z-stack to see if I can share the binary. If so, I will definetely share it.

But I would like if somebody was able to comment / test / tweak and improve these parameters before my IAR 1-month free license expires. I only downloaded it to do this :slight_smile:. I still have some days so I may try to build a DIY wall button :slight_smile:

Unfortunately, these parameters are compile time only. Tables are allocated statically and shared with the propietary zigbee stack library (for which the code is not available). Ideally, looking at the code, we could massively change some of the source code files (i.e. ZGlobals.c) to allocate some and initialize the parameters of these after reading config. But it would not be a trivial work, specially on the initial heap allocation. Maybe some of these values may be tweakable at run-time, but not the most relevant ones, so… not in a 30-day trial timeframe

1035 
The License
limits your use, and you acknowledge, that the Software may not be modified,
copied or distributed unless embedded on a Texas Instruments microcontroller
or used solely and exclusively in conjunction with a Texas Instruments radio
frequency transceiver, which is integrated into your product.  Other than for
the foregoing purpose, you may not use, reproduce, copy, prepare derivative
works of, modify, distribute, perform, display or sell this Software and/or
its documentation for any purpose.

So being “itchy” I cannot share the binary unless I am distributing it already loaded into a TI CC2xxx, or unless it is part of a product with a TI radio I am distributing, none of which being the case…

Unless somebody offers to distribute the dongles with this firmware already embedded onto it :expressionless: , the only way I can figure out is everybody wanting to use it downloading the IAR free trial, modifying the two files with the parameters of the previous post, and compiling, similarly to having to download the whole z-stack just to get the hex files as it is done now.

1036

Shame - thanks for checking :frowning:

1037

Well. I know the zigbee has been very unreliable for me via Openhab, and perhaps that is the fault of stick? I am using the Dual Zwave/Zigbee stick, the HUSBZB-1 and I don’t know how to determine what kind of firmware is on it.

I have limited USB ports, so really need a dual stick if possible. So if the HUSBZB-1 uses the CC2531 firmwware mentioned, and if someone can provide some basic instructions, I can try and compile and update my stick to test.

1038

Just look in PaperUI - it should be shown there.

It doesn’t - it uses the Silabs Ember chipset.

1039

Ok, so its back to the beginning in trying to understand why I my zigbee stops working. I tested yesterday on a different VM setup, and was able to pair a few bulbs fine. But then the lights stopped updating a short while later although the OH2 logs looked pretty normal with the items showing as updated although they never actually did.

If you have any ideas, I hope to try and spend some more time looking at things tonight.

1040

Done :wink:

1041

Hi @Chris,
I’m experience another strange serial port issue with the Zigbee-binding:

210 │ Active   │  80 │ 2.3.0                  │ ZigBee Binding
211 │ Active   │  80 │ 2.3.0                  │ ZigBee CC2531 Binding

When the coordinator is the only USB-serial device plugged into the system, the binding is initializing it.
But when I have a couple of other serial devices connected, it fails permanently.

Well, I’m aware of some of the common issues regarding USB-to-serial devices connected to Linux. So I have symlinked the Zigbee coordinator ( /dev/zigbee, since this had the same issue now to /dev/ttyUSB99 to match a common pattern):

SUBSYSTEM=="tty",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="16a8", SYMLINK+="ttyUSB99", GROUP="dialout", MODE="0666"

/etc/defaults/openhab2 is adjusted as well:

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB99:/dev/bluegiga0:/dev/bluegiga1:/dev/bluegiga2:/dev/bluegiga3:/dev/bluegiga4"

If it’s the only serial device, then it works:

2018-07-09 15:14:41.926 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:88c83f29' changed from UNINITIALIZED to INITIALIZING
2018-07-09 15:14:41.936 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:88c83f29' changed from INITIALIZING to UNKNOWN
2018-07-09 15:14:41.942 [hingStatusInfoChangedEvent] - 'zigbee:device:88c83f29:00158d000243776c' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2018-07-09 15:14:41.944 [hingStatusInfoChangedEvent] - 'zigbee:device:88c83f29:00158d000243776c' changed from INITIALIZING to OFFLINE
2018-07-09 15:14:46.804 [hingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:88c83f29' changed from UNKNOWN to ONLINE

But if some Bluegiga BLE dongles are connected to the system as well, the binding can’t open the serial port:

2018-07-09 15:00:12.061 [ERROR] [ding.zigbee.handler.ZigBeeSerialPort] - Serial Error: Port /dev/ttyUSB99 does not exist.
2018-07-09 15:00:12.061 [ERROR] [.cc2531.network.ZigBeeNetworkManager] - Failed to open the dongle.

btw: The Bluegiga-dongles are symlinked to /dev/bluegiga0, /dev/bluegiga1 etc.

More than this: When I remove a CC2531 coordinator from the paper UI and add it back again, it only offers a wrong serial port (/dev/bluegiga1) in the drop-down list to me:

image
image.png676×1048 40 KB

Since the field is not editable, I cannot adjust to the /dev/ttyUSB99 in that case.

Any idea what’s wrong here?

As I said, plug in the CC2531 first, start openHAB and then plug the Bluegigas later works. But this is not a solution for daily operation. And I should have mitigated this need by the symlinking stuff … :wink:

1042

I did some more tests. Looks to me now, that I likely need look more on the Bluetooth binding for that issue.
I’ve asked it’s maintainer @vkolotov as well:

Sorry for noise. But I leave it though - just for reference :wink:

1043

Isn´t the Philips hue sensor applied fully into the binding 2.3.0 stable?

I have just added this device to my Zigbee network, but the switch for motion doesn´t seem to work. It´s stated ‘Undefined’.
Illumiance, temprature and Occupancy is working just fine…

Screenshot from PaperUI:

philipsmotionsensor1
philipsmotionsensor1.jpg1192×681 81.1 KB

My item file:

Switch 	Stue_HUE_Motion		"Hue sensor motion [%s]"		<cum_motion>				{ channel="zigbee:device:6ec05458:0017880102139d00:0017880102139D00_1_switch_onoff" }
Number	Stue_HUE_Temp 		"Hue sensor temperatur [%.1f °C]"	<cu_heating>	(Temperatur)		{ channel="zigbee:device:6ec05458:0017880102139d00:0017880102139D00_2_measurement_temperature" }
Number	Stue_HUE_illumiance 	"Hue sensor Ilumiance [%s]"		<light>					{ channel="zigbee:device:6ec05458:0017880102139d00:0017880102139D00_2_measurement_illuminance" }
Switch 	Stue_HUE_Occu		"Hue sensor Occupancy [%s]"		<cum_motion>				{ channel="zigbee:device:6ec05458:0017880102139d00:0017880102139D00_2_sensor_occupancy" }

Screenshot from BasicUI:

philipsmotionsensor2
philipsmotionsensor2.jpg1106×164 19.9 KB

Nothing from the motionsensor :frowning: But the other channels are working just fine. A few minutes ago it worked just fine from the Hue gateway. I just removed it fra Hue setup, reset it, and added it to my Zigbee controller insted.