search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 496 forks source link

Using (mobile) RaspBee to integrate more remote zigbee devices #247

Closed mathos77 closed 5 years ago

mathos77 commented 6 years ago

Hi, I have several Hue lights, including GU10 and Lightstrip.

For the latter, I am unable to bring them down to my NUC which has the Conbee stick.

Now, I have a brand new RaspBee, and was thinking about using that to reset and incorporate those lights into my ConBee network.

Is there any way to use that RasBee using the same (temporary) database I use for the ConBee, after stopping that one ?

Or maybe configure it differently so that it will just act as a router kind of thing ?

I have read this thread, but I am still struggling to get this to work. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/117

Any help is appreciated!

Kind regards, Tom.

manup commented 6 years ago

The simplest approach is to copy the database to the new device (deCONZ should not running at this point)

.local/share/dresden-elektronik/deCONZ/zll.db

It holds all rules, groups, names, .etc.

The devices still need to be reset and joined to the new network. If you have a Hue dimmer switch resetting the lights with it is most easy.

mathos77 commented 6 years ago

Thanks @manup,

I will try again with the RaspBee, somehow it did not hook into the original zigbee network, and just started a new one, even after I copied the DB. The stick works in the mobile Pi, but I want that to stay inside the NUC where it belongs.

I did stop de deCONZ setup on the nuc, copied the DB to the pi, in the /home/pi/.local/share/dresden-elektronik/deCONZ/ but maybe something went wrong.

I suppose I do not need to change any network ID and such ?

Kind regards, Tom.

manup commented 6 years ago

I will try again with the RaspBee, somehow it did not hook into the original zigbee network, and just started a new one, even after I copied the DB.

That's normal since both devices use their own ZigBee network, therefore it is required to move the devices from one network to the other by resetting the devices and join them to the new network.

mathos77 commented 6 years ago

I have successfully performed this now, by using the ConBee on the "mobile" rpi. I placed the stick back and took the new database to the NUC and it works like a charm.

So, let's say my conbee would die on me, and I would like to replace it. Does that mean that I would have to reset and relearn every single node again, rather than just adjusting a few params on a potentially new stick ?

manup commented 6 years ago

Nope for this particular case the backup feature should be used. it does literally clone the device (including mac address and security keys, ...)

It has a catch, two clones should not be used side by side since this would confuse the devices like hell.

mathos77 commented 6 years ago

@manup , just to confirm, the backup option within the Web UI, only exists within the Raspbian package. I did not see it before on the Ubuntu intel package, not even on 2.04.84.

This topic can be closed btw, although I am still uncertain if I can use the RaspBee, after restoring a backup from the ConBee, as a solution for this. (Noting that I would off course have only one of the Bee's active at the same time!)

manup commented 6 years ago

Good question yes I think the backup is only visible for RPi based gateways in the 'old' webapp.

mathos77 commented 6 years ago

@manup @ebaauw

Can you tell me how I would migrate my system from my ConBee to my RaspBee safely. This without having to grab all nodes manually again that is :)

I wish to use the conbee as a sniffer as Erik pointed out in a different thread.

Thanks!

ebaauw commented 6 years ago

I haven't tried this myself yet, but it's probably enough to copy manually the deCONZ Network Settings (notably MAC address, PANID, channel, and network key) through the deCONZ GUI. I would backup ~/.local/share/dresden-elektronik/deCONZ before trying this.

[Another (!) note to self: do the freaking restore test!]

As far as I can tell Backup does nothing more than create a gzip compressed tar file with:

