After being a UDI user for just over a year now, I've noticed a few things with being involved with the hardware/software and the community.

- There is often excitement...and trepidation when new releases of IoX come out. I've seen the birth of 5.9.1, Matter support, and now 6.0.0 and eisy-ui. It appears that it's not rare that something doesn't quite turn out as expected and the update causes some users to not be able to reconnect with their controller, and require some extra manual steps (ie: pkg install ...) to get it working. In some cases it just fails and a ticket is needed. Other times there are some unexplained effects, like the "small filesystem" that a few of us ended up with on a Polisy.

- A few of us have more than one controller. Myself I have a eisy actually running things, and two Polisys. Sometimes it happens from having upgraded from one to the other, or by chancing upon a unit for cheap or free. I certainly enjoy have the two Polisys for experimenting. When a new release comes out, I'll try it on a test controller (Polisy) first. It's a great, risk-free way of trying things out and learning about new stuff, like eisy-ui. Having the ability to reflash the SSD on a Polisy adds greatly to the "risks" we can take! I like to try things that would be quite foolhardy on a running system.

My reason for starting this thread is that I'd like to see what people are doing for backup. Not just file backups as we see in the menus, but actual operational backup, in case our main controller fails (failed upgrade or whatever). A lot of us have come to depend on our controllers, and having voice control with Alexa has often widened the user base to our families too. When things stop working, we quickly get called upon to "fix it!".

At minimum, A serious (read: highly dependent) user should at least have a spare PLM, and a spare power supply for the controller isn't a bad idea either. Having a spare controller is a bit more expensive, and moving our operations to another one when our main one fails isn't exactly a simple process. In fact that's the real reason I'm starting this discussion: does anyone have that kind of plan? How are you doing it, to be in a state of readiness? For the purpose of this discussion, let's stick to switching between eisy and Polisy (both: between same type of controller, or from one to the other). Several sticking points come to mind:

- Zwave: how do you backup zwave when you have a zooz stick? Is it included in the main IoX backup? The Zmatter dongle offers a backup/restore menu, but zooz doesn't. With Zmatter, is it as simple as moving the dongle over and restoring the zmatter backup? How about zooz? If you have a Zmatter dongle insie a Polisy, you'll need an adapter if you want to be able to quickly move to a eisy.

- Insteon: usually that just requires you to move the PLM over. But if you have a Polisy with a serial PLM, you'll need a USB to serial adapter.

- IP based connections: If you have plugins, network resources, and especially external devices or apps that send REST commands to your controller, It will be complicated if it ends up with a different IP address. To switch controllers, you'll probably have to play with your router's DHCP address reservations so that your replacement controller has the same IP address as the controller you're replacing.

- Portal access: The difficulty here is that portal subscriptions are based on your controller UUID. And that is based on the network card's MAC address. Even if UDI moves over your subscription to your new UUID, do you have to manually recreate all the device definitions? Or can UDI actually reassign all the definitions to the new UUID at the same time? This still means that you can't quickly move over to another controller, without external support.

- Plugins: This is probably the most complicated part, especially with paid plugins. I know that the plugins pathnames include the UUID of the controller. Can plugins be backed up and restored on a different controller without external intervention.

I think we have enough here for getting a good discussion going...

 

 

On 10/7/2025 at 4:22 PM, Guy Lavoie said:

My reason for starting this thread is that I'd like to see what people are doing for backup.

At the top level of just the file level of backup...since I will make random changes or programs to help others here just about anytime I open Admin Console I run a backup right away. That way I know I have a "that moment" backup to rever to if something I do goes south.

Otherwise, if it's just for personal change reasons I always make sure to make a backup after I make a change in something (either device setting or program change). Again, so I know I have a backup right then. 

All my backups are saved to a Dropbox folder so they're available on other computers I have so if my primary computer crashes the backups are available. 

On 10/7/2025 at 4:22 PM, Guy Lavoie said:

actual operational backup, in case our main controller fails (failed upgrade or whatever)

Operationally I have 1 backup PLM that is "NIB" (new in box) that I got from Insteon before they closed so it has a couple of years on it being in the box. I have a backup serial conversion cable in case my current cable from eisy to PLM goes bad.

I have a box of "spare" Insteon devices that would replace the most used devices in the house. It's not a large box, but it's enough to replace devices should they fail and get me back up and running quickly rather than having to order new from Insteon (again, from before their close when items were more difficult to source than they are currently). 

Z-wave - I only have a small number of devices in use that if they die they won't be replaced. They aren't mission critical currently and only used in random programs.

