I currently have a lot of my light automations setup by first having an automation that turns the light on at a certain time, then another that turns the light off at another time. This works, and it has for years, but I’m imagining there must be blueprints or other methods to do this on/ off behavior in a single automation rather than having them in pairs (this is not scaling very well).

Anyone have suggestions? The image is a blueprint I have for turning lights on/ off based on a time window which is very handy, and I’m hoping there’s something similar out there for my needs.

  • Damage@feddit.it
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 days ago

    It’s possible but honestly it’s a bit off-putting to me.
    For scheduled actions I use the Scheduler addon: It’s mostly for covers and awnings, I don’t schedule lights on and off, I enable their motion sensors depending on the time of day, but that’s a more complex automation and I wrote it in Node-RED, which to me is a cleaner approach than the automation system in HA.

    The Scheduler has the advantage of being wife-accessible too!

  • Onno (VK6FLAB)@lemmy.radio
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 days ago

    Before you start consolidating, consider what might happen if the switch is in an unexpected state. For example, someone turned off the heater or pump and you were expecting it to be on.

    In other words, you need to consider what a “safe state” is for each thing and how your code, when it fails, reverts to that state. This is an example of “failsafe”.

    Note that I said “when it fails”. This is true for all software, even on mission critical systems.

    Source: I write software for a living.

    • root@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      2 days ago

      Yes, definitely. That’s one of the reasons I’ve implemented this way. If a light (for example) had the physical switch turned off and back on, a lot of smart bulbs will go to the on state, even if HA had previously set (and expects it to be) off. The next execution may turn it off in an off state, on in an on state, on from an off state or off from an on state, but either way that truth table will resolve after an iteration

  • madjo@feddit.nl
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    2 days ago

    I use scenes and automate those scenes. That way, if I ever get a new light or have to replace a bulb, I only have to update the scenes.

    • root@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 day ago

      I recently started playing with scenes too. Maybe I should go that route with more of my lights

      • madjo@feddit.nl
        link
        fedilink
        English
        arrow-up
        1
        ·
        17 hours ago

        It took me a while to get my head around how it worked, and initially I would have enormous automations “turn on light X at 75%”, “turn on light Y at 55%”, “turn on power outlet XYZ”, “close shades window XYZ” for each and every lamp and feature I wanted for the evening, for instance. And you could actually see those things happen sequentially.

        Now it’s just “turn on scene 1” and poof all lights are on exactly how I want them.

  • jrke3ok2@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 days ago

    In fact there is the option. What I do is: I set two triggers, for example, tine to turn on the lights and time to turn the off. There is an option called name ID or soemthing like that and I set a name for each trigger.

    When you then set the actions, in the advanced actions there is an action called “choose” if you select this action, on the conditions you can choose your trigger base din the ID name and the action you want to perform once the trigger is activated.

    • echutaaa
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 days ago

      This is usually the best method, but just beware if you’re trying to get performant on demand execution the larger decision trees will cause issues. If you find the automation taking too long to trigger/execute you’ll want to break up the automation into smaller ones and just group them.

  • Zwuzelmaus@feddit.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    Just to provide a different point of view:

    My general strategy is to decentralize these simple condition-action things.

    Where only one sensor controls only one action/state, the function should run on the device itself, not on HA. Either the sensor or the switch or both is “smart”, and it is good that HA knows and shows the state, and you can switch it on/off there in the HA app, but it should not depend on HA. It should still work when HA is down.

    In my case, Tasmota runs on all the light switches and a rule in Tasmota does the job.