Folks,
I am contemplating a new Plugin … This is motivated by the memory utilization used by Virtual Device plugins. They each require their own LUA context and 2 stacks for threads. That’s quite a bit of memory.
This would just be a controller Device that would allow you to create any number of:
a) Virtual Switches
b) Virtual Dimmers
c) Virtual Thermostats
d) Maybe Rex will let me create Virtual Multi-Switches.
You can then easily use any of these devices in your Automation Logic (i.e. interfaced with PLEG).
Since they look like existing device types they should work with all of the 3rd party apps.
Instead of large amounts of memory for each device … their is only a large chunk of memory allocated to the “Virtual Device” plugin.
All of the instances would be lightweight. It would be trivial to add more virtual device classes.
I am concerned about rumors that UI6 is more memory hungry than UI5.
Excellent suggestion. I like to use Virtual Switches in debugging, create one to basically display the state of various functions until I’m sure everything is working right and then deleting them to conserve memory. So anything that made these processes more efficient would be welcome.
As you know my VeraLite is on it’s last legs (memory wise) so anything that could make better use of the amount I have would be of huge benefit.
To help me understand what your are suggesting a little more, what is your definition of a ‘virtual device’, is that anything that is not a z-wave node?
If so, would this therefore benefit anything that is managed via just code (with or without an external controller e.g RFXtrx433, miLight Wifi Bridge, Phillips Hue etc?)
Many of my devices are technically dormant until I need to use them, so if it means they share a chunk of memory rather than each have their own dedicated chunk (assuming I’ve understood your goal correctly) it sounds like a huge efficiency improvement…
[quote=“RichardTSchaefer, post:1, topic:179005”]Folks,
I am contemplating a new Plugin … This is motivated by the memory utilization used by Virtual Device plugins. They each require their own LUA context and 2 stacks for threads. That’s quite a bit of memory.
This would just be a controller Device that would allow you to create any number of:
a) Virtual Switches
b) Virtual Dimmers
c) Virtual Thermostats
d) Maybe Rex will let me create Virtual Multi-Switches.
You can then easily use any of these devices in your Automation Logic (i.e. interfaced with PLEG).
Since they look like existing device types they should work with all of the 3rd party apps.
Instead of large amounts of memory for each device … their is only a large chunk of memory allocated to the “Virtual Device” plugin.
All of the instances would be lightweight. It would be trivial to add more virtual device classes.
I am concerned about rumors that UI6 is more memory hungry than UI5.[/quote]
This is a good initiative, Richard. It could save a considerable amount of memory in configurations with several virtual devices - which is probably the case for most of us.
Maybe Rex will let me create Virtual Multi-Switches.
Absolutely. MultiSwitch already uses much less memory than eight individual virtual switches but still too much for such a simple function.
Since they look like existing device types they should work with all of the 3rd party apps.
Unless you can keep the device-type identical to the Z-Wave version, the next released version of AutHomationHD (currently in apha testing) will need to have your device-types added.
If you do, please consider…
Many of us rely heavily upon Virtual Switches, Multi-Switches, and Variable Containers - along with PLEG (and thank you for that!).
Thus, I hope there is an easy migration path to your new plugin. For example, changing all PLEG devices and associated items (triggers, actions, etc) inside would be a nightmare to change. I don’t know exactly the best solution - Maybe someway to export - modify - import with PLEG? This still leaves the native Vera items.
[quote=“RichardTSchaefer, post:1, topic:179005”] This would just be a controller Device that would allow you to create any number of:
a) Virtual Switches
b) Virtual Dimmers
c) Virtual Thermostats
d) Maybe Rex will let me create Virtual Multi-Switches.[/quote]
great idea! please consider adding “Variable Containers”
@richard: If you think there would also be an advantage concerning the memory footprint, I would of course agree if you integrate the Variable Container. Feel free to use any of the code (…I guess you’ll do it bether anyway…).
Still a little proud to see that my plugin as simple as the Container is used so often
Variable Container… well I found yet another new use for it just yesterday. I have weather underground plugin working on one vera, needed the info on my other bridged vera… Variable Container to the rescue. I save the memory no having to install another instance of WU by making calls in a scene that runs every hour, just as my weather updates.
Its a great little app, so hats off chixxi.
Richard,
Since the learning curve for vera is a little steep (I’m talking about a very rich experience, not just turning on lights at night or your thermostat) I feel that a huge opportunity exists to improve the UI and integrate the works of others. I am jealous of future Noobies, who will surely have it easier than us!
[quote=“BulldogLowell, post:17, topic:179005”]Variable Container… well I found yet another new use for it just yesterday. I have weather underground plugin working on one vera, needed the info on my other bridged vera… Variable Container to the rescue. I save the memory no having to install another instance of WU by making calls in a scene that runs every hour, just as my weather updates.
Its a great little app, so hats off chixxi.
Richard,
Since the learning curve for vera is a little steep (I’m talking about a very rich experience, not just turning on lights at night or your thermostat) I feel that a huge opportunity exists to improve the UI and integrate the works of others. I am jealous of future Noobies, who will surely have it easier than us![/quote]
@BullDog, I had to remove my Virtual Containers and MultiSwtiches to get my Bridged Vera to work at all … and its still not 100%. Tech Support has worked this problem for over a month now and the only way we could get switches, sensors, et al to replicate was to remove the VC and MS components from the Secondary Vera. I have MS installed and in use on the Primary but things from the Secondary would not replicate properly until we removed the VC and MS from the Secondary.
Right now i’m getting most of the status changes from the Secondary replicated on the Primary but i’m still not comfortable that the two are tracking close enough to make use of them.
I quit working on this earlier this year when MCV indicated that they had new Vera’s coming out later in the year.
I (wrongly) assumed they would solve the memory issue and this would not be needed …
I will look into again after the first of the year.
