Time condition - inclusive or exclusive?

I’m trying to build an automation that runs “before sunset AND if cloudy” -or- “at exactly this time” as one combined automation. I know how to “and” and “or” conditions, but I’m unsure about the condition specification for an exact time.

Does anyone know if the time and sunset conditions are inclusive (<=, >=)/exclusive (<, >)?

For example, if I want it to trigger only at exactly 6PM, is it “inclusive” less/greater or equal like this:

condition: time
before: '18:00:00'
after: '18:00:00'

Or is it exclusive “greater/less but not equal” requiring this:

condition: time
before: '17:59:59'
after: '18:00:01'

Similarly, for sunset would I be ale to do just condition: sunset or would I have to do condition: sunset after -00:00:01 before +00:00:01 if my trigger is on sunset “exactly”?

What about using the at

condition: time
at:'18:00'

I would be putting the @time in the Trigger and them check the condition to match

    trigger:
      platform: time
      at: "18:00"

I know the trigger has kick off and now I check the condition are true and then do the action

1 Like

Ah, that’s it! Somehow I overlooked there being an “at” option.

I’m still curious if anyone knows for future, but the “at” would do what I’m asking for today.

It is never before and after 18:00:00 at the same time.

so true bro didn’t see that just sore the at

And to answer this question, it is what it says it is, after means after not at So “exclusive”.

1 Like

Just revisiting this (got around to implementing my change) seems ‘at’ is not valid as a condition?

Invalid config for [automation]: [at] is an invalid option for [automation]. Check: automation->condition->0->conditions->1->at. (See ?, line ?).

    condition:
      - condition: or
        conditions:
          - condition: sun
            after: sunset
            after_offset: "-01:30:00"
            before_offset: "-00:45:00"
          - condition: time
            at: '16:00:00'
      - condition: template
        value_template: "{{ states('weather.home') != sunny }}"

But if I change to a (stupid) before/after spanning only 1 second, then it is valid (albeit very hokey)

    condition:
      - condition: or
        conditions:
          - condition: sun
            after: sunset
            after_offset: "-01:30:00"
            before_offset: "-00:45:00"
          - condition: time
            after: '15:59:59'
            before: '16:00:01'
      - condition: template
        value_template: "{{ states('weather.home') != sunny }}"

Trying to make it turn on lights if it’s 4PM or X before sunset when cloudy (or becomes cloudy during the duration, hence the conditions not just a trigger).

Correct, at is not valid for a time condition (docs). You could have a template condition comparing sensor.time with "16:00".

So you want to turn the light on if it is cloudy and either 16:00 or a range of times around sunset? I don’t believe you can use before_offset with after:sunset (docs).

Please paste the entire automation and a super-clear explanation of what you’re trying to achieve. I’m struggling to understand the span around sunset, or the relevance of 16:00.

The range of times is because I want it to trigger when it’s around sunset, during times that may be getting dark but not always - without interfering with other automation I have that control the same lights at/after sunset nor during the day. That part has been working fine.

I’m sure it could use some refining, but at this point I’m still not 100% certain exactly what I want to specify all the requirements. More or less, if it’s late day or nearing sunset, I want to turn on lights if it’s cloudy, or if it becomes cloudy during that time. Then I decided I also want it to turn on lights at a specific earlier time if it’s cloudy, even if sunset is much later.

I only got started with this back in Jan/Feb and my rules worked great…until I noticed with a summer storm even though sunset was much later I wanted it on at an earlier “evening” time like a traditional lamp timer I’m replacing (which would dumbly waste power turning on even if it’s sunny). Adding the “at 16:00” handles the case I hadn’t considered of “it’s stormy all day and sunset is late in summer”.

The biggest problem I’m having is figuring out how to translate what (in my head as a programmer) I am thinking about “less-than / less-than equal-to / just equal-to” type conditions I’d do in C++/Java to the words-ing that YAML uses to play with the options I think I want. In a “normal” program I’d just have an event loop trigger at 16:00 and add an “or” to my if-checks to “now == 16:00” but with YAML that’s an at in one place and apparently you can’t at it in another place as an “equal” condition so ??? and then I want to keep things reasonably maintainable so I am trying to avoid having several automation that do the same thing on minimally different conditions (in a program I’d use “functions” to encapsulate but that’s not a thing apparently with YAML).

  - alias: "Kitchen Lamp Timers On Cloudy Evening"
    trigger:
      # If it's near sunset, or stops being sunny, or hits 16:00, try and do it
      - platform: sun
        event: sunset
        offset: "-01:30:00"
      - platform: template
        value_template: "{{ states('weather.home') != sunny }}"
      - platform: time
        at: '16:00:00'
    condition:
      # If it's getting near (but still early) sunset, or at 16:00, let it go thru
      - condition: or
        conditions:
          - condition: sun
            after: sunset
            after_offset: "-01:30:00"
            before_offset: "-00:45:00"
          - condition: time
            after: '15:59:59'
            before: '16:00:01'
      # but only if it's not sunny (cloudy, rainy, foggy, whatever)
      - condition: template
        value_template: "{{ states('weather.home') != sunny }}"
    action:
      service: input_boolean.turn_on
      data:
        entity_id: input_boolean.kitchen_lamp_timers_on

I’m open to other ideas, but I have “daytime” automations I don’t want to overlap with and “approaching sunset” automations I don’t want to overlap with. I believe that has been working correctly though.

Some of this is also finding what DO I want it to do. I’m still not used to the flexibility of more than a dumb lamp timer…which I would just manually push in some extra pins if it was stormy for some days to make it on longer, or pull them out as the days were shorter. This can do it automatically but I haven’t thought of WHY I want it on, used to just be like “oh it should be on earlier” and move a pin, not considering the specifications for that decision.

