Premise How to make a Scene do what you want.

[123]

Premise's Scenes: flexible, powerful, and sometimes a source of frustration! You make a Scene that is supposed to turn on lights and then turn them off but sometimes they don't all turn off. Why? How can Scenes be forced to do what you want?

Background
When you play a Scene, you set the state of a group of items. For example, a single Scene can turn on a TV, dim lights, turn up the thermostat, and set the volume to a desired level. A Scene can even include other Scenes (as well as Timers and Variables). However, I'll bet most people use Scenes to control a group of lights.

A Scene can have one of two types of "Behavior":

Set
"Set" behavior means a Scene will set all its items to a specified state. Enable the Scene's "Play" property, the item states are set and then the scene stops playing. "Set" behavior makes a Scene simply act like a macro: trigger it and it does its magic.

Set-Restore
Set-Restore behavior means a Scene will set all its items to a specified state while it is playing. When the scene stops playing, all its items are restored to their initial state. Enable Play, the item states are set. Disable Play, all items revert to their initial state.

"Initial state" does not necessarily mean off! Let's assume you have a Set-Restore Scene that turns on two lights. Initially, one light is on and the other is off. The Scene plays and turns on both lights. When the Scene ends, one light is turned off but the light that was initially on will remain on.

Why did Premise's designers make Set-Restore work this way? Because Set-Restore Scenes can be nested. Here's an example:

• Everything in the Home Theater room is off.
• Play the WatchMovie Scene and A/V equipment is turned on, lights dim, thermostat is adjusted, etc
• This evening you want a darker room so you manually dim the lights.
• While you are watching a movie, the phone rings and activates the PauseMovie Scene.
• The DVD player is paused, the lights brighten, etc.
• You answer the call. The moment you hang up (on-hook), you automatically stop the PauseMovie Scene.
• The DVD player resumes playing and the lights return to their original brightness which happens to be the level you had set manually and not what is dictated by the WatchMovie Scene.

The advantage of Set-Restore behavior is the ability of a nested Scene to 'put everything back the way it found it'. This advantage can also be a drawback because it cannot forcibly turn everything off! Here's an example:

• It is overcast outside and your home's interior is dimmer than usual. You turn on the lights in the Family room. You leave all others off.
• It is close to sunset and the Evening Scene plays. It turns on many lights including the ones in the Family room.
• At bedtime the Evening Scene stops playing and restores all lights to their initial state. That means most everything is turned off, except the Family room lights because they were already on when the Evening Scene started. In this case, we don't want the Evening Scene to restore the initial state, we want it to force all lights off.

In a perfect world, you would have a choice between "Restore to Initial State" and "Force Restore to Off". In other words, you should have the ability to have a Set-Restore Scene turn off everything when it finishes playing. The SceneStateEx module gives you that capability.



Solution
SceneStateEx extends Premise's SceneState class and adds a new property called "ForceRestoreToOff". Enable this property and when a Set-Restore Scene finishes playing it will turn off all Devices having a PowerState or State property. In practice this means it will turn off all Lighting and Appliance objects included in the Scene.

Simply import the SceneStateEx module and then review your list of Set-Restore Scenes. Enable the ForceRestoreToOff property for each Scene that ought to turn things off when it is finished playing. SceneEx records its activities in the debug log so if you have DebugView running you can see precisely what happens after a Scene stops playing.

Now a word about Tasks. Tasks appear in Builder's Schedule section. Each Task is a Scene combined with a Schedule. Given that it is basically a Scene, each Task will also feature the ForceRestoreToOff property.

 

[w84no1]

Thanks 123, I can't wait to get some devices so i can get everything running.

 

[123]

When is a bug a feature and a feature a bug?!?

The more I experiment with Scenes, the more I feel Premise's designers were either evil geniuses or mere mortals who overlooked a bug or two!

My Predicament:

I have a Scene called Evening that turns on several interior lights in my home. Evening can be activated by two conditions, Low Interior Lighting or a Scheduled Task:

1. Low interior lighting
   1. We are home (SecuritySystem is not armed away)
   2. It is within 2 hours of sunset.
   3. It is dim (as reported by an interior light sensor).
2. Scheduled Task
   1. A Scheduled Task runs shortly before sunset and turns on the Evening Scene. At 11:15 PM, the Task stops playing the Evening Scene.

You'd think the two conditions would work like this:

1. All Low-Lighting conditions are met, and the Evening scene is activated. Lights turn on (and they do).
2. Shortly before sunset, the Evening Scene is activated by the scheduled Task. The Evening Scene is already playing so lights stay on (and they do).
3. At 11:15 PM, the scheduled Task terminates the Evening Scene and lights are turned off (and they do not).
4. If you check in Builder, the Evening Scene is shown as playing (???).

It seems to suggest that Tasks handle Scenes in some special way. In an attempt to gain a better understanding of this 'special way', I carried out a few simple experiments. Here are my results:


Scenario 1: Evening Scene is not playing.
The scheduled Task will successfully start and stop the Evening Scene.

Scenario 2: Evening Scene is already playing.
The scheduled Task will successfully start but not stop the Evening Scene. Builder displays the Evening Scene as running.

So is this a bug? Maybe. Or it is another example of Premise's fiendishly clever ability to nest Scenes! In other words, a Task always creates an instance of a Scene. If the Evening Scene is already playing, the Task starts another instance of the Evening Scene! It ignores the fact that the Evening Scene is already running because it always creates a new instance. When the Task ends, it stops its instance of the Evening Scene. The instance that was already playing, continues to play because the Task is not controlling that one. Builder continues to report the Scene as playing.

Or else it's a bug. :blink:

Either way, it goofs up my ability to have a Task stop a Scene that is already running.

 

[123]

Now that I have a better understanding of how Scheduled Tasks handle Scenes (they run a copy of the scene), I revised my scripts.

Summary:

• If interior lighting is dim and we are home, the Task's start-time, normally scheduled to begin 15 minutes before sunset, is rescheduled to start immediately.
• When the Task reaches its scheduled end-time, its original start-time is restored.

Under normal use, a low-light condition will change the Task's start-time every day. However, it always has a default start-time (15 minutes prior to sunset). Typically, the default start-time is used when we are not home.



Details:

• I have a Scheduled Task, called Evening_Everyday, that starts the Evening Scene 15 minutes before sunset.
• I have an interior light sensor that triggers a script when interior illumination drops below a threshold.
• The script determines if the home is occupied and the time is within 2 hours of sunset.
• If the Evening Scene is not already running, it starts the Schedule Task, Evening_Everyday, immediately.
• In order to start Evening_Everyday immediately, the script alters the Task's StartOffset property as follows:
  • Schedule.Evening_EveryDay.StartOffset.Minutes = datediff("n", times.sysSunset(times.sysDate), times.systime) -1
• Evening_Everyday is scheduled to stop playing at 11:15 PM. When it stops, its OnChangePlay script restores the original StartOffset.
  • if sysevent.newVal = false then this.StartOffset.Minutes = -15

And there you have it, a Scheduled Task that starts if the lighting level is low or according to a schedule.

 

[Timoh]

So instead of stopping the scene which was *not* started by the scheduled task (because you can't=bug), you change the startoffset which actually stops the scene from play... irrespective of how it was started?
Tim

 

[123]

Umm, no. Originally, the Evening scene was started by either a scheduled Task or a script (due to a low-light condition). What I did not anticipate was that the Task would start a second instance of the Evening scene if the scene was already running (started by the script). As a result, two instances of the same scene were running and that caused some undesirable effects when the scenes ended and attempted to restore lights to their original state.

In the new scenario, the script no longer attempts to start the Evening scene directly. Now it simply alters the Task's start-time. The Task has exclusive control of the Evening scene.

 

[Timoh]

Right. That's what I understood, but poorly articulated. Instead of the "bug" or not, that starts a second instance, you reworked it so everything goes through a task=single instance.
Tim