This is the issue I PM’ed you about yesterday… The IP address is an attribute, and you can not modify an attribute with AltUI on openluup.
Yes. Changing attributes via the UI is not implemented, for good reason. But if your PM is right, it’s now easily fixable. Will PM you and @amg0 a response a bit later.
The development branch on GitHub now has a fix to enable HTTP id=variableset to change device attributes, which then persist over reloads. A few existing attributes can’t be changed this way (eg. Model) since they are over-written by the information in the device files (or, rather, they can be changed, but the change does not persist over a reload.)
The upshot should be that the AltUI interface can now be used to change some device attributes.
Hello,
I’m currently struggling to get openLuup to work currently with a Vera Edge.
The devices respond perfectly fine when sending command directly from the Vera Controller but openLuup timeout very frequently when sending commands to the vera.
do -- the VERA BRIDGE !!
local dev = luup.create_device ('', "Vera", "Vera", "D_VeraBridge.xml")
luup.ip_set ("10.1.10.120", dev) -- set remote Vera IP address
end
This is what the logs shows:
2016-03-12 19:33:07.812 openLuup.server:: /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1457829144539 tcp{client}: 0x29c2278
2016-03-12 19:33:07.813 openLuup.server:: /data_request?id=action&output_format=json&DeviceNum=10219&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 tcp{client}: 0x2faa9e8
2016-03-12 19:33:07.813 luup.call_action:0: 10219.urn:upnp-org:serviceId:SwitchPower1.SetTarget
2016-03-12 19:33:07.813 luup.call_action:0: action will be handled by parent: 17
2016-03-12 19:33:07.813 luup_log:17: http://10.1.10.10:3480/data_request?id=action&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&DeviceNum=219&newTargetValue=1&action=SetTarget&serviceId=urn%3aupnp%2dorg%3aserviceId%3aSwitchPower1
2016-03-12 19:33:12.818 luup_log:17: failed requests status:
2016-03-12 19:33:12.819 openLuup.server:: request completed (35 bytes, 1 chunks, 5006 ms) tcp{client}: 0x2faa9e8
2016-03-12 19:33:12.820 openLuup.server:: request completed (1 bytes, 1 chunks, 5007 ms) tcp{client}: 0x29c2278
2016-03-12 19:33:14.461 luup_log:17: Zwave data update ignored for device 1
2016-03-12 19:33:14.464 luup.variable_set:17: 10183.urn:micasaverde-com:serviceId:ZWaveDevice1.PollOk was: 303 now: 304 #hooks:0
2016-03-12 19:33:14.465 luup.variable_set:17: 10197.urn:micasaverde-com:serviceId:ZWaveDevice1.PollOk was: 260 now: 261 #hooks:0
2016-03-12 19:33:14.975 openLuup.server:: request completed (11096 bytes, 1 chunks, 15077 ms) tcp{client}: 0x3001e48
2016-03-12 20:08:31.146 openLuup.server:: /data_request?output_format=json&id=lu_status&DataVersion=830725400 tcp{client}: 0x2189478
2016-03-12 20:08:31.147 openLuup.server:: receive error: closed tcp{client}: 0x1ca94a8
2016-03-12 20:08:31.149 openLuup.server:: request completed (2389 bytes, 1 chunks, 3 ms) tcp{client}: 0x2189478
2016-03-12 20:08:31.349 openLuup.server:: new client connection: tcp{client}: 0x2033938
2016-03-12 20:08:31.350 openLuup.server:: /data_request?output_format=json&id=lu_action&DeviceNum=10180&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0 tcp{client}: 0x2033938
2016-03-12 20:08:31.351 luup.call_action:0: 10180.urn:upnp-org:serviceId:SwitchPower1.SetTarget
2016-03-12 20:08:31.351 luup.call_action:0: action will be handled by parent: 17
2016-03-12 20:08:31.351 luup_log:17: http://10.1.10.10:3480/data_request?id=action&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&DeviceNum=180&newTargetValue=0&action=SetTarget&serviceId=urn%3aupnp%2dorg%3aserviceId%3aSwitchPower1
2016-03-12 20:08:36.354 luup_log:17: failed requests status:
2016-03-12 20:08:36.355 openLuup.server:: request completed (35 bytes, 1 chunks, 5004 ms) tcp{client}: 0x2033938
2016-03-12 20:08:41.360 openLuup.server:: /data_request?output_format=json&id=lu_status&DataVersion=830725400 tcp{client}: 0x2189478
2016-03-12 20:08:41.360 openLuup.server:: closing client connection: tcp{client}: 0x1cfe678
2016-03-12 20:08:41.363 openLuup.server:: request completed (2390 bytes, 1 chunks, 3 ms) tcp{client}: 0x2189478
So this is only some of the time, not every time…
[ul][li]remind me what environment you’re running, is it a virtual machine?[/li]
[li]confirm you’re running the latest bridge version by showing the startup log[/li]
[li]have you only had this problem only since running an Edge?[/li][/ul]
I do see two things from the log which need fixing, but are minor:
[ol][li]duplicate serviceId in the relayed request[/li]
[li]status message with no status![/li][/ol]
One of my test machines links to three Veras, one of them an Edge. I’ve not noticed it missing any action requests, but will look again.
Ubuntu 14.04
2016-03-13 13:07:14.477 openLuup.scheduler:: starting
2016-03-13 13:07:14.477 openLuup.scheduler:: [3] device startup
2016-03-13 13:07:14.477 luup_log:3: VeraBridge
2016-03-13 13:07:14.477 luup_log:3: 2016.02.15
2016-03-13 13:07:14.477 luup_log:3: device clone numbering starts at 10000
2016-03-13 13:07:14.477 luup_log:3: 10.1.10.10
2016-03-13 13:07:19.482 luup.variable_set:3: 3.urn:akbooer-com:serviceId:VeraBridge1.Devices was: 0 now: 0 #hooks:0
2016-03-13 13:07:19.482 luup.variable_set:3: 3.urn:akbooer-com:serviceId:VeraBridge1.Scenes was: 0 now: 0 #hooks:0
2016-03-13 13:07:19.482 luup.variable_set:3: 3.urn:akbooer-com:serviceId:VeraBridge1.Version was: 2016.02.15 now: 2016.02.15 #hooks:0
2016-03-13 13:07:19.482 luup.variable_set:3: 3.urn:upnp-org:serviceId:altui1.DisplayLine1 was: 0 devices, 0 scenes now: 0 devices, 0 scenes #hooks:0
2016-03-13 13:07:19.482 luup.variable_set:3: 3.urn:upnp-org:serviceId:altui1.DisplayLine2 was: 10.1.10.10 now: 10.1.10.10 #hooks:0
2016-03-13 13:07:23.116 luup_log:3: Zwave data update ignored for device 1
I’ve been testing VeraBridge on the same environment with a smaller z-wave network and I do get frequent timeouts but I thought it could just be the controller that was overloaded or something.
The controller where I’m testing has no plugins installed and has a little over 100 z-wave devices and the timeouts are way more frequent (almost every time).In L_VeraBridge.lua I’ve tried decreasing the POLL_DELAY from 5 seconds to 2 seconds and that helped for a couples of hours but then Verabridge got worse so I put it back to 5 seconds.
I have only used VeraBridge on Edge’s controllers. I believe the timeouts were there although I wasn’t paying much attention until now. :-[
something else I’ve noticed while I was digging a little deeper. for some reason the lua engine crashes on the edge while openluup is running and polling the vera edge. I had to restore the vera edge from a previous backup as the lua engine gets on a crashing loop every 6 minutes after that as tow of the z-wave devices apparently are out of reach. I will exclude them and make sure that’s was causing the luup crashing luup on the vera edge controller.
I can’t believe the lua engine crashing nightmares follow us even while sending simple actions to a stock unit without a single plugin instaled.
01 03/13/16 17:55:03.511 UserData::WriteUserData saved--before move File Size: 61251 save size 61251 <0x7738c520>
02 03/13/16 17:55:03.511 UserData::TempLogFileSystemFailure start 0 <0x7738c520>
02 03/13/16 17:55:03.582 UserData::TempLogFileSystemFailure 4302 res:1
-rw-r--r-- 1 root root 33 Dec 31 1999 /etc/cmh/HW_Key
I have moved from one Edge controller to another the devices that were not reachable. I’ve add the second controller to openluup.
VeraBridge is vera quick on the new controller since it has only 2 devices. Things improved a little on the main controller but openluup continues to timeout … It seems as the more devices the controller has the more timeouts openluup will experience.
Strange, since, as I’ve mentioned previously, I have one instance linked to three Veras each with about 60 bridged devices…
I remember a few month ago when ALTUI was timing out from remote hosts and I was able to only access it through localhost. I experienced that behavior on ubuntu 14.04 . Wondering if this issue could have something to with the VeraBridge timeouts?
Something else to note is when there is a timeout on openluup the controller does not show any request on the logs. I’m going crazy here… ??? ??? ???
Also I’d like to confirm that when multiple command are being sent from openLuup to a vera edge running UI7 firmware 1.7.1707 the controller’s LUA engine crashes.
I have tested in 3 different 4 different controller from 3 different servers running Ubuntu 14.04 and Mac OS X in different locations and I get the same behavior. ??? ??? ??? ??? Literally going crazy here…
Something I’m currently trying to improved reliability while sending commands to the controller is increasing the timeout on the luup.init.wget command. It has helped me and seems like it’s not timing out as much… Although the status update do take much longer to show up (about 24 seconds to update). This works ok when sending about 8 actions to the controller , If I try to send a little over those 8 it will time out…
Any other ideas of what else could it be done to truly get rid of this issue?
-- logged request
local function wget (request)
luup.log (request)
local status, result = luup.inet.wget (request, 12)
if status ~= 0 then
luup.log ("failed requests status: " .. (result or '?'))
end
end
If I send more command
The development branch now has a V2.0 version of the bridge:
[ul][li]device parent/child relationships supported[/li]
[li]Zwave and Scene controllers (device 1 & 2) mapped[/li]
[li]LastUpdate device variable shows most recent communication (as per @reneboer suggestion)[/li]
[li]internal refactoring[/li][/ul]
This implements some of the proposed changes discussed here: http://forum.micasaverde.com/index.php/topic,34476.msg275504.html#msg275504
The before/after effects of the parent/child relationships are shown in the network diagrams attached. Functionally, the most obvious change is that the ‘zWave Network’ matrix display in AltUI now works. More subtly, I’m hoping that this means a few more plugins work without modification… specifically, SmartVT?
Just updated the development branch bridge to honour bridged devices which are invisible - in order to maintain parent/child relationships. Attached screen shots show ‘before’ and ‘after’ network diagrams for an openLuup machine bridged to three remote Veras.
Each remote machine has a Zwave controller to which its Zwave devices are attached, but the primary (lowest device number on openLuup) VeraBridge Zwave controller is the local device #1, making the openLuup machine almost indistinguishable from the Vera to which it bridges, so far as local plugins are concerned.
Testing the new VeraBridge. But for some reason there must be something in one of my controllers causing the openluup on a never ending reload loop.
Wondering where could I look to get more info as of why this is happening.
It reloads while processing device 200. while I was looking at my user_data I’ve notices that device id: 199 has a state variable defined with the same id (“200”) and the next device is device “200” 2 devices using the same id “200” but
device : 199
{
id: 199,
device_type: "urn:schemas-micasaverde-com:device:DoorLock:1",
id_parent: 1,
embedded: 0,
disabled: 0,
device_file: "D_DoorLock1.xml",
impl_file: "",
model: "",
altid: "35",
ip: "",
mac: "",
time_created: "1459643277",
states: [
{
id: 200,
service: "urn:micasaverde-com:serviceId:DoorLock1",
variable: "sl_LockButton",
value: "1"
},The following Devices is 200
{
id: 200,
device_type: "urn:schemas-micasaverde-com:device:DoorLock:1",
id_parent: 1,
embedded: 0,
disabled: 0,
device_file: "D_DoorLock1.xml",
impl_file: "",
model: "",
altid: "36",
ip: "",
mac: "",
time_created: "1459643802",
states: [
{
service: "urn:micasaverde-com:serviceId:ZWaveDevice1",
variable: "Capabilities",
value: "83,220,0,4,64,3,R,B,RS,W1,|32S,76S,78S:2,93S,98S,99S,112S,113S:1,114S,117S,128S,133S,134S,139S,152S,",
id: 0
},
Could it be that VeraBridge does not how to handle identical ids even though they are on different level in the json file?
2016-04-13 18:33:10.995 openLuup.scheduler:: [3] device startup completed: status=nil, msg=nil, name=nil
2016-04-13 18:33:10.995 openLuup.scheduler:: [4] device startup
2016-04-13 18:33:10.995 luup_log:4: VeraBridge
2016-04-13 18:33:10.995 luup_log:4: 2016.03.19
2016-04-13 18:33:10.995 luup_log:4: device clone numbering starts at 10000
2016-04-13 18:33:10.995 luup_log:4: device[1] parent set to 4
2016-04-13 18:33:10.995 luup_log:4: VeraBridge maps remote Zwave and Scene controllers
2016-04-13 18:33:10.995 luup_log:4: 10.10.10.224
2016-04-13 18:33:11.293 luup_log:4: Vera info received!
2016-04-13 18:33:11.294 luup_log:4: MiOS-45000940
2016-04-13 18:33:11.294 luup_log:4: new room number: 10
2016-04-13 18:33:11.294 luup_log:4: number of remote devices = 74
2016-04-13 18:33:11.294 luup_log:4: deleting device numbers: [2]
2016-04-13 18:33:11.294 luup_log:4: device[1] parent set to 4
2016-04-13 18:33:11.294 luup_log:4: device[10004] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10005] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10006] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10008] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10012] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10013] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10014] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10015] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10016] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10017] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10018] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10019] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10020] parent set to 10019
2016-04-13 18:33:11.294 luup_log:4: device[10021] parent set to 10019
2016-04-13 18:33:11.294 luup_log:4: device[10022] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10023] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10024] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10025] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10026] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10028] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10029] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10030] parent set to 1
2016-04-13 18:33:11.294 luup_log:4: device[10037] parent set to 4
2016-04-13 18:33:11.294 luup_log:4: device[10038] parent set to 4
2016-04-13 18:33:11.294 luup_log:4: device[10040] parent set to 4
2016-04-13 18:33:11.294 luup_log:4: device[10044] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10045] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10052] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10053] parent set to 10052
2016-04-13 18:33:11.295 luup_log:4: device[10055] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10067] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10068] parent set to 10067
2016-04-13 18:33:11.295 luup_log:4: device[10069] parent set to 10067
2016-04-13 18:33:11.295 luup_log:4: device[10070] parent set to 10067
2016-04-13 18:33:11.295 luup_log:4: device[10071] parent set to 10067
2016-04-13 18:33:11.295 luup_log:4: device[10072] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10073] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10075] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10080] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10081] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10082] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10084] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10086] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10092] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10093] parent set to 10092
2016-04-13 18:33:11.295 luup_log:4: device[10094] parent set to 10092
2016-04-13 18:33:11.295 luup_log:4: device[10095] parent set to 10092
2016-04-13 18:33:11.295 luup_log:4: device[10096] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10097] parent set to 10096
2016-04-13 18:33:11.295 luup_log:4: device[10098] parent set to 10096
2016-04-13 18:33:11.295 luup_log:4: device[10099] parent set to 10096
2016-04-13 18:33:11.295 luup_log:4: device[10111] parent set to 10055
2016-04-13 18:33:11.295 luup_log:4: device[10112] parent set to 10055
2016-04-13 18:33:11.295 luup_log:4: device[10126] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10127] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10128] parent set to 1
2016-04-13 18:33:11.295 luup_log:4: device[10153] parent set to 10128
2016-04-13 18:33:11.295 luup_log:4: device[10154] parent set to 10128
2016-04-13 18:33:11.295 luup_log:4: device[10155] parent set to 10128
2016-04-13 18:33:11.295 luup_log:4: device[10156] parent set to 10128
2016-04-13 18:33:11.295 luup_log:4: device[10167] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10168] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10169] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10170] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10171] parent set to 4
2016-04-13 18:33:11.295 luup_log:4: device[10172] parent set to 10170
2016-04-13 18:33:11.295 luup_log:4: device[10173] parent set to 10170
2016-04-13 18:33:11.295 luup_log:4: device[10174] parent set to 10170
2016-04-13 18:33:11.295 luup_log:4: device[10196] parent set to 10008
2016-04-13 18:33:11.295 luup_log:4: device[10197] parent set to 10008
2016-04-13 18:33:11.295 luup_log:4: device[10198] parent set to 10008
2016-04-13 18:33:11.296 luup_log:4: device[10199] parent set to 1
2016-04-13 18:33:11.296 luup_log:4: device[10200] parent set to 1
2016-04-13 18:33:11.296 openLuup.luup:4: device 4 'Vera' requesting reload
2016-04-13 18:33:11.296 luup.reload:4: saving user_data
2016-04-13 18:33:11.340 openLuup.luup:4: exiting with code 42 - after 0.0 hours
I have removed the duplicate id from user_data.json by manually decompressing the file and removing the variable thinking it could solve the issue but it didn’t… Something else I did noticed is that id:200 is the last id of my device’s list following up by the scene list. Could it be the scene list creating the openLuup reload loop?
After letting openLuup reload like crazy it gets to a point where it stops and then I can access ALTUI but no scenes get imported from the Vera controller.
Unfounded speculation and, as you have found out, totally wrong!
The clue, as ever, is in the logs:
2016-04-13 18:33:11.294 luup_log:4: number of remote devices = 74
2016-04-13 18:33:11.294 luup_log:4: deleting device numbers: [2]
2016-04-13 18:33:11.294 luup_log:4: device[1] parent set to 4
2016-04-13 18:33:11.294 luup_log:4: device[10004] parent set to 1Compare this with what I see in mine:
2016-04-14 10:04:01.618 luup_log:6: number of remote devices = 46
2016-04-14 10:04:01.625 luup_log:6: device[1] parent set to 6
2016-04-14 10:04:01.626 luup_log:6: device[2] parent set to 1
2016-04-14 10:04:01.628 luup_log:6: device[10003] parent set to 1
2016-04-14 10:04:01.630 luup_log:6: device[10004] parent set to 1Rather than setting device 2 (remote Vera’s scene controller) to have the VeraBridge as a parent device, it deletes it.
This is behaviour I would expect on running the bridge for the first time after a system reset or startup with a new configuration file. However, it should reload and the next time retain device #2 and adopt it, as per my log above.
Can you show two logs in a row and confirm you have not in any way changed the script file openLuup_reload. Are you sure you are running the latest from the development branch?
I have re-downloaded a copy of the development branch and placed the files in the appropriate locations.
cat /etc/cmh-ludl/openLuup_reload
#!/bin/sh
#
# reload loop for openLuup
# @akbooer, Aug 2015
# you may need to change ?lua? to ?lua5.1? depending on your install
lua5.1 openLuup/init.lua $1
while [ $? -eq 42 ]
do
lua5.1 openLuup/init.lua
doneStarting VeraBridge for the first time after a system reset.
./openLuup_reload startup.lua
Then I check the logs while openLuup is on the reload loop.
tail -f /etc/cmh-ludl/LuaUPnP.log
2016-04-14 07:39:48.108 luup_log:4: new room number: 10
2016-04-14 07:39:48.108 luup_log:4: number of remote devices = 74
2016-04-14 07:39:48.108 luup_log:4: deleting device numbers: [2]
2016-04-14 07:39:48.108 luup_log:4: device[1] parent set to 4
2016-04-14 07:39:48.108 luup_log:4: device[10004] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10005] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10006] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10008] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10012] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10013] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10014] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10015] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10016] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10017] parent set to 1
2016-04-14 07:39:48.108 luup_log:4: device[10018] parent set to 1
2016-04-14 07:39:48.109 luup_log:4: device[10019] parent set to 1
2016-04-14 07:39:48.109 luup_log:4: device[10020] parent set to 10019
2016-04-14 07:39:48.109 luup_log:4: device[10021] parent set to 10019tail -f /etc/cmh-ludl/LuaUPnP.log
2016-04-14 07:39:52.739 luup_log:4: new room number: 10
2016-04-14 07:39:52.739 luup_log:4: number of remote devices = 74
2016-04-14 07:39:52.739 luup_log:4: deleting device numbers: [2]
2016-04-14 07:39:52.739 luup_log:4: device[1] parent set to 4
2016-04-14 07:39:52.739 luup_log:4: device[10004] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10005] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10006] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10008] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10012] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10013] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10014] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10015] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10016] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10017] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10018] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10019] parent set to 1
2016-04-14 07:39:52.739 luup_log:4: device[10020] parent set to 10019
2016-04-14 07:39:52.739 luup_log:4: device[10021] parent set to 10019tail -f /etc/cmh-ludl/LuaUPnP.log
2016-04-14 07:39:58.790 luup_log:4: new room number: 10
2016-04-14 07:39:58.790 luup_log:4: number of remote devices = 74
2016-04-14 07:39:58.790 luup_log:4: deleting device numbers: [2]
2016-04-14 07:39:58.790 luup_log:4: device[1] parent set to 4
2016-04-14 07:39:58.790 luup_log:4: device[10004] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10005] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10006] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10008] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10012] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10013] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10014] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10015] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10016] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10017] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10018] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10019] parent set to 1
2016-04-14 07:39:58.790 luup_log:4: device[10020] parent set to 10019
2016-04-14 07:39:58.790 luup_log:4: device[10021] parent set to 10019tail -f /etc/cmh-ludl/LuaUPnP.log
2016-04-14 07:40:11.766 luup_log:4: new room number: 10
2016-04-14 07:40:11.766 luup_log:4: number of remote devices = 74
2016-04-14 07:40:11.767 luup_log:4: deleting device numbers: [2]
2016-04-14 07:40:11.767 luup_log:4: device[1] parent set to 4
2016-04-14 07:40:11.767 luup_log:4: device[10004] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10005] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10006] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10008] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10012] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10013] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10014] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10015] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10016] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10017] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10018] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10019] parent set to 1
2016-04-14 07:40:11.767 luup_log:4: device[10020] parent set to 10019
2016-04-14 07:40:11.767 luup_log:4: device[10021] parent set to 10019Could it be that there is a device or scene in the Vera Controller causing this behavior? I have tried another controller and it works fine. I believe its worth mentioning that this secondary controller (which loads correctly in openluup) has been UPnP bridged with the main controller (which does not loads correctly but it used to load correctly on the previous VeraBridge Version), by the way, I’m not trying to load both controllers at the same time in openLuup, I’m simply trying to load the main Vera controller onto openloop/
do -- ALTUI
local dev = luup.create_device ('', "ALTUI", "ALTUI", "D_ALTUI.xml")
end
do -- the VERA BRIDGE !!
local dev = luup.create_device ('', "Vera1", "Vera1", "D_VeraBridge.xml")
luup.ip_set ("controller_ip", dev) -- set remote Vera IP address
end
-- set up whatever Startup Lua code you normally need here
luup.attr_set ("StartupCode", [[
luup.log "Hello from my very own startup code"I think I need to see the whole logs to make any sense of this.
I have PM’ed you. 
Would you care to try the updated bridge file at openLuup/VeraBridge at development · akbooer/openLuup · GitHub ?
I’m happy to report that it is now working!!!
Thanks a bunch…
Btw something else I did noticed… is that some variables (such as LoadLevelStatus) do not get updated accordingly in ALTUI .
Example: If I dim a light to 30% on the actual switch. the device’s variables get updated on the vera controller as well on openLuup’s user_data but for some reason it does not get updated on ALTUI. Perhaps I should talk to @amg0 about it.