So I want to implement what I think I want, and then if I don’t like it I’ll change it again.

Maybe AppDaemon is a good fit for you. It lets you program your automations in Python.

1 Like

I’ve heard some references to that though Python has been one of the most frustrating languages to figure out I’ve seen so far with everything being ambiguously loose typed and then mismatches of versions and no way to figure out fixing lost whitespace even worse than YAML…I’ll stop there before I end up on a 3 page rant.

Actually before 18:00 and after 18:00 intersect at exactly 18:00 (its the way the time boundary conditions are written)
But this makes no sense as a condition I agree

Eh, ok. I’m not a programmer, I don’t even work in the IT industry, but I learned enough Python to program fairly complex HA automations in about 2-3 months, but probably it’s different for an experienced programmer who is used to other programming languages.

How do you edit your files? I can not remember ever having an issue due to indendation/mix of spaces and tabs when using a proper Editor like Visual Studio Code.

Usually VIM or Notepadqq. It seems worst when trying to copy examples from the Internet and when you paste it ends up all on the left edge because they used CSS or something stupid to do the indents on the website and none of that translates.

Its also a PITA that settings are not persistent in HassOS so you have to rebuild your vimrc every time you do anything, on top of the nightmares with trying to guess what will REALLY work because the absurd “container everything” means you can’t test a program/script in the real environment and it inexplicably fails because oops mqtt_pub and all the libraries exists in the SSH container but not the who-knows-what-it-runs-in real container. That makes any minor issues with learning curves much more of a headache to debug with HomeAssistant.

Isn’t Visual Studio paid? I’ve only heard of that being used for .Net and C# at work, and it’s a big deal because of licensing costs, plus Windows (I run Linux)

I think Home Assistant Supervised on top of a generic Linux install would be more appropriate for a user with linux/programming background like you. Please be informed that if you do this, it will only be officially supported if the base OS is Debian and nothing else than HA is running on the machine.

Yes, Visual Studio is, but it’s not the same as Visual Studio Code. There’s even a Home Assistant Plugin for Visual Studio Code, which will auto-complete entities which is quite handy and other stuff as well.

Interesting…I was not aware there was an option to have a Vanilla Linux and still use add-ons and manage thru the web-UI. I would have much preferred that over the UEFI nightmare trying to make KVM/QEMU boot it properly. If it ever stops working I’ll have to see if I can set that up, I think it would be easier to manage. I bet that would solve some of my issues with LetsEncrypt too (I run my own DNS to autot-issue certs against my LAN machines automatically, but can’t get it working with HassOS since I can’t figure out how to make the script changes to the “container” addon thing)

It should be pretty easy to migrate to Vanilla Linux + HA Supervised (with add-ons etc.). Take a snapshot in Home Assistant, install HA Supervised on top of Vanilla Linux by following this for Debian 10, this for Ubuntu 18.04 or any of the other “HA Supervised” guides here, load your snapshot and you should be good to go.

1 Like

I’ll certainly have to look at that. I’d imagine it would also make managing multiple network interfaces easier (I have one for trusted-LAN and one non-Internet IoT untrusted devices)

Either Supervised or Home Assistant Core as a Python virtualenv installation, just-another-application running on a base Linux machine. If you’re familiar with Linux, that gives you complete freedom to do what you like on the rest of the machine. You do lose the Add-Ons & HACS systems though.

For me, who grew up with C at university (I even got a mention in preface of the 2nd ed of Deitel & Deitel’s C How To Program!) and that newfangled Java, Python is a breath of fresh air and my go-to (!) language of choice now. A decent .vimrc, banishing tabs to the abyss, and all is well with the world.

I’d second the AppDaemon recommendation as well: it’s a bit of a hurdle to set up on a Core machine, but allows much more complex systems to be set up, like my council bin schedule web scraping and deciding whether/when to run the immersion heater overnight based on the half-hourly tariff of Octopus Agile.

Here’s a suggestion: build yourself an ambient light sensor and switch the lights based on that, rather than time or weather reports which are “second-order” inputs. I’ve done this with our hall light: a Wemos D1 mini and a BH1750 sensor (GY-301 module) running ESPHome peeking out of a hole above the garage door reports the light level to HA, which then switches the light based on either house occupancy + sun state; or light level, sun azimuth angle (taking into account the west-facing windows driving a lower threshold in the morning) and an adjustment slider for fine-tuning. I tend to break things down into simpler elements, so I have a sensor for working out the switch threshold, a binary_sensor to indicate if the light should be on based only off that threshold, and then the automation (not shown) does the actual switching if a) house is occupied and binary_sensor stays on for 30s or off for 10m or b) house is unoccupied based purely on sun-up/down.

sensor:
  - platform: template
    sensors:
      hall_light_threshold:
        friendly_name: "Hall light threshold"
        unit_of_measurement: 'lx'
        entity_id:
          - sun.sun
          - input_number.light_threshold
        value_template: >-
          {% set azi = state_attr('sun.sun', 'azimuth')|float %}
          {% set adj = states('input_number.light_threshold')|float %}
          {# base setting 100lx at azi 80, 200lx at azi 270 #}
          {{ ((100 + ([0, azi-80]|max)/1.9) * (adj / 100))|int }}

binary_sensor:
  - platform: template
    sensors:
      hall_light:
        friendly_name: "Hall light should be on"
        entity_id:
          - sensor.hall_light_threshold
          - sensor.outside_illuminance
        value_template: "{{ states('sensor.outside_illuminance')|float < states('sensor.hall_light_threshold')|float  }}"

1 Like

Do you have a github repo or any other way to see your appdaemon apps? I’m really interested in how you tackle things in AppDaemon, the structure of your apps etc.