Openluup - verabridge can not load devices.

[RogerO]

I should clarify my last statement of "getting it to work". What I was referring to was getting past the error message and getting the ALTUI interface to load.
Here is the sequence of events from yesterday.

1. Deleted the cmh-ludl directory that I had originally installed in the /home/pi path.
   Was having issues getting openLuup to run on startup based on the samples in the openLuup users guide. (more of a windows guy than linux).
2. Created a cmh-ludl in /etc, so that the install point matched the scripts in the doc.
3. Ran sudo lua5.1 openLuup_install.lua which installed the v19.12.27
4. Based on comments in thread added "development" to Update dialog box and ran update script. That completely broke everything. openLuup would not load.
5. Tried to copy openLuup files from github to my RPI. That didn't work either.
6. Reran sudo lua5.1 openLuup_install.lua and it installed the 20.5.1 version (at least that is what it says on the plugins page).

So the current state is that ALTUI runs. I can control a few switches through my Vera from ALTUI. The majority of my devices are displaying the generic z-wave icon and have no control buttons.
In devices, VeraBridge has a red title bar even though I can control it.

When I try to run the GetVeraScenes action I get this in the LuaUPnP log:
"2020-05-03 09:36:17.169 luup_log:5: GetVeraScenes action called
2020-05-03 09:36:17.374 openLuup.server:: request completed (2581 bytes, 1 chunks, 16755 ms) tcp{client}: 0x29334d8
2020-05-03 09:36:19.706 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=463507015&Timeout=60&MinimumDelay=1500&_=1588522721664 HTTP/1.1 tcp{client}: 0x29334d8
2020-05-03 09:36:30.267 openLuup.io.server:: HTTP:3480 connection closed EXPIRED tcp{client}: 0x237b8d8
2020-05-03 09:36:30.469 openLuup.io.server:: HTTP:3480 connection closed EXPIRED tcp{client}: 0x21da810
2020-05-03 09:36:30.470 openLuup.io.server:: HTTP:3480 connection closed EXPIRED tcp{client}: 0x2a04e58
2020-05-03 09:36:30.470 openLuup.io.server:: HTTP:3480 connection closed EXPIRED tcp{client}: 0x24e02a0
"
When I run GetVeraFiles I get a bunch of these:
"2020-05-03 09:39:19.118 openLuup.client:: WGET error status: 503, request: http://192.168.0.143/port_3480/D_ReactorSensor_UI7.json
2020-05-03 09:39:19.118 luup_log:5: ERROR: D_ReactorSensor_UI7.json
2020-05-03 09:39:19.121 openLuup.client:: WGET error status: 503, request: http://192.168.0.143/port_3480/D_DelayLightTimer.xml
2020-05-03 09:39:19.122 luup_log:5: ERROR: D_DelayLightTimer.xml
2020-05-03 09:39:19.129 openLuup.client:: WGET error status: 503, request: http://192.168.0.143/port_3480/D_VenstarColorTouchThermostat1_F.json
2020-05-03 09:39:19.129 luup_log:5: ERROR: D_VenstarColorTouchThermostat1_F.json
2020-05-03 09:39:19.133 openLuup.client:: WGET error status: 503, request: http://192.168.0.143/port_3480/I_DelayLight.xml
2020-05-03 09:39:19.133 luup_log:5: ERROR: I_DelayLight.xml"

I can, however, paste this, http://192.168.0.143/port_3480/I_DelayLight.xml, in the browser on my RPI and it returns the xml data.

Thanks for your assistance.

[akbooer]

Ok, that's lots to go on.

I've just done a completely fresh install on a RPI of the development system (crrently v20.5.3, actually, but no material difference from what you're trying.) Donwloaded all files successfully from a Vera Edge, running 7.30.

I think that, at this stage, I'd like a copy of the startup log and the main log after a restart.

In addition, the listing provided by the openLuup console Startup page would be of use:

