Setting up multiple / complex automation

[123 (Taras)]

@DJKalz

was looking for a way to have all my helpers in one file

It’s split by domain, not by random groupings of domains.

@DJKalz

I can get one helper working but when I add another one I get the following error

The documentation link, supplied by septillion, contains an example showing the correct format. For your convenience, here it is:

# Example configuration.yaml entry
input_number:
  slider1:
    name: Slider
    initial: 30
    min: -20
    max: 35
    step: 1
  box1:
    name: Numeric Input Box
    initial: 30
    min: -20
    max: 35
    step: 1
    mode: box

Notice that it specifies the domain input_number: just once and not before each entity.

Also, if you split all input_numbers into a separate file then you don’t include input_number: at the beginning of the file.

[DJKalz (Kal)]

Ahh, thanks, I was including the input_number: at the start

[finity]

@DJKalz

looking for a way to have all my helpers in one file

You can do that using “packages”:

Packages

[DJKalz (Kal)]

Hey Guys

I am trying to get 123 solution work work.

I have made the helpers but there seems to be a problem with the code.

When the automation is run it does not change / set the temperature of the TRV.

I looked at the logbook and the automation is getting triggered by the time set in the input.datetime.workday_x helper (so that part is working):

However, when I check the:
> show trace > trace timeline
for the automation I see the following error:

I have tried to troubleshoot the issue but am not getting anywhere. In > developer tools > template > I added the code {{ [states('input_boolean. day_' ~ now().isoweekday())] }} and that works when I toggle the helper, so the first part of the code is working.

Also the next bit of code (is_state(day, 'on') and 'workday' in trigger.to_state.object_id) is working:

You can see it returns the value input_boolean.day_6 and correctly setting day “6” (which is today, Saturday).

When I combine the 2 codes i get this:

However, when I add the code "test": ('input_boolean.day_' ~ now().isoweekday()) I get the following error:

From this the only thing I can conclude there is an error with the variable ‘day’:

I really don’t know what else I can do so looking for help from the community, and thanks in advance!!

[123 (Taras)]

@DJKalz

for the automation I see the following error:

The following message is misleading:

Choose: Error: undefined

It simply means none of the choices in choose evaluated to True and so no action was taken. I reported this misleading message as an Issue in the Core repo nine days ago. Balloob created a PR to correct it and in the next version (2021.5) it will appear as:

Choose: No action taken

@DJKalz

From this the only thing I can conclude there is an error with the variable ‘day’:

Your experiment is flawed and I have no idea why you chose to use dicts and lists in it to handle strings.

[DJKalz (Kal)]

OK, thanks for the update, I really don’t understand what choices I’ve missed that needs to be evaluated as True because I have set up the variables like this:

Day 6 (Saturday) is set to on so the workday times and temperatures should be used.

I set the variables:

input_datetime.workday_1 = “14:02”
input_number.workday_1 = “25”
input_datetime.offday_1 = “14:00”
input_number.offday_1 = “20”

So I am assuming that at 14:02 the TRVs temperature should be set to “25”, but it wasn’t (as shown in the logbook trace).

Am I missing something or a setting? How can I troubleshoot and trace why it didn’t change the temperature?

Here’s the automation code (I have only setup 1 helper for day 6 (today) as I’m just testing and one for each work / off days time & temp).

Thanks

[DJKalz (Kal)]

Hey 123, Also just noticed in the automation yaml code you made, HS is adding extra '' in two places? Could that be causing the issue?

[123 (Taras)]

@DJKalz

adding extra '' in two places?

It’s not that. I found my mistake.

Although I know this, for some inexplicable reason I forgot it and used the following with a Time Trigger!

trigger.to_state.object_id
        ^^^^^^^^
           No!

The trigger variable for a State Trigger has a to_state property but not a Time Trigger.

According to the documentation for Time Trigger, the trigger variable only has two possible properties:

Time

Template variable	Data
trigger.platform	Hardcoded: time
trigger.now	DateTime object that triggered the time trigger.

Neither platform or now tell us which input_datetime was responsible for triggering the automation.

However, all is not lost. I happen to remember that this issue was brought to Balloob’s attention and entity_id was added as a property of the trigger variable but only if the Time Trigger uses an input_datetime. For whatever reason, this tidbit never made it into the documentation.

Anyway, we can take advantage of that enhancement (trigger.entity_id) to identify which input_datetime triggered the automation and extract its object_id.

- alias: 'Simple Scheduler'
  id: simple_scheduler
  trigger:
    - platform: time
      at:
      - input_datetime.workday_1
      - input_datetime.workday_2
      - input_datetime.workday_3
      - input_datetime.workday_4
      - input_datetime.workday_5
      - input_datetime.offday_1
      - input_datetime.offday_2
      - input_datetime.offday_3
      - input_datetime.offday_4
      - input_datetime.offday_5
  action:
    - variables:
        day: "{{ 'input_boolean.day_' ~ now().isoweekday() }}"
        oid: "{{ trigger.entity_id.split('.')[1] }}"
    - choose:
      - conditions: >
          {{ (is_state(day, 'on')  and 'workday' in oid) or
             (is_state(day, 'off') and 'offday'  in oid) }}
       sequence:
       - service: climate.set_temperature
         target:
           device_id: d8c34b0dce275e2c56a9b1f68f0a6d19
         data:
           temperature: "{{ states('input_number.' ~ oid) }}"

