How to set a automation's conditon based on the previous state of a device?

Configuration
, , ,
1

I have an automation that listens to a state change of a wall switch (a Meross 510 connected via the wonderful @krahabb meross_lan integration) and depending on the state it switches some lights on or off.

The switch for unknown reasons (probably a defect) sometimes goes to an unavailable state, and then to on:

image
image1171×411 28.4 KB

At 8:37 the switch michael main became unavailable, then a minute later it was back, the automation was triggered, lights went on and I got an annoyed message from my son that this already happened twice and he is awakened in the middle of the night.

I would like to set a condition on the previous state of the switch: “only if the previous state was on or off”. Since there is no direct way to do this in the automation building blocks, I hope that by using a template this would be possible. Is it?

2

So why does the light turn on, is that part of the automation you didn’t provide us with?

3

Sorry, I am not sure I understand. The automation is a simple one:

image
image1111×601 15.6 KB

And then depending on the ID lights are turned on or off

The whole automation:

alias: interrupteur mur
description: chez michael
triggers:
  - type: turned_on
    device_id: d4ae80995d09de415c0ab69a04a0a936
    entity_id: 5fae5c2818e5c87fbf9a8e385921e998
    domain: switch
    trigger: device
    id: "on"
  - type: turned_off
    device_id: d4ae80995d09de415c0ab69a04a0a936
    entity_id: 5fae5c2818e5c87fbf9a8e385921e998
    domain: switch
    trigger: device
    id: "off"
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - "on"
        sequence:
          - action: light.turn_on
            target:
              area_id:
                - michael
            data: {}
      - conditions:
          - condition: trigger
            id:
              - "off"
        sequence:
          - action: light.turn_off
            target:
              area_id: michael
            data: {}
mode: single
4

Ok in that case it’s the integration that turns on the light when it becomes available.

It’s a bad idea to use device triggers since it will be harder to replace them later.
I’m not even sure you can get the previous state with device triggers. Make them state based instead and you can use the {{ trigger.from_state.state }} as a condition.

1 Like
5

Thank you for the great idea. It is even simpler because the transition states are available in the automation directly:

image
image1059×663 15.2 KB

I will test this and tell this is @Hellis81 fault if my son is waken up in the middle of the night at 8:30 again :slight_smile: But seriously: thanks a lot!

EDIT: I will have a closer look at my other 1765 automations to see if I cannot improve them with states vs devices triggers.

6

I don’t think that alone will help.
Looking at your first image it seems the outlet turned on first then the automation triggered.
The outlet will probably still turn on, but that might not be an issue?

8

Ahhhh, I now got what you meant - good catch, thanks! (I removed my previous answer)

I will add an extra step to switch it back to the previous state (this is going to be more complicated). This is not really a big issue, it would require two hits when switching it on (to go from on to off, then from off to on). I will see if fixing this is reasonably easy (but I do not think so, I would need to do memoisation which may not be simple)

This was really a good catch.

9

I think what you need is an automation or just a part of the current automation that catches the outlet going from unavailable to on, this should set it to off.
And at the same time stop the other automation from setting the room to on.

But there could be times when the switch is on goes unavailable then back on and your new automation turns it off.
I think the best option is to create a triggered template sensor that triggers when the outlet goes to unavailable and saves the previous state.
Then use this state in the automation when it goes from unavailable to on.

10

Yes this is more or less what I have in mind too. I am not sure if I do not have any unavailable → off transitions (they would be less visible) so I need to account for that.
Thanks for all the help and follow-up!