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.
I am getting (may be wrongly) concerned that openLuup’s logging activity to the SD card on the Raspberries Pi that I am using might result in premature wear of the cards… Could you consider allowing the user (say as an openLuup device variable) to specifiy a ram drive for openLuup’s logging activity (i.e. what is currently written in /etc/cmh-ludl/ or whatever is the openLuup running folder) ?
Edit: I appreciate the logging in /var/cmh is not versioned and can become quite big for a ram drive, so as a trade off its maximum file size could be reduced also at the user’s option ?
Obviously the user would have to create the ram drive based on the specific of the system openLuup runs on. For instance I already pointed /var/log/cmh to a ram drive for the variable logging.
I appreciate the logging in /var/cmh is not versioned and can become quite big for a ram drive, so as a trade off its maximum file size could be reduced also at the user's option ?
… indeed, I didn’t version it because it’s not important and I didn’t want to use up too much space. IIRC it’s currently set at 5000 lines, which might be about half a Mbyte. I have no control over where it is written or what it is called because it is only there for the convenience of AltUI, which uses it to retrieve variable, scene, and workflow history (as used in the variable display pages.) For this reason, openLuup doean’t write a full log here, only those relevant events. openLuup tries to be as similar as possible as Vera (but better) which uses this same name / location. However, AFAIK, /var is generally mapped to /tmp so should be in RAM anyway?
/etc/cmh-ludl/LuaUPnP.log.*
This is easy to change and make user configurable, because AltUI makes no use of this. It currently is versioned (last 5 rotations, needed for debugging across restarts) and is about 2000 lines for each. It’s really an historical accident that it writes the log here… I just want as simple a directory structure as possible, in the old days. I’ll make the change to the development version before I make it the latest master release. I’m likely to put the configuration into Startup Lua, rather than openLuup device variable(s).
Yes, I realized that after posting and was probably editing my initial post when you wrote your answer… I indeed already have the /var/cmh/LuaUPnP.log pointing to a tmps ram mount. Was easy to do and indeed the 5000 lines limit is very reasonable (I figured that limit from reading the code in the logs.lua module, that I should have dissected earlier… my bad).
This is easy to change and make user configurable, because AltUI makes no use of this. It currently is versioned (last 5 rotations, needed for debugging across restarts) and is about 2000 lines for each. It’s really an historical accident that it writes the log here… I just want as simple a directory structure as possible, in the old days. I’ll make the change to the development version before I make it the latest master release. I’m likely to put the configuration into Startup Lua, rather than openLuup device variable(s).[/quote]
That would be great. Indeed a startup lua option is most probably best !