---

EDIT

Correction. Replace last line’s reference to trigger.to_state.object_id with oid variable.

[DJKalz (Kal)]

Thanks 123, it definitely going a lot further in the automation now, but still is throwing up and error at the every last step I think, if you can please have a look at the attached, your input is much appreciated!!

[123 (Taras)]

Yep, I missed one more reference to trigger.to_state.object_id in the last line. Replace it with oid as now shown in the corrected version above.

[DJKalz (Kal)]

Worked flawlessly!!! Thank you so much, I could never have coded this without your help and perseverance. I really do appreciate all your hard work.

[123 (Taras)]

You’re welcome! Glad to hear it works to your satisfaction.

Please consider marking my post (above) with the Solution tag. Only you, the author of this topic, can do that. It will automatically place a checkmark next to the topic’s title which signals to others that your issue is resolved. It will also place a link below your first post that leads to the Solution post (helpful given this thread is now 50 posts long). All of this helps other users find answers to similar questions.

[DJKalz (Kal)]

OK, will do 123, I just have one more thing I would like to do to expand on what you have created so far. I am not planning to do this right now as I want to try and test everything created so far, which will take me a week or so. Also I want to design an intuitive frontend, which will take me a while, but will be looking to do the following in the not so distant future:

Basically I have a total of 15-20 TRVs I would eventually like to add to my HS setup. I would like to have my house split into locations:

Living Locations (living rooms, kitchen, etc.)
Sleeping Locations (bedrooms, en suites, etc)
Manual Locations (hallways, bathrooms, etc.)

I would like to have 2 separate schedules I can dynamically assign any TRV in the house:

Schedule 1: for all Living Locations
Schedule 2: for all Sleeping Locations
A “None” option: for all Manual Locations (these TRVs will not be linked into any time schedule and will have their temperatures controlled manually by the user).

I would like to be able to dynamically assign TRVs (via frontend) to either belonging to Schedule 1, Schedule 2, or None (by using a dropdown helper for example).

The reason I would not like to “hard code” the TRVs via the automation yaml file is to have the option to make a Bedroom TRV (for example) linked to Schedule 1 for Living Locations, or a living room TRV linked to “None” so that its temperature is controlled manually without any time schedule (I think you get the idea).

Finally, will I be better marking this post with the solution tag (as the issue has been solved) and start a new post to achieve what I described above, or just continue it in this post when I’m ready to start implementing 2 Schedules?

Thanks in advance for your help!!

[123 (Taras)]

@DJKalz

Finally, will I be better marking this post with the solution tag (as the issue has been solved) and start a new post to achieve what I described above

It’s usually better to keep each topic focused on the first post’s question and/or requirements. If your original requirements have been met, mark the post with the Solution tag (only one post per thread can bear the Solution tag). Your additional requirements are more complex than the ones in this topic and merit their own separate topic.

FWIW, imagine the extreme example where someone uses a single topic to discuss the automation of every aspect of their entire home. It may contain multiple useful solutions (however only one tagged Solution post per topic is permitted) but who would be willing to wade through the entire lengthy thread to discover them? Best to keep the thread focused and concise.

[DJKalz (Kal)]

Hey, Just a quick one, at the moment the code is only updating 1 TRV
(ie device_id: d8c34b0dce275e2c56a9b1f68f0a6d19)
how would I modify this part of the yaml code:

        sequence:
          - service: climate.set_temperature
            target:
              device_id: d8c34b0dce275e2c56a9b1f68f0a6d19
            data:
              temperature: '{{ states(''input_number.'' ~ oid) }}'

To include several TRVs, for example:

#TRV 2
device_id: xxxxxxxxxxxxxxxxxxxxxxxxxx2

#TRV 3
device_id: xxxxxxxxxxxxxxxxxxxxxxxxxx3

And so on ….

Thanks

[123 (Taras)]

One way to find the answer to your question is to use Developer Tools > Services to create a service call with multiple areas/devices/entities then switch it from UI mode to YAML mode. The resulting code will be displayed, revealing how multiple areas/devices/entities are entered.

        sequence:
          - service: climate.set_temperature
            target:
              device_id:
                - d8c34b0dce275e2c56a9b1f68f0a6d19
                - b7c4etc
                - d4f6etc
            data:
              temperature: '{{ states(''input_number.'' ~ oid) }}'

[DJKalz (Kal)]

Perfect, Thanks 123Taras

[denver]

Thank you for this code, does exactly what I’ve been looking for.

[denver]

Ive notice an issue I’m getting, for instance, Ive got input_datetime.workday_5 and input_datetime.offday_5 set for the same time in the evening to turn the heating down for over night, the code triggers but doesn’t adjust the temperature.

To get round this, I set the time with a minute difference between the two and it works.

I’m not sure if its something I’ve done or missed.

[123 (Taras)]

If both are set to precisely the same time, you now have an automation with two identical Time Triggers. In other words, something like this:

trigger:
- platform: time
  at:
  - '07:00:00'
  - '07:00:00'

where the first one represents the value of workday_5 and the second is offday_5. Which one of the two actually triggers the automation, workday or offday, might not be predictable (i.e. I don’t know for sure but it might not always be the first one of the two as it appears in the list of input_datetimes … or maybe it is).

Given this potential ambiguity, you should do exactly what you did and avoid having identical times for the same workday/offday.