Mode Logic

I’m having a bit of an issue with the logic for modes. The away / home logic is simple, but for instance, I want my lights to come on when I walk in a room only when I’m home and it’s dark out, and not just when the dog walks into the living room.

Right now I have 5 modes - Away, Morning, Home, Evening, Night. If I was manually setting the modes, everything would be fine, but it’s getting them to set automatically that’s the issue.

For instance, if I’m home, the mode switches to “evening” when the sun sets, which allows my Light Follows Me programs to run. However, if I leave the house in the evening and return, I can only change it to “home,” since there is no if/then stage to instead switch to “evening” if I get home after the sun goes down.

I’m wondering if I’m going about this the wrong way, or if I should write a single presence app to include that logic, or if I should update the “light follows me” app to include logic to only fire if we’re past the sunset time.

Any suggestions?

Ryan, I don’t necessarily think you are going about this the wrong way, but I do think that this is one of those times were you are hitting the limits of what modes can do. Maybe your evening vs. night mode idea is too specific and you are shooting yourself in the foot by trying to set it up that way?

It’s definitely possible. What you would have to do is augment the SmartApp that switches your mode to “Home” when you come home to look at the sunset time and switch to “Evening” if the sun has already set. There may be an app that already does that, or you may have to get intimate with groovy.

For what it’s worth, I have been trying to solve this problem the other way around and let my apps decide whether it is dark or not, if they need that sort of information. It’s also not a great solution, because now I need to add logic to deal with sunrise/sunset times to all my apps.

I think, what we really need is a virtual luminosity sensor, which outputs a binary dark/bright value based on the local sunset/sunrise times, and the current time. Any app that then takes a luminosity sensor input could use the virtual device. And instead of adding the astro check to all the apps, they can just take the luminosity input, which a lot of them already do. Does that make sense?

I haven’t had time to implement this virtual luminosity device.

This covers Home, Away and Night - but not your custom modes. It could be worth looking at to see if you can add those additional modes?

So glad you posted this Ryan, the “returning home day vs night” problem has been bugging me for months (I’ve just been too lazy to do anything about it.)

ImBrian, thanks for posting your code. I’ll take it for a spin.

I had a similar problem, but created 3 virtual switches to keep track of:

day/night
home/away
awake/asleep

Then I can include them in any smartapp where I want to have different outcomes based on one of these variables. I also have one mode-changing smartapp that subscribes to all three, and changes between my four modes:

Home- Day
Home- Night
Away
Asleep

Just so people are aware, the virtual weather station (you can set it up through the ide) has a virtual luminosity sensor. I don’t know how well it works as I don’t use that part of it.

If you’re an iOS user, you might want to check out Hello, Home in the new version of the app we released today. (You can get there by tapping the red number or gear you see in the top right of the screen.)

It might not solve all of your issues, but it’s another approach at configuring your mode changes.

If you’re an Android user, that functionality will be coming soon.

Sweet, thanks for the tip @Dianoga.

I have the same thoughts: I don’t know that Mode logic is flawed, but a more cohesive built-in mode “state machine” would be nice.

I defined the following modes:

Home-day
Home-evening
Home-night
Away-day
Away-evening
Away-night

“home” and “away” modes automatically cycle based on time (morning transitions) and sunset (evening/night transitions). But it means I’ve got 6 very basic smartapps running just for that.

Then I have 3 (each) of the “bon voyage” and “greetings earthling” apps to transition between “home” to “away” modes. e.g. “Home-day” becomes “Away-day” when I leave.

It works, but what a pain, and sorting through the sea of apps shown on my smartphone is annoying.

A single mode scheduling app that allows for clock or sunrise/sunset-based transitions throughout the whole day, accounting for presence, would be ideal. I may just write it, just surprised it doesn’t exist. I would add “morning” modes as well, plus day-of-week logic: e.g. mornings start earlier on M-F than Saturday and Sunday.

The idea of having virtual switches for day/night, home/away, awake/asleep is a good one - but it means you have to either find apps that can take advantage of it, or write them yourself. It also overloads the purpose of “things” and adds clutter to the UI. To me, a switch should always be something a user would explicitly trigger to request a change of state. Here, you’d be automating the switches ~100% of the time, so there is no reason to present them as devices. That’s what the mode change UI is for (if you can’t fully automate it anyway). Again, good idea, and maybe the best way to handle it explicitly right now, but I really like the idea of modes - just need cleaner control!