Zigbee binding

I’ve done some search regarding compatibility of Ikea Tradfri with Zigbee ZLL. It is somehow contradictory:

Zigbee Alliance is listing them as being ZLL compliant:
http://www.zigbee.org/zigbee-products-2/#zigbeecertifiedproducts/productdetails3/5714d134d68b322d16de033d/

BUT:
HUE developer support claims it not beeing fully compliant to ZLL because of reporting their profile-id corresponding to ZHA:
https://developers.meethue.com/comment/2686#comment-2686

The Tradfri bulbs have been reported working in combination with a former firmware release of the HUE bridge (which supports ZLL-only according to Philips) and seem now beeing rejected by the HUE bridge from joining because of a more strict implementation (or interpretation) of the ZLL standard.

Not sure, if this relates to the discovery issue we see here - or if this is a real issue at all (besides the HUE bridge combination)

@Chris, you probably know all this already.
Nevertheless, I wanted to let you know just in case, you haven’t heard yet :wink:

Try the firmware named CC2531ZNP-Pro-Secure_LinkKeyJoin.hex from zstack, with that file loaded on the stick i have been able to control them with zigbee4java. I have tried pro, and pro-secure with zigbee4java and with them i am not able to join Ikea trådfri there.

//Mattias

Wow, @elevation thanks for that hint!

Just one question:
Do you have other brands of ZLL bulbs working in combination with that firmware.
I’m asking especially about Philips and Osram (as you guess easily from my other posts ;-))

I think i joined hue lamps also, it has a while ago. Started using the stick from Dresden that they managed to get working instead.
The solution at https://kappa.io/download was working also, byt that old firmware was not accepted by zigbee4java.
Ikea lamps are based on the ember stack from silabs, i think i saw version 5.7.0 in some firmware file, tried to google and find if it was related to the stack itself or their implementation byt have not found anything.

//Mattias

Maybe the Ikea lamps are looking at ZigBee 3 compliance which does away with ZLL. ZLL isn’t used by the binding anyway and ZLL bulbs are meant to work with HA, so this shouldn’t matter. I’ve not looked at the logs yet though…

Version 5.7 of ember is reasonably new - they just released 5.9 a few weeks back… (I have all Ember developers kit here and am generally using 5.8).

Yes, that worked. Thanks again for sharing this @elevation ! As you said, the other lamps can join as well. Well - I had to rediscover them :wink:

So I currently have the Ikea, Osram and Philips in the same PAN. All can be controlled for level and switch cluster, the RGBs (HUE and the Osram stripe) can also controlled by the color cluster commands.

Now looking forward to @chris’s color temp channel implementation :slight_smile:

