Caveats: This may not work for you, for reasons I haven’t envisaged. You should be able to save yourself. All care and no responsibility. Need to be able to use WinSCP or similar. Can make backups of the data_data.json file in openLuup. Need to be confident editing json files. Have an understanding of how to execute Linux commands. Have AltUI installed on your Vera. Know how to make a scene be triggered by a “watched” variable. This may all become redundant if akbooer ever automates this process somehow or changes openLuup in some unexpected way.
The openLuup Vera bridge conveniently mirrors Vera scenes, so they can be shown in AltUI, when browsing the openLuup server. We can make use of this functionality, to port Vera scenes to the openLuup environment.
- Triggers: Events vs watches:
openLuup does not use “Event” triggers. It instead (and quite rightly) makes use of “Watched” variables. On Vera you need to modify any scene that uses an Event trigger to use a “Watch” instead. These can be found via AltUI:
Using AltUI–>More–>Scenes: Use the table checkbox list and check “id”, “triggers”, “watches”, “lua”, “room”. Any scene that has a trigger (an Event) needs to be converted to use a watch. Make the appropriate changes to the scene(s)
It’s too complicated to explain the process here. Note that this needs to be done before continuing and one needs to be confident your set up is still functioning, as it should, before proceeding. May need a few days to make sure all is OK. If you can’t do this - then time to have a rethink about continuing.
- So one doesn’t get confused about what is what; make a record of the scenes used by Vera and the openLuup device:
Using AltUI–>More–>Scenes: Use the table checkbox list and check “id”, “triggers”, “watches”, “lua”, “room”
Set the display to show all scenes and sort the table by “id”.
Cut and paste the info into a text file; one file each for Vera and openLuup.
- Stop the openLuup server using this URL in your browser:
Web page will report:
requested openLuup exit at <date & time>
You can no longer access openLuup via the browser as you have just stopped the openLuup server. Plus openLuup is no longer doing any automation.
Back up the user_data.json file:
Just before openLuup stops, it writes out the most recent “user_data.json” file to “/etc/cmh-ludl”
Use WinSCP to copy this file to your PC of choice. MAKE A BACKUP OF THIS FILE somewhere.
If you can’t do this - then time to have a rethink about continuing.
Edit the file to copy Vera scenes to the openLuup environment:
Using you favorite text editor (that would be Notepad++) start hacking the json data.
Search for this including the brackets/braces:
This will be found very close to the end of the file. This is the start of the scenes array. Each scene and what is does is defined in this array, eg a single scene looks like so:
"name":"Scene sw momentary",
Two items to note:
a) scenes that are bridged have 10,000 added to the Vera scene id. So in the above, the Vera scene id is “25” since the bridged id is “10025”. If more than one Vera is bridged then 20,000 is added, etc, per Vera.
b) the “Lua” tag is in use for every bridged scene. The Lua code just runs the scene on the bridged Vera. See above.
Make the changes:
a) select the scene json text, eg as shown above, to be ported to openLuup and just copy it immediately underneath. Be very careful with the curly brackets and commas.
b) change the scene id to an id not being used by openLuup. Be careful to keep the double quotes in place. Your chosen new id will not be a number above 10,000 and will be unused by openLuup. Refer to you scene lists you made in section 2). Accidentally having two scenes with the same id is not a good idea.
c) the Lua json section, that calls the scene in Vera, must be replaced with the Lua used by the scene in Vera. This may be none, so an empty string would be used or it would be the Lua found in Vera. You can use the scene editor on Vera to find the Lua to copy into to place or you could directly access Vera’s “user_data.json” file (more complicated procedure not explained here). If the Lua may need to be re arranged to sort out any referencing problem after porting (user specific - you need to work this out)
a) don’t duplicate scene numbers
b) openLuup sorts the scenes by scene id, next time it writes out the user_data.json file. So the order of scene ids is unimportant when you do your editing. But of course, must still be part of the scenes array.
c) you can port one scene at a time or if feeling confident, as many as you like at the one time.
d) you may encounter some user specific problem that may need to be cleaned up using AltUI scene editor at a later stage.
e) it may not make sense to port some scenes depending on what they do (user specific). Think about what each scene does.
f) scenes will probably need to be altered to reference the Vera devices, especially Z-Wave devices.
Check the json file:
Use https://jsonlint.com/ or similar to be sure you have not introduced any parse errors into the json file.
Return file to openLuup hardware
Copy the changed “user_data.json” file back to “/etc/cmh-ludl”
8 ) Restart openLuup
Using WinSCP change the display so that it’s showing “/etc/cmh-ludl”. Execute this command:
Note that WinSCP looses access at this stage and you will probably have to log back in.
Using your browser navigate to: http://openLuup_IP_Address:3480/console?page=log&version=startup
Make sure all looks OK. Refresh AltUI and see if the scenes show up.
NOT working? Then stop openLuup, restore your “user_data.json” back up and restart openLuup. Have a rethink on how to proceed.
If the scenes appear you will now have the original bridged scenes and your new local copies in openLuup. Delete the unwanted scenes in Vera. Restart the Luup engine in Vera using: AltUI–>Misc–>Reload_Luup_Engine. Refresh the Vera browser page. Now do the same for the openLuup. The Bridge plugin will see the scenes are no longer in Vera and will change its mirroring, so they no longer appear in the openLuup browser page.
All may need tinkering to get all this to work.
NOTE you can use the same concept for porting devices but there are definitely extra steps that need to be completed to do so. Perhaps in another post.