Have you checked the logs for more information?

@therealdb said in Advice on Storing and Backing Up Bind Mounts - Docker:

Yeah, containers are a game changer for manageability.

I just have a /home/casa/containers (where casa is the user) where I have my configs/storage. Easy to backup/mirror. In case of disaster recovery, just copy everything and I'm ready. For consistency, I save my docker-compose file in the same dir. Restoring a container is very easy.

Perfect thats exactly what I was thinking of doing! Since I am using Portainer their equivalent of Docker Compose is Stacks and Portainer has a handy built in GUI back up feature which backs all that up. Just need to figure out how to automate it and store it off the host for easy future retrieval.

@toggledbits said in Advice on Storing and Backing Up Bind Mounts - Docker:

@therealdb is spot on here. I do something very similar. His last point, having the docker-compose file with the volatile data, is particularly important to speeding recovery. Another tip: practice doing recovery, and write yourself a text file in the same directory with the steps to do it, so when it happens, you're not (a) doing it for the first time, or (b) trying to remember what worked two years ago.

As a side note, in a past life, I wrote a "high availability" subsystem for a routing product -- software that ran on a master system and a number of hot standbys that would bring up a standby quickly when the master failed. I have often thought about doing that for Reactor, but always conclude that our world doesn't really demand that level of response, no matter how "cool" it may be. It's so easy and quick to recover containers, I feel like lt's good enough, and my time is better spent on other features.

I did actually already kinda do a practice recovery to make sure Docker was the right choice for me. I used an old pi I had kicking around to tinker with to get familiar with Docker before doing a clean wipe and install of Ubuntu on my main driver. Transferred everything over from the old Pi to my main host (odroid N2+) and it was painless. On top of that I was also able to set up a few more containers that I wouldn't have otherwise set up because Docker is so damn easy.

In my lifetime with home automation I actually (*knocks on wood) haven't suffered a complete failure that isn't self inflicted. However I have moved hosts pretty often as my setup continues to grow in size and complexity so having Docker now will allow me to continue moving up without having to worry about spending countless hours trying to install packages via the CLI.

Hello all, after seeing Catman's posts about their disaster recovery and move to Docker I took that as a sign to migrate everything (aside from HA) to Docker. After a small learning curve I had Docker+Portainer up and running in a few days.

Instead of using named Volumes I opted to use Bind Mounts so I can easily edit conf files and any other file needed. I do understand the nuances that come with bind mounts, such as migration to a different host may require changing file structures, the possibility of someone editing the bind mount files and permissions but to me those aren't too big of a deal.

My question is what is the best way to keep a back up of these bind mounts? I currently have them stored in the /etc directory in another directory named on a per container basis. I was thinking to move it all to a /home/user/docker/ directory so that I can use a simple cp command to my mounted SMB share to backup all the container data files. Anyone else do it differently?

Side note: I finally got to flex the benefits of Docker with updating Reactor.. it was dead simple. I had no idea what I was missing out on lol!

@sammybizz there are quite a few options out there, best to look into what suits your needs best

Z wave and Zigbee switches are good starting place. They dont use wifi, but will require some sort of controller (think a router but for the switches) to connect the switches too and control them

If the IP addresses of one of the routers starts with a 192.XXX.XX.X then it is still under the same LAN network as the other router.

Also these Smartlife wifi switches are probably connected to the cloud so they will work anywhere you have internet, so even if they are somehow on their own LAN network you will still have access to them. That is unless you blocked internet access for them in your router's settings.

Welcome! What is the workshop router connected to, the main router or the modem? Your can have separate wifi networks, but the devices will all be under one LAN unless you set up something like a VLAN for your workshop router.

First I would check MSR logs to see if any errors are showing up and check. I would also check your controller logs as well

@christian_fabre Yes, but unofficially and utilizing the cloud. Company's like Ring (Amazon) notoriously block third party use of their APIs at random, so what may work now will not be guaranteed to work in the future.

Home Assistant will likely cover most of the devices, just not your Ring Doorbell

@therealdb Ahh i see then it worked for me, now I notice the changes

Hm tried this and Reactor didnt seem to change after restarting and hard refresh.. mind sharing a screeshot of what your Reactor looks like. Maybe I havent noticed the changes

Ha I obviously missed the first line in the release notes in my excitement for the dark mode.. also my update script also bit me in the ass here since it didn't run sudo npm i --no-save --no-package-lock --omit dev.

All seems to be working well now, no more needing to use sunglasses when switching over to my Reactor tab .

PS by stating my Linux version I was trying to show what version of Linux Reactor was running on and not the devices I was accessing the UI from.. so can't confirm that the UI shows correctly in Ubuntu

Bare metal.. forgot to add that

Seems like switching the UI to the newly added dark mode (thank you for this) does nothing. The UI stays in light mode and only a few buttons turn into dark mode (see screenshot)

Things I have tried:

Hard refresh
Different browser
Different computer
Restarting Reactor

Failed troubleshooting attempts:

No errors in Chrome console
No relevant errors in Reactor log (can still PM the full log file)

Reactor version: latest-24293-ea42a81d
Hardware: Odroid N2+
Linux version: Ubuntu 24.04.1 LTS

Dark mode enabled

Light mode enabled

@CatmanV2 Ahhh I see then it could be a faulty unit if the OEM remote doesn't work in IR mode!

I also had no clue Logitech still provided support for the Harmony products! Really wish they kept the Harmony line around, was a great product.

Side note if anyones interested, I did find a reasonable alternative to the Harmony its called The Remote 3 from Unfolded Circle. Much more expensive but the HW and SW looks to be much better than Harmony. I have one on pre ordered to see if these will eventually replace my 6 Harmony remotes. (sorry for the thread hijack )

Looks like this is a common issue with the V6 and you will have to set it up as a different device for it to work take a look at this thread

I am currently using the Zooz Zen32, I have about 4 scattered throughout the house. They are nothing remarkable, I do like how in recent FW updates you can now control the RGB light colours to show states of certain things. The buttons are definitely on the smaller side, especially for labelling. I am still trying to figure out a way to etch in the some labels on the buttons but have not come up with a solution yet. Functionality wise they work as you'd expect a scene controller to work so no issues there.

heres an example of what the service call should look like. I prefer to call services on the entity and not device. Have you also recently renamed the lock? Go to the lock in question and click it and take a look at the entity id, not the name.