Don’t edit the JSON. There’s no need. There’s a “Device Repair” repair tool that will appear in the Tools tab of your ReactorSensor when a broken device is detected in the configuration. That should work much better/easier.
Thanks for the suggetsions @rigpapa! Yesterday was the firts time I played with Docker, and openLuup for that matter, so your suggestions sounds interesting. I’ll wait for @vwout who has done the container to get back about storage location and any suggestions. It would in any case be nice to be able to backup the config/plugin files and be able to restore them if you need /want to upgrade the Docker image/container at some point. But if that could somehow be done via the GUI that would be really nifty.
Oooh, awesome! Big thanks for that!
It could easily. There’s nothing to stop you right now from pasting into a Lua Test string and writing it somewhere.
File writing comes with the risk of over-writing something important, though…
The easiest way is to use
docker cp <path to backup json on host> <openluup-container-id>:/etc/cmh-ludl/.
For this reason, and for easy plugin development, I’m using a bind to
/etc/cmh-lu/ (see https://github.com/vwout/docker-openluup/blob/master/docker-compose.yml#L25), so you can easily exchange files between the host and the container. In case of the Reactor backup, you would only have to copy the file to
/etc/cmh-ludl/ using an interactive console - unless, I don’t know if that works, Reactor also checks
/etc/cmh-lu/ for the backup json.
Reactor expects the backup file to be in the same location as
L_Reactor.lua, wherever that may be.
docker export relaxed_pascal > openluup.tar to get a dump of the filesystem of the running container. I wanted to see where I would find the Reactor files, but searching through the whole .tar file has only given me Reactor references in
devices.lua. both under the path
etc/cmh-ludl/openluup/. I could not find the file ‘L_Reactor.lua’, nor the Reactor backup file, in the archive.
I also tried modifying some Reactor logic (adding a blank sensor) and exported the file system again, but the size of the tar archive is identical. This leads me to believe that the files are stored in my docker volumes and the info/files are saved there. Running
docker volume ls gives me:
local openluup-backups local openluup-env local openluup-logs
Can I somehow access them / copy to them / see what is in them @vwout ? Or should I start from scratch and do something different? I currently run the following to start the container:
sudo docker run -d -v openluup-env:/etc/cmh-ludl/ -v openluup-logs:/etc/cmh-ludl/logs/ -v openluup-backups:/etc/cmh-ludl/backup/ -p 3480:3480 vwout/openluup:alpine
but I have also tried the following:
sudo docker run -d -v /volume1/docker/openluup-env:/etc/cmh-ludl/ -v /volume1/docker/openluup-logs:/etc/cmh-ludl/logs/ -v /volume1/docker/openluup-backups:/etc/cmh-ludl/backup/ -p 3480:3480 vwout/openluup:alpine
This command should bind the host file system folder to the docker container openluup folders, if I understand these things correctly, but it doesn’t work. The container just starts and then stops…
EDIT: Just a quick update; I just went ahead and tried running ran
sudo docker cp reactor-config-backup.json a22b6b7e32bf:/etc/cmh-ludl/. Reactor in openLuup now sees the new backup file and I can restore all of my logic. Happiness! Still feels like magic, and I’m not sure how much of a pain it will be if the Docker environment/container or NAS crashes one day, but for now it works.
Is there anyway I could do the reverse, i.e. copy EVERYTHING from a22b6b7e32bf:/etc/cmh-ludl/ to a folder on the NAS? Basically a manual backup that I could copy back in the future if I need to?
Thanks again for any input and/or suggestions!
In your Docker setup you are using volumes to preserve data. The volume
openluup-env is mounted at
/etc/cmh-ludl/. This means the files that are stored in
/etc/cmh-ludl are kept in the volume
openluup-env and not in the container created from the image
This is the reason why e.g.
L_Reactor.lua is not in the tar file created by
docker export - the export command does not export the contents of volumes.
The reason that you do see some lua files in
/etc/cmh-ludl/ in the tar file, is that my image contains openLuup. Upon mounting of new empty volume, Docker will copy the files of the mounted destination location, to the volume. New files that are added later, e.g. when you install the Reactor plugin, are stored on the volume and not in the container, nor (of course) does it modify the source image.
This also explains why using binds (
-v /volume1/docker/openluup-env:/etc/cmh-ludl/) fails openLuup to start properly. Unless you manually copied files to
/volume1/docker/openluup-env, this folder is empty and does not contain openLuup.
In contrary to new (empty) volumes, Docker does not copy the files from the destination directory to the binded filesystem.
To see which files are in the volume
openluup-env, mount it and run
ls. You can mount the volume to any container, but you can also start an interactive shell inside the openluup container that you started from
vwout/openluup:alpine, e.g. using
docker exec -it <id-or-name of openluup container> /bin/sh.
To backup the contents of
openluup-env, you also could mount the volume to a secondary container. An alternative is to mix mounts and binds. Use a volume mount for the openluup environment and binds for logs and backups:
sudo docker run -d -v openluup-env:/etc/cmh-ludl/ -v /volume1/docker/openluup-logs:/etc/cmh-ludl/logs/ -v /volume1/docker/openluup-backups:/etc/cmh-ludl/backup/ -p 3480:3480 vwout/openluup:alpine
(or add arbitrary other mounts to other locations)
When you now run the following command, the created tarball will be stored on your filesystem in
docker exec <id-or-name of openluup container> tar -C /etc/cmh-ludl/ -czf /etc/cmh-ludl/backup/openluup-env.tar.gz
Oh, this explains alot! I never had any openluup files in the directory. I thought it would be populated from the image/container.
Your run command mixing mounts and binds works great. However, when I tried running the “backup” part I don’t get the files:
sudo docker exec c49c8a6d1af1 tar -C /etc/cmh-ludl/ -czf /etc/cmh-ludl/backup/openluup-env.tar.gz
tar: empty archive
As a side note; I can now see files in the /volume1/docker/openluup-logs folder but nothing in the /volume1/docker/openluup-backups folder for some reason. But that can perhaps be because of no backups existing at this point…?
The openLuup backup is manual unless you write a scheduled scene which does it.
You can either select Backup Controller from the AltUI > More > Table Controllers page or Backup Now from openLuup console’s Utilities > Backups menu.
Thank you guys for the help and input!
I now have a much more reliable system than before. At this point I have not removed anything from my Vera Plus, just disabled all of the Reactor Sensors on it. Before the Vera Plus wanted to reload Luup in the middle of executing Reactor activities and although Reactor does a good job trying to resume running the activities, it wasn’t perfect, missing a lamp or two, or three most of the times. I haven’t noticed any such behaviour so far with openLuup handling the Reactor logic so I’m really happy.