I propose that PLEG be modified to include Constants. Similar to the definitions for Triggers, Schedule, Device Properies would be a fourth tab “Constants” where fixed values may be defined for use in Conditions.
Not that I disagree, but can you give a use case for use in PLEG? I’m curious how you would use them.
Not that I disagree, but can you give a use case for use in PLEG? I’m curious how you would use them.[/quote]
Examples, Temperature Threshold, Light Level Threshold, Start Time, etc. for comparison with current values.
I had been using Variable Container for these (and would still perfer to do so) but Tech Support told me today that they suspected VC was causing my response time problems and asked that it be removed. I did and my response time problem appears to have gone away.
Not that I disagree, but can you give a use case for use in PLEG? I’m curious how you would use them.[/quote]
Examples, Temperature Threshold, Light Level Threshold, Start Time, etc. for comparison with current values.
I had been using Variable Container for these (and would still perfer to do so) but Tech Support told me today that they suspected VC was causing my response time problems and asked that it be removed. I did and my response time problem appears to have gone away.[/quote]
Interesting, I was about to use VC as a way to store a room’s previous settings before running something (so for instance, if I start a movie, I can restore the room to it’s previous mode, or even our Master’s “Nap Mode”). I guess I will hold off for now on doing that.
I haven’t raised this with the developer as yet but Tech Support seemed quite positive. And as I said things appear to be better.
He also said that the CPU numbers reported by Event Watcher were wrong and asked that I remove it for testing which I did … however removing it did not seen to have any impact.
You can do this in PLEG already!
Work Flow:
-
Open the Advanced Editor.
-
Create a New Variable.
Create your own ServiceID, use it for all of your variables.
i.e. Name: LightLevel
ServiceID: clippermiamiName: TemperatureSetpoint ServiceID: clippermiami -
Then bind to these variables using device properties.
-
You can set these varuables using luup.variable_set
OR the advanced tab of a Scene or PLEG/Action using the SeVariable Action of PLEG.
NOTE: You can attach these variables to ANY Plugin or Device!!
This does not provide a USER Interface on the Dashboard, but saves a LOT of memory compared to used a PLUGIN device.
RTS, how are these maintained between restarts? Do they keep their values that were last set?
[quote=“RichardTSchaefer, post:6, topic:184350”]You can do this in PLEG already!
Work Flow:
-
Open the Advanced Editor.
-
Create a New Variable.
Create your own ServiceID, use it for all of your variables.
i.e. Name: LightLevel
ServiceID: clippermiamiName: TemperatureSetpoint ServiceID: clippermiami -
Then bind to these variables using device properties.
-
You can set these varuables using luup.variable_set
OR the advanced tab of a Scene or PLEG/Action using the SeVariable Action of PLEG.
NOTE: You can attach these variables to ANY Plugin or Device!!
This does not provide a USER Interface on the Dashboard, but saves a LOT of memory compared to used a PLUGIN device.[/quote]
Thanks.Tthe idea of suggesting it in PLEG is that it DOES provide a user interface for maintaining them … not as convenient as the Variable Container perhaps (changes in the VC values do not require a Vera Restart) but still straightforward and documented in PLEG.
RTS, how are these maintained between restarts? Do they keep their values that were last set?These are stored persistently to the devices they were created with. This strategy works for LUA programming as well.
[quote=“RichardTSchaefer, post:9, topic:184350”]
RTS, how are these maintained between restarts? Do they keep their values that were last set?
These are stored persistently to the devices they were created with.
This strategy works for LUA programming as well.[/quote]
One more question then… You say to “create” the variables, but I assume this will be a 1 time action (no need to create them once they are created), so would you create a condition/action to create them, then just delete that action? What would your suggestion be for handling the initial creation of the variables and their initial population?
Thanks
(and Sorry @clippermiami for hijacking your thread a bit. I do like the idea of having constant variables.)
[quote=“SirMeili, post:10, topic:184350”][quote=“RichardTSchaefer, post:9, topic:184350”]
RTS, how are these maintained between restarts? Do they keep their values that were last set?
These are stored persistently to the devices they were created with.
This strategy works for LUA programming as well.[/quote]
One more question then… You say to “create” the variables, but I assume this will be a 1 time action (no need to create them once they are created), so would you create a condition/action to create them, then just delete that action? What would your suggestion be for handling the initial creation of the variables and their initial population?
Thanks
(and Sorry @clippermiami for hijacking your thread a bit. I do like the idea of having constant variables.)[/quote]
No problem, your question is interesting too. Although as I said I think putting them in PLEG allows for internal “documentation” and maintenance rather than “writing it down somewhere” 
Obviously i’d prefer to see them in the Variable Container but since I removed it my system has returned to near normal operation so it looks like Tech Support found the problem.
(As an aside I have asked Tech support for more information on why he thinks this is the problem and what he was seeing it do, I’d like to make sure the developer gets this information so he can do his own investigation, I found the VC to be pretty useful)
When you attach variables to a device in the Advanced tab … you can view/update the variable there as well … You just need to remember what device you attached these to …
Ah, remember. Is easy for you is not so easy for others
I guess I will muddle through with hard coded values in my PLEG until the VC “problem” can be verified and fixed if appropriate.
[quote=“SirMeili, post:10, topic:184350”][quote=“RichardTSchaefer, post:9, topic:184350”]
RTS, how are these maintained between restarts? Do they keep their values that were last set?
These are stored persistently to the devices they were created with.
This strategy works for LUA programming as well.[/quote]
One more question then… You say to “create” the variables, but I assume this will be a 1 time action (no need to create them once they are created), so would you create a condition/action to create them, then just delete that action? What would your suggestion be for handling the initial creation of the variables and their initial population?
Thanks
(and Sorry @clippermiami for hijacking your thread a bit. I do like the idea of having constant variables.)[/quote]
The act of writing a value to a device variable that doesn’t exist will create it. You can do this from the Advanced tab of the device you want to attach the variable to by clicking the Add button. You should previously have entered values for New service, New variable and New value. It is good practice to define a custom service ID to avoid contention with existing or future system variables. An example would be:
[b]urn:SirMeili-com:serviceId:Constants[/b]
You can also get the same result by using a Lua call:
luup.variable_set("urn:SirMeili-com:serviceId:Constants","<name>","<value>",<deviceno>Note that reading a non-existent variable will get you the value nil.
[quote=“RexBeckett, post:14, topic:184350”]The act of writing a value to a device variable that doesn’t exist will create it. You can do this from the Advanced tab of the device you want to attach the variable to by clicking the Add button. You should previously have entered values for New service, New variable and New value. It is good practice to define a custom service ID to avoid contention with existing or future system variables. An example would be:
[b]urn:SirMeili-com:serviceId:Constants[/b]
You can also get the same result by using a Lua call:
luup.variable_set("urn:SirMeili-com:serviceId:Constants","<name>","<value>",<deviceno>Note that reading a non-existent variable will get you the value nil.[/quote]
Thank you for this Rex. I had just mostly figured this out when I saw your post.
quick question though:
Once a variables is created, is there a way to delete it without deleting the plugin/device? This is just more for future use in case I need to change something.
@RichardTSchaefer, Even though I am fine with doing it this way, I am starting to think that at least having these variables show up in the status report would be nice. Of course I have no idea how hard it would be to do that. Would it be possible to pull all the variables for a given service and just dump them? Just a thought.
Edit, I think the above would no necessarily be necessary if you bind these variables to device properties, so that last request might not be needed since they would still show up in the status report, just not easily edited unless you go to the advanced tab.
Once a variables is created, is there a way to delete it without deleting the plugin/device? This is just more for future use in case I need to change something.
'fraid not. Make sure you think through names, service ID and which devices to use before you start creating them. 
Edit, I think the above would no necessarily be necessary if you bind these variables to device properties, so that last request might not be needed since they would still show up in the status report, just not easily edited unless you go to the advanced tab.
Yes - if you use them as Device Properties, they will show on the Status report.
[quote=“RexBeckett, post:16, topic:184350”]
Once a variables is created, is there a way to delete it without deleting the plugin/device? This is just more for future use in case I need to change something.
'fraid not. Make sure you think through names, service ID and which devices to use before you start creating them. ;)[/quote]
(below is more of a train of thought instead of a well though out comment…LOL)
This right here is what kinda makes it worth it to be able to set a “constant” input then. As my system evolves and changes, I may end up with a ton of extra variables that just aren’t used and hard to manage (could, not necessarily if I give enough forethought).
That said, I know that you can use
So @clippermiami, maybe you could just create conditions with static values? like name: c_constantValue1; expression:30. It is my understanding that would set the value of “c_constantValue1” to “30” and you could use it in other conditions. Not as nice as having a separate area for it, but not a horrible alternative.
@RichardTSchaefer and/or @RexBeckett, would that work?
edit: Nope, that doesn’t work. It lets me create the condition with an expression of “30”, but it won’t evaluate any conditions that have it in it (They have nil as the state).
edit2: Or, I had a typo in those 2 conditions. The above actually does work. (I added an image of my 3 test conditions)
[quote=“SirMeili, post:17, topic:184350”][quote=“RexBeckett, post:16, topic:184350”]
Once a variables is created, is there a way to delete it without deleting the plugin/device? This is just more for future use in case I need to change something.
'fraid not. Make sure you think through names, service ID and which devices to use before you start creating them. ;)[/quote]
(below is more of a train of thought instead of a well though out comment…LOL)
This right here is what kinda makes it worth it to be able to set a “constant” input then. As my system evolves and changes, I may end up with a ton of extra variables that just aren’t used and hard to manage (could, not necessarily if I give enough forethought).
That said, I know that you can use
So @clippermiami, maybe you could just create conditions with static values? like name: c_constantValue1; expression:30. It is my understanding that would set the value of “c_constantValue1” to “30” and you could use it in other conditions. Not as nice as having a separate area for it, but not a horrible alternative.
@RichardTSchaefer and/or @RexBeckett, would that work?
edit: Nope, that doesn’t work. It lets me create the condition with an expression of “30”, but it won’t evaluate any conditions that have it in it (They have nil as the state).
edit2: Or, I had a typo in those 2 conditions. The above actually does work. (I added an image of my 3 test conditions)[/quote]
So then to populate a bunch of these with various values that could be used globally as need be. Not bad. But you KNOW the value you want to use will not be there Murphy’s Law is immutable
Correct, the idea of a “constant” is that it never changes, so the only difference here is that it is stored as a “conditions” and not as an “input” as far as PLEG is concerned. The only thing is that those values are truly constant. In my example, that condition will only ever be 30 unless you change it in the PLEG device settings. You can’t change it programatically like you could a device property.
I would however, push all the constants to the top of the conditions page as I believe they are evaluated in order (top being the first). This way you know that all your constants are available to all your ‘normal’ conditions.
IMO a “Global Constant Container” would be very valuable - something like the Variable Container, but that can hold many, many more items.
… and it would reduce the size and replication/duplication of putting each into multiple PLEG devices. For Instance… I have 3 PLEGs that share at least a dozen inputs between them. It would be nice to define them once and have PLEG see them all from any PLEG device.
You may ask, why not combine the PLEGs… good question. Separation allows me to keep logic clean and partitioned - troubleshooting and adds/changes are WAY easier. I separate Occupancy logic, Security logic (house modes based on occupancy + time of day + other stuff), and Alerts/Notifications (based on many, many stuffs).
I was using VC for a while - it worked pretty well and did some cool things for me like tracking previous Home Modes. I was basically using what developers call a ‘stack’ (thus, I could recall a home mode). I no longer use/need stacks so I converted to MultiSwitches to gain ability to use constants that could be both visual (Authomation, Web, etc) and programmatic (PLEG, etc) status at the same time. I lost ability to easily store global variables/constants - which kinda sucks but I have worked around it but as my PLEGs grow, constants become more needed to reduce size and complexity of logic.