Optimize my setup - to chunky?

[mrhaugland]

1) Give a description of the problem
I know Im asking alot here, and I appologise for the long post, but here goes…

I have been playing around with Webcore for a week now, and I have sort of created a system that works for our family. It has a few “bugs” (created by me), but for now Im thinking about the overall picture of it. And since I have little experience, I wonder if I am setting myself up for fail when I expand with more devices in the future? I wonder if the idea behind my setup could / should be optimized / simplified? I am pretty sure that the following screenshots looks like a clusterf*** to the more experienced user, and I am not surprised if you shake your head in bewilderment

To clearify the text below, make note that when I use the word “mode”, I am not talking about “LocationMode”. I use the word “mode” to describe the “state of the house”.

The major lines of this setup:

• A panel running ActionTiles with Routines (only turning on virtual switches) for the three “modes” of the house: Home, Away and Good Night. I find presence to unreliable, and with two kids, one of them without a phone, I need something they can use as well. Setting the modes manually also lets me bypass the “nanny-spending-the-night” situation, and (IMO) making an intuitive setup for my wife, kids and guests.

• A piston that change the “home” - locationmode when we are the mode “home”, based on the time of the day (thanks @Robin). This allows for different light levels depending on time of day (bulletpoint below). We manually trigger the mode “home” when we wake up or arrive back home, and this piston change the locationmode within “home”, setting it to either “home-morning”, “home-day”, “home-evening” or “home-night”.

• Pistons for “away” and “good night”, triggered by virtual switch via routine / ActionTiles. I think these are pretty straight forward.

• Pistons for each room (thanks @faze) , that regulates light levels and settings, depending of time of day when home. These are clunky, and could probably be made more effective (?). Within these pistons lights are regulated based of:
  1 - motion OR 2 - when routine for home is exectured OR 3 - when virtual switch “home” is turned on.
  The routine “home” turns the home-switch on. But since I want lights to turn on instantly when this routine is executed, I have set my home-piston up so that it flips the switch off and on again. This allows my locationmode-piston rund, setting the correct locationmode for my room-pistons. (yeah…)

This is one of my biggest headaches, because I want the lights to turn on right away when routine “home” is executed within the correct locationMode, not wait for the motion to be registered.

2) What is your problem?
My problem is that there are so many scenarios to take into consideration:

• Turn on lights when routine is run and/or when motion is registered, within a specific locationMode to set correct level, but not if away, good night or movietime switch is on. Trying to account for all of this makes the pistons really chunky, and I have probably created more rules than needed.

3) What is happening/not happening?
Everything seems to be working (tested for a day now), with exception of some lights not turning on in sleep mode (I reckon there is just something I have overlooked, not the issue of this post). It could be faster, but not sure if the delay is piston-related or ST-related…or both! So my question is: am I setting myself up for failure here, will this crash and burn as I expand with more rooms and more devices? Or am I actually on to something that could work in the long run? And if you find the time, how would you guys - the experts - set this up?

Thanks for your time.

4) Post a Green Snapshot of the piston
I am excluding the screenshots of away, good night, and two of the three rooms I have set up.

[WCmore]

It could be faster, but not sure if the delay is piston-related or ST-related…or both!

I am not at a computer at the moment, but I notice that all 3 pistons you have listed above are ran simultaneously when Routine executes Hjemme. To keep delays to a minimum, the ideal structure will only have ONE piston firing off when something happens. (although I have been known to ‘Daisy-chain’ pistons occasionally, only one of them will have the trigger, and I usually add a small WAIT between pistons so multiple things are not happening all at once)

am I setting myself up for failure here, will this crash and burn as I expand with more rooms and more devices? Or am I actually on to something that could work in the long run?

I would definitely NOT expand upon this any further until the above issue is addressed. You are already on the borderline.

[mrhaugland]

Thanks @WCmore, solid advice!

I could let my room-pistons only be triggered from motion.
And I could let my time schedule piston be triggered by scheduled time, if home-switch is on.
And I could let my home-piston be triggered by the execution of the routine…

But this leaves me back to how I get lights turned on with the correct setting depending on what time (which states locationmode) it is

[WCmore]

To expound upon my last post a bit… Having 18 triggers in one piston means whenever ANY one of them triggers, the entire code is ran thru looking for matching conditions.

this leaves me back to how I get lights turned on with the correct setting depending on what time (which states locationmode) it is

I would plug in the condition for that inside your motion sensor piston.
(a condition will NOT run thru the code when it changes, while a trigger will)

