Best way to automate

Configuration
21

Agree with most of this post. Note, however, that HA is not an enterprise project that starts with a set of requirements, builds, then launches. It’s an open-source evolution, which, as you say, is on a journey.

Huge steps have been made improving the UI. A couple of years ago, I wouldn’t even have considered using it or recommending it because of all of its shortfalls and state as a terrible interface to build YAML behind the scenes. Now I often recommend using it in posts, although I still mostly write YAML myself for familiarity.

Yes, if HA were to be rewritten from the ground up, it might be approached differently — but we are where we are and have to move forwards with what we have.

Feel free (and this is meant sincerely, not facetiously) to contribute to the project yourself.

There are patterns that could be simplified — for example, a common use case (your bedroom AC one) is to “run an action when a number of things become true”. This trips up a lot of noobs, confused by the concept of a trigger being an instantaneous event. The correct way to handle this is to trigger off everything and have matching conditions, such that the action runs when the final criterion is met.

This is easy but laborious to set up because of the mapping to the YAML structure and the non-abstraction of the underlying backend. Improvements could be made here, and in future, I’m sure they will be. I’m not complaining because a) I could help and I’m not and b) those that eventually will are providing it free.

3 Likes
22

**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.**

You are describing your credentials that would parallel with someone with OUR “knowledge”, but in the next sentence you stated a few automation generated such confusion that you formed a solid stance on how poor the programming is. There is little to no one amongst this group that are happy with the status quo.

This forum is literally people donating their free time to improve and enhance the core system, but that not what makes it successfully. Folks spend hours and hours each day teaching folks how the system works and how to customize it. That generates so much creativity !

Putting out a finished product based on your and only your opinions would be limited at best. It’s simple, this will become the most dynamic home automation program developed by folks from around the world.

Stating there is only one method to achieve total success is naive in itself.

1 Like
23

I think you’re missing the context I originally replied to. It was a very long discussion of how and why people (especially newbies) don’t understand the difference between the “when” and “if” parts, with a tangent about how both words translate to the same word in many Germanic languages.

I personally I’m not confused—I have learned to work with new software from scratch often enough that I know I cannot yet be confused as I haven’t put enough time in to learn even half I need to know. I, however, can relate to the described issues. I also found that I fell into a pitfall with the triggers with the very first automation I ever created. And chances are that this pitfall may be systemic and not a pure “me problem”.

That’s why I didn’t sit down and wrote a pull request to throw the existing stuff out and replace it with my ideas. (Joke aside, I have seen pull requests that basically were exactly this on other projects.) Instead I dropped a description of one possible alternative way to present the automation configuration in the hope that whoever gets to work on it some time will have another data point to work with.

Software design works best when you have a good stack of suggestions and alternatives to think through before doing the final design. The fewer suggestions you have on top of “make it better!!!”, the harder it is to come up with a good design. Basing a design on one person’s ideas with no other inputs or reflection rarely gives useful results.

The worst thing to hear after you deliver the final product is “but we wanted it that way” from someone who never said a single word about it before. Trust me, those were the few times in my career where I found it really hard not to strangle the customer… ;) The second worst is to hear a year later that they didn’t like the solution and had another company redo it according to their wishes.

1 Like
24

Trust me, I didn’t miss the context you replied to, I think you missed the depth of this system and were too quick to admonish it.

1 Like
25

Henry has some good points and we need to get away from the tenet of dismissing alternative views of what might be good additions or changes to the system. If someone comes here and says "this system is really weird to my way of thinking, and it could be better to do X” then we need to stop saying “that’s the way it is, like it or go away” and say “your view is appreciated, let’s make it better”

Of course we can also say “we welcome your PRs”

6 Likes
26

Your credentials also make it impossible to have an unbiassed view. That is because you apparently came to Home Assistant with a lot of programming experience and a preconceived notion on how a home automation system should work. But Home assistant is designed around a different paradigm, and within a few days, you decided this is not how you like it.

You blame this on the UI, but your examples show you do not want an event driven system at all. You want something PLC like. No amount of GUI redesign is going to change the underlying design principles of the core system.

There are over 350.000 active users, so HA must do something right. according to you that is because they are too invested in the system to see the fundamental flaws. Flaws being: not how you’d do it. A common affliction among programmers: Not Invented Here Syndrome in Software Engineering.

My advise to you is to find a home automation system that is designed the way you like it, instead of bashing one that is different. And should you come to the conclusion pretty much other home automation systems work the same way: design your own and see if your ideas catch on.

5 Likes
27

I don’t feel that was what was said. I personally said his opinion matters, but there is a process to enact change and this approach is unproductive.

28

Isn’t that exactly what writing down design suggestions is? Contributing to software design? And isn’t running them by a couple of fellow users before nagging a dev about it considered polite?

Those were rhetorical questions. I know that around open source projects voicing suggestions before working your way up with code contributions into the core team is considered to be the most evil thing to do. I’ve seen it time and time again, not just here.

