Device log?

[gwp1]

@toggledbits Oy. I don't know how I missed that. I am embarassed.

In my defense, I do have a history of designing rules much harder than they need to be. I tell myself "think edge" but still try to circle everything instead.

Guessing for Evening the recommendation would be after sunset vs between sunset/sunrise?

@Pabla the OR is there for future state... waiting on an update to iCloud3 in HASS that will allow triggering from the presence of my Apple Watch as well as iPhone for those times when it's a quick trip out and I let the Ultra do the work vs carrying the phone, too (think workout, bike ride, etc.)

[gwp1]

This post is deleted!

[gwp1]

@toggledbits had to mess about with some mode additions/removals and changed sunrise/sunset to between to make this work as at sunset both Day and Evening modes were valid at sunset.

Would this be better served as is or by adding this under Constraints?

[toggledbits]

Depends entirely on what the actions are, and when you want them to run. I'm assuming it just sets mode to Day. If the mode changed during the day, would you want it changed back to Day? Trigger.

[gwp1]

@toggledbits Yep, absolutely - if I leave during the day mode shifts to Away - returning home the expectation would be a return to Day if still before sunset. Same with Evening if after sunset.

[gwp1]

I continue to wrestle with modes. Changing Wake-up and Sunrise to after in Day resulted in a battle between Day and Evening in the later hours as both were "valid" after sunset given the OR in Day

I've modified Wake-up to start at the two wake times, 0630 ET and 0730 ET, and end before 12noon ET. This closes it off from arguing at sunset.

Day currently reads as such now:

• I must be home (can this be addressed better by "mode != Away"?)
• It must be after wake-up times OR after sunset sunrise, whichever comes first
• must be ignored if in Vacation (I'm away for extended period) or Guest (someone specific is checking on the house whilst I'm on vaca)

Evening

• should kick in after Sunset
• I must be home (again, can this be driven by mode != Away better?)
  must be ignored if in Vacation (I'm away for extended period) or Guest (someone specific is checking on the house whilst I'm on vaca)

Night is set manually, ie not on a schedule. Two ways it can be set, the more basic is via voice command to Amazon Echo device that flips a virtual switch which triggers mode.

The second is more complex but still manual:

• phone must be in master bedroom
• phone must be charging for > 00:00:10 (so lockdown can be aborted if needed)
• can only be triggered if the above triggers happen whilst in Evening or Work (awakened in the middle of the night for a work thing and returning to sleep). If I happen to charge the phone during the day the house shouldn't lock down in Night mode.

I put this out there because I have a tendency (ok, more than a tendency) to overthink and over-complicate my rules as @toggledbits will confirm. This results in unnecessary demand on MSR as well as rules fighting with rules or duplicating outcomes.

[CatmanV2]

@gwp1 said in Day mode implementation question:

It must be after wake-up times OR after sunset, whichever comes first

I suspect you mean 'Sunrise'?

C

[gwp1]

@catmanv2 Egad, yes. Edited. Thank you!

[Pabla]

In your "Day" ruleset for sunrise/sunset condition set the sunset condition to be a few minutes before sunset. This way both sunset conditions in "Day" and "Evening" won't go true at the same time. Alternatively you could also add a condition in the "Day" rule that the "Evening" rule must be false . This will make sure "Day" can't be true at the same time as "Evening".

[gwp1]

@pabla Add a specific condition for Evening = false or add it to this existing condition in Day:

[Pabla]

@gwp1 On second thought I would just add the offset to the sunset time in the "Day" rule. Its less of a band-aid solution.

[gwp1]

@pabla Updated to:

[Pabla]

Yeaup that should do the trick, what basically was happening as you said was the sunset conditions in both Day and Evening were true at the same time therefore causing the both rules to be true as well.

Now that you added the 1 mins before sunset, they won't overlap.

[gwp1]

@pabla It should eliminate any race state. The original config was to have "Wake-up" and "sun" both use after but that created a mess alongside Evening as everything ran to midnight together.

[therealdb]

I don't known why you're all setting a mode like this, but I'm still using home/away/night to drive my rules, plus a lot of flags (dark, sleeping, holiday, party, mute, green mode, solar, rainy, windy, bad weather) to combine all them together and drive my reactions. I'm curious to understand why you prefer this approach.

[Pabla]

@therealdb My house modes are simple: Night/Home/Away/Vacation. All them are configured very simply, based on if the alarm is turned on (either stay or away) and who's home. That way there is no accidental/unexpected mode changes

[gwp1]

@therealdb said in Day mode implementation question:

still using home/away/night to drive my rules, plus a lot of flags (dark, sleeping, holiday, party, mute, green mode, solar, rainy, windy, bad weather) to combine all them together and drive my reactions.

This is exactly what I'm driving at. I use Mode followed by a number of what I call "shared rules" (Wake-up times, cloudy day, temp < 40º, presence, etc.) that can be/are referenced in many other rulesets. Where I'm hitting my wall is the actual triggering of the modes (Day, Away, Evening, Night).

My curiosity is around how you're actually triggering the modes themselves. The rest... I've got that nailed down.

[gwp1]

So I went back in time to when I first set modes up. Here's my current settings:

I will use Wake Up Times internally with other rulesets rather than trying to use it to drive at the higher Mode level. Presence will be in those rulesets as well.

[therealdb]

@gwp1 I'm using the alarm to drive modes, as @Pabla
I'm also triggering wakeup mode from the alexa's alarm, so it's possible to move the time and automatically execute actions.

[gwp1]

@therealdb Interesting approach, using the Echo devices. I'd be concerned over any outage potential, has that been an issue?