http://openLuupIP:3480/openLuup?page=startup

I'm worried by the red banner on the VeraBridge device.

[RogerO]

Here is the startup page:
Plugin Startup Jobs CPU usage (in startup order)

date / time device priority status hhss.sss job # info notes

1 2020-05-03 13:17:38.558 2 1 Done 0.004 1 plugin: openLuup sync in 21.9 s
2 2020-05-03 13:17:38.559 3 3 Done 0.000 2 plugin: Alternate UI
3 2020-05-03 13:17:41.731 5 5 Abort 2.793 4 plugin: VeraBridge ./openLuup/loader.lua:476: Implementation XML root element name is not 'implementation'
4 2020-05-03 13:17:41.847 6 5 Done 0.008 5 plugin: Z-Way OK
5 2020-05-03 13:17:41.848 4 Done 0.001 3 plugin: Alternate App Store OK

Link for log files sent via chat.

[akbooer]

OK, straight-forward error. How did you create the VeraBridge plugin? It doesn't have a correct implementation file. What do its device attributes look like?

[RogerO]

I I created the VeraBridge by going into the app - Plugins and clicking the update button.
altid
category_num 1
cpu(s) 2.793128
device_file D_VeraBridge.xml
device_json D_VeraBridge.json
device_type VeraBridge
disabled 0
id 5
id_parent 0
impl_file I_VeraBridge.xml
invisible 0
ip 192.168.0.143
local_udn uuid:d764c8cc-e932-55c4-478d-7aa05d83f3ea
mac
manufacturer akbooer
model
name VeraBridge
plugin
room 0
status -1
subcategory_num 0
time_created 05/02/2020 04:29:14 PM
altuiid 0-5
favorite false
dirty false

[akbooer]

There are several inconsistencies here.

• The startup page shows a failure to read the implementation file, yet the details in the startup log show that the VeraBridge plugin has started correctly.
• The VeraBridge version as reported at the end of the startup log (19.12.12) is not consistent with the version number of the openLuup system.

If you look in the cmh-ludl folder, and in its files folder, do you find any VeraBridge files? There should be none. The only findable VeraBridge file should be the L_VeraBridge.lua one in the openLuup folder (20.4.30). If there are any others, delete them.

I believe I know what went wrong, but the above should get you going OK.

[RogerO]

