Ideas for improvement…
The deal breaker here (for me) is that it doesn’t support PLEG, otherwise, I’d jump ship in the bat of an eyelid. Please reconsider this, please…
No reconsideration necessary, since it has always been under consideration…
…however, it’s Richard, not me, that you need to lobby. I’m fairly sure that a secure way to handle encryption and licence keys is well within the bounds of possibility.
I’d like to be able to take this data and push it to ThingSpeak (support provided by amg0) for statistics-over-time. Also the ability to trigger (#hooks) off the data as a watched variable.
[quote=“akbooer, post:1, topic:189397”]openLuup saves performance data as attributes in the user_data.json file, which is updated every 6 minutes. You can configure ALTUI to run a command to give you a glimpse of this under the Misc > OS Command page. Save this command line with the label “Stats” or such like:
cat user_data.json | grep Stats_Running it gives output like this:
"Stats_CpuLoad":"4.15%",
"Stats_Memory":"9.2Mb",
"Stats_Uptime":"3.96 days",The same data is accessible with the [tt]luup.attr_get[/tt] call.[/quote]
You could do this already if you installed EventWatcher, but you’re right, this should be an intrinsic part. The easiest thing would be a separate plugin device, but that’s a bit clunky (it would be odd to have an openLuup plugin in openLuup!) although I can’t see a good alternative if we’re to use the built-in AltUI support.
Yes, I saw this as an opportunity to do what Vera won’t do (without a plugin) for me or doesn’t do well. Basically give me information (logged and if possible - visually) relative to the operation of the product itself within it’s environment. In this case, performance statistics, connectivity, disk utilization and whatever else escapes me as I write this. Basically a set of defined agents …
Having the user_data.json file is a great feature. It would be fantastic if we could split it up in let’s say a local config and remote config. What I mean is that as I often synchronise with my vera I always need to integrate the openluup locally defined scenes. It would be nice if we had a distinction between these
Thanks
Don’t quite understand this. Are you talking about ALL device numbers changing if local OR remote machines change config? I did have a development version of the Bridge which separated device numbers into groups so that a small change didn’t affect much.
Maybe this is not what you’re asking at all.
I did also think of splitting out scene configuration, but again, with device numbers changing, that’s quite hard.
I’m prototyping a new version of VeraBridge which logically separates local and cloned devices from remote Veras (a bit like AltUI does, but in a way which is consistent with Vera device numbering.)
What this will do (I hope) is make device numbering of local devices totally unaffected by device additions or deletions on remote machines, and vice versa. This means that scenes will now be much more robust between device configuration changes, only failing if a dependent device (that is either a trigger or an action) is removed.
Hopefully, this will address some of the issues that configuration changes have given you. Especially if I can also split out, and then reload separately, all the scene definitions.
Edit: added in Release 5.5
I’m toying with the idea of getting VeraBridge to replicate scenes from a remote Vera to openLuup. These would be logically separate from any openLuup scenes, and if you wanted to edit them, you’d have to do so on the actual Vera. It means that you could the usual scenes interface on AltUI to fire those remote actions, without having to recreate the scene locally using the cloned devices.
Any thoughts on this?
[quote=“akbooer”]I’m toying with the idea of getting VeraBridge to replicate scenes from a remote Vera to openLuup. These would be logically separate from any openLuup scenes, and if you wanted to edit them, you’d have to do so on the actual Vera. It means that you could the usual scenes interface on AltUI to fire those remote actions, without having to recreate the scene locally using the cloned devices.
Any thoughts on this?[/quote]
Would that make it possible to then delete the scenes from the Vera and have openLuup run the scene logic controlling devices (and be triggered by devices) on the Vera?
That would be marvelous… I could then take probably a hundred scenes off my Vera and maybe then it would be stable for a change 
!
Sent from my iPhone using Tapatalk
I know this is where you want to go, but this is just a small step: it would allow you to run a scene on a remote Vera. How you trigger that scene is quite up to you.
That would be marvelous... I could then take probably a hundred scenes off my Vera and maybe then it would be stable for a change :) !
So you can do a lot of this already. Devices cloned by the bridge from the remote Vera can be used to trigger openLuup scenes, which, in turn, can run actions on remote Veras. What you CAN’T do on openLuup is set variables on remote devices except through using one of several HTTP requests which make that happen.
Seems I totally missed this post…
Well, you know already know my thoughts regarding Vera. I’m going to run every single scene I can on openLuup and just let Vera be a z-wave controller… Sorry but implementing bridged and local capability was love at first sight for me. Honestly though, I personally don’t have a need but others might. Would love to hear more about the road map for openLuup…
[quote=“akbooer, post:11, topic:189405”]I’m toying with the idea of getting VeraBridge to replicate scenes from a remote Vera to openLuup. These would be logically separate from any openLuup scenes, and if you wanted to edit them, you’d have to do so on the actual Vera. It means that you could the usual scenes interface on AltUI to fire those remote actions, without having to recreate the scene locally using the cloned devices.
Any thoughts on this?[/quote]
If I understand this correctly then openLuup would be able to clone both devices and plugins right? But any modifications would need to happen on the original vera. I like this idea.
My main wish for openLuup would be that it could also handle it’s own devices e.g. via a Zwave usb stick. This way I could have a mix of vera lite’s and some raspberry pi’s at strategic locations in my house to get the best possible zwave coverage and manage everything from one central openluup server.
Well this it does at the moment. What it didn’t do until today (I have it working in my development branch) was to give access to scenes.
I was actually thinking of removing the cloning of Vera-installed plugins, since they are not operational in openLuup (although locally installed plugins obviously are.)
But any modifications would need to happen on the original vera. I like this idea.If you're speaking of scene modifications, then yes, that's the idea. You can run it (you could even add additional local timers, triggers and actions) but you can't see or modify the timers, triggers, or actions that it has already and which are [u]only[/u] operational (and only editable) on the Vera.
My main wish for openLuup would be that it could also handle it's own devices e.g. via a Zwave usb stick. This way I could have a mix of vera lite's and some raspberry pi's at strategic locations in my house to get the best possible zwave coverage and manage everything from one central openluup server.Well yes, I understand. That's one of the reasons why I actually have multiple Veras. But for me, Vera IS the 'usb stick'. For other hardware (eg. WiFi, or MySensors Arduino devices) there are plugins already that handle that. I'm personally moving away from Zwave devices.
The serial protocol suported by most USB sticks is quite low-level and it would be hard to do, I think. Some come with C libraries that implement the Zwave stack along with some HTML insterface. This is a bit higher level. If someone wanted to write a plugin for openLuup to handle one of those sticks then it would fit in just fine - it’s exactly the same as writing a plugin for Vera, after all.
I’m mulling the possibility of cloning the ZWaveNetwork device (#1) into openLuup. This would allow plugins, which manipulate the Zwave network directly, to run. Most notably, this would include the RGBController with its colour wheel.
Obviously, this can only work for one remote Vera. It wouldn’t work for the second Vera if you had two VeraBridges running (or more.)
Would a scene migration tool/function be desirable? I haven’t look deeper to understand how openLuup manage and execute its own scenes, but I guess it is using the same scene definition format on Vera? If so, a migration is simply to map the device IDs correctly?
Thinking further, is there a switch on VeraBridge not to show scenes on Vera?
I have given it a bit of thought, but I do wonder how often it might be used.
I haven't look deeper to understand how openLuup manage and execute its own scenes, but I guess it is using the same scene definition format on Vera? If so, a migration is simply to map the device IDs correctly?It DOES use the same scene definition format (otherwise a lot of things wouldn't work) although it doesn't use (or even store) Vera-style triggers, preferring instead to go with the device variable watch triggers of AltUI.
It is not, in fact, quite as easy as you might imagine to deal with changed device IDs. This can be done for actions, but if if there’s any Luup code involved then it is essentially impossible to do, since important numbers could come from global variables, functions, other device variables, …
Thinking further, is there a switch on VeraBridge not to show scenes on Vera?No, but it could easily be done, and I have thought about it. My preference is actually to offer as few options on the bridge as possible, since every new option is something that complicates configuration. All scenes from bridged Veras go into the same room as all of its devices, named after the machine ID. By default, the scene page shows all scenes, but if you select "No Room" then you'll only see local scenes (assuming you haven't allocated them to a different room.)
If there’s wide support for the idea, I could pursue this further, so thanks very much for the suggestion. It would be possible to create these scenes in a separate room and initially disable them, but I’m worried that the scale of editing and further customisation required would completely negate the initial efficiency of automatically transferring them.
[quote=“akbooer, post:19, topic:189405”]I have given it a bit of thought, but I do wonder how often it might be used.
It DOES use the same scene definition format (otherwise a lot of things wouldn’t work) although it doesn’t use (or even store) Vera-style triggers, preferring instead to go with the device variable watch triggers of AltUI.
It is not, in fact, quite as easy as you might imagine to deal with changed device IDs. This can be done for actions, but if if there’s any Luup code involved then it is essentially impossible to do, since important numbers could come from global variables, functions, other device variables, …[/quote]
Ah, sounds like a messy road! Just trying to see if there is anything to help drive up openLuup usage.
If there's wide support for the idea, I could pursue this further, so thanks very much for the suggestion. It would be possible to create these scenes in a separate room and initially disable them, but I'm worried that the scale of editing and further customisation required would completely negate the initial efficiency of automatically transferring them.Good point. If there is a desire for this feature, I would be happy to help explore options.