2017-05-30 18:21:46.531 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 000B57FFFE305336: Starting ZigBee device discovery
2017-05-30 18:21:46.532 [DEBUG] [31.network.impl.CommandInterfaceImpl] - ->  AF_DATA_REQUEST (Packet: subsystem=null, length=15, apiId=24 01, data=FE 0F 24 01 64 3B 03 01 00 00 12 30 1F 05 00 12 00 06 00 5B, checksum=5B, error=false)
2017-05-30 18:21:46.539 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 000B57FFFE305336: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_cc2531:af6da79d
2017-05-30 18:21:46.544 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zigbee:device:af6da79d:000b57fffe305336' to inbox.
2017-05-30 18:21:46.546 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 000B57FFFE305336: ZigBee node property discovery start
2017-05-30 18:21:46.550 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 000B57FFFE305336: ZigBee node property discovery using 8910/1
2017-05-30 18:21:46.552 [DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - readSync request: ZclAttribute [id=4, name=ManufacturerName, dataType=CHARACTER_STRING, lastValue=IKEA of Sweden]
2017-05-30 18:21:46.553 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ReadAttributesCommand [Basic: 0/0 -> 8910/1, cluster=0000, TID=13, identifiers=[Attribute Identifier: attributeIdentifier=4]]
2017-05-30 18:21:46.556 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-  AF_DATA_SRSP (FE 01 64 01 00 64)
2017-05-30 18:21:46.558 [DEBUG] [31.network.impl.CommandInterfaceImpl] - ->  AF_DATA_REQUEST (Packet: subsystem=null, length=15, apiId=24 01, data=FE 0F 24 01 CE 22 01 01 00 00 13 30 1F 05 00 13 00 04 00 E8, checksum=E8, error=false)
2017-05-30 18:21:46.584 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-  AF_DATA_SRSP (FE 01 64 01 00 64)
2017-05-30 18:21:46.601 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- ZToolPacket (FE 03 45 C4 CE 22 00 6E)
2017-05-30 18:21:46.603 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=3, apiId=45 C4, data=FE 03 45 C4 CE 22 00 6E, checksum=6E, error=false
2017-05-30 18:21:46.604 [DEBUG] [e.dongle.cc2531.ZigBeeDongleTiCc2531] - Unhandled ZToolPacket type 0x45c4
2017-05-30 18:21:46.606 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- ZToolPacket (FE 03 45 C4 CE 22 00 6E)
2017-05-30 18:21:46.608 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=3, apiId=45 C4, data=FE 03 45 C4 CE 22 00 6E, checksum=6E, error=false
2017-05-30 18:21:46.609 [DEBUG] [e.dongle.cc2531.ZigBeeDongleTiCc2531] - Unhandled ZToolPacket type 0x45c4
2017-05-30 18:21:46.661 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- AF_DATA_CONFIRM (FE 03 44 80 00 01 13 D5)
2017-05-30 18:21:46.663 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: AF_DATA_CONFIRM(Endpoint=1, Status=SUCCESS(0), TransID=19)
2017-05-30 18:21:46.668 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- AF_INCOMING_MSG (FE 2A 44 81 00 00 00 00 CE 22 01 01 00 A0 00 34 41 35 00 00 16 18 13 01 04 00 00 42 0E 49 4B 45 41 20 6F 66 20 53 77 65 64 65 6E CE 22 1D 67)
2017-05-30 18:21:46.670 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=42, apiId=44 81, data=FE 2A 44 81 00 00 00 00 CE 22 01 01 00 A0 00 34 41 35 00 00 16 18 13 01 04 00 00 42 0E 49 4B 45 41 20 6F 66 20 53 77 65 64 65 6E CE 22 1D 67, checksum=67, error=false
2017-05-30 18:21:46.671 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Basic: 8910/1 -> 0/1, cluster=0000, TID=13, records=[Read Attribute Status Record: attributeDataType=CHARACTER_STRING, attributeIdentifier=4, status=0, attributeValue=IKEA of Sweden]]
2017-05-30 18:21:46.678 [DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - readSync request: ZclAttribute [id=5, name=ModelIdentifier, dataType=CHARACTER_STRING, lastValue=**TRADFRI bulb GU10 WS 400lm**]
2017-05-30 18:21:46.680 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ReadAttributesCommand [Basic: 0/0 -> 8910/1, cluster=0000, TID=14, identifiers=[Attribute Identifier: attributeIdentifier=5]]

Nice that it worked. Is it possible to join the remote also? With deConz from dresden a new group is created when i join the remote, and the lamps added in that group can be toggled on/off and level cobtrolled, temp is not working (atleast with the versions i use). To join a remote in deConz i reset the remote with 4 (or 5, do not remember) quick presses on linkbutton on backside, then with network open i remove battery and put it back.

//Mattias

Sorry Mattias, I can’t help here.
Unfortunately, I don’t have Tradfri remotes (yet).

Hi all,
I recently got a CC2531 USB dongle on aliexpress and a smartrf04EB to flash the firmware using cc-tool on Linux:

reinhold@zweistein:~$ cc-tool -e -w CC2531ZNP-Pro-Secure_LinkKeyJoin.hex -v r 
  Programmer: SmartRF04EB
  Target: CC2531
  Erasing flash...
  Completed       
  Writing flash (242 KB)...
  Completed (7.89 s.)
  Verifying flash...
  Completed (78.21 s.)

However, when I try to add it to OpenHab on my Raspberry Pi 3, the binding (installed from the marketplace) claims that the tty does not exist:

2017-05-30 21:32:58.095 [DEBUG] [zigbee.internal.ZigBeeHandlerFactory] - Creating coordinator handler for org.eclipse.smarthome.core.thing.internal.BridgeImpl@d6e705f2
2017-05-30 21:32:58.126 [DEBUG] [ndler.ZigBeeCoordinatorCC2531Handler] - Initializing ZigBee CC2531EMK serial bridge handler.
2017-05-30 21:32:58.127 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_cc2531:15c07b43].
2017-05-30 21:32:58.128 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel -1
2017-05-30 21:32:58.129 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - PANID 0
2017-05-30 21:32:58.131 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - EPANID 0000000000000000
2017-05-30 21:32:58.132 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2017-05-30 21:32:58.133 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising network
2017-05-30 21:32:58.134 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Created random ZigBee PAN ID [5DA0].
2017-05-30 21:32:58.186 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Created random ZigBee extended PAN ID [6F50A53C67F77800].
2017-05-30 21:32:58.229 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key String 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2017-05-30 21:32:58.230 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key array [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2017-05-30 21:32:58.231 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key final array [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2017-05-30 21:32:58.274 [DEBUG] [ndler.ZigBeeCoordinatorCC2531Handler] - ZigBee Coordinator CC2531 opening Port:’/dev/ttyACM1’ PAN:5da0, Channel:-1
2017-05-30 21:32:58.275 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
2017-05-30 21:32:59.276 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
2017-05-30 21:32:59.277 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
2017-05-30 21:32:59.279 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Creating ZigBee discovery service for zigbee:coordinator_cc2531:15c07b43
2017-05-30 21:32:59.280 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Activating ZigBee discovery service for zigbee:coordinator_cc2531:15c07b43
2017-05-30 21:32:59.315 [DEBUG] [org.openhab.binding.zigbee ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=422, service.bundleid=23 service.scope=singleton} - org.openhab.binding.zigbee
2017-05-30 21:32:59.317 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key initialise [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2017-05-30 21:32:59.320 [DEBUG] [ndler.ZigBeeCoordinatorCC2531Handler] - Opening ZigBee CC2531 serial port
2017-05-30 21:32:59.321 [DEBUG] [ndler.ZigBeeCoordinatorCC2531Handler] - Connecting to serial port [/dev/ttyACM1]
2017-05-30 21:32:59.325 [ERROR] [ndler.ZigBeeCoordinatorCC2531Handler] - Serial Error: Port /dev/ttyACM1 does not exist

The serial device /dev/ttyACM1 does exist (by default with group dialout and permissions 660, but I changed it to 777 to be sure it’s not a permissions issue):

[22:26:30] root@openHABian:~# ls -la /dev/ttyACM1
crwxrwxrwx 1 root dialout 166, 1 May 30 21:39 /dev/ttyACM1

The dmesg command also shows that the serial device is properly created when I plug in the USB stick:

[70930.149076] usb 1-1.2: new full-speed USB device number 24 using dwc_otg
[70930.271804] usb 1-1.2: New USB device found, idVendor=0451, idProduct=16a8
[70930.271829] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[70930.271842] usb 1-1.2: Product: TI CC2531 USB CDC
[70930.271854] usb 1-1.2: Manufacturer: Texas Instruments
[70930.271867] usb 1-1.2: SerialNumber: __0X00124B0009EB0CE8
[70930.274523] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device

Any idea what might be wrong?

Thanks,
Reinhold

1 Like

Just to be sure:
Do you have installed:

as Chris mentioned above?

The binding wont even start if the serial bundle isn’t found. This will likely be the “standard” permissions problems that people have with RPi - even when they set the permissions. This is also reasonably common with ZWave and other serial bindings.

Unfortunately I don’t have an answer though, but “port doesn’t exist” is the standard response for permissions issues…

Ah, I see, thanks for clarifying.
Since I use openHABian on my “developement/test”-RasPI-system, I’ve probably not stumbled over this serial permission issue.

Another idea is to check:

/etc/default/openhab2 to permit the required serial port, similar to:

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/rdev/zwave:/rdev/rfxcom"

@reinhold,

Just a WAG on my part, but have you reviewed the guidance found in this post by @ThomDietrich? Obviously the device path is different in your case, but some (all?) of the info may be applicable.

Good luck!

1 Like

Dear All,
thanks for your ideas. It was indeed a simple issue (also suggested by some here): I “forgot” to add the /dev/ttyACM1 serial device to the gnu.io.rxtx.SerialPorts in the EXTRA_JAVA_OPTS in /etc/default/openhab2 (for my Z-Wave stick the /dev/ttyACM0 was already added a while back, but I completely forgot about this requirement). The serial port now works. It’s just a bit strange that in times of plug-and-play you still have to explicitly tell Java which devices it can use as serial ports… Shouldn’t the RXTX library be able to simply try to open any device it is given as a serial device and see if it works?

In particular, can’t the binding explicitly add the configured device to the SerialPorts variable if it is not included there? See e.g. http://angryelectron.com/rxtx-on-raspbian/ and http://rxtx.qbang.org/wiki/index.php/FAQ#RXTX_does_not_find_my_device.2C_what.27s_wrong.3F or https://www.raspberrypi.org/forums/viewtopic.php?f=5&t=6011

The particular problem seems to be that the RXTX library on linux only identifies /dev/ttyS* and /dev/ttyUSB* as serial ports, while many serial devices are made available as /dev/ttyACM* by the kernel. Unfortunately, RXTX does NOT by default identify these as serial devices, even though by definition they are (https://rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/). In my eyes this is main reason for many of the permissions problems on linux / RPi.

1 Like

That’s interesting - it might pay to see if you can find somewhere in the OH docs to add this point. Problems with serial ports, especially with the RPi, is one of the most common problems I see…

1 Like

Hi @Chris,
I’m curious to hear, if you made further progress on the zigbee binding - especially regarding the mentioned color temperature mods.

Do you have something new to test? :wink:

Hi,
Sorry - no I didn’t finish off the refactoring yet. It’s a little larger than I had originally hoped but I’ll try and get it completed this week.

Cheers
Chris

Hi Chris,

First of all, thank you so much for this great work. I’m really looking forward to using your binding as i have many Smartthings sensors and want to control them directly from the OH2. I installed your binding successfully and activated the serial driver through karaf.

Can i use the Raspbee module from Dresden Elektronik with your binding?

When i go the inbox and search things using your binding it give 2 options:
CC2531EMK Coordinator and the Ember EM35x Coordinator.
Can i use one of them for the Raspbee module?

Secondly, which serial port should i use? I mean the Raspbee module is plugged directly into the Raspi (and not thru USB port). So i have no clue what the port is. And I cannot use /dev/ttyACM0 as i have the Aeon Z-Stick using that port.

Any help would be very appreciated.
Thanks in advance.
Emre

No - this is not supported (at least not yet).

No.[quote=“asemev, post:106, topic:15763”]
Secondly, which serial port should i use? I mean the Raspbee module is plugged directly into the Raspi
[/quote]

I guess you should use the ls /dev/tty* command - but as above - this device is not currently supported.

Thanks Chris.