Replace Raspberry Pi

[McCass]

I've been running Domoticz on a Raspberry Pi 3B for 4 years and would like to replace the hardware.
Is there an instruction for replacing the Raspberry Pi and moving Domoticz (including database)?

[Sjonnie2017]

You might want to consider running Domoticz in a Docker container on the hardware of your choice. I have my Docker Domoticz container running on an Intel machine running Debian 11 (Bullseye). Once up and running you can create a backup of the Domoticz database on your Pi and restore it in the Domoticz instance on Docker. Connect your hardware to it (i.e. Zwave, Zigbee or other hardware) and you are ready to go.

[McCass]

OK, that's a complete new subject for me. I have to study that. Thanks for the information.

[RedEarth]

Using docker isn't essential for migrating a domoticz installation to be RPi hardware, you could probably do it by just backing up the database on the old hardware, create a clean domoticz installation on the new hardware and then restore the database backup into the new installation. You might need to tweak some settings to get things working in the new installation depending on what hardware integrations you use but it should be pretty straightforward.
This is the approach I took when I moved domoticz from a Synology NAS to an RPi, and it was all pretty simple.

[waltervl]

I've been running Domoticz on a Raspberry Pi 3B for 4 years and would like to replace the hardware.
Is there an instruction for replacing the Raspberry Pi and moving Domoticz (including database)?

Basic steps:
1. Install Domoticz on the new system.
2. Shutdown domoticz service on old and new system
3. Copy domoticz.db from old to new system.
4. Copy external scripts and plugins (folder scripts and plugins) from old to new system.
5. Startup domoticz on new system.
6. Get hardware configurations (menu setup hardware) correct for USB devices as they probably have changed.

[lost]

I've been running Domoticz on a Raspberry Pi 3B for 4 years and would like to replace the hardware.
Is there an instruction for replacing the Raspberry Pi and moving Domoticz (including database)?

Basic steps:
1. Install Domoticz on the new system.
2. Shutdown domoticz service on old and new system
3. Copy domoticz.db from old to new system.
4. Copy external scripts and plugins (folder scripts and plugins) from old to new system.
5. Startup domoticz on new system.
6. Get hardware configurations (menu setup hardware) correct for USB devices as they probably have changed.

In 3, don't forget www/templates custom pages, if any was built! If using open z-wave, I would also add the Config/ozwXXX file restore to avoid rebuilding all device setup/discovery that takes time (up to latest battery device wake-up, or need to wake them up manually).

In case of other more specific stuff, this should be remembered by user (well, after several years??!!) and added.

Take care that if also upgrading Linux/raspbian, there may be some python 2 (Debian 10 was still using 2.7 by default) to 3 (Debian 11 moved to 3.9 default) adaptations needed if using some old python plugins/scripts. Usually 2to3 scripts will do a good job, but I had issues with python serial module (I use it to control an old serial-usb modem that was assigned the task to filter phone spam, hanging-up & down immediately if phone nb/range blacklisted, using it's AT command set through "serial" line) due to the fact default string type in python 3 is no more "bytes" but "str". And python serial (directly linked to HW using good old ascii) still use "bytes" type.

One question: Why changing the PI3B? I have one and Domoticz (plus some other stuff I use like FTP/Samba for IP cams, my own services linked to domoticz...) does not load it a lot! PI3 was also 1st 64bit PI hardware and raspbian 64bit (based on Debian 11) is now available and 64bit arm domoticz build can be used (that's what I did for 2022.2 upgrade from 2021.1). So this one is quite still future-proof. Only observed ~10% higher memory usage using 64 bit setup than previous 32 bit one. But as all was upgraded, difficult to say if it's really due to the 64bit versions move and/or domoticz/linux upgrades.

[McCass]

One question: Why changing the PI3B? I have one and Domoticz (plus some other stuff I use like FTP/Samba for IP cams, my own services linked to domoticz...) does not load it a lot! PI3 was also 1st 64bit PI hardware and raspbian 64bit (based on Debian 11) is now available and 64bit arm domoticz build can be used (that's what I did for 2022.2 upgrade from 2021.1). So this one is quite still future-proof. Only observed ~10% higher memory usage using 64 bit setup than previous 32 bit one. But as all was upgraded, difficult to say if it's really due to the 64bit versions move and/or domoticz/linux upgrades.

The PI3B is quit slow (maybe enough for Domoticz).
It runs since februari 2018.
Beside Domoticz I have Homebridge running.
And I have a PI4 which I could use for the job

[lost]

The PI3B is quit slow (maybe enough for Domoticz).
It runs since februari 2018.
Beside Domoticz I have Homebridge running.
And I have a PI4 which I could use for the job

If you experience latency using the Domoticz (web) interface, that's IMO most likely due to uSD storage being slow. If so, going to the PI4 may not solve the issue.

I experienced better reactivity on my PI3B after:

1) Changing the uSD card (former one was industrial, to avoid wear issues) to one labelled A2: A1/A2 are tuned for a smartphone use-case, so being used 24/7 (unlike video/photo devices that are only switched on during use for mostly sequential data accesses) for applicative (thus the A) data. So background operations (allowing better wear-leveling & perfs) can be enabled (would make no sense for a mostly off device use-case) & they are tuned for better random access performance (IO/s for A2 higher than A1).

2) Once you have a good/reliable uSD, you can change PI conservative MMC interface clock setting: Default is 50MHz, can be tuned up up to 100. My PI3 is set at 83MHz without issues since ~3 years. You'll need to change a file in /boot (can check on my system exact config if needed) and reboot.

3) Setting tmpfs (ramdisk) for some temporary data (heavy!) use I have on my system (captures from IP cam sent by FTP...), before processing them. Here a PI4 with >1GB (as PI3) may make more sense as this'll allow to increase tmpfs size if needed without risking going too low on available ram during runtime. My use-case almost never use more than 50% of available 1GB despite tmpfs use so PI3 is OK.

4) My PI is powered through a buffer battery, so no risk of power down. As a consequence, I tuned a few sysfs/memory management setup to allow more file-system cache & write merge: On system that are not battery backed, this may be at the expense of more data loss on a power fail but a journaled FS like Ext4 should not be broken anyway. As for 2, can check/publish my settings if needed.

2 and 4 alone may already be worth a check as this really meant better reactivity on my system.