Can a nested automation trace the original trigger event?

Your type comes every now and then and it’s always the same thing.
Ask a question and be determined the only correct answer is the one that is impossible.
Blame every single one in the thread for not helping bend the reality to suit you.

When you see these people I generally have a look at their history, and more often than not you see the same pattern in the past.

Is it helpful? Yes it is.
I doubt it but perhaps you have learned something.
But it sure isn’t helpful to bend reality to someone’s completely flawed view. It won’t last long until you get the next issue in the same rabbit hole.

You see the same thing on programming sites like stack overflow.
People don’t help because it will just make things worse.

Again think about it.

Your type comes every now and then and it’s always the same thing.
Ask a question and be determined the only correct answer is the one that is impossible.

I didn’t think that the answer that you gave was right for me, and you got angry when I continued looking for alternatives. You then decided to pursue me across multiple threads telling everyone that I didn’t listen to you.

This isn’t helpful.

When you see these people I generally have a look at their history, and more often than not you see the same pattern in the past.

People will see a string of threads that I abandon once you show up.

Blame every single one in the thread for not helping bend the reality to suit you.`

You offered an alternative way of doing things that I decided not to follow. I didn’t blame you, I simply asked you if you could help with the original question rather than offer alternatives.

If it was impossible you could have said so.

I have never posted anything to you ever before.

As I said earlier on, this is a people problem, not a technical one.

I’ll put everyone right out of their misery.

No, it is not possible.

I’m no sure why this wasn’t said earlier by other people.

Question anwered.

Oh my god :man_facepalming:
It has been said many times before.
You just don’t listen

4 Likes

Are you aware that by using the YAML editor built into the automation and script GUI, you can simply copy and paste over the actions?

8 Likes

What a fun topic.
Obviously you are right. Doing fringe things that are not as intended on a half dozen automatons that may or may not have a proper trigger, (I think an automation without a trigger is called a script, maybe?), anyway all those weird automatons are MUCH easier to manage that 1 automation that has full context to everything without fighting. That thing might have fewer lines than all the code you already wrote so it would be be horrible to manage…

Anyway, good luck with that. I suggest you get future advice from https://r/Homeassistant.
They are better listeners and will tell you the answers you already came up with are correct.

4 Likes

If you insist on using automations, instead of using automation.trigger, raise an event from the initiating automation and have your target automation fire based on an actual trigger type that allows passing data forward:

Raise and Consume Custom Events

3 Likes

Are you aware that by using the YAML editor built into the automation and script GUI, you can simply copy and paste over the actions?

Could you please admin delete this thread, it’s gone so far off topic that it’s probably not salvageable. Or at least remove the “solved” tag as I haven’t solved the problem yet, and the proposed solution is misleading because it’s addressing an issue that someone raised in the thread, and not my original issue.

To answer you’re question. Yes, I am aware that scripts and automations both use the same structure and engine, so that code can be transferred between them pretty easily, but this isn’t really the issue here.

I’m simply not in a place where I want to make structural changes to a live system. It’s as simple as that. Could people please accept this and move on.

I’m also not sure how moving to scripts would solve my original problem. Unless I’m reading the documentation wrong, you still have to set up a system level variable and then pass it to the script in order for the script to act on it. There isn’t a built in mechanism for the script to call the information itself by checking a state. Which is all that I’m really asking for.

They most certainly can. Here’s one way: https://www.home-assistant.io/integrations/script/#passing-variables-to-scripts

1 Like

If you weren’t so combative about this your issue would have been solved hours ago.

You have multiple HA experts telling you the path forward and you’re still refuting it. Please take a step back and understand that you have miss conceptions about this system, not others.

If you need help transferring from an automation.trigger to a script.turn_on, post an automation and the automation that it’s triggering. We will show you how to get exactly what you want.

This constant arguing from your perspective is really unfounded. Why did you even come here and ask a question if you’re unwilling to listen to the correct answers?

5 Likes

OK, I may have a solution that you can use.

As @Didgeridrew mentioned the way to do this is via events.

My lights are controlled by a set of automation’s that firstly deal with the ‘inputs’ - Motion triggers / Smart switch’s / Manually turned on / Alexa.

Once that has been processed I raise an event specifying the event data that includes trigger ids, room data etc. to an automation that specifically deals with turning on the lights.

Now this could be converted to use scripts with fields but it has worked for years successfully.

The drawback to events is that you lose context. Which is exactly what OP is asking for.


@zombies.aaargh

I have a feeling you’re not going to respond to me about my proposition, so I’ll just provide an example.

Lets take these 2 automations:

Using automation.trigger and passing values between automations

- alias: A
  trigger:
  - platform: state
    entity_id: binary_sensor.a
    to: 'on'
  condition:
  - condition: state
    entity_id: light.a
    state: 'off'
  action:
  - service: input_text.set_value
    target:
      entity_id: input_text.my_message
    data:
      value: My Message From Automation A
  - service: light.turn_on
    target:
      entity_id: light.a
  - service: automation.trigger
    target:
      entity_id: automation.b
- alias: B
  trigger:
  - platform: state
    entity_id: binary_sensor.b
    to: 'on'
  condition:
  - condition: state
    entity_id: light.b
    state: 'off'
  action:
  - service: persistent_notification.create
    data:
      message: "{{ states('input_text.my_message') }}"
  - service: light.turn_on
    target:
      entity_id: light.b

Automation A triggers automation B and uses an input text (A global variable of sorts) to pass a message from automation A to B before it triggers. When automation B is triggered, only the actions fire. So the trigger and condition in automation B are skipped.


Using Scripts instead of automation.trigger

Now lets look at the equivalent with a script and automations that do the exact same things without a global variable.

- alias: A
  trigger:
  - platform: state
    entity_id: binary_sensor.a
    to: 'on'
  condition:
  - condition: state
    entity_id: light.a
    state: 'off'
  action:
  - service: light.turn_on
    target:
      entity_id: light.a
  - service: script.turn_on
    target:
      entity_id: script.b
    data:
      variables:
        message: My Message From Automation A
b:
  sequence:
  - service: persistent_notification.create
    data:
      message: "{{ message }}"
  - service: light.turn_on
    target:
      entity_id: light.b
- alias: B
  trigger:
  - platform: state
    entity_id: binary_sensor.b
    to: 'on'
  condition:
  - condition: state
    entity_id: light.b
    state: 'off'
  action:
  - service: script.b
    data:
      message: My Message From Automation B

These 2 examples are identical. The difference is that your logbook will contain the context for what called the script. You won’t need a global variable. And you can still have your 2 automations. If you don’t need the second automation, great, get rid of it. I’m saying this because you mentioned having dummy triggers for automations, you won’t need those dummy triggers with a script. A script is an automation without triggers. In fact, both automations and scripts run the exact same code. One is not more stable than the other.

script.turn_on will not block automation A from running. When you call a script using the scripts name like this is doing in script.b, the automation will wait for the script to finish (blocks).

7 Likes

And to add to Petros excellent post.
You don’t need to do this in a live environment.

You make a copy of your existing automation, disable it and edit it to the style Petro posted.
When you need to make a test you disable the live automation and enable the test/duplicate.

2 Likes