Enjoyed this! As a newbie I found input booleans difficult to understand reading the HA docs. You made it so simple and clear I've already started using them for my automations. Thanks, so easy to follow your guides :}
Glad I could help! The official documentation sure isn't easy to read or make sense of sometimes... especially if you are newer to Home Assistant. In my Home Assistant 101 videos, I try to break down these concepts and explain them in a way that hopefully once understood , then maybe the official documentation might start to make a little more sense. Thanks for watching. And I appreciate you taking a few moments to leave a comment. More Home Assistant 101 videos will be coming soon!
Thanks. We were all just getting started at some point, so I try to make these Home Assistant 101 videos from that point of view. Thanks for watching and taking the time to post a comment.
Nice video. I hadn't even heard about helpers until I started watching your channel. Perhaps you could provide a flow chart to help understand the logic of your automations, especially if the logic is spread out in different timers and switches and automations. That's why I like to use NodeRED. I'm also used to using Informatica and other graphical tools.
I tried Node-RED at one point, but was already so use to doing my automations in YAML, that I gave up on it. It is pretty powerful and there is absolutely nothing wrong with it, it's just that I learned and am accustomed to YAML, so that's what I just stick with. I can certainly consider creating some sort of flowchart, especially if I create a corresponding blog article like I do for many of my other videos. That way there'd be someplace where the flowchart could be published. Thanks for watching... and for the comments.
Well, you'd be surprised at how often I go back to my own videos or blog articles (or Github repo) to remember how I did something. It is sorta' like documentation for a lot of my projects. But I also use copious comments in my YAML and any other code that I write. That's one drawback to using the Home Assistant UI editor... the inability to add comments. You can add comments to the default auotmations.yaml file, but as soon as you edit an automation (via the UI), those comments are lost. I also break up my code into Home Assistant packages and each package has a detailed description at the top of the file. For larger projects that I build, I generally have a project folder that will contain documents, spec sheets, diagrams, photos and anything else related to that project. I hope that is somewhat helpful. Don't hesitate to let me know if you have any additional questions.
Hi there. I just came across this channel and loved this video. I'm pretty new to HA and just getting my head around some of the basics. I'm a developer by trade, so YAML files, scripts, etc, don't bother me. I'd already done some of what you described in this video, but it does give a good way to wrap my head around some of the elements. When I was looking at my own config file, I noticed that while I had Toggle helpers available to me, I did not have the input_boolean: section on my configuration.yaml file. I also noticed that I had a decfault_config: section at the top of the file and I assume that this is what made them available to me. I also noticed that when I created input_boolean and input_select helpers from the UI, their definition seemed to be stored in corresponding input_boolean and input_select files (no extensions) in the .storage directory. While the HA documentation is excellent overall, it's sometimes hard to connect the dots. Is there a good reference for how the config files like this are organized and what might be best practices around managing them? It's not clear to me whether or how I might use a hybrid approach or if I do go to primarily YAML how I should organize my config.
Interesting that you bring this up. I did a video about a month ago that covers using a split configuration for managing your YAML ( ruclips.net/video/GG3IVcjTKOw/видео.html ). Tomorrow, I will be releasing another video on using Home Assistant packages as a different way of organizing your YAML. Both approaches can be used simultaneously to organize your YAML. Personally, I never use the UI editors for helpers, automations, scripts, etc. For one, when I started with Home Assistant a number of years ago, YAML was the only option. I'm not slamming the UI editors, especially for those that are newer to Home Assistant, but as you have found, it creates things like helper in a hidden .storage folder that isn't meant to be edited. In addition, all automations and scripts are thrown together into a single YAML file (one for each) that doesn't allow you to document, add comments, reorganize, etc. So for me, I maintain all of these things myself in my own YAML files, mostly in packages but a few things in split config files. That way, I can maintain my own organization, add comments, etc. without fear of them being overwritten the next time I use the UI editor or apply a Home Assistant upgrade. You might take a peak at the above video on split configuration and tomorrow's video on Home Assistant packages to give you some idea of how you may want to organize your own YAML. Luckily, you mentioned you are still relatively new, so now is a great time to setup an organizational structure that works for you. I had a ton of manual entities that had to be split out after the fact (and then eventually migrated into packages). But don't hesitate to reach back out if you have any follow up questions after the split config and/or tomorrow's package videos.
@@ResinChemTech - Funny. I literally just noticed the video you mentioned and watched it. I agree with you about organizing it myself. I find it very strange that HA went with the organization structure they're using for UI generated items, especially since they seem to be JSON files, not YAML and even then, not at all easy to find or consistently located. For example, I happened to make a template binary_sensor and it go shoved into a core.config_entries file. I'm not knocking it, either, it just seems to be an odd mix. Guess I'll need to start shifting this stuff around. It's early enough in the process for me that I can break a few automations without it getting too bad if needed. I also noted that in the case of helpers, at least, you can't start to create them and then edit the YAML to cut & paste. Of course that makes sense, given that they aren't being stored as YAML. I hope this doesn't represent a significant underlying architecture change that will cause issues for those with large YAML based installations. Thanks!
I think some of that is due to the fact that YAML configurations were exclusively used in the past and they have had to bolt on the UI editors without breaking everything for us "old timers". In fact, I have an older video where I went on a bit of a rant as they (HA devs) will sometimes take away manual (and in my opinion much more flexible) YAML device configurations in favor of more "user-friendly" black box integrations. When this happens, you no longer have the option to maintain your own manual configuration and are forced to use the 'native' integration. For me, when they do this, like they did with OctoPrint, I can lose significant functionality (not to mention breaking dozens of automations). My rant was that I was all for making Home Assistant more user friendly for beginners, but not at the expense of the power and flexibility that some of use and want in our own systems. Regardless, I still think it is the best platform around. As I mentioned, I have moved almost everything from the split configuration in that last video to packages, which I cover in tomorrow's video. In hindsight, I probably would have opted for a bit more of a hybrid approach... but I cover some of the pros and cons in the package video and may move back to hybrid in the future. But with 1,000s of manual YAML entities, it isn't a minor undertaking for me at this point, so I don't know if I'll ever actually get around to doing it!
@@ResinChemTech - Fair enough. It's a hassle to constantly refactor code and it seems to me that you need to get something significant out of the process to make it worth it. I've got maybe 10-15 automations, scripts, and helpers. It's really tiny at the moment, so now is the time. I'm looking forward to tomorrow's video now.
In my particular case, I was using a text_input helper to specify a date/time value to pass via MQTT to the clock, which 'decoded' that text message. But if you just want to set the value of a timer, you could use an input_number helper. There you could enter (or use a slider) to select a value that would be used to set the duration of the timer (in minutes or seconds). Let me know if you have any follow up questions. Thanks for watching!
Another Great video! So if you wanted to have different timers for the same thing but not 20 minutes. Is there way to have a timer set upon an input helper. I see it as a fixed time as shown which I can configure like you have.
Yep... you can use something like an input_number helper to dynamically select a time value. You can then use that input_number as the duration for the timer. You do have to template the value when using it to set a timer duration. I know that you can do it in YAML... and probably in the UI, but you'd still have to manually create the templated data. Since I don't use the UI, I can't say that for sure. But short answer is that if you can template the value into a number or time format (e.g 00:00:00), then you can use any input helper type like an input number, input text, input select, etc. to set a value for the timer.
In the yaml code for the motion timer automation, should the mode parameter be set to "single" or "restart". It is set to "single" by default. Will this prevent the timer from restarting.
The mode only has to do with the automation itself... how the automation reacts if the trigger fires again before the original automation finishes. In most cases, an automation will complete in a matter of milliseconds unless you are using something like a "for" clause (e.g a state has to be held for a certain amount of time... like 3 minutes... or you have a delay: in your actions). If a timer is running and the automation fires again, it will repeat the actions... including starting or restarting the timer, regardless of the automation mode if the prior automation has already completed... which it probably has unless you have one of the "for:" or "delay:" conditions described above. If you want to prevent a timer from restarting if the automation fires again before the timer expires, then you can add a condition to the automation to assure the state of the timer is not already running before executing the actions that start/restart the timer. Or you can take different actions based on whether the timer is running or idle. But you can see more about automation modes here: www.home-assistant.io/docs/automation/modes/
I’ve tried to follow you video but it doesn’t work on my case as my timer does not start triggered by a motion detector. In my bathroom I have a mirror which is heated by a resistance and controlled by a spring-loaded rocker light switch which I connected a smart switch. The idea is every time I push the rocker switch a timer starts for 15 minutes to heat the mirror. Following your instructions, I created a helper but I need some guidance on how to create a trigger and an action specifically for this case. Could you perhaps give me some instructions. Thanks, and great job with the channel.
You need to create an automation that is triggered by the smart switch (state goes from off to on) and runs an action that will start the timer and sets the 15 minute duration. You then need an automation that runs when the timer finishes (trigger based on state of timer as finished) that will run an action to turn off the switch. These can easily be done by using the Home Assistant UI automation editor... it's just point-and-click (no code involved). If you are brand new to creating automations or using the UI editor, you should probably start by reviewing this Home Assistant doc: www.home-assistant.io/docs/automation/basics/ That page also has a link that will show you exactly how to use the automation editor in Home Assistant.
Enjoyed this! As a newbie I found input booleans difficult to understand reading the HA docs. You made it so simple and clear I've already started using them for my automations. Thanks, so easy to follow your guides :}
Glad I could help! The official documentation sure isn't easy to read or make sense of sometimes... especially if you are newer to Home Assistant. In my Home Assistant 101 videos, I try to break down these concepts and explain them in a way that hopefully once understood , then maybe the official documentation might start to make a little more sense.
Thanks for watching. And I appreciate you taking a few moments to leave a comment. More Home Assistant 101 videos will be coming soon!
Nice tutorial for us old geezers getting started!
Thanks. We were all just getting started at some point, so I try to make these Home Assistant 101 videos from that point of view.
Thanks for watching and taking the time to post a comment.
Great examples. Thank you for making these videos.
You are most welcome. Thanks for watching and taking the time to leave a comment!
This channel is a gem, I am glad I found it, good work as always!
Thanks! I appreciate it.
Great video. Thanks.
You are welcome. Thanks for the kind words and taking the time to post a comment.
Nice video. I hadn't even heard about helpers until I started watching your channel. Perhaps you could provide a flow chart to help understand the logic of your automations, especially if the logic is spread out in different timers and switches and automations. That's why I like to use NodeRED. I'm also used to using Informatica and other graphical tools.
By the way, how do you documents your automation strategy, besides making nifty YT videos?
I tried Node-RED at one point, but was already so use to doing my automations in YAML, that I gave up on it. It is pretty powerful and there is absolutely nothing wrong with it, it's just that I learned and am accustomed to YAML, so that's what I just stick with.
I can certainly consider creating some sort of flowchart, especially if I create a corresponding blog article like I do for many of my other videos. That way there'd be someplace where the flowchart could be published.
Thanks for watching... and for the comments.
Well, you'd be surprised at how often I go back to my own videos or blog articles (or Github repo) to remember how I did something. It is sorta' like documentation for a lot of my projects.
But I also use copious comments in my YAML and any other code that I write. That's one drawback to using the Home Assistant UI editor... the inability to add comments. You can add comments to the default auotmations.yaml file, but as soon as you edit an automation (via the UI), those comments are lost. I also break up my code into Home Assistant packages and each package has a detailed description at the top of the file.
For larger projects that I build, I generally have a project folder that will contain documents, spec sheets, diagrams, photos and anything else related to that project.
I hope that is somewhat helpful. Don't hesitate to let me know if you have any additional questions.
Hi there. I just came across this channel and loved this video. I'm pretty new to HA and just getting my head around some of the basics. I'm a developer by trade, so YAML files, scripts, etc, don't bother me. I'd already done some of what you described in this video, but it does give a good way to wrap my head around some of the elements.
When I was looking at my own config file, I noticed that while I had Toggle helpers available to me, I did not have the input_boolean: section on my configuration.yaml file. I also noticed that I had a decfault_config: section at the top of the file and I assume that this is what made them available to me. I also noticed that when I created input_boolean and input_select helpers from the UI, their definition seemed to be stored in corresponding input_boolean and input_select files (no extensions) in the .storage directory. While the HA documentation is excellent overall, it's sometimes hard to connect the dots. Is there a good reference for how the config files like this are organized and what might be best practices around managing them? It's not clear to me whether or how I might use a hybrid approach or if I do go to primarily YAML how I should organize my config.
Interesting that you bring this up. I did a video about a month ago that covers using a split configuration for managing your YAML ( ruclips.net/video/GG3IVcjTKOw/видео.html ). Tomorrow, I will be releasing another video on using Home Assistant packages as a different way of organizing your YAML. Both approaches can be used simultaneously to organize your YAML.
Personally, I never use the UI editors for helpers, automations, scripts, etc. For one, when I started with Home Assistant a number of years ago, YAML was the only option. I'm not slamming the UI editors, especially for those that are newer to Home Assistant, but as you have found, it creates things like helper in a hidden .storage folder that isn't meant to be edited. In addition, all automations and scripts are thrown together into a single YAML file (one for each) that doesn't allow you to document, add comments, reorganize, etc. So for me, I maintain all of these things myself in my own YAML files, mostly in packages but a few things in split config files. That way, I can maintain my own organization, add comments, etc. without fear of them being overwritten the next time I use the UI editor or apply a Home Assistant upgrade.
You might take a peak at the above video on split configuration and tomorrow's video on Home Assistant packages to give you some idea of how you may want to organize your own YAML. Luckily, you mentioned you are still relatively new, so now is a great time to setup an organizational structure that works for you. I had a ton of manual entities that had to be split out after the fact (and then eventually migrated into packages). But don't hesitate to reach back out if you have any follow up questions after the split config and/or tomorrow's package videos.
@@ResinChemTech - Funny. I literally just noticed the video you mentioned and watched it. I agree with you about organizing it myself. I find it very strange that HA went with the organization structure they're using for UI generated items, especially since they seem to be JSON files, not YAML and even then, not at all easy to find or consistently located. For example, I happened to make a template binary_sensor and it go shoved into a core.config_entries file. I'm not knocking it, either, it just seems to be an odd mix. Guess I'll need to start shifting this stuff around. It's early enough in the process for me that I can break a few automations without it getting too bad if needed.
I also noted that in the case of helpers, at least, you can't start to create them and then edit the YAML to cut & paste. Of course that makes sense, given that they aren't being stored as YAML. I hope this doesn't represent a significant underlying architecture change that will cause issues for those with large YAML based installations.
Thanks!
I think some of that is due to the fact that YAML configurations were exclusively used in the past and they have had to bolt on the UI editors without breaking everything for us "old timers". In fact, I have an older video where I went on a bit of a rant as they (HA devs) will sometimes take away manual (and in my opinion much more flexible) YAML device configurations in favor of more "user-friendly" black box integrations. When this happens, you no longer have the option to maintain your own manual configuration and are forced to use the 'native' integration. For me, when they do this, like they did with OctoPrint, I can lose significant functionality (not to mention breaking dozens of automations). My rant was that I was all for making Home Assistant more user friendly for beginners, but not at the expense of the power and flexibility that some of use and want in our own systems. Regardless, I still think it is the best platform around.
As I mentioned, I have moved almost everything from the split configuration in that last video to packages, which I cover in tomorrow's video. In hindsight, I probably would have opted for a bit more of a hybrid approach... but I cover some of the pros and cons in the package video and may move back to hybrid in the future. But with 1,000s of manual YAML entities, it isn't a minor undertaking for me at this point, so I don't know if I'll ever actually get around to doing it!
@@ResinChemTech - Fair enough. It's a hassle to constantly refactor code and it seems to me that you need to get something significant out of the process to make it worth it. I've got maybe 10-15 automations, scripts, and helpers. It's really tiny at the moment, so now is the time.
I'm looking forward to tomorrow's video now.
Good video, thank you. What was the helper that you used to enter the date and time? What would i use to set the timer duration through the dash?
In my particular case, I was using a text_input helper to specify a date/time value to pass via MQTT to the clock, which 'decoded' that text message. But if you just want to set the value of a timer, you could use an input_number helper. There you could enter (or use a slider) to select a value that would be used to set the duration of the timer (in minutes or seconds).
Let me know if you have any follow up questions. Thanks for watching!
Another Great video! So if you wanted to have different timers for the same thing but not 20 minutes. Is there way to have a timer set upon an input helper. I see it as a fixed time as shown which I can configure like you have.
Yep... you can use something like an input_number helper to dynamically select a time value. You can then use that input_number as the duration for the timer. You do have to template the value when using it to set a timer duration. I know that you can do it in YAML... and probably in the UI, but you'd still have to manually create the templated data. Since I don't use the UI, I can't say that for sure.
But short answer is that if you can template the value into a number or time format (e.g 00:00:00), then you can use any input helper type like an input number, input text, input select, etc. to set a value for the timer.
In the yaml code for the motion timer automation, should the mode parameter be set to "single" or "restart". It is set to "single" by default. Will this prevent the timer from restarting.
The mode only has to do with the automation itself... how the automation reacts if the trigger fires again before the original automation finishes. In most cases, an automation will complete in a matter of milliseconds unless you are using something like a "for" clause (e.g a state has to be held for a certain amount of time... like 3 minutes... or you have a delay: in your actions). If a timer is running and the automation fires again, it will repeat the actions... including starting or restarting the timer, regardless of the automation mode if the prior automation has already completed... which it probably has unless you have one of the "for:" or "delay:" conditions described above.
If you want to prevent a timer from restarting if the automation fires again before the timer expires, then you can add a condition to the automation to assure the state of the timer is not already running before executing the actions that start/restart the timer. Or you can take different actions based on whether the timer is running or idle.
But you can see more about automation modes here: www.home-assistant.io/docs/automation/modes/
I’ve tried to follow you video but it doesn’t work on my case as my timer does not start triggered by a motion detector. In my bathroom I have a mirror which is heated by a resistance and controlled by a spring-loaded rocker light switch which I connected a smart switch. The idea is every time I push the rocker switch a timer starts for 15 minutes to heat the mirror. Following your instructions, I created a helper but I need some guidance on how to create a trigger and an action specifically for this case. Could you perhaps give me some instructions. Thanks, and great job with the channel.
You need to create an automation that is triggered by the smart switch (state goes from off to on) and runs an action that will start the timer and sets the 15 minute duration. You then need an automation that runs when the timer finishes (trigger based on state of timer as finished) that will run an action to turn off the switch. These can easily be done by using the Home Assistant UI automation editor... it's just point-and-click (no code involved). If you are brand new to creating automations or using the UI editor, you should probably start by reviewing this Home Assistant doc: www.home-assistant.io/docs/automation/basics/
That page also has a link that will show you exactly how to use the automation editor in Home Assistant.
What configuration.yaml additions or omissions would cause helpers like these to be unavailable?
I cover that exact scenario in the video at 01:27 and 07:55. Please review those sections as the answer to your question is already answered there.
@@ResinChemTech oops! I'll have another look, thanks.
I just get my wife to notify me, 'cause she's all knowing & seeing ;)
Yeah... that will work too! And it still works even during a power outage!