Pass Device Value as Script Parameter?

[Uncle Michael]

Send Value(s) directly to Script
- reduces code needed
- faster execution of scripts (reduces code & system calls)

I suspect that the code to implement this scheme will actually be significantly greater than the code required without it. The only code that disappears in the script is the line that assigns the value to a variable, but the script would still need to have code to know where to use the value in the script logic. (Plus, of course, there's all the code 'behind the scenes' that defines the function.)

Send Value(s) directly to Event
- eliminates need for script completely, and for the mess / over-reliance on vDevice to hold state values and such (aka workaround for lack of proper way)
... this would require Events could receive values, like scripts do... potentially reducing some need for scripts, in some cases, at all. At very least reduce unnecessary vDevices

This is intriguing, but I'm still catching up. Events can receive values now, as in the example below. Can you give an example of how else you see values being used in events?

As far as eliminating virtual devices, how do you envision storing state values, such as occupancy, for example?

[Ltek]

I suspect that the code to implement this scheme will actually be significantly greater than the code required without it. The only code that disappears in the script is the line that assigns the value to a variable, but the script would still need to have code to know where to use the value in the script logic. (Plus, of course, there's all the code 'behind the scenes' that defines the function.)

This is intriguing, but I'm still catching up. Events can receive values now, as in the example below. Can you give an example of how else you see values being used in events?

As far as eliminating virtual devices, how do you envision storing state values, such as occupancy, for example?

I don't think you are grasping what I'm saying. Currently, in order to 'pass' an Event a value (any value) it must be stored in a device. I'm talking about eliminating that completely...

Inside the Event you could create a variable/value pair (not tied to a Device)... then you could 'send' that to an event.

ut, since we don't have the right event engine, even using it with what we have could do some cool things. In this case, keep track of that last House Mode, before setting a new one...

THEN
Set Variable $HouseMode-1 = <RefID435.Value> ... HouseMode device
Set Device HouseMode to 'Away'

(another Event using the one above to create a 'stack' of prior HouseModes)

Set Variable $HouseMode-2 = $HouseMode-1
Set Device HouseMode to 'Home'

... not sure if or how you could do it in a vDevice?

I will ask Spud if he can add this to Easy Trigger. If he doesnt, I may write a script to do this but a script is far from ideal as it create more complexity I prefer to avoid.


Now, if we had a proper IF THEN event engine this would be much more powerful as you could set the variable to different values depending on the branch.

IF THEN $VAL="ABC"
ELSE $VAL="XYZ"
ELSE $VAL = "123"

[Uncle Michael]

You are definitely correct that I am not grasping what you are saying.

The biggest problem I am having is that whenever a value is saved to be retrieved later for some other purpose, it has to be save somewhere, and there has to be a record of where it is. That is exactly what is happening when you save a value in a device. Yes, HS could save all values "behind the scenes", but that would require some sort of database, which could conceivably add substantial overhead, and certainly complexity. Keep in mind, that there is no way for HS to predict ab initio which values will be uses when, if ever, so everything would need to be saved indefinitely. Is that what you have in mind?

What I'm missing is how such a capability helps. I am struggling to think of a situation where I'd make use of it. So, it's either something that I don't need or it's something I just do not understand at all.