openLuup: Suggestions

[akbooer]

Ideas for improvement...

[zedrally]

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....

[akbooer]

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.

[CudaNet]

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.

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:

Code: [Select]

cat user_data.json | grep Stats_

Running it gives output like this:

Code: [Select]

  "Stats_CpuLoad":"4.15%",
  "Stats_Memory":"9.2Mb",
  "Stats_Uptime":"3.96 days",

The same data is accessible with the luup.attr_get call.

[akbooer]

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.

[CudaNet]

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 ...

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.

[delle]

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

[akbooer]

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. 

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.

[delle]

Thanks @akbooer
Splitting up the files is exactly what I meant.  I understand this hard to achieve

[akbooer]

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

[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? 

[mda]

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?

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

[akbooer]

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?

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.

[CudaNet]

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..

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?

[jcsv75]

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.