One of Smart Things core features is the home mode, Which is available in their Web API. This could easily be integrated as a sensor in HA, or at least an event.
What is “Smartthings Home Mode”? And what is the use case you are asking for?
Search the forum for ‘Home Mode’, there are several solutions.
1 Like
The closest facsimile I’ve been able to come up with is an input_select driven by an automation works well enough. (I many cases it’s superior)
I just use the state of that sensor anywhere I’d have used home mode and can display it on the dash as a selector.
1 Like
There are several hacks, I am aware… But this is provided directly in the api. There is no reason we should be hacking around this simple thing. Thus why it’s in WTH 
Once again, that’s a hack. The point of WTH is to be like “why do we need to hack to get to basic functionality and information” I’m using the hacks now. While Simi reliable, absolutely unnecessary, as it can easily be pulled today in the smartthings api which this integration is actively using.
I don’t understand.
The link you provided has the following explanation.
A Location has a number of Modes that users can switch between, such as “Home” or “Away.” These Modes can act as automation conditions (only run when Location is in a certain Mode) and triggers (run when switching to a certain Mode). A Location is always in a Mode, and must have at least one Mode at all times.
So? That’s the same as a persons state in HA?
1 Like
In ST it’s more of a ‘home state’ than the person, he. Single entity that holds a text status.
So like zone.home > 0 but as text?
Not sure how that makes anything better.
The ‘automatic’ part op is looking for is prefilled with basic modes (home, away, night) Home Mode and Security Mdoe are first class citizens in both thier old and post-groovy architecture… and prefill meanings in the automation editors.
@kenobob what you’ll run into is at its core - home mode is just a multimode selector. which by itself is covered by a single input_select. helper entity. In core ST it was just a select in groovy before the new infrastructure.
as a former ST-er Here’s mine:
And yes it seems core to a ST user because most of the core automation asks about home mode as a first-class citizen.
What it doesn’t account for is most people in HA who came before didn’t want things setup for them and ‘how dare you assume.’ So, HA’s DNA would - allow for yay get a multiselect box! (done - input_select) But would NOT build it for you - assuming they know better than the owner.
…and a fair number of users would be equally hacked off if they did (Just read back to mid last year and dashboards… woah)
or just make the state of that home mode input select both a trigger and filter (HA automations are MOST like old Webcore, state trigger and filtering action) on most of your automations and you get the very same thing, but it will make for very one dimensional, linear automations.
I still have home mode intrinsic to all my automations and nr flows - (mostly because Away Mode and Pause Mode need to be unconditional in everything for me and its a convenient single point) but I also have a lot that completely ignores everything except for home mode because Pause and Away. I can see a point to having a single ‘mode’ but I can equally see not - as JD on the ST community says, choice is good.
I just made a helper that lets me set a home mode since I wanted a vacation and staycation option for furnace control. Among other lighting options and such.
Short answer - because Home Assistant isn’t Smartthings. It’s better.
It’s not a hack. It’s flexibility. I know way better than Samsung which modes my house needs to support and what things should determine those modes.
It takes all of 30 seconds to set up a select helper with the values you need and maybe another minute to set up a basic automation that controls these modes. It can be done right in the UI. There is nothing “hacky” about this, it’s literally the way Home Assistant works.
Thankfully, if you are struggling with the concept of house modes or setting yours up there is a great community of “hackers” here to help you along. I see a few examples for you to learn from right here in this thread!
2 Likes
Read this to see the multitude of variations.
Once again, you are getting hung up on hacking around the problem. Defensive. I’m just putting in WTH that the state of home mode be part of the integration. Since this is a first class citizen of smartthings, it should be included in the integration. And since it’s part of the core api, it’s fairly easy.
@jazzyisj It’s just stubbornness in your own response above keeping it out there are work arounds, but why do those when it’s part of the api? I have it working today. I don’t need your condescending responses and watch you put people down for expressing ideas.
@jazzyisj, if you don’t have positive responses to expanding functionality in the integration, why comment in these forums? WTH is intended for expanding and fixing.
I’m not looking got solutions here, I’m proposing this be integrated directly into the offical integration, as a sensor.
There are plenty of work arounds. I see those in the forum. This is WTH ideas.