I just added a function to VeraBridge that can toggle a switch after not receiving any data from the remote Vera for a set timeout (configurable between 2-10 minutes).[/quote]
OK, whatever you want to do to your bridge is up to you! I don’t see that my proposed updates get in the way of this?
As we agreed I'll also add something to pull the files for a specific plug in from the Vera to the openLuup box. I think this is a useful add on to the VeraBridge.
The code is not fully tested yet, but Ill put it on GitHub once I had my first ‘forced reboot’ succeed.
If you rather have me create a separate plugin I will. Just let me know.
The bridge is really more about functionality of a running system, rather than system configuration. This might sit better as a separate utility (like getfiles, or perhaps part of that) since it’s not frequently used and doesn’t need to be there all the time?
This seems like a useful thing to have. I could simply make a variable on the bridge which reports the time of the latest received data. I’d arrange it so that it didn’t write a log entry every time it was changed (so doesn’t clutter the log with too frequent entries.) You could use it as a trigger or a condition for any logic you liked.
This seems like a useful thing to have. I could simply make a variable on the bridge which reports the time of the latest received data. I’d arrange it so that it didn’t write a log entry every time it was changed (so doesn’t clutter the log with too frequent entries.) You could use it as a trigger or a condition for any logic you liked.[/quote]
Sounds like a plan sir 8)
BTW; I did complete a function to pull the files of a plugin onto the openLuup folders. I will make a separate plugin out of it that can also do a sort of Auto-update and to pull all files that could be useful after a new Vera release (when ever that comes as those seem to have slowed down).
This seems like a useful thing to have. I could simply make a variable on the bridge which reports the time of the latest received data. I’d arrange it so that it didn’t write a log entry every time it was changed (so doesn’t clutter the log with too frequent entries.) You could use it as a trigger or a condition for any logic you liked.[/quote]
The latest development version of VeraBridge now has this variable (urn:akbooer-com:serviceId:VeraBridge1, LastUpdate)
I noted that house modes are not handled (possibly by design ?) by VeraBridge… a change in house mode on the bridged Vera is not reflected in openLuup.
Sseveral of the scenes I am migrating to openLuup depend on house mode (despite the many shortcomings of Vera’s implementation of house modes I find it more convenient than adding multiple virtual switches).
It would be nice to have such a feature in future versions of openLuup. For now as a quick fix I implemented a one line code addition to the polling function in the L_VeraBridge.lua file as follows:
if s and s.devices then
UpdateVariables (s.devices)
luup.attr_set("Mode", s.Mode, 0) -- added by logread to update openLuup house mode to actual on Vera
DataVersion = s.DataVersion
end
Yes, right on both counts. One of the major hurdles here is that openLuup can easily bridge to multiple Veras (mine does, to 4) and, in my application at least, the house modes should be independent.
However, I had the same problem with the Zwave controller but solved it recently with the policy that the FIRST (lowest device number) VeraBridge clones the remote Zwave controller, but any others do not. The same policy could be applied to house mode, I think?
Could make it a configuration parameter in the bridge, although I generally deplore such things.
Yes, right on both counts. One of the major hurdles here is that openLuup can easily bridge to multiple Veras (mine does, to 4) and, in my application at least, the house modes should be independent.
However, I had the same problem with the Zwave controller but solved it recently with the policy that the FIRST (lowest device number) VeraBridge clones the remote Zwave controller, but any others do not. The same policy could be applied to house mode, I think?
Could make it a configuration parameter in the bridge, although I generally deplore such things.[/quote]
the above policy could make sense indeed, though I agree it is not very neat…
Incidentally, I am curious about your use of the house modes. Unless your different Veras are in different houses/properties (with same LAN/VPN), I would have expected all your platforms (openLuup and Veras) to share a common single house mode at any point in time. But may be you use house modes for a different purpose than they are advertised for ?
We need to get away from the MiOS App Store / Trac / SVG dependencies. I’m alpha testing a version that can pull both AltUI and openLuup releases from GitHub. Once that’s done (soon, hopefully, although not on @amg0’s timescale), the current development branch will become the candidate for release 8. If there’s other things that are needed, now’s perhaps the time to add the to the list…
… this release will also handle the licensing of AltUI when not connected to a Vera by the bridge.
Well, it’s just that it pulls tagged releases from certain GitHub repositories. With a small amount of customization it could load almost any set of modules. There’s always the possibility to pull from MiOS Trac as well. The main focus had been to use it for automatic openLuup upgrades, but since MiOS is now unreliable for AltUI updates, my priority is now on getting that going.
Yes, right on both counts. One of the major hurdles here is that openLuup can easily bridge to multiple Veras (mine does, to 4) and, in my application at least, the house modes should be independent.
However, I had the same problem with the Zwave controller but solved it recently with the policy that the FIRST (lowest device number) VeraBridge clones the remote Zwave controller, but any others do not. The same policy could be applied to house mode, I think?
Could make it a configuration parameter in the bridge, although I generally deplore such things.[/quote]
the above policy could make sense indeed, though I agree it is not very neat…[/quote]
As I was testing openLuup 8 Release Candidate, this house mode issue came back to life (I solved it in my production system by tweaking the VeraBridge code, but this is not ideal now that you are to implement auto upgrades)… Could you include house mode attribute in the remote vera polling loop and just update with it a new variable in the VeraBridge plugin device, say “HouseMode”… It would allow multiple bridges to each report their status, and the local automation of the openLuup system could then use variable watches or triggers to set its own house mode ?
Ah yes, we hadn’t really come to closure on that issue.
...but this is not ideal now that you are to implement auto upgrades...
There’s really no pleasing some people
Could you include house mode attribute in the remote vera polling loop and just update with it a new variable in the VeraBridge plugin device, say "HouseMode"... It would allow multiple bridges to each report their status, and the local automation of the openLuup system could then use variable watches or triggers to set its own house mode ?
now THIS suggestion I can really subscribe to… much better than trying to link with the openLuup HouseMode itself. You’d like a device variable, rather than an attribute, so that you can see it change with a callback? Need to decide, then, on a serviceId. For the bridge, I have been using “urn:akbooer-com:service:VeraBridge:1”.
Most of the modules display their version number in the log at the start of a reload.
However, this isn’t satisfactory, and I’m currently working on using the Plugins page of AltUI to display the current version of known plugins and also to install / update / remove them with one click. See attached screen shot.
Latest version in development branch 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.
To install this version of VeraBridge, simply enter development into the Update box against VeraBridge on the Plugins page, and press Update.
