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.
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?
"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...
Openluup - verabridge can not load devices.
-
OK, three things to check:
- Startup log
- Attribute page of the bridge (ie. did you install it right?)
- does this work from the Lua Test page?
local a,b = luup.inet.wget "http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1" print(pretty(b))
-
Console Output: :
First output was :
"MD5 module not available for digest authorization: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1"
I'ves solved it with :
sudo apt-get -y install lua-md5Now the console output is :
"<?xml version="1.0" encoding="iso-8859-1"?>\010<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\010 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\010<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\010 <head>\010 <title>401 - Unauthorized</title>\010 </head>\010 <body>\010 <h1>401 - Unauthorized</h1>\010 </body>\010</html>\010<?xml version="1.0" encoding="iso-8859-1"?>\010<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\010 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\010<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\010 <head>\010 <title>400 - Bad Request</title>\010 </head>\010 <body>\010 <h1>400 - Bad Request</h1>\010 </body>\010</html>\010"
So it seems an auth problem.
Is there any possibilities to give the credentials to the VeraBridge plugin ?Strange that if I try this way (:3480 instead of /port_3480) it's working and get back everything:
http://192.168.1.2:3480/data_request?id=user_data2&output_format=json&ns=1What I try to bridge is a Vera Lite with UI5.
How can I reinstall the verabridge plugin from scratch ?
-
device attributes page :
I am very new here and can't find how can I send PM in this forum (I am not sure is it even possible in NodeBB engine), the forum can not allow me to attach files to my post yet.
I am not sure whether the log contains any sensitive info so I attached a link for the logs and send you the password in chat for the file.
log files : linkAfter it did not worked as I wrote here yestersay I had a (maybe stupid) try to change the L_VerBridge.lua to use ":3840" string instead of "/port_3480" . I've changed RemotPort variable and the remote_request function. After the changes it downloaded the devices, but got another errors. You can see these at the end of the logs.
Now I copied back the original L_VerBridge.lua and got the original error atthe beginning of teh log.This is why I asked how can I reinstall the VeraBridge plugin, to eliminate the mixing with my tries in the log files.
-
The files for VeraBridge are installed with openLuup, so updating from the development branch will reload them. Note, though, that these are located in the openLuup folder. Delete any VeraBridge files that you may inadvertently have placed directly in the cmh_ludl home directory.
-
I've found this old forum post with similar problem (except I have no slave vera, only one) : verabridge-credentials
So I edited the two mentioned file in vera with ssh (/etc/lighttpd/lighttpd.conf, /etc/lighttpd.conf) and commented out the “mod_auth” section.
I've reinstalled freshly the VeraBrdige plugin.
Everything worked fine, the devices has been loadaded, and the GetVeraFiles donwloaded the needed files from the Vera.After this I changed back the “mod_auth” section in the two files. Now the auth is enabled again.
I had to changed the RemotePort to :3840 at Variables.Now it seems working.
I really don't know why my vera needs auth if you mentioned that your vera doesn't need it from OpenLuup. -
The RemotePort change to :3480 was enogh for the device loading from vera, but was not enough for the GetVeraFiles.
For the GetVeraFiles working it needed the auth switch off in vera, because of this code in GetVeraFiles : http://192.168.1.2/directory.txt -
Just wanted to add that my Vera Bridges stopped working, I can’t be sure exactly when, maybe after a reboot ? But wanted to share here as they were working fine..
The Variable for the
RemotePort
on both is/port_3480
Updating to
:3480
fixes it..@akbooer - not sure why this worked first and then stopped..
-
-