And the result is that people who could contribute either don’t, or they implement their half-arsed ideas and send them in as a PR, usually with horrible code quality because they’re not familiar with the project. I’ve seen that one often enough on the open source projects I managed. There, I much preferred someone to come up with an idea, open to discussing it. That’s how I got most contributors on those projects, even people who started out stating they didn’t have the coding skills to implement that stuff (and they didn’t—in the beginning). Not be telling them to stay away with their ideas until they had contributed code.

1 Like
29

I would like to add to the 300.000+ active forum users, we also have hundreds of contributing developers Credits - Home Assistant

30

Well that is not actually happening here so your point is mute. Suggesting an idea does not require code that backs it. These Ideas are voted on and with traction develop a path to production.

31

My advice is sped some time here, observe, offer up your knowledge , but keep a positive attitude towards the success of HA. People helping People.

32

Sorry, I have no way of knowing if you’re familiar with (or even noticed) the thread I originally replied to or not. Pure guesswork on my side here.

That’s why I wrote “If I were to design this from scratch” and not “I suggest to change it to”. And only as an example after going into the differences between human mindset and computer programming.

I may have forgotten to state explicitly that I was only talking about the way the system interacts with the user, not about how the underlying engine works. However, it should be pretty clear that the system would still need to work like a computer and not turn into a simulation of relay-logic. That would be weird. Things like that are commonly handled by translating (compiling) the user input into a form the computer (or engine, in this case) can process.

Also, “admonish it”? I agreed with a sentiment stated and discussed in the thread before and tried to provide an explanation of where the disconnect between users and system comes from. And I stand by that. The form of, say, a cooking recipe and the form of the instructions on a fire alarm are fundamentally different. Swapping them works, but feels very unnatural to humans.

33

Your sarcasm hasn’t gone unnoticed…I spent my life in corporate business for 30 years so I’m reminded to ask you to convey what you liked to change in simple terms.

If we pause and ask, what is your end goal? To be simply right or to make significant changes to the program?

1 Like
34

You said you did not want programming help, but here it is anyway: this is what happens in Home Assistant when you use a template trigger, or create a binary sensor to detect this (using the same template). Template triggers will monitor any state that changes to make it true. However, it will not fire when the condition already is true. It remains a trigger for an event (it listens to change). And it is not well supported by the GUI.

So you can have it the way you describe if you want it. But you should not want to aim for a system that always does this. I disagree with you on the fact that seeing it in an electromechanical way is always helpful. That is why I would never want to lose the distinction between triggers and conditions, even if it is a bit more work.

A simple example.
Consider: When zone home becomes occupied, and it is dark outside, turn on the lights.
This is totally different from: The lights are always on when people are home and it is dark.

Yes, as you said you can add in more conditions when this rule should not work. But my point is those conditions would amount to detecting the coming home trigger, in order to negate the dark condition. It would add complexity a lot if you want to consider all rules when the light should be on or off. And you’d need to if the rule is always active.

For me, home automation is not thinking of my home as a totally predictible state machine. Event driven behavior has proven to me over many years of home automation to be way more simple and intuitive, because it is impossible to fully describe what devices should do when. Life is too complex.

Having Home Assistant react on certain changes and leave the house alone when it is not interested in that particular event is what makes the home responsive to both the inhabitants and the home automation. Doing anything different would have the two fighting each other. It would lead to “Computer says no” in all cases that the home automation did not foresee something happening in real life.

3 Likes
35

Thank you. That is the kind of engagement with the topic I had expected.

Thanks for the pointer, I’ll have a look at that.

5 Likes
36

Thank you, Henry, for sharing your thoughts on automations when onboarding new users. A lot of what you said echoes what others have brought up in the past but it’s always nice getting fresh perspectives. :slight_smile:

This is something I am actually helping with as the community manager! I own feedback from the community and this is exactly the type of stuff I raise to the team. Not only that, but I myself am a relatively new user to HA and have shared several instances where I either got stuck or found a UX that was not great for new users. I am a technical person, so if I have problems with something for sure new users are running into it. And honestly very likely just giving up.

While I cannot guarantee anything happens with it right now, I have shared this thread with the team to consider the user feedback talked about here. We have been making a lot of improvements over the past year to make it easier for new users to adopt HA but still have a long way to go.

And just to touch on something you mentioned, despite your rhetorical intentions, so that if anyone else comes across this thread maybe has clarity that is missed here. People in this community will say “contribute to the project” and this means writing code and submitting PRs. You call out offering suggestions for improvements is part of that, and I wholeheartedly agree, however that isn’t standard practice with this open source project. Hopefully I can change the way we view “contributing” to the project to include your definition of contributing - I think it will go that way because with our voice assistant contest we implemented a feature from one of the submitted entries before we finished the contest!

I know that you were jumped on here by a few people, but I do appreciate your responses to them because you do bring clarity to your post with each reply. Again, thanks for sharing your thoughts. Feel free to reach out with any more! :smiley:

10 Likes
37

I just wanna say @MissyQ – you’re a pro!

3 Likes
38

Oh my, I must be dreaming right now. I could have sworn I’ve woken up today already… :wink:

