Questions here to do with VeraBridge configuration.
I am a gluten for punishment and have 2 Vera edges. How do I modify startup.lua to ensure verabridge sees both machines?
Just hold on for a day, and test out the new bridge!
Just to show that it works, here’s a parent/child network diagram of the new VeraBridge linked to four systems: 1x Edge, 3xLite, and the front panel showing how many devices on each.
Very nice !
quick question …
what is the best aproach for this scenario:
i want the Vera to be still the center of the universe … (this may change later … but for now this is how it is …)
offloading everything that makes load is simple … (as long there is no interaction required)
lets say i want to offload a plugin that actually interacts with humans … like (virtual switches, wifi enabled devices to control, and so on)
adding them in openluup results in the vera can’t see them,
adding them on the vera will result that openluup will not do the brain-work.
i have my sprinkler system as example set up via virtual switches, the vera simply makes wget calls on triggers, but thats exactly what i want to avoid.
what is the best aproach ?
The VeraBridge in Release 5.5 is NOT compatible with the old version, you will have to rebuild from a startup.lua file rather than an existing user_data.json (sorry)
There was an intrinsic problem with the way that the bridge used to treat device numbers: any new device, be it local or cloned from a remote machine, would receive the next available deviceID, as in a standard Vera. This meant that any change to local devices or ones on remote machines (ie. creation/deletion) could result in an extensive renumbering of all devices in openLuup… clearly not acceptable.
The approach now is for local device numbers to work as in Vera - a new device gets the next available ID. However, cloned devices from remote machines get device IDs allocated from higher-numbered blocks. The first VeraBridge uses device numbers starting at 10,000, the second one at 20,000, and so on. There is also some consistency in the remote device numbering in that the original Vera deviceIDs are simply shifted by the bridge offset. Thus device 42 on your first bridged Vera will always be device 10042 on openLuup.
Local and remote devices are thus completely isolated in terms of device numbering interactions. This will make scene triggers and action much more stable.
[quote=“nullx8, post:6, topic:189396”]i want the Vera to be still the center of the universe … (this may change later … but for now this is how it is …)
offloading everything that makes load is simple … (as long there is no interaction required)[/quote]
I think you asked this sort of question before and I probably gave a very poor answer.
lets say i want to offload a plugin that actually interacts with humans .. like (virtual switches, wifi enabled devices to control, and so on) adding them in openluup results in the vera can't see them, adding them on the vera will result that openluup will not do the brain-work.Yes, all that's true. You had asked before for a sort-of 'reverse' bridge, so that Vera could see things on openLuup. But my point was that this is likely to be at least a much load on Vera as before, which really defeats the point of doing it.
i have my sprinkler system as example set up via virtual switches, the vera simply makes wget calls on triggers, but thats exactly what i want to avoid.what is the best aproach ?
So I guess the question is “what does Vera actually need to know about the state of the sprinklers?”
…if you move the logic to openLuup, and the control of the actual sprinklers, you could perhaps just have a multi-switch with a few key states set remotely by openLuup to echo the status of the system to Vera.
Am I missing something?
Have installed verabridge 5.5 and the other 5.5 files started from new startup.lua. I must be going senile as I cannot see any way to add more than one vera to the verabridge section, my programming days ended with BASIC on AppleII !!!
More detailed help needed.(Netatmo installation was much easier)
David
[quote=“dsroberts1945, post:9, topic:189396”]Have installed verabridge 5.5 and the other 5.5 files started from new startup.lua. I must be going senile as I cannot see any way to add more than one vera to the verabridge section, my programming days ended with BASIC on AppleII !!!
More detailed help needed.(Netatmo installation was much easier)[/quote]
No, not senility, just lack of documentation from me.
Yes, Netatmo was easier, but Netatmo was not a whole virtual environment sitting on top of an unknown operating system on different hardware!
Anyway, it’s simple - just create another VeraBridge, setting the IP address to that of your second Vera.
[quote=“akbooer, post:8, topic:189396”]So I guess the question is “what does Vera actually need to know about the state of the sprinklers?”
…if you move the logic to openLuup, and the control of the actual sprinklers, you could perhaps just have a multi-switch with a few key states set remotely by openLuup to echo the status of the system to Vera.[/quote]
exactly …
after giving it some tought … i think this can be solved easy
on a complex plugin like a thermostat it would require ALOT of manual triggers to keep the data in sync, which will sooner or later lead to big headache …
what if:
the Vera Bridge would be in a read-only state for certain plugins ?
as example:
we have on both machines the code anyway … so it does not really matter which one execute the logic.
the “problem” is that if i push a button on a plugin driven device … openluup sends the execute command to the vera (as expected)
if there would be a way to have a local setting for a device which simply prevents that and execute it locally instead
that would fix the problem.
or even better execute on both …
(then i would simply remove the internal triggers/logic on the vera’s plugin files … so the ver will know via the bridge that somethings did happen . but not executing anything where openluup still have the original code and do what its supposed to do …
the question is now, how i “fake” a bridged device to accomplish that.
let me give you a real example.
my Radio thermostat plugin … it works perfectly … but its slowing down the vera dramatically because of continusly connect timeouts
and refresh of the data.
what i would do where … remove the refresh triggers on the lua code at the vera … and have openluup doing it instead.
so if i click “CoolOn” on either systems … it works anyway as both will execute it … but vera does only update the status.
i have no problem with change sourcecode to make that happen.
this would keep the compatiblity but opens more room for offloading.
Long story short: a “process locally” flag … would simply do the trick for most plugins … (i guess)
Probably a dumb question but…
I have my OpenLuup system setup - I have my main vera bridge connected and I can see all of my devices and scenes from the main Vera.
But… I cannot seem to control them from the OpenLuup interface. I can turn the light off in the AltUI but nothing is sent to the main vera ( Looking at the logs ) and the light stays on?
Something very basic must be wrong. I struggle to think of a scenario where you see the devices, but control doesn’t work, unless the bridge has crashed because it’s run across something it really doesn’t like.
It would be good to know your Vera configuration and to have a complete log of openLuup after a reload up to the point of trying to turn a light on or off.
So I found the correct logs - was looking a LuaUpnp.log in /var/log/cmh/ instead of /etc/cmh-luld
This is what is happening- the divice 20039 in OpenLUUP is calling device 10039 in the Vera Edge - Should be device 39?
Some of the devices looks like they mapped correctly and are working but not others?
openLuup.server:: /data_request?id=action&output_format=json&DeviceNum=20039&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0 tcp{client}: 0x2cc3a58
2016-02-01 13:47:03.142 luup.call_action:0: 20039.urn:upnp-org:serviceId:SwitchPower1.SetTarget
2016-02-01 13:47:03.142 luup.call_action:0: action will be handled by parent: 8
2016-02-01 13:47:03.142 luup_log:8: http://192.168.253.6:3480/data_request?id=action&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&DeviceNum=10039&newTargetValue=0&action=SetTarget&serviceId=urn%3Aupnp-org%3AserviceId%3ASwitchPower1
So you are bridged to two remote Veras?
What IS your full configuration (Veras, UIs, platform for openLuup) ?
No Just one
I have just 1 Vera Edge - about 150 devices and 20 scenes running current UI7
Built a Ubuntu 14.03 system to run OpenLUUP - AltUI all latest versions
As I was setting it up I manually added a VeraBridge device using the Test LUA code
do -- the BRIDGE !!
local d = create_device ("Remote Vera", "D_VeraBridge.xml")
#luup.ip_set ("0.0.0.0", d) -- set remote Vera IP address
end
Forgot to remove the # for the IP - I added the IP through the UI by editing the configuration - That did not seem to work so I deleted it and recreated the VeraBridge device with
do -- the BRIDGE !!
local d = create_device ("Remote Vera", "D_VeraBridge.xml")
luup.ip_set ("0.0.0.0", d) -- set remote Vera IP address
end
The devices and scenes showed up immediately.
I think that’s the source of your problem. There is the vestige of two bridges, I think. But I can’t tell without further information. Best to start with a clean system from startup.lua, if not too much trouble. I regularly bridge multiple machines (up to four) and have no problems. I just tried it again for my sanity’s sake with two machines and all works as expected. Just one certainly works OK.
Once again the advice: ALWAYS keep a startup.lua version which can reconstruct your latest system (rather than building it incrementally.)
Of course, you can try to patch things up manually by editing user_data.json, but that does lead to errors creeping in.
Will do - Thanks for the help
Starting clean - I simply remove the user_data.json and then rerun the startup.lua?
That took care of the 20000 Series devices - all good now. Thanks
Glad this worked! For future reference, running openLuup_reload with any file parameter, be it a startup.lua file or a different user_data.json file, will overwrite your existing user_data.json file anyway.