$ pwd
/home/pi/.local/share/dresden-elektronik/deCONZ
$ tar tvzf deCONZ.tar.gz 
-rw-r--r-- pi/pi           686 2018-01-18 18:40 deCONZ.conf
-rw-r--r-- pi/pi        365568 2018-01-18 18:01 zll.db
-rw-r--r-- pi/pi         21823 2018-01-16 20:46 session.default
{
  "apsAck": false,
  "apsUseExtPanId": "0x212effff******",
  "curChannel": 25,
  "deconzVersion": "20499",
  "deviceType": 0,
  "endpoint1": {
    "deviceId": "0x5",
    "deviceVersion": "0x1",
    "endpoint": "0x1",
    "inClusters": [
      "0x19"
    ],
    "index": 0,
    "outClusters": [
      "0x500"
    ],
    "profileId": "0x104"
  },
  "endpoint2": {
    "deviceId": "0x1",
    "deviceVersion": "0x1",
    "endpoint": "0x50",
    "inClusters": [],
    "index": 1,
    "outClusters": [],
    "profileId": "0xde00"
  },
  "extPanId": "0x212effff******",
  "macAddress": "0x212effff******",
  "networkKey": "********************************",
  "nwkAddress": "0x0",
  "nwkUpdateId": 0,
  "otauactive": 1,
  "panId": "0x****",
  "securityMode": 3,
  "staticNwkAddress": false,
  "tcAddress": "0x212effff******",
  "tcLinkKey": "5a6967426565416c6c69616e63653039"
}
ebaauw commented 6 years ago

Did some more digging. Turns out you can start the backup from the API. This enables us to schedule automated backups!

$ ls -al .local/share/dresden-elektronik/deCONZ
total 56
drwxr-xr-x 2 pi pi  4096 Jan 19 11:45 ./
drwxr-xr-x 3 pi pi  4096 Sep 24 15:34 ../
-rw-r--r-- 1 pi pi  1528 Jan 19 11:39 config.ini
-rw-r--r-- 1 pi pi  1615 Jan 14 13:35 session.default
-rw-r--r-- 1 pi pi    35 Sep 24 15:34 zcldb.txt
-rw-r--r-- 1 pi pi 29696 Jan 19 11:38 zll.db
$ ph_post /config/export
success
$ ls -al .local/share/dresden-elektronik/deCONZ
total 64
drwxr-xr-x 2 pi pi  4096 Jan 19 11:46 ./
drwxr-xr-x 3 pi pi  4096 Sep 24 15:34 ../
-rw-r--r-- 1 pi pi  1528 Jan 19 11:39 config.ini
-rw-r--r-- 1 pi pi  5206 Jan 19 11:46 deCONZ.tar.gz
-rw-r--r-- 1 pi pi  1615 Jan 14 13:35 session.default
-rw-r--r-- 1 pi pi    35 Sep 24 15:34 zcldb.txt
-rw-r--r-- 1 pi pi 29696 Jan 19 11:38 zll.db
$ tar tvzf .local/share/dresden-elektronik/deCONZ/deCONZ.tar.gz 
-rw-r--r-- pi/pi           673 2018-01-19 11:46 deCONZ.conf
-rw-r--r-- pi/pi         29696 2018-01-19 11:38 zll.db
-rw-r--r-- pi/pi          1615 2018-01-14 13:35 session.default

Unsurprisingly, the restore is started by ph_post /config/import. It requires deCONZ.tar.gz to be in ~/.local/share/dresden-elektronik/deCONZ.

I did and export on my production Raspberry and stopped deCONZ. Then, I did an import on my test Raspberry. After the import, deCONZ restarted (or crashed - I'm not sure) and came back up with the test RaspBee now showing the production RaspBee's MAC address. The GUI is scaringly empty - it only shows the RaspBee. This is probably to be expected, as the RapsBee's neighbour table would be empty. I power-cycled some of my lights, and, indeed, they appear and respond. Of course power-cycling the light would also clear it's neighbour table as well, so only the power-cycled lights appear. After a good many minutes, some other lights begin to appear in the GUI. However, they're not responding, and turn red. My sensors and switches blink red (no ack from the new RaspBee), but continue to work directly on the lights that are not yet reachable. I'll try and stretch my patience to the max and leave it for now, but I fear you might need to power-cycle all your devices after a restore. @manup, do you have any insights here?

I did notice that, after import, the NWK Update ID is 5. In the deCONZ.conf of the backup, nwkUpdateId is 0.

Created separate issue for backup/restore.

manup commented 5 years ago

Closing the oldest issues for know to tidy up the tracker and duplicates in newer issues.