AK,
The action “getverafiles”, need to be run only at the first install or we need to run it here and there when we have “new” files on the vera ?
I recently added a new Aeotec switch to my vera and after a bit it automatically appeared in the openLuup instance. Though I can’t tell you exactly how long it took.
Don’t know how I missed this over the holidays!
The action gets all existing device files from Vera. It’s probably overkill to use it to add just a few new ones, although it should work. I keep meaning to add a parameter which allows you to specify the device type to get. In the absence of that, I simply download the required files using the Vera UI, from the Develop App pages.
hey get vera file doesnt work for me it says
[quote=“RichieB, post:4, topic:197988”]hey get vera file doesnt work for me it says
[…][/quote]
Sorry to hear that. From the screen shot, this is actually what is expected. It should load remote device files into the files/ directory, and icons into the icons/ one.
Do those directories remain empty?
What messages do you get in the log?
nothing goes into the folders on my vera the files have a .vzo entention i even tried manually coping via SFTP but nothing actually gets copied and the files dont actuall load - it doesnt even reboot the luup engine
so as per usual i have been trying to get this to wrk for about 2 days, then as soon as i post in the forum the icons magically appear, so now im gonna wait to see if it will copy the device files
The Job log
Scheduled Jobs, Thu Aug 2 22:46:27 2018
# date time device status[n] info
1 2018-08-02 22:46:32 system Wait[12] job#201 :HTTP new connection tcp{client}: 0x1f6d330
2 2018-08-02 22:46:32 system Wait[12] job#202 :HTTP new connection tcp{client}: 0x1f6f3a8
3 2018-08-02 22:46:32 system Wait[12] job#203 :HTTP new connection tcp{client}: 0x1f71420
4 2018-08-02 22:46:32 system Wait[2] job#226 :HTTP new connection tcp{client}: 0x1d73818
5 2018-08-02 22:46:32 system Wait[12] job#204 :HTTP new connection tcp{client}: 0x1f73498
6 2018-08-02 22:46:32 system Wait[12] job#205 :HTTP new connection tcp{client}: 0x1f75510
7 2018-08-02 22:46:32 system Wait[12] job#206 :HTTP new connection tcp{client}: 0x15b9ad8
8 2018-08-02 22:46:32 system Wait[12] job#207 :HTTP new connection tcp{client}: 0x1cfd398
9 2018-08-02 22:46:32 system Wait[12] job#208 :HTTP new connection tcp{client}: 0x17c0a58
10 2018-08-02 22:46:32 system Wait[12] job#209 :HTTP new connection tcp{client}: 0x119f8b8
11 2018-08-02 22:46:32 system Wait[17] job#193 :HTTP new connection tcp{client}: 0x158ef30
12 2018-08-02 22:46:32 system Wait[1] job#232 :HTTP new connection tcp{client}: 0x212f980
13 2018-08-02 22:46:32 system Wait[17] job#182 :HTTP new connection tcp{client}: 0x1f9d0c8
14 2018-08-02 22:46:32 system Wait[17] job#186 :HTTP new connection tcp{client}: 0x160e830
15 2018-08-02 22:46:32 system Wait[17] job#190 :HTTP new connection tcp{client}: 0x1f81f68
16 2018-08-02 22:46:32 system Wait[22] job#163 :HTTP new connection tcp{client}: 0x156cc50
17 2018-08-02 22:46:32 system Wait[1] job#233 :HTTP new connection tcp{client}: 0x21319f8
18 2018-08-02 22:46:32 system Wait[17] job#183 :HTTP new connection tcp{client}: 0x1ba9910
19 2018-08-02 22:46:32 system Wait[17] job#187 :HTTP new connection tcp{client}: 0x1623ed8
20 2018-08-02 22:46:32 system Wait[17] job#191 :HTTP new connection tcp{client}: 0x1f83fe0
21 2018-08-02 22:46:32 system Wait[1] job#234 :HTTP new connection tcp{client}: 0x2133a70
22 2018-08-02 22:46:32 system Wait[17] job#184 :HTTP new connection tcp{client}: 0x146ebc8
23 2018-08-02 22:46:32 system Wait[5] job#223 :HTTP new connection tcp{client}: 0x18e7db0
24 2018-08-02 22:46:32 system Wait[1] job#231 :HTTP new connection tcp{client}: 0x212d908
25 2018-08-02 22:46:32 system Wait[1] job#235 :HTTP new connection tcp{client}: 0x2135ae8
26 2018-08-02 22:46:32 system Wait[17] job#185 :HTTP new connection tcp{client}: 0x1586678
27 2018-08-02 22:46:32 system Wait[17] job#189 :HTTP new connection tcp{client}: 0x1f7fef0
28 2018-08-02 22:46:32 system Wait[17] job#192 :HTTP new connection tcp{client}: 0x155c078
29 2018-08-02 22:48:00 0 Wait[4] job#51 :timer 'openLuup_ticker' (interval: time=2m, days={})
If it’s copied the icon files, then it should also have copied the device files. On Vera, these have a .lzo extension, as they are compressed, but the VeraBridge action copies uncompressed versions.
You should do a manual reload of openLuup, it will not do so automatically. You should also refresh your browser afterward to ensure it has all the information it needs.
The console Jobs listing you posted shows only incoming connections. To see what is really happening you need the full log from the logs menu, whilst the download job is running (or just after.)
However, it does sound as though all should be working now.
yeah it worked i was just being stupid and impatient, im sorry
Hi @akbooer,
What does the method do precisely? Does it overwrite existing files blindly? Can it potentially interfere with existing openluup files?
It’s corrupting my png files somehow and I now wonder what other damage could have been done to my existing openluup system.
It simply reads any .lzo (compressed) files in /etc/cmh-lu/ and /etc/cmh-ludl/ and copies them (uncompressed) to the files/ folder. It also gets .png and .svg files from various folders (depending on Vera firmware version) and puts them into the icons/ folder.
In both cases it overwrites any existing files of the same name.
It’s really design to be used as described in the user manual, at system installation time, to get a base set of files to get you up and running.
The best way to install new plugins (or update existing ones) is from the Alt App Store (or manually if not available from there.) I would never update a plugin on Vera and then use getfiles to transfer that to openLuup.
Ok, thanks for your answer. I wanted to get some plugin files from Vera, but the minute I did it I thought it wasn’t very smart.