You should (I assume) be able to put the binding into discovery mode and it should detect the device. I’m not sure though what profile the Tap uses - if it’s ZLL rather than HA it might not work with the binding. I was looking at getting one of the Tap devices recently to control some Hue strips, but I decided not to in the end as I wasn’t sure what the profile was…
Hi, I do have the same problem. If i build the binding as in the repository I get the BundleException The bundle class path entry “nrjavaserial-3.9.3.jar”. When I remove the entry in the Manifest file and rebuild there is no error. The binding also shows up using bundle:list command in karaf. But when I add zigbee to the bindings in my addons.cfg I get the following error:
[ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-zigbee': No matching features for openhab-binding-zigbee/0.0.0
What am I doing wrong?
You need to install the serial bundle. Since you’re installing the bundle manually, you need to resolve dependancies manually as well.
Thanks for your help but I still can not install the jar. How can I install the serial binding. Just by adding binding = serial in my addons.cfg?
If you drop the io.transport.serial bundle into the addons folder, this should work I think.
Hey @KPaul20005, it is a shame, that you can not install the jar. Have you
tried using bindings:list command in karaf console to check if your serial
bundle is installed? You can pipe the info to grep to filter information
and if you use -s (symbolic) paramater with bindings:list you should see
it. Then the command should look like this bindings:list -s | grep
[symbolic bundle name]. You could also try to install it via Paper UI if
you haven’t tried yet. Granted, I haven’t checked the latest OH2 release
and don’t know if the UI has changed much, but it should be something like
this: PaperUI > Extensions > type in serial binding in the search bar a nd
hit install. Hope this helps!
Thanks a lot. I finally got it running. I removed the nrjavaserial-3.8.8.jar entry from the manifest and packed the jar. This jar I could copy to the addons folder and it installed without a problem. First I did not understand that I do not have to add a “zigbee” entry to my addons.cfg. I could set up my coordinator and it detected my device, a Dresden Electronics FLS-PP lp. But when I now try to add the device I get the debug output:
Can't initializing ZigBee thing handler without address{}.
The device switches from Initializing to Offline. Am I doing something wrong? Is it possible to specify the Things in the text files to have more control over the process?
Regards Kenny
Dear Chris
I have been tinkering with your openhab2 zigbee binding (last updated 3 months ago) for a while now and experienced a few things that I would like your assistance with: (I am by no means a competent JAVA programmer)
I am using windows, 32bit eclipse installation, and a CC2531 TI Dongle.
-
List item
I could not get the CC2531 to function properly, (never reached discovery status) until I changed the magic byte in ZigbeeCoordinatorCC2530handler from “0xef” to “0x07”. In addition every time before i “Run Configuration” in eclipse I have to unplug the dongle and re-plug otherwise a “Com2 port in use error” is logged, and the dongle does not startup. --ANY POINTERS to get this resolved? -
List item
After the openhab startup and the subsequent 60 second device discover period, I noticed that Develco Products A/S ZHOT101 - ZigBee Occupancy, Temperature & Light Sensors with mac’s 00:15:BC:00:1A:00:39:CB and xx.xx.xx.xx.2B are not properly configured. (see log extract below) These are battery based devices that are sleeping during the discovery period. The only way to get them properly recorded is to reset the devices (battery out/in) during the discovery period.
Once discovered and moved from the inbox to the Thing handler (with paperUI), I manage to get the initial status read (from the initial call to the clusterhandler ) displayed in the UI but no further updates. I have been searching the code but did not mange to find a way that an independent status update, from a battery based device, are processed, not even switching off the smartplug (not using the UI). The handleRefresh() and handleCommand(Command command) in the respective clusterhandlers are called by the 60 second polling in the ZigbeethingHandler and any UI/rules interventions receptively.
According to my limited understanding, any status changes experienced by a devices between successive polling periods, will be lost. Therefore battery based devices will not be able to update their status changes (motion, temperature, occupation etc). Is the purpose of the receivedReport() function not to deal with the status reporting between polling updates?? If so how would you activate this function. ??
- List item
The demo.item channel descriptors
{ channel = “zigbee:device:ti_dongle:0015bc001900c61a:switch_onoff__33” }
{ channel = “zigbee:device:ti_dongle:0015bc001a003d2b:measurement_temperature__38” }
are in my case for a smart plug and a temperature sensor. I do not understand where this numbering convention originates from. Only manged to get things functional by analyzing the log file. The 33 and 38 according to my understanding does not correlate with the HA profile device ID’s. According to my info smartplug = 0x0051 (generic) and temperature 0x0302 (HVAC) has no correlation with the numbers 33 and 38 used. Can you provide some insight? and or point me to the file where I can verify this numbering system??
2016-10-31 16:48:41.734 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:293 ] - Bridge connection open. Updating thing status to ONLINE.
2016-10-31 16:48:41.734 [INFO ] [b.z.handler.ZigBeeThingHandler:70 ] - Start Initializing ZigBee thing handler 00:15:BC:00:19:00:C6:1A.
2016-10-31 16:48:41.738 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:122 ] - 00:15:BC:00:19:00:C6:1A: Serializing from file .\userdata\zigbee\00:15:BC:00:19:00:C6:1A.xml
2016-10-31 16:48:41.739 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:125 ] - 00:15:BC:00:19:00:C6:1A: Error serializing from file: file does not exist.
2016-10-31 16:48:41.739 [INFO ] [b.z.handler.ZigBeeThingHandler:83 ] - Load node information coordinatorHandler [#58869 (00:15:BC:00:19:00:C6:1A)].
2016-10-31 16:48:41.754 [WARN ] [o.b.z.h.c.ZigBeeClusterHandler:115 ] - Cluster converter for cluster Basic(0)is not implemented!
2016-10-31 16:48:41.754 [WARN ] [o.b.z.h.c.ZigBeeClusterHandler:115 ] - Cluster converter for cluster Identify(3)is not implemented!
2016-10-31 16:48:41.756 [WARN ] [o.b.z.h.c.ZigBeeClusterHandler:115 ] - Cluster converter for cluster Alarms(9)is not implemented!
2016-10-31 16:48:41.757 [WARN ] [o.b.z.h.c.ZigBeeClusterHandler:115 ] - Cluster converter for cluster Metering(1794)is not implemented!
2016-10-31 16:48:41.757 [WARN ] [o.b.z.h.c.ZigBeeClusterHandler:115 ] - Cluster converter for cluster DeviceTemperatureConfiguration(2)is not implemented!
2016-10-31 16:48:41.757 [WARN ] [o.b.z.h.c.ZigBeeClusterHandler:115 ] - Cluster converter for cluster Identify(3)is not implemented!
2016-10-31 16:48:41.818 [INFO ] [rthome.event.ThingUpdatedEvent:43 ] - Thing ‘zigbee:device:ti_dongle:0015bc001900c61a’ has been updated.
2016-10-31 16:48:41.818 [DEBUG] [.c.c.r.AbstractManagedProvider:135 ] - Updated element zigbee:device:ti_dongle:0015bc001900c61a in ManagedThingProvider.
2016-10-31 16:48:41.818 [INFO ] [b.z.handler.ZigBeeThingHandler:108 ] - Channel properties for [00:15:BC:00:19:00:C6:1A], is [6]
2016-10-31 16:48:41.821 [INFO ] [.z.a.c.impl.core.AttributeImpl:134 ] - Reading OnOff from 00:15:BC:00:19:00:C6:1A
2016-10-31 16:48:41.902 [INFO ] [smarthome.event.ItemStateEvent:43 ] - Ugly_Betty_On_off updated to ON
2016-10-31 16:48:41.905 [INFO ] [smarthome.event.ItemStateEvent:43 ] - zigbee_device_ti_dongle_0015bc001900c61a_switch_onoff__33 updated to ON
2016-10-31 16:48:41.906 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - ‘zigbee:device:ti_dongle:0015bc001900c61a’ updated: ONLINE
2016-10-31 16:48:41.907 [INFO ] [s.event.ItemStateChangedEvent :43 ] - Ugly_Betty_On_off changed from NULL to ON
2016-10-31 16:48:41.907 [INFO ] [s.event.ItemStateChangedEvent :43 ] - zigbee_device_ti_dongle_0015bc001900c61a_switch_onoff__33 changed from NULL to ON
2016-10-31 16:48:41.911 [INFO ] [ent.GroupItemStateChangedEvent:43 ] - Plugs changed from NULL to UNDEF through Ugly_Betty_On_off
2016-10-31 16:48:41.914 [INFO ] [b.z.handler.ZigBeeThingHandler:70 ] - Start Initializing ZigBee thing handler 00:15:BC:00:1A:00:39:CB.
2016-10-31 16:48:41.915 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:122 ] - 00:15:BC:00:1A:00:39:CB: Serializing from file .\userdata\zigbee\00:15:BC:00:1A:00:39:CB.xml
2016-10-31 16:48:41.915 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:125 ] - 00:15:BC:00:1A:00:39:CB: Error serializing from file: file does not exist.
2016-10-31 16:48:41.916 [INFO ] [b.z.handler.ZigBeeThingHandler:83 ] - Load node information coordinatorHandler [null].
2016-10-31 16:48:41.961 [DEBUG] [.c.c.r.AbstractManagedProvider:135 ] - Updated element zigbee:device:ti_dongle:0015bc001a0039cb in ManagedThingProvider.
2016-10-31 16:48:41.962 [INFO ] [rthome.event.ThingUpdatedEvent:43 ] - Thing ‘zigbee:device:ti_dongle:0015bc001a0039cb’ has been updated.
2016-10-31 16:48:41.962 [INFO ] [b.z.handler.ZigBeeThingHandler:70 ] - Start Initializing ZigBee thing handler 00:15:BC:00:1A:00:3D:2B.
2016-10-31 16:48:41.962 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:122 ] - 00:15:BC:00:1A:00:3D:2B: Serializing from file .\userdata\zigbee\00:15:BC:00:1A:00:3D:2B.xml
2016-10-31 16:48:41.962 [DEBUG] [o.o.b.z.i.ZigBeeNodeSerializer:125 ] - 00:15:BC:00:1A:00:3D:2B: Error serializing from file: file does not exist.
I think there are different firmware versions with a different magic byte - I seem to recall in the past that this changed. What firmware did you load?
The TI sticks are a bit of a pain as you need to get the right firmware and not everyone has the programmer to load the firmware as it can’t be loaded using USB.
Battery [quote=“Mariusm, post:48, topic:12895”]
I noticed that Develco Products A/S ZHOT101
[/quote]
These devices are difficult to get working - I have one here and it’s been a pain. I’ve not used it for a while so I don’t remember how I finally got it discovered properly, but I do recall it being a nightmare.
These devices ultimately need the reporting set - you can’t poll them.
This binding needs some attention. I’ve started to rewrite the ZCL stack and the binding above, and I’m highly likely to look at using more commercially friendly sticks (almost certainly the EM357 based sticks).
Thanks for the feedback Chris
- List item
I am aware that the battery devices can’t be polled hence my investigation if the receivedReport() option, can’t it be a way to solve this problem. The ReportBase&ReportListernerNotifier defines a ClusterListener / ClusterHandler that calls the receivedReport() in the ClustnerHandlers, I do not know what settings are required to activate this? if at all possible.
- List item
Is it normal that “things” appearing in the Inbox (paperUI) when added to things do not change state from “Initializing” to “Online” unless you restart openhab ??? (Zigbee binding specific)
- List item
Any feedback on the naming convention in the demo.item file? (See detail previous post)
{ channel = “zigbee:device:ti_dongle:0015bc001900c61a:switch_onoff__33” }
{ channel = “zigbee:device:ti_dongle:0015bc001a003d2b:measurement_temperature__38” }
- List item
The Dongle firmware came pre-loaded with the ZigBee Home Automation Gateway reference design from TI. Works every time when booted on the Beaglebone Black with z-stack_linux_gateway loaded. I have not attempted to verify the firmware build. (don’t know how) I have loaded the Zigbe4java build on my raspberry using the same dongle. Although i do not have to unplug the dongle before activating the software, one may have to restart the server app more than once to get things going.
hi
any update if other zigbee dongles work yet? 
No - but very soon I am going to have to do this for a customer - first up will likely be the EM357 from CEL (similar or same hardware to the Telegesis dongle).
Hi chris,
1 Am I correct to say that as long as a USB dongle use 2531 chipset programmed with the specific firmware on TI website, it should work with zigbee binding?
2 Would you mind share a link for this telegesis dongle OR provide some more info for it?
Basically I just want to take a look whether this dongle is cc2531 based.
Thank you.
No - it is EM35x based.
Am I correct to say, to make zigbee binding work,
we also need cp210x.ko and usbserial.ko which is needed for zwave usb dongle to work?
Thank you.
I don’t know what these are - can you explain please? Maybe they are specific to your configuration or something?
Sorry - Just find that cp210x.ko is for Aeon Lab USB sticker S2.
And usbserial.ko is a module cp210x.ko depend on, but it works a like a general usb module.
So say I have programmed the firmware to TI cc2531 usb dongle, then I clone this repo below,
Switch to zigbee branch, is that enough to make zigbee binding work?
Should I do something else? Like plug in some drive module?
Thank you.
Hey @chris, I am working with your latest ZigBee binding implementation for a custom ZigBee device, due to memory constraints it cannot use reporting capability, so instead it sends out commands to change the state of the channel on the OH2.
From what I can see in the binding the channel converters don’t handle the state updates without the reporting functionality, thus the commands being sent from the custom device are ignored (I also observed this in paper UI control panel, if the device, for example, sends a ZCL_GENERAL_SWITCH_ON command, the switch state in the paper UI does not change). I am not sure how should I implement this functionality into the binding, I know I can check for the command ID by calling getCommandID() from com.zsmartsystems.zigbee.zcl.protocol.ZclCommand and check it against com.zsmartsystems.zigbee.zcl.protocol.ZclCommandType enum value, what I am not sure is how to let the ZigBeeThingHandler know when the channel state has been changed (of course I would have to set up a thread to check each of the channels states, but I am not sure what should be done inside that check. Should I implement a ThingHandlerCallback for each of the channels and use the postCommand() method to check if a specific channel received a command from the device to change the state of that channel and then use updateState() method from the BaseThingHandler, if so, then I am not sure how ThingHandlerCallback implementation should connect to com.zsmartsystems.zigbee package (I do not know how the commands from the device are handled by this package and how I could forward them to the callback implementation)).
Also, the custom device has an Occupancy Sensor, which also sends ZCL commands to the OH2, currently OH2 handles this channel as a switch, but I’ll implement an OccupancySensorChannelConverter when I have some time.
And there was another thing, I noticed in the logs, that the setChannelState() does not seem to work, it throws an IllegalStateException with a message “Could not update state, because callback is missing”, does that mean that reporting does not work as well?
Thanks for your input in advance!
Hi @chris,
I am trying to use the Telegesis ETRX357-LRS with openHAB ZigBee binding 2.2.0 and also tried the 2.3.0 SNAPSHOT.
I have confirmed using a serial terminal that the dongle works (in that it communicates reliably over USB).
However, although PaperUI shows that the dongle is installed and is online, I cannot detect any Philips HUE bulbs that I have.
Below is a snippet of the debug log which suggests that an AT+ command is not being recognised by the dongle.
My ETRX357 has firmware r308. The command may be suitable for r309 only, perhaps.
2017-12-24 11:58:14.535 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Starting mesh update
2017-12-24 11:58:14.539 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 0/0, cluster=0031, TID=39, startIndex=0]
2017-12-24 11:58:14.544 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, sequence=57, payload=00 00]
2017-12-24 11:58:14.548 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=49, messageData=00 00, messageId=null]
2017-12-24 11:58:14.551 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1
2017-12-24 11:58:14.566 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS TX: Data 41 54 2B 53 45 4E 44 55 43 41 53 54 42 3A 30 32 2C 30 30 30 30 2C 30 30 2C 30 30 2C 30 30 30 30 2C 30 30 33 31 0D 00 00 0D 0A
2017-12-24 11:58:14.691 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 45 52 52 4F 52 3A 30 32
2017-12-24 11:58:14.695 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis command complete: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=49, messageData=00 00, messageId=null, status=UNKNOWN_COMMAND]
Translation of the hex data above for convenience:
AT+SENDUCASTB:02,0000,00,00,0000,0031
0 0
ERROR:02
Any help to get discovery started appreciated.
I’ll take a look at this in a couple of days when I’m back home - currently I have very limited internet access to check this.
Merry Christmas.