Zigbee - never got into this one. Only have one device and that's just a thermometer/humidistat device so if it goes south I'd probably never know. I only got it for testing Zigbee when it went live.

UD Portal - I'm not sure what you mean by having to recreate definitions if UD moves your license to a new UUID. I think they made a process that you can migrate the license to a new device and it does move everything over. If you have them manually move it then I do think you have to recreate everything. 

Gret thought and conversation start. I probably don't fit the mold of so many here that tend to have things so tightly integrated and reliant on commingling different systems. I'm no ultra power user, by any means. If my system went down (for a few hours, or days) I would be able to manually turn on any light in the house that I would need on (or off). My eisy and Insteon devices are more for convience and my automation is built around 7+ years of how we want our house to look/feel during the day and based on where we are in the house. It's not overly complicated and just works for us. 

You make an excellent point Guy. It is one thing to back up the logic using the Admin Console, but that doesn't help when the whole EISY is acting like a brick.

I faced that exact problem this week, trying to upgrade to 6.0.0. Fortunately, Michael came to my rescue, and we determined that the file system on the EISY was corrupt, but our home was without a functional EISY for three days. That presented a real problem because we use the EISY for a lot more than just turning on a few lights. It manages our water system levels, our irrigation system and our Z-Wave lock and access system. Had the EISY not been recoverable, I wouldn't have been able to get one for about a month, as I live in Canada and having no automation at all for that time would've had a significant impact on our life (and plants).

I'd really like to see a bit of documentation on how to back up and recover an entire EISY system. Like you suggest, I have a spare PLM (too many of those have failed over the past 20 years), and a spare power supply for the controller. However, I'm reluctant to purchase a full EISY to have it sit in a box for a decade. I'm also unclear how I migrate over the various plug-ins I've purchased over the years and if I need a separate backup for my Z-Wave dongle.

