ZLL Commissioning about deconz-rest-plugin HOT 17 CLOSED

pi@raspbee:~ $ sudo GCFFlasher_internal -f deCONZ_Rpi_0x261a0500.bin.GCF
GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26
no device specified use RaspBee (/dev/ttyS0)
using firmware file: deCONZ_Rpi_0x261a0500.bin.GCF
reset target

RaspBee Bootloader premium
Vers. 1.02
build 2013/08/01

flashing 127162 bytes: |==============================|
verify: ....
SUCCESS
pi@raspbee:~ $

Thanks, @manup

from deconz-rest-plugin.

It is possible but there is no official guide to configure the RaspBee to join the Hue network as router. In order to let the RaspBee/ConBee join a Hue network, the settings must be adjusted:

• Device Type : Router
• TC Link Key : ZLL Link Key (not the ZLL Master Key). This key used to be secret but can be found in the web (hint: google peeveeone breakout breakthrough)
• TC Address: 0xffffffffffffffff
• Network Key: 0x00000000000000000000000000000000
• Predefined PANID: disabled
• Static NWK Address: checked, should be set to some arbitrary number
• Channel Mask: 11, 15, 20 and 25

After saving the configuration:

• press the Leave button
• in the Hue app start automatic searching for lights (this opens the ZigBee network)
• press the Join button

Connection to the hue bridge should now be established, be aware that there might be unexpected behaviour since two commissioning tools try to control the network in different ways. For example one bridge might delete the groups and scenes created by another one, since it doesn't know that them and assume they can be deleted.

from deconz-rest-plugin.

Connection to the hue bridge should now be established

Brilliant! I tried the (once secret) ZLL Master Key before, and failed, but the ZLL Link Key did the trick. Many thanks!

be aware that there might be unexpected behaviour since two commissioning tools try to control the network in different ways

For now, I'm just charting the ZigBee network using the RaspBee.

from deconz-rest-plugin.

Do I understand correctly that the ZLL Commissioning cluster is used only for touch linking? I see the Hue bridge has a client cluster and each light seems to have a server cluster.

from deconz-rest-plugin.

It's mainly used for Touchlink but it's also handy to query controlled groups from light switches. ZLL devices are required to have an server cluster.

from deconz-rest-plugin.

Here's an interesting little fact: In an attempt to get rid of any "ghosts", I bluntly deleted ~/.local/share/data/dresden-elektronik/deCONZ, shutdown and powered off the Rasberry Pi (so the RapsBee would reset), unplugged my Hue bridge from power. After powering on the RasPi, the deCONZ GUI naturally shows only the RaspBee, not in any network. It remembered the Network Settings, like PAN ID and Channel Mask (I suppose they're stored on the RaspBee's non-volatile memory?), except for the ZLL Link Key. After entering that, the RaspBee joins my network even while the Hue bridge is still powered off.
Did the RaspBee somehow store the network key or is this the doing of the ZLL Commissioning in the Hue lights?

Related question: obviously the network key is stored somewhere: after a reboot the RaspBee joins the network automatically. Is there a way to see what it is (so I can configure the RaspBee as coordinator, without having to re-commission all my devices)?

Thanks.

from deconz-rest-plugin.

Thats correct behaviour, the RaspBee as well as any other ZLL device store all network parameters like PANID and network key which are required to operate in the network in NVRAM.

When you open the deCONZ network settings most network parameters from NVRAM are visible there.

Reconfiguring the RaspBee from router to a coordinator in the same network is not recommended, because right now the network uses a distributed trust center (ZLL) and once the RaspBee becomes a coordinator it should serve as a trust center which would confuse some devices in the distributed trust center network. So I would recommend either to don't change RaspBee to coordinator or to reset devices and rejoin them to the fresh coordinator network.

from deconz-rest-plugin.

When you open the deCONZ network settings most network parameters from NVRAM are visible there.

Yes, but the Network Key shows all zeroes.

So I would recommend either to don't change RaspBee to coordinator or to reset devices and rejoin them to the fresh coordinator network.

Thanks, understood. I suppose the REST API wouldn't even know whether the RaspBee is a coordinator or router?
I've got 38 lights, 10 Hue motion sensors, 6 Hue dimmer switches and 2 Hue tap switches - joining all these to a different network for testing and then joining them back to the Hue bridge before it's dark is no fun. I'll keep the RaspBee as router for now.

from deconz-rest-plugin.

I can not connect the RaspBee as a Router to the Hue bridge ZLL network.
After saving the configuration:
press the Leave button
... and ZLL Link Key (81....B8) resets to the ZLL Master Key (5A...39)

from deconz-rest-plugin.

I've seen the same in recent deCONZ versions.

from deconz-rest-plugin.