There is only one Verabridge file on the cmh-ludl folder or any of the sub's located in the openLuup folder. File header is:
BOUT = {
NAME = "VeraBridge",
VERSION = "2019.12.12",
DESCRIPTION = "VeraBridge plugin for openLuup",
AUTHOR = "@akbooer",
COPYRIGHT = "(c) 2013-2019 AKBooer",
DOCUMENTATION = "https://github.com/akbooer/openLuup/tree/master/Documentation",
DEBUG = false,
LICENSE = [[
Copyright 2013-2019 AK Booer

[akbooer]

OK, this was overwritten because you updated it from the default (master) branch, rather than the development one. It’s entirely my fault that this is possible. Sorry.

Solution is to update openLuup from the development branch again. This should replace that file with the correct one. getVeraFiles should then work.

[RogerO]

How do I specify that? Of should I just write development in the update box for the plugins?
No worries about the issue. Glad to help finding it, and currently am just playing with it.

[RogerO]

Got it. Thanks for your help.
Plugin Startup Jobs CPU usage (in startup order)

date / time device priority status hhss.sss job # info notes

1 2020-05-03 15:22:33.769 2 1 Done 0.004 1 plugin: openLuup sync in 86.7 s
2 2020-05-03 15:22:33.770 3 3 Done 0.000 2 plugin: Alternate UI
3 2020-05-03 15:22:39.200 5 5 Done 4.403 4 plugin: VeraBridge OK
4 2020-05-03 15:22:39.293 6 5 Done 0.008 5 plugin: Z-Way OK
5 2020-05-03 15:22:39.294 4 Done 0.001 3 plugin: Alternate App Store OK

[RogerO]

I am still getting a lot of 503 errors and have quite a few devices from Vera that do not have all the controls present and functioning. Any ideas on why that might be happening?

[akbooer]

Perhaps Vera just can’t keep up, although I’ve never seen this before.

Are these always the same files, or are you incrementally getting what you need? I really don’t know what to suggest for this one... anyone else seen anything like this?

Which devices are not working? If it’s not too many, you can manually download.

Alternatively, you can add a parameter to the GetVeraFiles request in the form of a Lua search pattern.

For example

Binary

will download all files with "Binary" in the name.

[rafale77]

Granted I am not using vera anymore, for the couple of years I have used the vera bridge, no, I have not seen this.
I was actually wondering the same thing: Did something in the recent vera firmwares attempt to block files upload.
Or is the socket of openWRT just overwhelmed by the command frequency?
Also @RogerO, what is between your vera and the openLuup machine? Wondering if you are having LAN packet losses.

[RogerO]

I have been running the getfiles job specifying file types and I am seeing more devices that have the correct controls now. I am still missing most of the icons on the devices
Here is a breakdown by device type:.
Dimmable Switch: controls working, all have generic icon regardless of level and state.
Door Lock: Controls working. Generic icon
HVAC: controls and icons correct
Light Sensor: lux readings correct, generic icons
On/Off switch: Controls working, generic icons except Harmony Control
Motion Sensors: controls working, generic icons except for reactor
Temp sensors: functioning, generic icons.
So it looks like everything is functioning, just some icons are not displaying.
Which file has the icon description?
max packet size ping test between Vera and RPI
ping 192.168.0.143 -s65507
8 packets transmitted, 8 received, 0% packet loss, time 7009ms
rtt min/avg/max/mdev = 12.750/12.915/13.079/0.157 ms

[rafale77]

The D_XYX.json controls the icons display. I suspect though that you are missing the icon file which is buried in the /www folder of the vera and has been moving around from version to version of firmware and might be what is failing?

[akbooer]

Yes, it’s possible that the icons are not found. The bridge does try downloading them from different places according to the firmware, but maybe that’s what’s gone wrong. A log file showing the GetVeraFiles activity would confirm that.

[RogerO]

Just picked dimmable lights as an example. Looking in d_DimmableLight1.json I see this in the first few lines:
"default_icon": "dimmable_light_default.png",
"state_icons": [
{
"img": "dimmable_light_100.png",

These files are on the RPI
pi@raspberrypi:/etc/cmh-ludl/icons $ ls dimmable
dimmable_light_100.png dimmable_light_40.png dimmable_light_80.png
dimmable_light_10.png dimmable_light_50.png dimmable_light_90.png
dimmable_light_20.png dimmable_light_60.png dimmable_light_default.png
dimmable_light_30.png dimmable_light_70.png dimmable_light_off.png

But I am only getting the generic z-wave icon in the UI

[akbooer]

Is there a file ownership issue? ie. can you actually see those files if you look for them through the openLuup server? I have seen this sometimes, depending on how openLuup is started at boot time. How DOES your openLuup startup work?

[RogerO]

Interesting, just noticed that the files on the RPI are 0 bytes. Let me see if I can figure out why.

[RogerO]

So I copied all the png files off my Vera and moved them into the /cmh-ludl/icons folder on my rpi. That fixed the bulb icons for dimmable lights and some of the others. I am still getting generic icons for binary lights. According to the json file it should be using the binary_light_default.png file. file is there in the icons folder and has the following permissions.
-rw-r--r-- 1 pi pi 683 Dec 13 07:44 binary_light_default.png
Looks the same as the dimable light png file that works
-rw-r--r-- 1 pi pi 909 Dec 13 07:44 dimmable_light_20.png
Are there other locations the app looks for to finds icons to use?