One trick that I often employ is deciding first, how I want the room. (lights on/off, what levels of brightness etc) I can code all of that ‘scene’ into a single piston, with NO triggers whatsoever. Then, in my ‘Welcome Home’ piston, and my Motion Sensor piston, I can just execute that other piston to set the lights to my preferred levels. It does mean creating a few pistons per room (one for each ‘scene’) but it keeps pistons streamlined since any piston can trigger that ‘scene’ whenever.

In other words, when I create my ideal ‘scene’ in a piston, I assign no brain power whatsoever to that piston. All the logic is done in another piston, and depending on what it finds, a single piston is executed to activate that ‘scene’.

[mrhaugland]

Grateful for your help, @WCmore !

Could this translate to something like this:

Piston "MotionLivingRoom"
IF motion active THEN run piston “SceneLivingRoomDay” (which turns on livingroom lights at given level which is stated in Piston “SceneLivingRoomDay”)

Piston "NoMOtionLivingRoom"
IF motion inactive THEN run piston “SceneNoMotion” (which turns off livingroom lights after given waiting time which is stated in piston “SceneNoMotion”)

Repeat pistons for number of rooms and scensors.

Piston "Welcome Home"
If routine “Home” is executed THEN run

• piston “SceneLivingRoom”
• piston “SceneHallway”
• piston “SceneKitchen”

How is it recommended to account for multiple factors, like time of day?
Should I put the time specification within “MotionLivingRoom” as another IF, or should I use it as a restraint? Or somewhere else?
IF motion active AND time is between sunrise and sunset THEN run piston SceneLivingroomDay
IF motion active AND time is after sunset and before sunsire THEN run piston SceneLivingroomNight
I easily see myself winding up in chunkytown again!

Is global variable recommended?
I`ve read something somewhere around here (I think?) which have put me off using global variables. I can see with a setup like this that they would really come in handy.

[WCmore]

All that could work. If I could make a small tweak to that logic. When you come home, since you want multiple rooms to turn on a specific way, you could make all of those light adjustments in one piston, and just call that one piston when you walk in the door. (same as my original idea, just expanded a bit) Remember our goal is to ideally have only one piston running at any given moment.

Also, the motion active and inactive should be in the same piston, since that device is already subscribed to. (it’s efficient coding with only one piston monitoring any particular motion sensor)

As far as time of day, in the piston with no triggers (the one setting the scene) you could make time as a condition. (make sure it is UNSUBSCRIBED). This way, when your logic piston calls the scene, it may act differently depending on what time of day it is.

Is global variable recommended?

I love globals, but I use them sparingly. Definitely for things that rarely change (like your phone number) they are perfect. As far as using them for conditions, they do work, as long as you are not relying on instant feedback. If PistonA changes a global, it will not be written (or seen by PistonB) until after PistonA has finished running thru it’s code.

---

SIDE NOTE

For example, I use globals in my house to denote what ‘mode’ my house is in. (Home, Away & Asleep are the normal, but I have a ton of others like when I am watching a movie, guests are over, or my partner is taking a nap, just to name a few) Different pistons will change my mode depending on many other factors. Then I can let that global ‘mode’ be a condition for what happens when

[mrhaugland]

I`m sorry for being slow…

All that could work. If I could make a small tweak to that logic. When you come home, since you want multiple rooms to turn on a specific way, you could make all of those light adjustments in one piston, and just call that one piston when you walk in the door. (same as my original idea, just expanded a bit) Remember our goal is to ideally have only one piston running at any given moment.[…] As far as time of day, in the piston with no triggers (the one setting the scene) you could make time as a condition. (make sure it is UNSUBSCRIBED). This way, when your logic piston calls the scene, it may act differently depending on what time of day it is.

Do you mean a piston containing the scene, but also conditions for time? So the welcome home piston (which is triggered when routine is executed) calls this scene-piston, which checks condition for time? Im probably reading you to litteraly, but this would set in motion two pistons (welcome home and scene).

As far as time of day, in the piston with no triggers (the one setting the scene) you could make time as a condition. (make sure it is UNSUBSCRIBED). This way, when your logic piston calls the scene, it may act differently depending on what time of day it is.

Is unsubscribed an option I can set within the piston?

Also, the motion active and inactive should be in the same piston, since that device is already subscribed to. (it’s efficient coding with only one piston monitoring any particular motion sensor)

Do you mean that motion active and inactive should be in one and the same piston, not in two separate pistons (as I mentioned in an example above)? Not that it should be in the same piston as the scene.

I realise that this is what I need, I need to learn the logic first, not the technical aspect of WebCore!

[WCmore]

