Thanks akbooer,
I am with you on the objectives…
Though I cannot envision maintaining the plugins database, for many reasons including my main job in a totally different field.
For now, looks like I am going to carry on with my endeavors and post as appropriate… Always happy to learn new tricks ever since I first sat in front of a commodore PET machine…
Please keep on developing openLuup… Great stuff
Just one additional thing to consider , Altui is not capable of supporting all plugins either. The limits are mostly due to the plugins JavaScript tabs and the key things you need to take care (meaning to avoid) of are:
-encrypted plugins
-Plugins use other JavaScript framework than jQuery
-Plugins use non documented js api in either ui5 or ui7 own code.
Just wanted to give a “heads up” on some up-coming and much-needed improvements to the VeraBridge plugin:
[ul][li]parent/ child relationship retained - at the moment, all remote devices are children of the bridge.[/li]
[li]Zwave controller (device #1) bridged - currently ignored, the plan is for remote Zwave devices to have this as a parent (as they do on Vera) and for actions on this device to be relayed to the remote Vera.[/li]
[li]asynchronous I/O for polling - this will allow a much more responsive behaviour for device status and controls to reflect the actual value of the remote device. With the present version, this can be delayed up to 5 seconds, and it’s also heavier than it needs to be on network traffic.[/li]
[li]mirroring of selected devices to the remote Vera - at this time, the bridge acts in a purely uni-directional way. The plan is to allow specific, local, openLuup devices to have their variables mirrored to virtual devices on the remote Vera.[/li]
[li]significant refactoring - doesn’t matter to you, but does to me! The original bridge code was written so that it could also run on an actual Vera. That so much isn’t true any more and I need to move away from some of those legacy constraints.[/li][/ul]
The above enhancements are aimed at making more plugins work without any change (specifically those which examine the parent/child relationship, like SmartVT, and those which directly use the Zwave controller, like RGBController.)
The Zwave controller changes are likely only to apply to the first VeraBridge in the system. Most people probably only bridge to one Vera anyway.
Some of these things are a bit challenging, so I may release in phases, but I did want to check that these developments would not cause any problems that might be obvious to you, but not to me.
Thanks for any feedback.
Hi akbooer,
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). For this to work you do need two Veras and openLuup with a bridge device for both. Each has a z-wave switch that is on the power of the other. So this way a stuck Vera is rebooted using a power cycle when it becomes unresponsive. Especially my Edge gets completely stuck every now and then, it is always when you cannot really have the hassle of restarting it manually if you even find out quickly. I can also create a plugin to do just this and have it work with just two Vera’s, but adding it to VeraBridge seemed simpler for me ;D
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.
Cheers Rene
[quote=“reneboer, post:64, topic:189405”]Hi akbooer,
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?
Hi akbooer,
Not a problem. I just thought of piggy backing on the Vera Bridge as it already points to a specific Vera. But I’ll make something separate then.
Cheers Rene
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).
Cheers Rene
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.
Can you provide some details on the new Installer process ?
About the upgrade process ?
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.
Suggestion: separate user data files… One for the location and user details… One for devices and one for automation
Or keep it as one but somehow allow… #include or #require to add another file with more data
Sent from my ONE A2003 using Tapatalk
Sent from my ONE A2003 using Tapatalk
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”.
VeraBridge: “urn:akbooer-com:service:VeraBridge:1” / “HouseMode” variable reflects remote machine’s Mode.
Done! … it was literally a one-liner. Development branch updated.
Thanks @logread!
How can you check the version of Openluup is up to date?
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules