Best way to automate

Edit: Just to avoid misunderstandings, this originally was a reply to a very long thread that had a discussion about how people (don’t) understand the “if” and “when” of automations.


As someone who has a very technical background with 40 years of programming and system design experience, just having installed HA yesterday and having struggled mightily with even 2 very simple automations, here’s my 2 cents on the whole if/when trigger/condition situation:

Expressing to a computer that it should do certain things based on conditions that change over time always has been problematic and very non-trivial. Compared to what was the computer’s predecessor in many field of automation, the electro-mechanical logic, it’s even worse.

With electromechanical logic, all conditions are evaluated in parallel all the time. If you want some condition to not run, you have to add a ( ... ) AND NOT x to it, i.e. power it down with an additional relay. While that seems daunting to design, if you lay out all the logic in text, it is very intuitive. (I recommend Technology Connections series on how a flipper machine works on YouTube.) The same is not true for a computer (or mircoprocessor, to be exact) that evaluates every instruction in sequence. That looks intuitive for writing instructions to do something (e.g. calculate pi), but when reacting to triggers and conditions, it becomes the opposite.

So, in my opinion, the main issue with HA’s automation is that they are not just executed by a computer, but also configured like a computer program. The most unintuitive thing about conditions over time is exposed to the user. Oops?

Were I to design such a system from scratch, I would go the other route and present it to the user like an electromechanical device, leaving the hard work of translating that to a sequence of instructions to the computer.

For example, an automation trigger could look like this:

(time is after sunset OR luminance sensor is below 20%) AND (any of (user1, user2, user2) is in zone "home") AND (motion sensor is triggered)
When entering state:
-> (X) execute once or (_) execute every [__] seconds
-> (X) execute immediately or (_) execute when condition persists for [__] seconds
-> run action [turn on lights]
When exiting state:
-> (X) execute once or (_) execute every [__] seconds
-> (_) execute immediately or (X) execute when condition persists for [30] seconds
-> run action [turn off lights]

The computer would then be responsible to find out on which state changes to evaluate the formula (i.e. when to trigger it). Also, action could have further logic, e.g. in this example to check in the “turn off lights” script if the lights were turned on manually and do nothing then. An advanced form would have more than two states, with conditions and actions for each possible state change.


Also, reading this topic has made me realise that my first instinct on how to write my automations was right and I just made it worse when I changed what I had done based on what the UI presented me as possibilities in the “when” section. I will change it back to running on a “every 15 minutes” trigger as I want it to activate no matter which in order my “and if” conditions become true. Is that the best or intended way to use automations? Probably not, but my device is more than powerful enough to check half a dozen on values every 15 minutes…

Probably will be something like:

When: every 15 minutes
And if: bedroom AC is off AND user1 is home AND bedroom temp is too high AND outside temp is too high to open the window AND window is closed AND none of the ACs are set to "heat" AND time is between sunset and 5am
Then do: set bedroom AC to "cool", remember that automation has turned on the bedroom AC

Edit: This ^ isn’t a call for help; the AC automation is just something I’m playing with while I wait for the Bluetooth bridge to arrive that I need to use the sensors I got HA for. Hard to order all the parts upfront when you don’t know if the internal BT chip will work without testing and you can’t test as HA fails to install with a network error if the boot medium is to slow, so you first need to order an SSD.

I disagree with all of that.

Especially the inefficient polling based on time. As someone “who has a very technical background with 40 years of programming and system design” I’m extreemly surprised you don’t realise the difference between state driven automations and inefficient polling.

What you have described is even more confusing than the simple:

Trigger on some state change, then check some conditions. If they are true perform some actions.

Please start a new topic so we can help you with this. It’s off topic here.

6 Likes

I would say(vote for) above in an if/when (script/automation) ( When time is between sunset and 5am, And the rest of the bullock is true/false(check every 15 min), Run action)
It’s not a matter of how much power you have under the hood, running an automation 24 hours day in day out, when/if you can run it i.e only 8 hour, is a waste of resources, money, and power which have to be produced(speaking of environmental sustainability)
It’s like saying, wth i let the engine of my car running over the night, i have to get to work again tomorrow anyway, and i have lots of money and full tank
In fact that’s how i try to create my automations which has i.e a sunset/sunrice etc included, i rather make 2 simple automations 1 for “on/run” and 1 for “Don’t” . if that’s what i takes Not to a activate/read a script/automation 2/3 of the day, for no reasons

And in my case, this would probably “break” it all, as my basement is always much much colder, so how/why should this interfere with the climate i want in my bedroom at night ?

Joining a community less than a day ago and immediately attacking the core programming, the people who have dedicated their time and abandoning the simple courtesies you give folks you know nothing about speaks volumes.

Comments like the following go against the entire premise this community thrives on.

Were I to design such a system from scratch, I would go the other route and present it to the user like an electromechanical device, leaving the hard work of translating that to a sequence of instructions to the computer.

There is nothing as robust and free on the market like HA. That leaves plenty of room for you to compete with a more viable system.

You may have valid points and something to contribute to this community, but IMO I would have chosen a different approach.

Actually never mind I’ve split this into it’s own topic for you.

2 Likes

Yes Ha does have a steep learning curve, but what does having x years experience has to do with it?
I also have 40+ years of experience, and a very technical background, it didn’t bother me when onboarding HA.

This immediately brought me back to this remark:

I feel like that form is going to be very, very big.
Just imagine an automation with 10 triggers, each with 5 or 6 states, and then 10-20 conditions…
brrrr