Hmm, and what deCONZ version will work?

from deconz-rest-plugin.

The problem is not the application deCONZ but recent firmware versions for RaspBee/ConBee which were modified for IKEA and OSRAM issues; sadly lost the router ability.

Following not yet official firmware might work again (but I have not testet it as router yet).

deCONZ_Rpi_0x261a0500.bin.GCF.zip

from deconz-rest-plugin.

My RPI3 system is Raspbian GNU/Linux 9.1 (stretch)
I installed GCFFlasher as discribed in the RaspBee-BHB-en.pdf:

pi@raspbee:~ $ wget http://www.dresden-elektronik.de/rpi/gcfflasher/gcfflasher-latest.deb
--2017-11-01 08:56:23-- http://www.dresden-elektronik.de/rpi/gcfflasher/gcfflasher-latest.deb
Resolving www.dresden-elektronik.de (www.dresden-elektronik.de)... 84.19.195.242
Connecting to www.dresden-elektronik.de (www.dresden-elektronik.de)|84.19.195.242|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127384 (124K) [application/x-debian-package]
Saving to: ‘gcfflasher-latest.deb’
gcfflasher-latest.d 100%[===================>] 124.40K 490KB/s in 0.3s
2017-11-01 08:56:24 (490 KB/s) - ‘gcfflasher-latest.deb’ saved [127384/127384]

pi@raspbee:~ $ sudo dpkg -i gcfflasher-latest.deb
Selecting previously unselected package gcfflasher.
(Reading database ... 119931 files and directories currently installed.)
Preparing to unpack gcfflasher-latest.deb ...
Unpacking gcfflasher (2.10) ...
Setting up gcfflasher (2.10) ...

and got errors:

pi@raspbee:~ $ sudo GCFFlasher -f deCONZ_Rpi_0x261a0500.bin.GCF
/usr/bin/GCFFlasher.bin: error while loading shared libraries: libQtCore.so.4: cannot open shared object file: No such file or directory
pi@raspbee:~ $

pi@raspbee:~ $ sudo apt-get install -y libqtcore4
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
libuv1
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
qtcore4-l10n
The following NEW packages will be installed:
libqtcore4 qtcore4-l10n
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 2,028 kB of archives.
After this operation, 9,264 kB of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian stretch/main armhf qtcore4-l10n all 4:4.8.7+dfsg-11+rpi1 [662 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian stretch/main armhf libqtcore4 armhf 4:4.8.7+dfsg-11+rpi1 [1,366 kB]
Fetched 2,028 kB in 2s (949 kB/s)
Selecting previously unselected package qtcore4-l10n.
(Reading database ... 119933 files and directories currently installed.)
Preparing to unpack .../qtcore4-l10n_4%3a4.8.7+dfsg-11+rpi1_all.deb ...
Unpacking qtcore4-l10n (4:4.8.7+dfsg-11+rpi1) ...
Selecting previously unselected package libqtcore4:armhf.
Preparing to unpack .../libqtcore4_4%3a4.8.7+dfsg-11+rpi1_armhf.deb ...
Unpacking libqtcore4:armhf (4:4.8.7+dfsg-11+rpi1) ...
Setting up qtcore4-l10n (4:4.8.7+dfsg-11+rpi1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
Setting up libqtcore4:armhf (4:4.8.7+dfsg-11+rpi1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...

pi@raspbee:~ $ sudo GCFFlasher -f deCONZ_Rpi_0x261a0500.bin.GCF
GCFFlasher V2_10 (c) dresden elektronik ingenieurtechnik gmbh 2016/09/26
no device specified use RaspBee (/dev/ttyS0)
using firmware file: deCONZ_Rpi_0x261a0500.bin.GCF
Unable to determine hardware version. I see: Hardware : BCM2835
,

• expecting BCM2708 or BCM2709.
  If this is a genuine Raspberry Pi then please report this
  to [email protected]. If this is not a Raspberry Pi then you
  are on your own as wiringPi is designed to support the
  Raspberry Pi ONLY.

from deconz-rest-plugin.

Sorry I should have mentioned this, on Raspbian stretch the standalone GCFFlasher package is broken, it's on the todo list.

As workaround please use GCFFlasher from the deCONZ package as follows:

$ sudo GCFFlasher_internal -f deCONZ_Rpi_0x261a0500.bin.GCF

Note deCONZ must be closed before.

from deconz-rest-plugin.

still ZLL Link Key (81....B8) resets to the ZLL Master Key (5A...39)

from deconz-rest-plugin.

What old version of fw can i use?

from deconz-rest-plugin.

deCONZ_Rpi_0x26050500.bin.GCF seems to work, gets installed in /usr/share/deCONZ/firewall with the release version of deconz.

from deconz-rest-plugin.