Thank you for taking your time to write that.

To add to the topic, here’s a real-life, serious, non-made-up, not-just-playing-around example:

Intention: Keep the temperature inside the formicarium between 28°C and 29°C during the day and 25°C and 26°C during the night.

Unspoken implied intention: If it’s warmer than allowed but the heating is off, it’s fine.

Initial, flawed implementation:

Name: Turn on (Night)
When: Sensor Temperature changes to below 25
And if: -
Then do: Turn on Heating

Name: Turn on (Day)
When: Sensor Temperature changes to below 28
And if: Confirm sun after sunrise before sunset
Then do: Turn on Heating

Name: Turn off (Night)
When: Sensor Temperature changes to above 26
And if: Confirm sun after sunset before sunrise (Note: I haven't yet tested if this works, UI feedback would be appreciated)
Then do: Turn off Heating

Name: Turn off (Day)
When: Sensor Temperature changes to above 29
And if: -
Then do: Turn on Heating

Missed cases:

  • At sunset, heating is on and temperature is above 26°C. “Turn off (Night)” won’t activate.
  • At sunrise, heating is off and temperature is below 28°C, “Turn on (Day”) won’t activate
  • Turning on the system while the temperature and/or heating state is outside bounds

I made this mistake on the same day I discussed exactly this type of issue here in length. Sure, it was immediately obvious why the heating didn’t turn off yesterday, but it was more or less luck that the conditions were right. If the heating had been off already (or was’t still power-limited and had been able to hit the 29° at night, or if I hadn’t left out the unnecessary "And If"s), I might not have noticed and could have trusted this. This could have worked as intended for weeks until conditions were just right.

I solved it by adding two addition “When: Sunset/Sunrise; And if: temp too high/low; Then do: Turn on/off heating” automations. (And ignored the “cold start” one.)

This again is something, where a state-based instead of event-based definition comes more natural to humans. when the temperature IS above 26 AND it IS night, not (when the temperature RISES to above 26 AND it IS night) OR (when it BECOMES night AND the temperature IS above 26. For the computer, converting from the former to the latter form is trivial. For a human…now that’s why we have programmers to translate business requirements into code.

Disclaimer: There are probably better triggers and conditions to use. That’s not the point; fixing the mistake is trivial. Not making it and/or recognising it while writing the automation is.

I have contemplated adding automations to control the room temperature with the (reversible) AC, central heating and electric blinds if the local heating isn’t enough or it really gets too hot, but that’d be a pain to express trigger-based. It also would be just for fun, not for need, as I expect to keep the room temp within human-acceptable bounds anyway. I sit within arm’s reach of that temp sensor all day…

39

Right, that would be a good start, before creating/developing any system, have a good overview of what does what and what is the intensions
I.e " Crossing a line" or " Be on the other side " is 2 different things

A trigger is as you mention an event “Crossing a Line” A Condition can be a State, " being on the other side"

This is where Templates comes in handy, If you cant fit this into your Trigger/or condition othervice
i.e by adding additional triggers/conditions, or i.e Template-Triggers
( template-(binary)sensor example which i actually think you are aware of)
" if temp > 26 state: true "

There is +3 big pages under DOCS describing options and with examples, for templates, templating and triggers
There are MULTIPLE Topics And a Search function in this Forum, where you can get additional help, After you read the DOCS and trying to understand them ( With your background i believe you could/would get a good grip over what the Docs states, And you can contributes to get them more “understanable” )
However many people skip the docs And the search functions, which btw Actually in the end will lead them to fully usable, working examples/solutions

2 Likes
40

Its taken years for me to come around to the way HA does automations, but now with some understanding I really see the benefits.

I think a cleaner solution to do what you are proposing here would to break it into smaller parts.

step 1: control the temperature: use a generic thermostat,
Generic Thermostat
this gives other benefits of stopping the heater cycling on and off too quickly if you hover at 25.9 degrees.

climate:
  - platform: generic_thermostat
    name: formicarium
    heater: switch.formicarium_heater
    target_sensor: sensor.formicarium_temperature
    min_temp: 24
    max_temp: 30
    ac_mode: false
    target_temp: 28
    cold_tolerance: 0.3
    hot_tolerance: 1
    min_cycle_duration:
      seconds: 5
    keep_alive:
      minutes: 3
    initial_hvac_mode: "heat"
    away_temp: 25
    precision: 0.1

step 2: adjust the setpoints according to time: have an automation alter the setpoint when the sunrise/sunset event fires.

description: ""
mode: single
trigger:
  - platform: sun
    event: sunrise
    offset: 0
condition: []
action:
  - service: climate.set_temperature
    target:
      entity_id: climate.formicarium
    data:
      temperature: 28

description: ""
mode: single
trigger:
  - platform: sun
    event: sunset
    offset: 0
condition: []
action:
  - service: climate.set_temperature
    target:
      entity_id: climate.formicarium
    data:
      temperature: 25

if you do decide to add a cooling method later you can just add another generic thermostat and have it controlled in the same way

4 Likes