They are all on the same split system, so the first one to request heating or cooling sets the outside unit’s operation. Any inside unit that comes online with a different request later will just there complaining with a blinking light.

And putting the time window into the trigger would work for this one, I just put it down this way to make the point clearer—that this (or its “AC off” counterpart) needs to check its conditions when any single one of of the conditions changes. I sed this not just because it is the first thing I tried out, but also because it looks to me like a pretty typical use case for a background automation, i.e. something that doesn’t react to a user action or other specific event.

Strongly suggest you learn how HA works rather than trying to bend it to work how you think it should; or alternatively find a different system.

I also have a lot of experience in programming and system design (can just about claim 40 years starting with Z80 machine code aged 11!), and have used HA for many years now. The way it works is efficient, consistent and predictable.

If you need help learning, then posting a request for help with your “mighty struggles” might have been better than deciding HA is fundamentally mis-designed and then posting a long rant about how a polling system would be better.

Definitely not. Trigger off all the things you care about, match them up to conditions as needed. That way you’re not waiting up to 15 minutes for your AC to come on when you get home on a hot day.

5 Likes

And so the basement unit will request Heat, it’s basically 10degrees C all year around, if no heat
So when can i expect the Bedroom-unit will be “in charge” of the bedroom cooling ?

Totally agree with that.

Similar story here…started coding on Comodore Vic20 at he age of 11 :smiley:

That was actually one of his conditions ( That he( or User1 ) should be home, else not, just let the temperature rice infinity )

Haha 1984 i was 23 , but im glad im not twice your age anymore :smile:

2 Likes

Ah the Commadore VIC20. My dad brought one home, so excited until I realized he didn’t get the external storage or RAM cartridges. I never turned it off :rofl:

Shit I was 11 too! No more talk of our original PCs.

1 Like

Sinclair zx80, then Spectrum then Amstrad cpc 6128. (The latter ran a great FORTH).

Oh and before that, the school computer had core memory and punch cards or a teletype for I/o.

2 Likes

@nickrout is in the lead…

image

If you consider the way the GUI interacts with the user “core programming”, that’s certainly your opinion.

But then I could argue that that “core” is really weak, as it only presents the native data structures of the engine in a slightly pretty way to the user instead of providing an abstraction layer that translates between human concepts and how the engine works.

But, in general, I do not consider the presentation layer to be “the core” of a project, unless a project is all about UI. And so I see no way in which talking about the shortcomings of the automation UI being basically a 1:1 yaml-to-dropdown translator could affect, insult or attack the “core programming” of HA.

To me, the core of HA is the engine that makes all of this possible, combined with the huge set of integrations that allow HA to be useful. That stuff is solid, even though the installation can be a 2-day nightmare. But it also is in a majure state of working well, so naturally the focus shifts towards usability. We’re way past the “write a yaml file and upload it with scp” stage.

But, in my opinions, the “the UI is a graphical yaml editor” stage needs to be passed, too. How people intrinsically think about conditions and how the engine processes them are different. Hanging on to forcing humans to adapt their thinking to how a computer internally works is not the way forward.

Just take the smartphone as an example. It is one of the most successful product of the last two decades, and nowadays even people who would self-describe as computer illiterate use them successfully all the time. What made them successful wasn’t the big screen, or an ability to connect them to your computer and put .mp3 file into the right folders. The breakthrough was Apple’s decision to decouple the internal workings of a fairly standard operating system from the user interface. Suddenly you had a (admittedly also very sleek and portable) computer you could use without even having the slightest clue what a “file” even was.

Back then, plenty of people complained. They know what files were and they wanted to ssh into their phones and vi some config files. That is what they knew, what they had done for ages with their computers. For them, the UI abstraction felt utterly alien and they could not understand that that UI was way closer to the mindset of a normal non-computer-savvy person.

Those people would have been the wrong ones to design that phone UI. They were so deep into the subject matter, that they can’t even imagine how people think who are not. And your reply (and others) reminded me of that. Y’all know the system well. Y’all are comfortable working with its configuration on a technical level. Y’all invested huge amounts of time and effort to become so well-skilled with it. But that’s also a trap. The more you know, the harder it is to imagine how someone who doesn’t know anything thinks.

And that’s why I think that is important to voice opinions and suggestions about the user experience of a product before becoming too comfortable with it. Only then do you have the fresh and unbiased view.

A well-designed application has two sets of inputs: The formal requirements what the software must do and a documentation of the workflows gained from interviewing the people who will use the software. The latter is the key to user acceptance; the way to design a software so it feels as natural to use as possible.

1 Like

Thriller Michael GIF - Thriller Michael Jackson GIFs

5 Likes

Simply don’t install a multi-split system with the indoor units in rooms that have opposite needs. For me it’s just a week or two in fall and spring when my east-facing office may be cool in the afternoon while my west-facing bedroom might be blasted by the sun. The “outside temp” condition should mostly catch that one, but it’s weather-service data, not measured, so it may be off. (And I know where the stations are, I’m smack in the middle between 3…but not close to any of them.)

I rarely get to bed directly when coming home. I can wait for the bedroom to cool down.

Also, that wouldn’t be the only thing to switch on the bedroom AC. This is just the “out of comfort zone, too warm” one. The “don’t let the house heat up too much” one would have kept the bedroom from becoming unbearable.

Science of Cambridge MK14, Probably still in the loft somewhere.

The pain of typing machine code from the manual on a hex keyboard still haunts me.