Does anyone feel like starting some commentary on any one of those backup subtopics? Or discuss the design of a hot backup system with a primary and secondary ISY in hot standby (frankly, I doubt that is possible, but I'm curious if anyone else has this)?

43 minutes ago, WhiteHat said:

I'd really like to see a bit of documentation on how to back up and recover an entire EISY system. Like you suggest, I have a spare PLM (too many of those have failed over the past 20 years), and a spare power supply for the controller. However, I'm reluctant to purchase a full EISY to have it sit in a box for a decade. I'm also unclear how I migrate over the various plug-ins I've purchased over the years and if I need a separate backup for my Z-Wave dongle.

Does anyone feel like starting some commentary on any one of those backup subtopics? Or discuss the design of a hot backup system with a primary and secondary ISY in hot standby (frankly, I doubt that is possible, but I'm curious if anyone else has this)?

Well I've made some interesting progress in backup strategy. The fact that I have two Polisys (and the hardware necessary to reflash their SSDs) for testing allowed me to try some of the riskier things that I wouldn't do on a single system that's actively in production. The first was to do a full file backup (unix, IoX, plugins... everything) to a USB stick, and then use that to "clone" the Polisy I took it from to the second Polisy. Worked great. This involves connecting by ssh and running unix commands. This type of backup is good when you're about to do a major change, like an upgrade to a new IoX version, especially if it also upgrades the version of FreeBSD. This has been the case with 6.0.0.

Before doing any of this: Please... UDI provides truly great support (almost to a fault, if we think that we can try risky stuff because at worse, they can always bail us out). At minimum, you need to be confident with using unix commands, and be ready to recover using one of their supported methods if you get into trouble doing this (like buying their recovery USB stick). As the saying goes: a lack of planning on your part does not necessarily constitute an emergency on their part. UDI gives us an amazingly open product and great support. Don't abuse it!

That said, here is my procedure for making a full cpio unix backup of a controller. Cpio is the name of the unix command (means copy in and out) that we use here. I know that most people use "sudo" commands for this kind of thing. I've worked with unix since 1985 and was used to doing everything in straight "root" login. Sudo didn't exist back in the day! Yes, I'm an old dinosaur. Try it with sudo commands if you feel better doing it that way. To get to a root prompt, login with ssh the usual way (admin@polisy.local) then do:

sudo sh

and when prompted for a password, enter the admin password. You should then get the "#" prompt.

Ok, you'll need a USB stick. I bought some 32 GB sticks for this. First you need to create a filesystem on the stick, partitioned as a single large partition:

- insert the usb stick and view disk devices:

# geom disk list

- note that da0 is the usb stick, should show brand and size.

# gpart destroy -F da0

da0 destroyed

# gpart create -s GPT da0

da0 created

# gpart add -t ms-basic-data da0

da0p1 added

# newfs -U /dev/da0p1

Now you have a mountable filesystem that you can copy files to. cd to the root directory (cd /) and create a directory that will be a mount point with a filename that you won't find anywhere else in the system, to make it easy to find in a list.

# mkdir abcxyz

Finally, mount the usb stick:

# mount /dev/da0p1 /abcxyz

Verify that its mounted, using just the mount command. You can also see the storage capacity using the df command, which will show you the number of blocks available on both the SSD and the mounted USB stick.

# mount

# df

In unix, filesystems are mounted as subdirectories to the root filesystem. This makes file operations between physical media seamless. It's just another directory.

Ok, now for the cpio backup. The trick is to create a file list of everything on the root filesystem, and then have the cpio command get the names of the files to backup from the list. The reason for this two step process is because we need to make a list from the root filesystem, which will by default include the subdirectory where the USB stick is mounted. We then want to edit the list to remove that directory from the file list because if you don't then the backup will try to backup the backup itself, recursively, like a snake eating it's own tail. So create the file list from the root directory, using a unique file name:

# cd /

# find . -print >/tmp/file_list

Now use the vi editor to remove the mount point directory from the file list. Delete any lines that begin as "./abcxyz" in the file, and save the file. Then launch the actual backup, which will back up everything into a single large file with a name of your choosing:

# cpio -ov >/abdxyz/my_pre_upgrade_backup </tmp/file_list

This cpio command redirects it's standard output to the /abcxyz/my_pre_upgrade_backup file, and redirects it's standard input from the file list we created earlier. the "o" option means output, and the "v" option means verbose, which means it will display the file names it's backing up to the screen (technically, to the "error output" file descriptor). You'll see hundreds of file names scroll by. Once it's finished and you're back to the root prompt.

You can verify the presence and size of the backup file:

# ls -l /abcxyz

You then need to unmount the USB stick, using the umount command:

# umount /dev/da0p1

You're done!

Now suppose that digital armageddon occurs and you need to restore your system. You at least need to get back to a unix shell prompt. This could involve reflashing the SSD, or connecting a keyboard and screen to a eisy because networking isn't working. Whatever. The first thing you need to do is recreate the mount point if it got lost as part of the disaster:

# mkdir abcxyz

Now insert and mount the usb stick:

# mount /dev/da0p1 /abcxyz

Verify that its mounted, using just the mount command. All ok? So now make sure you're in the root directory and logged in as root, because this is going to be a real smash! Cringing is permitted! (remember, I did this on a test system that I could reflash). Launch the restore:

# cpio -ivumd </abcxyz/my_pre_upgrade_backup

Aside from the obvious "i" for input and "v" for verbose options, "u" means unconditionally overwrite same name files, even if the existing file has a newer modification time, "m" means write back the original modification times that the files had when backed up, and "d" means create any directories needed for the files to restore.

This will totally overwrite everything, unix and all, with the files from the backup.

Once your back to the root prompt, reboot the controller:

# reboot

Your controller should be back to how it was when you backed up. Don't use this procedure to change controller types (eg: Polisy to eisy, or other way around) as some files would be different. We're talking about a backup here, not a migration. Also, if you're restoring to a different physical controller, the UUID of the old controller will not be carried over to the new one. The UUID is generated by the startup process, extracted from the controller's network card MAC address.

Once again: this is for your information only, and use at your own risk, And...if something happens where you think you'll need UDI to help you, well this isn't the kind of procedure they support. Be ready to reflash your SSD from a image file they provide before getting them involved.

On the bright side, I've done this a couple of times and it's worked well 🙂


PS: cpio is a great tool for copying unix directory trees, when multiple files and directories are involved. If you don't need to copy to a subdirectory to your current one, but rather to a directory above or beside yours. You don't need to do the two step directory list thing. Here is an example: suppose you're working on a plugin and you want to make a copy of all the files in it to a new directory as a backup, because you're about to make big changes to it. Let's say that your plugin's home directory is "/home/admin/workspace/plugin-dev/myplugin" and you want to copy everything in it to a new directory: "/home/admin/myplugin_save".

Begin by creating the new directory you want to copy to:

# mkdir /home/admin/myplugin_save

Now position yourself in the directory to want to copy:

# cd /home/admin/workspace/plugin-dev/myplugin

Make sure you're in it, using the pwd (print working directory) command:

# pwd

Once that's confirmed, copy everything over to the new directory with the magic cpio command:

# find . -print | cpio -pduv /home/admin/myplugin_save

Verify that everything has been copied to the new directory 🙂

Edited Monday at 12:50 AM3 days by Guy Lavoie