Question: if you have devices in a Vera that are bridged to openLuup and then you delete some of those device off the Vera, then how do you tell Vera Bridge to update those virtual Vera devices in openLuup?
I've done this in the past and it just came good but I'm not sure how that occurred. I've tried a few Luup engine restarts to no avail.
EDIT: looks like it has come good, all by itself, once again. What's the functionality behind this?
Hello,
I have a fresh openluup install on a raspberry.
Just installed "Vera Bridge" plugin, but I can't make it to work.
The plugin can not load the device infos from the vera.
This is what I can see in the OpenLuup log :
openLuup.client:: WGET error status: -1, request: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1
I have tried it from a console on the same raspberry this way :
wget http://192.168.1.2:3480/data_request?id=user_data2&output_format=json&ns=1
It worked, so I think it's not credential or network issue.
What can be the solution for this ?
more openluup log :
408 lines, 1 error, max gap 61s @ 2022-08-12 20:51:01.568
2022-08-12 19:21:24.150 :: openLuup LOG ROTATION :: (runtime 0.0 days)
2022-08-12 19:21:24.154 openLuup.init:: init phase completed
2022-08-12 19:21:24.155 openLuup.io.server:: starting HTTP:3480 server on port: 3480 tcp{server}: 0x1c48ee8
2022-08-12 19:21:24.157 openLuup.io.server:: starting SMTP server on port: 2525 tcp{server}: 0x1b461d8
2022-08-12 19:21:24.158 openLuup.io.server:: starting POP3 server on port: 11011 tcp{server}: 0x1b48780
2022-08-12 19:21:24.158 openLuup.historian:: starting data historian
2022-08-12 19:21:24.159 openLuup.historian:: using memory cache size (per-variable): 1024
2022-08-12 19:21:24.168 openLuup.scheduler:: starting
2022-08-12 19:21:24.169 openLuup.scheduler:: [2] openLuup device startup
2022-08-12 19:21:24.170 luup_log:2: v22.7.31
2022-08-12 19:21:24.171 luup_log:2: sync in 35.8 s
2022-08-12 19:21:24.190 luup.variable_watch:: callback=housemode_watcher, watching=2.openLuup.HouseMode
2022-08-12 19:21:24.191 luup.register_handler:: global_function_name=openLuup_email, request=openLuup@openLuup.local
2022-08-12 19:21:24.191 luup.register_handler:: global_function_name=openLuup_images, request=images@openLuup.local
2022-08-12 19:21:24.192 luup.register_handler:: global_function_name=openLuup_events, request=events@openLuup.local
2022-08-12 19:21:24.192 luup.register_handler:: global_function_name=openLuup_mailbox, request=mail@openLuup.local
2022-08-12 19:21:24.193 luup.chdev.append:: [AltAppStore] Alternate App Store
2022-08-12 19:21:24.193 luup.chdev.sync:: [2] openLuup, syncing children
2022-08-12 19:21:24.194 luup_log:2: starting MQTT $SYS/broker statistics
2022-08-12 19:21:24.196 luup_log:2: 3Mb, 2.1%cpu, 0.0days
2022-08-12 19:21:24.211 openLuup.scheduler:: [2] openLuup device startup completed: status=true, msg=sync in 35.8 s, name=L_openLuup
2022-08-12 19:21:24.212 openLuup.scheduler:: [3] Alternate UI device startup
2022-08-12 19:21:24.212 luup_log:3: ALTUI: initstatus(3) starting version: v2.54
2022-08-12 19:21:24.214 openLuup.scheduler:: [3] Alternate UI device startup completed: status=, msg=, name=
2022-08-12 19:21:24.214 openLuup.scheduler:: [7] VeraBridge device startup
2022-08-12 19:21:24.215 luup_log:7: VeraBridge
2022-08-12 19:21:24.215 luup_log:7: 2021.01.03
2022-08-12 19:21:24.216 luup_log:7: 192.168.1.2
2022-08-12 19:21:24.216 luup_log:7: device clone numbering starts at 10000
2022-08-12 19:21:24.217 luup_log:7: VeraBridge maps remote Zwave controller
2022-08-12 19:21:24.218 luup_log:7: v21.1.3
2022-08-12 19:21:24.242 openLuup.client:: WGET error status: -1, request: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1
2022-08-12 19:21:24.242 luup.set_failure:: status = 2
2022-08-12 19:21:24.243 luup.variable_set:: 7.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 2 now: 2 #hooks:0
2022-08-12 19:21:24.244 luup.variable_set:: 7.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1660323316 now: 1660324884 #hooks:0
2022-08-12 19:21:24.246 luup_log:7: registering with AltUI [3] as Data Storage Provider
2022-08-12 19:21:24.247 luup.register_handler:: global_function_name=HTTP_VeraBridgeMirror_192.168.1.2, request=HTTP_VeraBridgeMirror_192.168.1.2
2022-08-12 19:21:24.249 luup.call_action:: 3.urn:upnp-org:serviceId:altui1.RegisterDataProvider
2022-08-12 19:21:24.260 openLuup.scheduler:: [7] VeraBridge device startup completed: status=, msg=No Vera, name=VeraBridge
2022-08-12 19:21:24.261 openLuup.scheduler:: [4] Alternate App Store device startup
2022-08-12 19:21:24.261 luup_log:4: AltAppStore : starting...
2022-08-12 19:21:24.262 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine1 was: AltAppStore now: AltAppStore #hooks:0
2022-08-12 19:21:24.263 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine2 was: now: #hooks:0
2022-08-12 19:21:24.264 luup_log:4: AltAppStore : v20.3.30
2022-08-12 19:21:24.264 luup.set_failure:: status = 0
2022-08-12 19:21:24.265 luup.variable_set:: 4.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.266 luup.variable_set:: 4.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.267 openLuup.scheduler:: [4] Alternate App Store device startup completed: status=true, msg=OK, name=AltAppStore
2022-08-12 19:21:24.268 openLuup.scheduler:: [5] Harmony Hub Control device startup
2022-08-12 19:21:24.280 luup.variable_set:: 5.urn:rboer-com:serviceId:Harmony1.LinkStatus was: Ok now: Starting... #hooks:0
2022-08-12 19:21:24.281 luup.variable_set:: 5.urn:rboer-com:serviceId:Harmony1.IconSet was: 0 now: 3 #hooks:0
2022-08-12 19:21:24.282 luup.attr_set:: 5.altid = HAM5_CNTRL
2022-08-12 19:21:24.326 luup.set_failure:: status = 0
2022-08-12 19:21:24.326 luup.variable_set:: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.327 luup.variable_set:: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.328 openLuup.scheduler:: [5] Harmony Hub Control device startup completed: status=true, msg=OK, name=Harmony Control
2022-08-12 19:21:24.332 luup_log:3: ALTUI: UPNPregisterDataProvider(3,Vera@192.168.1.2,http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2,[{
"default":"device.serviceId.name",
"key":"mirror",
"label":"Mirror",
"type":"text"
}])
2022-08-12 19:21:24.337 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... now: {"Vera@192.168.1.2":{"url":"http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2","callback":... #hooks:0
2022-08-12 19:21:24.360 openLuup.io.server:: HTTP:3480 connection from 192.168.1.24 tcp{client}: 0x1d21868
2022-08-12 19:21:24.363 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=323312852&Timeout=60&MinimumDelay=1500&=1660323303557 HTTP/1.1 tcp{client}: 0x1d21868
2022-08-12 19:21:24.646 openLuup.server:: request completed (34267 bytes, 3 chunks, 280 ms) tcp{client}: 0x1d21868
2022-08-12 19:21:24.648 openLuup.io.server:: HTTP:3480 connection from 192.168.1.24 tcp{client}: 0x1d6a9b0
2022-08-12 19:21:24.661 openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=323312340&=1660323303558 HTTP/1.1 tcp{client}: 0x1d21868
2022-08-12 19:21:25.252 openLuup.server:: request completed (70135 bytes, 5 chunks, 588 ms) tcp{client}: 0x1d21868
2022-08-12 19:21:25.253 luup_log:3: ALTUI: startupDeferred, called on behalf of device:3
2022-08-12 19:21:25.338 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Version was: v2.54 now: v2.54 #hooks:0
2022-08-12 19:21:25.934 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"Vera@192.168.1.2":{"url":"http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2","callback":... now: {"thingspeak":{"url":"","callback":"sendValueToStorage_thingspeak","parameters":[{"type":"number","key":"channelid"... #hooks:0
2022-08-12 19:21:25.964 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"thingspeak":{"url":"","callback":"sendValueToStorage_thingspeak","parameters":[{"type":"number","key":"channelid"... now: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... #hooks:0
2022-08-12 19:21:25.996 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... now: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... #hooks:0
2022-08-12 19:21:25.999 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.VariablesToSend was: now: #hooks:0
2022-08-12 19:21:26.009 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.RemoteVariablesToWatch was: now: #hooks:0
2022-08-12 19:21:26.010 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.VariablesToWatch was: now: #hooks:0
2022-08-12 19:21:26.012 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Timers was: [] now: [] #hooks:0
2022-08-12 19:21:26.013 luup_log:3: ALTUI: Wkflow - enableWorkflows(3,0,0)
Thank You.
d.
"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?
This morning following a micro power cut, I have a problem with Vera Bridge.
After a GetVeraFiles I have this message:
Trying to bridge openLuup with another openLuup using Verabridge and getting no Vera. Is this the correct way of linking the two?
I have read this someone before but I cannot find the answer again. I have several devices and scenes in Vera which have been deleted so now the issue is to identify which ones they are in openluup ALTUI and remove them. I thought there was a process where you would delete the bridge and then add it again but I cant remember. Can anyone point me in the right direction?
Thanks
Hello,
Had a RPI laying around and saw the cheap razberry board so picked one up last week. Am trying to set up ALTUI and connect to my Vera Plus. Of the 80 or so devices it pulled in from my Vera, only about 14 look like they are functional. When I run the GetVeraFiles from the VeraBridge actions menu, I see a bunch of 503 errors in the log. If I open the URL that it is erroring on in the browser, it usually returns a valid image or page.
Is there a way to attach logs to messages or is it acceptable to just paste in the entire thing as text? Let me know what info you need to see to point me in the right direction.
Thanks,
Roger
Since Vera support sucks and I have this intermittent problem. Several devices which were included successfully and had always have instant status (updating vera directly when pressed locally) stop working every now and then. Vera support has 1 solution: exclude & include. And yes this works. But then after a while it starts all over and eventually I end up with a regular exclude include session which is unacceptable. Currently I am somewhere a around device number 1600 (no joke!).
Vera tells me they can set and association to 1 (lifeline) to try.
Is there any feasible solution which is stable to keep this working? Where to start? I only have Vera as zwave bridge...
Get Vera files throwing errors
-
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.- 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). - Created a cmh-ludl in /etc, so that the install point matched the scripts in the doc.
- Ran sudo lua5.1 openLuup_install.lua which installed the v19.12.27
- Based on comments in thread added "development" to Update dialog box and ran update script. That completely broke everything. openLuup would not load.
- Tried to copy openLuup files from github to my RPI. That didn't work either.
- 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.
- Deleted the cmh-ludl directory that I had originally installed in the /home/pi path.
-
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.
-
Here is the startup page:
Plugin Startup Jobs CPU usage (in startup order)date / time device priority status hh
ss.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 OKLink for log files sent via chat.
-
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 -
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 itsfiles
folder, do you find any VeraBridge files? There should be none. The only findable VeraBridge file should be theL_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.
-
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 -
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.
-
Got it. Thanks for your help.
Plugin Startup Jobs CPU usage (in startup order)date / time device priority status hh
ss.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 -
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.
-
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. -
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 -
-
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.pngBut I am only getting the generic z-wave icon in the UI