Where does one learn to set these automations and configs up?

Configuration
1

I’m a complete noob. I’ve been running Home Assistant for almost a year now, and nothing I’ve done looks anything like what you guys are constantly posting. I almost never touch the YAML and when I do it’s to paste something I found online and pray it works. 95% of my setup is all through the UI. Add an integration, type in some numbers, tied in an automation - no code used.

I’ve been trying to figure out how to run an hourly automation (I know how to do that) but conditionally only if a particular switch has been on for > X minutes. I’ve spent 2 days pounding my head on the keyboard. The only thing I got to work was using the history_stats, but it doesn’t show how long since the switch was turned on - it just shows how long the switch has been on today. I can get pretty graphs in my UI related to that, but it’s not really what I was after.

I see example snippets that start with a minus sign, but those always just throw an error for me. Looks like I need to specify a keyword before or something. The gap in my knowledge of the YAML structure this uses is rather large apparently.

I feel like I’m back when I started learning Linux and 95% of the answers were “read the man page” which we all know isn’t written in English. Where do you guys learn how all this functions? I keep hearing “template” but I don’t see anything in the UI about templates and I can’t figure out where it goes or how it works. Basic things like that. I’m missing some root understanding of how HASS reads configs and I’m not sure where to get that understanding from.

The most frustrating part: I’ve done software development for > 30 years from 6502 assembly, to Pascal, to Golang. This is just too alien for my experience to apply.

2 Likes
2

Not an all-including answer, but I really like the examples on the official HomeAssistant documentation pages. For instance this one including the code snippet to get a good starting point on how to define a template sensor. I do agree with you that it is an enormous system, and knowing “when to use a template sensor” is hard enough.

If you like/are confident in using docker I can suggest just pulling the latest HomeAssistant image onto your usual computer and use it as a “dev environment” with minimal config. Usually helps me learn stuff without having to reboot my real setup a million times.

3

Thanks for the answer - and note I finally did get a workable solution for the latest issue I was struggling with using counters and an every-minute automation. Not elegant but it’s working.

I am running it currently in docker, and a second docker for my Z-Wave. Docker I understand :slight_smile:

When running a “dev” environment what do you do for faking switches/sensors for it? Obviously I don’t want to disconnect my house devices from my live and connect to the dev environment. Having 2 HASS talking to the same switches testing automations that also monitor changes in those devices sounds like problems to me.

1 Like
4

I usually use the templated version of light and switch (or if I want more complicated things I can emulate them using input_boolean/datetime/select… etc)

I use this to set up one (or many) lights:

light:
  - platform: template
    lights:
      my_light_1:
        turn_on:
        turn_off:
        set_level:

And this for switches:

switch:
  - platform: template
    switches:
      my_switch:
        turn_on:
        turn_off:

And then I use these in my automations or scripts that I want to test :slight_smile:

5

This is just one of those legacy things… Because there are multiple ways external files can be included in the overall configuration, it is the convention of the documentation that, wherever appropriate, all yaml configuration examples be formatted as if they are in the configuration.yaml file. Some users continue to use that convention on these forums, though it is not mandated.

The concept of templates only shows up in a couple places in the UI as Template triggers and conditions. There’s no single source that covers all the things you can do with templates in HA, but make sure to check out:

Home Assistant Templating: This is the the most comprehensive source for HA-specific functions
Jinja Docs: These docs are not geared toward new/casual users, but they contain a lot of important information.
Jinja for Ninjas: @skalavala has put together a well organized tutorial and group of examples. It’s been a while since this was updated, so there are better/easier ways to do some of the things shown, but it’s still a good source.

HA also allows many Python methods to work in templates (for example get() and rsplit()). I’ve never seen a complete list of which methods work and which don’t… I’ve mostly just stumbled upon them in posts on this forum. My understanding is that these are considered to be out of scope for inclusion in Home Assistant’s documentation. As someone without formal training in coding or CS, I have ended up searching the Official Python docs multiple times to figure out what’s going on in templates posted by some of the more advanced users on this forum.

6

The one thing I didn’t see mentioned in your post is that you read the documentation. Is that merely an oversight or have you not actually read it?

To be clear, this isn’t an RTFM reply, simply a question to determine if you weren’t able to find answers in the documentation or you simply didn’t use it as a reference.

YAML

1 Like
7

Regarding your automation, maybe you can use the for-directive in your condition? Here is another post with a good example of that: Understanding the "for" time based condition.

 condition:
   - condition: state
     entity_id: 'switch.garage_south'
     state: 'on'
     for:
       minutes: 30

This way you could run the automation hourly and add a condition checking if the switch state meets your criteria.

8

Also just FYI, often it is better to trigger your automations on state changes or events (with conditions) rather than just running at a certain fixed interval. If you explain the automation problem you are trying to solve (rather than your chosen solution) we may be able to offer a more suitable solution.

9

Yes, I regularly read the docs. :slight_smile: A lot comes across as Greek (to a non-Greek speaker) because I’m missing a lot of foundation. I had an aha moment a few minutes ago when after setting up my pool pump I lost my hourly report of motion detection from Zoneminder. Turned out you can’t have two “sensor” blocks - had never seen that mentioned until I found someone posting the same Zoneminder issue. Copy-paste from two different tutorials gave me two sensor blocks.

Don’t get me wrong - I’m learning, it’s just a lot harder than it feels like it should be. I like that the integrations UI will link to the doc page for a given integration. It’s just that few of the examples in the docs appear to be complete and assume you know where to place each piece they show you.

