[quote=“jvanhambelgium, post:1, topic:200543”]I wonder if I could accomplish this inside a single Reaktor instance…
So my Reactor sensor has a very simple “Condition” , basically if my TV can be “pinged” (so a check if the thing is on).
IF that is the case, I currently have a simple set of sequenced activities :
1/ Issue a DLNA “Mute” to a running speaker
2/ Dim some LED-strip thing to 5% (vs normally 20% when TV is not running)
3/ Dim some HUE lamp back to 30% (vs normally 100%)
At some point in the evening, all these lamps get fired up also with another Reaktor sensor (LED wil do 20% brightness, HUE lamps will do 100%) typically X time before sunset.
Now things is … if I watch television in the DAY I want to avoid the HUE lamps from going on. The LED-strip during daytime cannot go online anyway since I shut the power-supply anyway at night.
But running the TV during daytime results in HUE lamps suddenly coming ON at 30% and when I switch the TV OFF they go to 100% (100% is in the “Untripped” activities panel.
Solutions : Sure I could make 2 “separate” Reaktor childs where 1 would trigger only if I consider it to be “not during the day” and the other execute only during day.
1/ Condition “ping OK” + Check if still day (I can do that by checking LUX-levels or check if the other Reactor has “fired” at Sunset) => My “Activity” would then only MUTE the DLNA speaker as I don’t want stuff to happen with any lights. As “untrip” action I only bring the sound of radio back when the TV is off (and thus the ping “fails”) That’s is.
2/ Condition “ping OK” + Check if NOT day anymore => Activity would contain everything I now have; dim LED, dim/set HUE, mute RADIO too etc and similar untrip action.
My question is if such can be modeled into a single instance. I’ve taken a look at the documentation on the “Expressions” but to be honoust …I’m missing some nice examples in the Wiki 
Any hints ?
Thanks! Great plugin btw!
This should be embedded in the core of a VERA ![/quote]
Unfortunately I’m traveling and can’t give you a comprehensive response. But, take a look at this post: http://forum.micasaverde.com/index.php/topic,111299.msg441102.html#msg441102 . Here I lay out a trivial “pool control” condition that (ostensibly) would turn on pool equipment at a different time of day based on the season. Your approach could be similar: build up a series of variables (more or less depending on your tolerance for looking at complex expressions), and use those variables to ultimately produce values that can be used in conditions or activities.
The linked example shows a condition with an “is true” operator against a boolean-producing expression/variable. But the expression can as easily produce a number or string, whatever is useful.
The service actions (and service conditions, in fact) can use a variable value by surrounding the variable name in “curly braces”. For example, let’s I have a variable/expression (or a series of them working together) that ultimately results in the number 0 during the day, 100 at night, and 30 at night when the TV is on, and I call it “brightness.” I can then use this variable/value in a service action to set the brightness of my LED strip: where the service action asks for the target load level, I enter “{brightness}”. When the action runs, whatever the computed value of brightness then is will sent in the action to the device.
Building up logic in expressions will make liberal use of the [tt]if()[/tt] function, usually. This function operates in the same manner as the function of the same name in Microsoft Excel and most similar spreadsheet applications. The first argument is an expression that produces a value, which is expected to be boolean (or can be coerced to boolean, e.g. 0=false, 1 or any other non-zero value is true; empty string “” is false; anything else is true). The second argument is an expression to evaluate when the first expression is true; the third argument is an expression to evaluate when the first expression is false. So, [tt]if( true, 123, 456 )[/tt] would return 123, while [tt]if( false, 123, 456 )[/tt] would return 456. In this way, expressions can make decisions.
The getstate() function can fetch the value of a device’s state variable. This requires that you know the device number or name, service Id of the variable, and name of the variable. To make that easier, there’s a “getstate insert tool” on each expression row that presents a simple UI to allow to pick a device and variable as you do in Conditions. You can use the result of getstate() in if() expressions as part of the test expression, or the result expressions.
There are many other functions. The Wiki documents those that are special to Reactor, while the LuaXP documentation documents the standard functions. The standard functions give you access to strings, time, etc.
I urge you to play around with all of this and see what you can discover.
And don’t feel like you need to cram all of the logic in one expression, or all of the conditions in one Reactor. I think this is one of the biggest reasons people can’t figure out their logic and stall out trying to get started: they try to do it all at once. As the old kids’ joke says, “how do you eat an elephant?” The answer: “one bite at a time.” Start by breaking everything down to its individual steps. ReactorSensors are cheap and fast. Within a single Reactor, expressions can refer to other variables/expressions. Among ReactorSensors, they can “sense” each other’s tripped state as they would any other device, and the result of variable/expressions in one ReactorSensor can be read and used by another (the variables you create become state variables on that ReactorSensor that you can access in the Conditions or getstate() of another). If you make things overly complex, you’ll have a tough time debugging it, and you’ll have a tough time remembering what it does after six months of not looking at it. Take each logic element in small steps and build it up. As you get more certain with each element, you can combine things where it makes sense.