Hi Chris. Thanks a lot for the update and your contributions. Just a quick question, I really have a Raspbee not a Conbee but previously you didn’t expect much differences in the implementation. Is still the case?
Yes - I believe that they are the same from a software perspective. I assume that the RaspBee provides a serial port and doesn’t require some other interface?
The documentation for the protocol states -:
Dresden elektronik offers two solutions for that purpose. The ConBee is a ZigBee capable radio USB dongle that turns any PC or MAC with a free USB port into a ZigBee gateway. The other solution is the RaspBee that is an attachment for the Raspberry Pi that uses the Raspberry Pi’s GPIO pins.
and…
On Windows, Linux PC or Mac you can use the ConBee USB Stick. On Rasberry Pi you can also use the RasBee Shield.
I’ve had confirmation from the manufacturer that they are exactly the same (other than the serial port name).
Thanks for the info. I think I have located the port of the RaspBee. I will see if I’m right guessing the port when you release the update. Currently I’m managing the lights with deconz software, do you think I will be able to keep both? There is a nice feature on the deconz software. Reset bulbs, remotes to a default state which allows to reinclude them in new controllers.
Dresden said it should be /dev/ttyAMA0 or /dev/serial0.
No - not at the same time anyway as only one program can access the serial port at any one time. There’s nothing to stop you closing OH and running other software of course.
I wanted to try the binding, so I got a Tradfri 980 lm from Ikea (Austria). Unfortunately I didn’t have much luck getting it to work. The bulb was discovered, but doesn’t have any channels 
I’ve set logging to debug for the binding:
org.openhab.binding.zigbee │ DEBUG
Unfortunately there isn’t much info:
17:31:41.550 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'binding-zigbee' has been installed.
17:31:42.329 [INFO ] [gbee.discovery.ZigBeeDiscoveryService] - 000D6F000D03D29E: Starting ZigBee device discovery
17:31:42.410 [INFO ] [gbee.discovery.ZigBeeDiscoveryService] - 000D6F000D03D29E: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_telegesis:0355f1f3
17:31:42.442 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'zigbee:device:0355f1f3:000d6f000d03d29e' has been added.
17:31:42.441 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'zigbee:device:0355f1f3:000d6f000d03d29e' to inbox.
17:31:42.469 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - 000D6F000D03D29E: ZigBee node property discovery start
17:31:42.486 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - 000D6F000D03D29E: Node doesn't support basic cluster
17:31:52.229 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zigbee:coordinator_telegesis:0355f1f3' has been updated.
17:32:49.978 [INFO ] [smarthome.event.InboxRemovedEvent ] - Discovery Result with UID 'zigbee:device:0355f1f3:000d6f000d03d29e' has been removed.
17:32:49.978 [DEBUG] [.zigbee.internal.ZigBeeHandlerFactory] - Creating coordinator handler for org.eclipse.smarthome.core.thing.internal.ThingImpl@fdbf5385
17:32:50.031 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - Initializing ZigBee thing handler zigbee:device:0355f1f3:000d6f000d03d29e.
17:32:50.032 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:0355f1f3:000d6f000d03d29e' changed from UNINITIALIZED to INITIALIZING
17:32:50.048 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Coordinator status changed to ONLINE.
17:32:50.060 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:0355f1f3:000d6f000d03d29e' changed from INITIALIZING to UNKNOWN
17:32:50.070 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Coordinator is ONLINE. Starting device initialisation.
17:32:50.112 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Initialising node
17:32:50.138 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Created 0 channels
17:32:50.183 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zigbee:device:0355f1f3:000d6f000d03d29e' has been updated.
17:32:50.184 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Initializing ZigBee thing handler
17:32:50.217 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:0355f1f3:000d6f000d03d29e' changed from UNKNOWN to ONLINE
17:32:50.227 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - 000D6F000D03D29E: ZigBee node property discovery start
17:32:50.223 [DEBUG] [org.openhab.binding.zigbee ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.firmware.FirmwareUpdateHandler}={service.id=326, service.bundleid=206, service.scope=singleton} - org.openhab.binding.zigbee
17:32:50.243 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - 000D6F000D03D29E: Node doesn't support basic cluster
17:32:54.315 [INFO ] [arthome.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:device:0355f1f3:000d6f000d03d29e changed to UNKNOWN.
7:33:22.234 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Node updated - ZigBeeNode [IEEE=000D6F000D03D29E, NWK=0000, Type=COORDINATOR]
17:34:52.186 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 000D6F000D03D29E: Node updated - ZigBeeNode [IEEE=000D6F000D03D29E, NWK=0000, Type=COORDINATOR]
Did I miss something? 
There’s no sign that the bulb has been detected - only the coordinator is listed in the log.
You could also enable debug loggin in the stack -:
log:set DEBUG com.zsmartsystems.zigbee
Thanks Chris, guess I misinterpreted the log then. I’ll give it another try tomorrow.
@chris: any chance you can have a look at my problem?
It seems my HUE RGB bulb doesn’t answer / times out
2017-11-23 10:01:18.432 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - Ieee Address for 39592 returned null
2017-11-23 10:01:18.436 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 39592: Discovery request IEEE_ADDRESS failed. Wait before retry.
2017-11-23 10:01:19.938 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0/0 -> 39592/0, cluster=0001, TID=51, nwkAddrOfInterest=39592, requestType=1, startIndex=0]
2017-11-23 10:01:19.941 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=39592/0, profile=0, cluster=1, addressMode=DEVICE, radius=31, sequence=81, payload=00 A8 9A 01 00]
2017-11-23 10:01:19.943 [DEBUG] [31.network.impl.CommandInterfaceImpl] - -> AF_DATA_REQUEST (Packet: subsystem=null, length=15, apiId=24 01, data=FE 0F 24 01 A8 9A 00 00 01 00 51 30 1F 05 00 A8 9A 01 00 51, checksum=51, error=false)
2017-11-23 10:01:20.070 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <- AF_DATA_SRSP (FE 01 64 01 00 64)
2017-11-23 10:01:30.074 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - Ieee Address for 39592 returned null
I’m not sure I can add a lot more than you’ve already stated - the device isn’t responding. From the log, there’s not a lot more I can say (sorry). I’m not using the TI dongle much at the moment, but I did run a quick test with it last week and it seemed to be working ok (I think I actually tested it with a Hue bulb if I remember correctly).
Thanks, I’ll try to fiddle around with it a bit more, maybe borrow a Hue Bridge. Maybe the lamp just needs a newer firmware? Will see.
After countless tries to add the Ikea Tradfri bulb, even moving my pi to the kitchen and using a usb extension cable to get the Telegesis dongle within 10 cms of the bulb I finally gave up. I have no idea why it’s not found.
I then unboxed a Busch-Jaeger battery powered wall-mounted transmitter (6735/01-84) and it was discovered immediately:
13:03:36.269 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - D85DEF11A1002A12: ZigBee node property discovery complete: {zigbee_manufacturer=Busch-Jaeger, zigbee_logicaltype=END_DEVICE, zigbee_powerlevel=FULL, zigbee_model=RB01, zigbee_networkaddress=14695, zigbee_powersource=DISPOSABLE_BATTERY, zigbee_stkversion=1, zigbee_datecode=20161222, zigbee_zclversion=1, zigbee_powermode=RECEIVER_ON_PERIODICALLY, zigbee_powersources=[DISPOSABLE_BATTERY, MAINS, RECHARGABLE_BATTERY], hardwareVersion=0, firmwareVersion=1}
13:03:36.272 [INFO ] [gbee.discovery.ZigBeeDiscoveryService] - D85DEF11A1002A12: Update ZigBee device zigbee:device with bridge zigbee:coordinator_telegesis:49455deb
[... REMOVED SOME LINES ... ]
13:03:42.487 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - D85DEF11A1002A12: Initialising node
13:03:42.514 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - D85DEF11A1002A12: Created 0 channels
13:03:42.582 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - D85DEF11A1002A12: Initializing ZigBee thing handler
13:03:42.583 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zigbee:device:49455deb:d85def11a1002a12' has been updated.
13:03:42.593 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:49455deb:d85def11a1002a12' changed from UNKNOWN to ONLINE
However, it doesn’t have any channels (yet). @chris any chance to get it working?
UPDATE:
I just saw a similar question has already been asked. Sounds like I’d need a virtual light to make it trigger a rule or use it for something else than other zigbee lights.
Maybe it was already used on another system and it needs to be reset? I don’t know how this is done with these bulbs and I don’t have any myself. I do know that others are using them with the binding though…
Currently I’ve not added support for switches and I don’t know what this device actually supports. It should be possible to have it control lights directly (if they are ZigBee) but again this will take some more features in the binding to configure.
I’ll take a look at adding an XML export of the devices features so I can get some of this information…
Maybe it was already used on another system and it needs to be reset? I don’t know how this is done with these bulbs and I don’t have any myself. I do know that others are using them with the binding though…
You can reset them by switching on/off six times. Tried that too to no avail
Currently I’ve not added support for switches and I don’t know what this device actually supports. It should be possible to have it control lights directly (if they are ZigBee) but again this will take some more features in the binding to configure.
As far as I understand it the battery powered switches can only be used to control other zigbee devices. I think what would be need is some kind of virtual zigbee light to pair the switch with and then trigger some openhab rules when the virtual light state changes.
One of my planned setups is to use a 6711 U insert relay in combination with a 6736 2-channel switch. The upper switch would control the relay (terrace lightning), the lower one should trigger an openhab rule to control the terrace awnings through the RFXCOM binding (RFXtrx433E). 
I’ll take a look at adding an XML export of the devices features so I can get some of this information…
Thanks, that would be awesome. Very much appreciated!
I hope the relays will work out of the box, but I need to adapt the electrical wiring before I can test them…
Seems unlikely, but maybe you’re right. I don’t really see why the command couldn’t be sent to the binding and the binding can set a channel/item state, but I’ve not tried it.
Didn’t you just say it could only control other ZigBee devices? 
I guess I’m not understanding what you mean - sorry.
Just the battery powered ones can only control scenes (or other devices as i understand it). The ones connected to the relay will switch the relay with the topmost switch and the other/lower switch(es) can be used for scenes (like the battery powered ones).
“In connection with the ZigBee Light Link flush-mounted inserts 6711 U and 6715 U the top rocker is used to switch or dim the non-ZLL lamps connected to the flush-mounted insert directly. In the case of 6736 and 6737, the other keys can be used for saving, calling and dimming lightscenes.”
Ok, but they still should be able to send a message to OH I would have thought? OH acts just like a device and should be able to receive any commands (unless the device is something ‘special’).
I’ll add this XML file so we can see what clusters it’s supporting at least…
Would be nice if they did, we’ll see. I didn’t see anything in the logs when pressing the switches though, but I don’t know if that is to be expected as I don’t know the internals of the binding.
Thanks again!
No - you won’t. Before you get commands sent, there would need to be a “binding” between the device and the ZigBee binding to tell the device to send messages to the binding…
Another quick update on this - Dresden are going to do an update to the ConBee firmware to make a small change to better support the way the binding works (and make it more common with other dongles and more standard with the ZigBee protocol layers). I expect to get a version to test this week and if it solves the remaining issues I’ll try and get it merged over the weekend.
(I should add, Dresden Electronic have been very supportive recently - always great to see 
).
1 Like