Don't leave us hanging!! Show some pics of it in action. I need some Inspo to replace my Fire tablets as well that no matter what I do will randomly stop waking up

@toggledbits interesting, I totally understand the rationale why the controllers act this way. However, I feel like there are times where you’d want to batch update entities. Could this be added into the UI, similar to the purge dead entities action? Maybe an “update entity metadata” action?

@therealdb This did the trick thank you!!

Patrick, how should Reactor handle updated entity names and deleted ones for Z Wave JS? With HA it seems fairy instant with a restart that renames and deleted entities are updated but not the case with Z Wave JS.

Hello all.. been a minute! I recently rebuilt my Z wave network and migrated to a new z wave stick. In order to prevent any downtime I kept my original z wave network up and ran a docker version of Z Wave JS UI with my new controller. This way I could add device by device without having any devices down.

I finally moved all the devices over to my new stick today. The final step was to migrate everything from my Docker instance of Z Wave JS UI to the HA add-on of Z Wave JS UI. However during this migration some of the names didn't populate correctly which I later managed to import back into Z Wave JS UI. The issue was in Reactor it is stuck on the default names and the entities are not updating. I removed the controller from Reactor, restarted, hard refreshed, and added the controller back however the new entity names have not updated. Also it seems like the old entities from my previous instance of Z Wave JS UI are lingering and not being marked as dead (I believe a certain amount of time needs to lapse before they're marked as dead in Reactor).

My goal is to basically purge all the entities for the 'ZWaveJS' controller in Reactor so it can pull all the updated entity names and only the entities that exist in Z Wave JS UI. I cannot find a quick way to do this, I know entities can be deleted one by one, but with over 100 entities this would take long

I am guessing that if I added the controller with a new name in in the Reactor config it would pull the updated entities and names but I think that would break my rules since the entity IDs would change (I made sure to name all the entities the exact same as they were previously to prevent this issue).

Not yet!! I have been waiting for something with a little bit better audio, think Sonos level. Do report back though

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