Export local data to move the gateway to another machine

Is it possible to export all data (rules, things…) so I can move the installation to another machine to provide more flexibility? Would the attached Conbee adapter cause problems in that case (I would of course move it to the new machine as well)?

You could do the following to move all of your data:

# From new machine
scp -r pi@gateway.local:~/.mozilla-iot ~/

Thanks, and then I just have to install the gateway on the new machine and start it and it should work like nothing happened right? (except of course the different host)

Yes, exactly! I do that quite frequently when reflashing my RPi.

Great, I liked the raspi setup (really quick), but I am a little concerned about the long term durability of a 24/7 attached SD card, so I am planning to move everything on a machine which also has BT and wifi (I am using a raspi 2), although I won’t be using the latter.
Do you have experience with zigbee hardware? Will I have to repair everything, and will it void my rules?

All of your Zigbee devices should still work just fine, as long as you’re using the same dongle.

ok that’s the plan, I have no use for more than one dongle at the time being.

Is this a safe way to back up everything into a .zip file?

sudo systemctl stop mozilla-iot-gateway.service
zip -r mozilla-iot.zip ~/.mozilla-iot/
sudo systemctl start mozilla-iot-gateway.service

(Stop the gateway first so that the sqlite database will be stable. Then make mozilla-iot.zip that contains the contents of .mozilla-iot. Then restart the gateway.)

Might need to do

sudo apt update
sudo apt install zip

if zip isn’t installed.

2nd question. Should we all be doing

sudo apt update
sudo apt upgrade

to keep Raspian updated? I didn’t know if doing this would break anything in the gateway.

Yes, that would be a good way to back things up.

As for updating… In theory, that’s a good idea. In practice, though, that can break lots of things. I’ve broken several gateways by doing that and have had to reflash.

Thank you. You just covered my next question. :slight_smile:

Why not boot from a network drive? This pretty much eliminates all the problems associated with SDCards, or so I have read, without much sacrifice in speed. I have been wanting to do this myself actually.

Booting from network would be a good idea, but I have a raspi 2 version ‘Pi 2 Model B v1.1’, and network model is supported only on 1.2 :frowning:

I finally tried to move my install to a docker machine; the backup went smoothly, but neither my timers, nor my datetime, nor my conbee II worked (everything was disconnected in my new machine).
As for the conbee the problem is obvious; the zigbee installs binary modules so direct move from raspberry to x86 is not possible; is there a way to reinstall the node_modules?
Datetime failed with errors at setup.by, because the directories were already there; lots of errors like this:
Target directory /home/node/.mozilla-iot/addons/date-time-adapter/lib/more_itertools already exists. Specify --upgrade to force replacement.

Timers simply failed because of:
timer-bf9b83a1b5244c0287f938a857f9b869 not found
I guess the id is recreated on the new install.

So, if I wanted to move to raspberry’s HDD I think I would still have the last 2 issues, but maybe not the first one (unless something else happen past the point of binary compatibility). Weirdly enough the rules editor seems to work ok.
TL/DR I can’t move my installation at the time being…

For the broken add-ons, I’d just recommend removing the corresponding directory from ~/.mozilla-iot/addons and reinstalling them via the UI.

For the timers, I’m not sure. Those IDs are stored in the database. Maybe try reinstalling that add-on as well?

Both problems (date time and zigbee) vanished after removing the directories.
But now I get this very strange error for zigbee and it doesn’t work:

SerialProber: timeout: deConz dongle not detected on /dev/ttyACM0
2020-01-01 16:30:54.237 INFO : zigbee: Serial ports that were found:
2020-01-01 16:30:54.283 INFO : zigbee: USB Serial Device 1cf1:0030 Vendor: dresden elektronik ingenieurtechnik GmbH Serial: found @ /dev/ttyACM0

I already checked and the user that is launching the container can read and write on the device (no permission denied errors)

It seems like your dongle is being a bit slow to respond. The code tries to probe the device but times out after 500ms. You could try modifying the timeout by doing the following:

  1. mkdir ~/.mozilla-iot/addons/zigbee-adapter/.git
  2. Edit ~/.mozilla-iot/addons/zigbee-adapter/node_modules/serial-prober/serial-prober.js
  • On line 96, change 500 to something longer. Maybe 2000. (see here)
  1. Save the file.
  2. Restart the add-on in the UI by navigating to Settings -> Add-ons, then clicking Disable and Enable for the Zigbee add-on.

Thanks for the help but it didn’t solve the problem; there seem to be no effect with the modification, even if I put 5000 or so…
But the migration itself probably went fine, it seems to be a problem with either the OS (Ubuntu 18.04 server) or docker, so I’d better file a issue on github for that; also it may be related to the fact that I am using a USB 3 port, where on the raspberry it’s USB 2 and the dongle works flawlessly on the raspi.


I just moved my IOT Gateway to a spare RPI 2B+ too using Docker on Raspian Lite Buster. The only difference is I inserted a 16G USB stick and mounted it in /etc/fstab. I restored the IOT backup into a sub-folder on the USB. Well see if it’s reliable and does not stress the SD card as much which was one of our concerns.

I too had DateTime problems, but in my case it failed because PIP was not installed by Raspian Lite by default. After manually installing it, DT updated and worked ok. My AEOTECH ZWave dongle worked without issues.

So, performing a zip as a backup and moving from an Ubuntu Laptop to a RPI 2B worked for me with only 1 issue.

I did have to manually fix the rules that contained DateTime states, but that was not too much of a problem…

Hope your module timeout issue was resolved…

thanks, in my case it was actually some sort of hardware issue with a specific usb 2 port…