So the welcome home piston (which is triggered when routine is executed) calls this scene-piston, which checks condition for time? Im probably reading you to litteraly, but this would set in motion two pistons (welcome home and scene).

WebCoRE is versatile, so technically, your time conditions can be either in the trigger piston or the set scene piston. I like them in the set scene piston as a condition so only one piston is called, and acts differently depending on the time of day.

Also, to circumvent the welcome home and set scene happening at once, you could make your welcome home piston run, and the very last line of that piston to execute the set scene piston. (this is what I call daisy-chaining pistons)

---

Is unsubscribed an option I can set within the piston?

Yes. If you do not manually UNsubscribe, it normally looks like this:

(Notice the lightning bolt on the left. This means it will trigger the code when there is a change. We do not want that in this case)

To remove it, edit the line with the lightning bolt, and then the ‘cog’ at the bottom. You want to choose Subscription method: Never subscribe.

Once you save it, it will look like this:

Also, to confirm, you will see this at the top of the piston (when outside edit mode)

---

Do you mean that motion active and inactive should be in one and the same piston, not in two separate pistons (as I mentioned in an example above)?

Yes. Whenever possible, I try to only have one piston monitor a motion sensor. (remember, these things fire off every time someone walks by, including pets) If a piston is subscribed to the motion active, it makes sense to also subscribe it to motion inactive, since either case will run thru the code once.

[mrhaugland]

Is it possible for you to post a screenshot of some of your pistons? Like “welcome home”, “motion” and “light scene”?

[WCmore]

Is it possible for you to post a screenshot of some of your pistons?

I do this each and every day in many threads here. (you can click on my icon to see all of my contributions) Often times, my own pistons have grown quite complex, so I share snippets of my own code based on the topic at hand.

Also, since so many of my pistons are integrated & working together, looking at one piston alone would likely not make much sense. (and would probably confuse more than help)

[mrhaugland]

Thanks for your explanation, I understand what your saying.

If you would be so kind, could you have a look at these to screenshots, which is of my “welcome home” piston, triggered by an empty routine, and my lighting scenario conditioned for time of day? I also have separate away and good night pistons, as well as a routine that triggers a piston for movietime.

My question to this is where do I go from here when I also would like to condition for motion / no motion and lux, as well as the lighting levels adjust itselfs troughout the day (if they already are on, triggered by motion).

I realise I can make a separate motion-piston, but this would imply I need to individually change lighting levels in each piston if I ever wanted to make som changes.

Again, grateful for your time.

EDIT: I see what you meant by “expanding” the logic. I could of course move the entire lighting-piston into the home-piston. But I am still left with how to condition for motion, lux and “auto-adjust”…

[WCmore]

Boy, you are really jumping right into the deep end! (I am known for this as well )

The only strange thing I see in your Welcome Home piston is the Keypad section. I thought Keypads only sent commands. I have never seen one that accepts commands. (or is that supposed to be in an IF block?)

Your time of day lighting levels looks solid. (although you can delete most of the “Turn on” commands if you wish, because “Set level to X” does that automatically for most brands of bulbs)

---

For lights that I want to control via motion sensor, I usually do not force the lights on like you are currently doing. In other words, certain lights I always want a certain way, even if there is no one in the room. Those are the lights that I may program the way you did.

Alternatively, for lights that I want to control by a motion sensor, I put all of them in their own piston (one piston per motion sensor), and let the time of day be a condition as to HOW bright they are.

---

Of course, these two ideas can be combined, you just have to be extra diligent with your logic so you don’t accidentally create an infinite loop.

For example, this is how NOT to do it:

PISTON A
IF Time is between noon and sunset
Set DimmerA to 20%
END IF

PISTON B
IF Motion is active
Set DimmerA to 50%
END IF

Do you see how if you are not careful, the lights could loop from 20-50% for a few hours straight?

There are many work-arounds for this, but I just wanted to give you a heads-up. Your wording will have to be different if you connect those same lights to a motion sensor.

[WCmore]

Here is one structure that I like for time based motion detects. (feel free to expand upon)

IF Motion changes to active
Then
    IF $hour24 is between 0-4
        Set Lamp's level to 10%
    END IF
    IF $hour24 is between 5-7
        Set Lamp's level to 30%
    END IF
    IF $hour24 is between 8-16
        Set Lamp's level to 40%
    END IF
    IF $hour24 is between 17-23
        Set Lamp's level to 50%
    END IF
END IF

Of course, you could change $time24 to some other time parameter, if that is not precise enough for you.

(but again, don’t try this without using different bulbs than the ones listed in your large piston above)