The most essential “basic” use case (“requirement”) that I have for save / restore is for short term temporary events.
Example:
- (a) My outdoor lights are set to a pleasing evening level, perhaps even with a few colors, using a nightly Hello Home Action; (b) An intrusion detection device (motion or window sensor) senses someone on the property and a SmartApp subscribes to this, and as a results, brings the lights up to full brightness. This might even be an appropriate response for my car entering the driveway – bring up the lights on the driveway to make it safer to see the road.; (c) a few minutes after the intrusion is over, I want the lights restored to the level they were at prior to (b).
Of course there are a few ways to handle this, particularly since (a) is established using a Hello Home Action – i.e., it is possible in this scenario to simply re-run the Hello Home action that applies to the current Mode…
BUT: In the more general case, I may have turned on a set of lights MANUALLY for a particular reason. Maybe the dog went into the yard and I adjusted SOME of the lights to see him. Regardless, if a temporary event caused by some SmartApp which changes the current settings (the live scene), then I want that live scene restored after the event has passed. The event could be a smoke detector false alarm, etc., etc., etc…
2. The state of my Sonos player is an example of a scene element. If it is playing a certain song, that song should be resumed, on the same set of speakers, after any messages are spoken due to an alert (“Mom’s home.”).
3. The state of a door lock can be considered a scene element. If my door is locked and I temporarily unlock it to allow a guest in, then the door should return to the locked OR unlocked state if it is in automatic restore mode. This saves me from writing complex logic to reference what the state of the lock should be after the event (e.g., If Mode = evening and all kids aren’t home, then leave door unlocked. If Mode = night, then lock the door, even though I went outside to walk the dog and purposefully did not lock the door behind me because it was a short walk and I expected that to be the state when I returned) – sure I’m stretching, but I’m demonstrating that the possibilities are numerous.
4. How about the state of a thermostat? Bring up the heat for an hour because I’m chilly, then restore to the previous temperature setting.
To deal with your concern:
… it is sufficient to put rules on the restore process so that it only applies in specific cases. If it turns out that we compromise and scene restore is only needed for temporary actions, then a “saved state” should have a limited lifespan. Alternatively, as I suggested in another post, a “saved state” can only be restored if the Mode is unchanged since the time of save.
If multiple overlapping scenes or individual state changes occur, then it is reasonable to default to some sort of functionality, even if it isn’t the most optimal or intuitive. Is a stack of scenes appropriate, perhaps not. Is it sufficient to say that a restore scene is no longer possible if any overlapping scene is executed after the save, … ok, I can live with that. In short: I can live with elimination of complexity, but I strongly disagree that we should throw this baby out with that bathwater.
…CP.