Conditional "extras" inside an Activity

#1

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 :wink:
Any hints ?

Thanks! Great plugin btw!
This should be embedded in the core of a VERA !

#2

[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 :wink:
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.

#3

Hi, just coming back to this. Studied 35 years ago Turbo Pascal ;o) and still in the If Then logic … I love your plugin, thanks a lot. What I want to do is very simple. I can do it in a script, but trying to use your interface seems more difficult to me. I would like to use only one Reactor Switch called Sunset, I know I could use two. So I would like to know if it was possible to do it with your logic.
My example is very simple:

On Sunset
If HomeCinemaSwitch is OFF then
Switch ON the living room light
EndIf
SleepingRoomBlinds = Down (in all cases).

I’ve seen that I can call Lua scripts in activities, but this is not the goal at this point.

Thanks for your help.

#5

Make the root group use the AND operator, and put in the device state condition to test your switch, and a subgroup. In the subgroup, put the sunset condition.

In Activities, put the action to lower the blinds in the true activity for the subgroup. Put the activity to turn on the light in the root group’s true activity.

#6

Thanks will see tonight.

#7

Looks like you are on the right track, but I think you want your SwitchHomeTheater actions to be in the is TRUE activity, because the group will be true when the switch is off (based on your original request).

#8

Ok, my fault. Maybe more adequate to say in conditions SwitchHomeTheater = 1? and let the Activity to False?
But at midnight due to the Sunset reset, my lights switch on!

#9

Using “between” instead of “after” may help. Lots of ways to do it.