Openluup - verabridge can not load devices.

[a-lurker]

"Verabridge has a CloneRooms variable which should be set to true to force all bridged devices to be in the same rooms as on the remote Vera. Devices which are in "No Room" remotely, are placed in the appropriately named "MiOS..." room which corresponds to the remote machine name."

Noting the above: OpenLuup has moved all the remote Vera devices from the correct rooms (where they have resided for years) to the MiOS-xxxxx room. I think it was caused by a power outage and it may have been some problem with the Vera and openLuup RasPi subsequently rebooting at different times (possibly).

The CloneRooms variable is set to true. Did a couple of openLuup restarts but the remote Vera devices stayed in the MiOS-xxxxx room. Note that on the Vera all devices are still in their correct rooms that are mirrored in openLuup. They are not in "No room" on the Vera.

Any idea on how to get the all remote Vera devices out of the MiOS-xxxxx room and back to their correct rooms in openLuup?

[akbooer]

This is caused by openLuup restarting and then unable to find Vera (which would be slower to start.)

I thought this was fixed previously. You can obviously manually move them, but I assume you have too many. If you have no openLuup scenes on which they are dependent, you can simply delete them, reload, and all should be well.

[akbooer]

…or you could simply restore openLuup from your last, recent, backup?

[a-lurker]

I can do both of the above - will probably use the backup, but just wanted to make sure I knew what was causing the issue. Clearly openLuup runs to fast. Another approach, besides a battery back up, could be to use systemd to control when openLuup starts. However I have little experience with systemd. Possibly someone has some idea on how systemd can make sure all remote Veras are up and running before openLuup starts? Or maybe that's something it would not typically be used for.

[akbooer]

I’ll look more closely at the bridge code to check a few things. It’s not as though this always happens, though, so it may be a bizarre combination of things.

[Buxton]

@a-lurker There's a systemd example in the openLuup user guide. Here's my startup based on those directions

[Unit]
Description=openLuup and AltUI Server for Vera 
After=network-online.target
After=sockproxy.service
Wants=network-online.target

[Service]
Type=forking
ExecStartPre=/bin/sh -c 'until ping -c1 <VeraIP>; do sleep 1; done;'
ExecStartPre=/bin/sleep 30
WorkingDirectory=/etc/cmh-ludl
ExecStart=/bin/bash /etc/cmh-ludl/openLuup_run.sh
ExecStop=/bin/bash /etc/cmh-ludl/openLuup_stop.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

"Wants=network-online.target" makes sure the network is up. Then the ping command loops until a response is sent back from the vera. Followed by a 30 second sleep to allow everything else to get up and running. However, no vera up-- no openLuup as the ping does not time out.

Your router must allow ICMP between the vera and the OL host. Per the OL help file, you then need to create the .sh files and then activate the systemd service. I use Patrick's sock proxy for an app, so that command does not need to be in there if you don't use the proxy.

[a-lurker]

akbooer thanks for the help. I seem to have it sorted out now. I do note that in the console/utilities/backups, that if you click on one of any the backups listed, a *.json file is presented for download rather than a *.lzap file. Not that it matters, as openLuup_reload seems to take either file type as a parameter and handle it accordingly. Like wise if you click on the "Backup Now" button, you a presented with a file that begins with "backup_backup.openLuup ...." Looks like the backup directory name has been prefixed to the filename. Not that matters either. A back up is a back up.

[a-lurker]

Buxton . Yes I think I should be using systemd. Currently I'm using rc.local for start up. Thought you were rather optimist using just a 30 second delay after being able to ping Vera!!!

Could you please post your openLuup_run.sh and openLuup_stop.sh scripts.

Thanks for the feedback.

[akbooer]

@a-lurker said in Power outage and all the Vera devices were moved to room MiOS-xxxxx. How to fix?:

Looks like the backup directory name has been prefixed to the filename.

Thanks for that. Yes, same for me. I will fix it.

However, when I download, I get a .lzap file, not a .json one. What system are you using to download?

EDIT:

Actually, I only checked the .lzap file for an actual live backup, not from the list of previous backups. This may be the difference.

[Buxton]

@a-lurker Yeah, HA takes a couple of minutes to fully start, so 30 seconds is the bare minimum I could get away with on my system. Not to mention the host server's atom processor, while parsimonious on power use, is a dog when ten containers are starting up from boot. Luckily, power outages here are infrequent. When prices are right, I'll get a home battery/solar setup to eliminate that rare nuisance.

Place in "/etc/cmh-ludl"

openLuup_run.sh

#!/bin/bash
echo "Starting openLuup server"
echo "To see tail of logfile: tail -f ./out.log"
cd /etc/cmh-ludl
sudo rm /etc/cmh-ludl/logs/out.log
nohup ./openLuup_reload >> /etc/cmh-ludl/logs/out.log 2>&1 &

openLuup_stop.sh

#!/bin/bash
echo "Stopping openLuup server"
echo "To see tail of logfile: tail -f ./out.log"
cd /etc/cmh-ludl
curl http://localhost:3480/data_request?id=exit

Then start the "openluup" service with:

$ sudo systemctl enable openluup
$ sudo systemctl start openluup

[a-lurker]

@Buxton OK got the systemd stuff working - thanks for that. A of couple notes for future readers:

• The script files need to be executable, so the permissions should be set to 0755.
• the scripts should use \n, not \r\n line endings ie Unix style
• you need to run this once to get the necessary symlinks built:

sudo systemctl enable openluup