1 Like
10

Well I wasn’t really trying to turn this into a “everyone show me how to do this one task” type of post - more of a “what am I missing in general”, but I’ll explain. Yes, I’ve done extensive googling and nothing was a match for what I’m doing.

From @Miicroo above, the problem here is I’m looking at 6 or 12 hour timers that I want to make conditional decisions on when the timer comes up. And if HASS gets restarted… that timer is gone.

I’ve z-waved my pool pump. Easy enough, set a schedule, be done with it. But, as the sadomasochist that I am I want to complicate it a bit.

If the pump is turned on -either by a timed event or manually, let it run 6 hours and turn off.

If I need to do an all-nighter (say I shock it or add stabilizer) have a way to make it run 12 hours then turn off.

Where I live it will sometimes drop below freezing, but not very often. I want the pump to kick on anytime it gets below 38F according to OpenWeatherMap’s current temperature.

If the weather is below 38F and it hits the off-timer for either of the first two events, don’t turn off.

Don’t let it run all day - in other words once it warms up above 38F but the 6 hour timer has expired while it was freezing, we still need to trigger a shut off at some point.

Ultimately what I’ve done is create a couple of helpers. One is a toggle I can set to trigger the 12 hour runtime mode. The other is a counter for tracking how long the pump has been in the ON state.

I have an automation that runs every minute and if the pump is on, it increments the counter helper. If it’s off, it resets it to zero. This gives me an approximation of how many minutes since it was turned on.

I have an automation every 15 minutes that checks the current weather temperature and if it drops below 38F turns on the pump if it’s not already on.

I have an hourly automation that will check the counter and if it’s been in an on-state for either the 6 or 12 hours depending on the toggle helper, it will turn it off but only if it’s above 38F.

Have a scheduled run at 3PM for 6 hours but only if it hasn’t run more than 4 hours already for the day. For this I’m using history_stats to see total runtime for the day.

I’ll probably tweak those timers later and I’ll need to modify them if my solar cover is on the pool or I’ll over-chlorinate (it’s a saltwater pool.)

So, I have a working solution for the project goals, but probably not an elegant one.

1 Like
11

Yep I understand that but one of the things you may be missing is how to structure automations. They are much more efficient and only run when necessary if state/event triggered rather than time based. There are exceptions though.

All that can be done with state triggers and one input boolean (to track if you are shocking the pool) rather than regularly polling every hour.

Would you be interested in seeing an example?

12

Through my testing I ran into a couple of things that seemed to complicate it. One being that the timers would be very long, and a restart of HASS would stop the automation. I’ve seen that in other scenarios with my lighting. A restart of HASS at the wrong time would cause things to not trigger as they should, and I don’t want to risk that when we’re talking about possible freezing pipes so the timed polling seemed appropriate.

But yes, I’m certain I don’t fully understand structuring automations since I’ve exclusively used the UI for creating them. I am doing several “AND” conditions but that’s about as complicated as I’ve got with them so far.

I’m always up for a good example. I have to say struggling with this has taught me more in the last 2 days than I’ve learned in 6 months.

It is funny though that installing Z-Wave in a docker and plugging it into HASS (which is also a docker) was easier for me. Zoneminder… kind of a toss up on difficulty lol.

1 Like
13

I’ll hopefully be able to post something later today. Duty calls at the moment.

1 Like
14

I recently switched from another SmartHome solution to Ha and haven’t had the time to look at all this Yaml stuff.

So another idea for you as you’re not new to coding (I also have a lot experience in software development) and it’s more the special HA/YAML part that might be your problem:

The Node-Red Addon with the nodes from
node-red-contrib-home-assistant-websocket are a very easy way to automate the things without ever touching a Yaml file.

I think I edited the configuration.Yaml only once to add an older integration that can’t be setup through GUI. And there’s no other Yaml I ever touched.

But I was able to convert hundred automations and devices in our house from the old smart home solution without missing anything…

15

Here is the result of “make it easy” that HA has been inexorably moving too.

Once upon a time in the “before times” everything was written in yaml in the configuration.yaml file directly. It was obvious how everything fit together and was syntactically structured.

then the ability to add external files thru !include directives and the use of packages was added. It made it way easier to organize your config but without knowing how the original syntax structure worked it could get a little bit confusing.

then there was the UI editors which totally negated a new user needing to try to understand the underlying structure and just use point and click. Unfortunately that doesn’t always get users where they need even now at this stage of the game.

And then all of the integrations being forced to be added thru the UI was just one more step away from users understanding how stuff worked under the hood.

then add the “default_config”…Now you almost never even need to open the configuration.yaml to even look at what’s in there at all.

All of the above is usually OK for the average user coming from other platforms that were less capable.

but once you get to this stage:

The frustration starts because users want to do more advanced stuff but now have no idea how to do it.

it’s like trying to do calculus without knowing algebra but you know addition.

that said there are some resources…

First as mentioned read thru the basics section of the docs.

then look for some other online yaml tutorials.

Here are a couple:

http://thomasloven.com/blog/2018/08/YAML-For-Nonprogrammers/

https://rhnh.net/2011/01/31/yaml-tutorial/

The better templating resources have already been posted above.

And finally if you are stuck on something the forum is a great place to get help.

If searching doesn’t help then create a new post. As long as you have shown that you have put some effort into trying to figure it out the there are lots of users that will help you out.

And most times it helps us that you have a specific question (or two) in mind as opposed to "this doesn’t work at all. what’s wrong?

4 Likes