Ever after upgradeing from 109, my automations (turns on a scene with tplink switches on a specific time/day) runs - even though they are disabled under “automation”. I would have to start all over again.
Does anyone have any ideas? Thanks, Best regards, Anders
1 Like
Sounds like you have them duplicated… maybe in a package?
Have you checked if they are listed twice in Configuration>automations?
It most certainly does not do that to me here.
1 Like
Make sure you don’t have a scene set up in the Kasa app. I had a node red flow that seems to continue working even after disabling it. Turned out, I had never removed a similar scene in Kasa.
hi, thanks for the reply; a good idea, but I do not have overlapping automations. The time 15:15 to switches are triggered
But the automation is disabled and was activated several days ago (21/5 2020).
The automation has worked flawless before. It activates a scene (that has the the tp-link hs100 switches as turned on (a better structure I thought in stead of creating automations pointing to the entities themselves . I will perhaps delete the automation and create it again.
Thanks.
thanks for this, but have no scenes in the original kasa app …
This might be a silly question but have you reloaded your automations or restarted HA since you disabled them?
Thanks, but several times and os reboot (new version out today).
Please look at the automations in the list on the STATES tab of the Developer Tools page. The “State” column will indicate if the automations are actually on or off.
thanks, a good suggestion. The state var off though; I have now edited the scene it self (deleting an entity and adding it again) and hope this will help.
I’m not completely following you. Also, when asking for help with an automation it’s usually helpful to post the YAML code of that automation.
If the automation’s state is off, as viewed on the STATES page, then I can guarantee you that the automation’s trigger will not fire and the actions will not run. If you have any evidence to the contrary (such as snippets from home-assitant.log) that proves otherwise, I would be very interested in that information. I happen to be working on the scripting & automation infrastructure. If there’s something amiss I’d like to know about it.
Hi, thanks for the reply - I appreciate the qualified feedback. My situation was two strange situations
an automation that triggere a scene (sofa) (consisting of turning on two switches (at 15:15 mon-fri)). It kept on turning on those two switches although the automation was deactivated (grey and not blue/active; that was before I look in the state section).
Everyday the log showed (one hs100 tplink switch showed):
The automation is this way
- scene: scene.eftermiddag
- id: ‘1583263792908’
alias: Eftermiddag_sen
description: ‘’
trigger:- at: ‘15:15’
platform: time
condition: - condition: time
weekday:- mon
- tue
- wed
- thu
- fri
action:
- scene: scene.sofa
- at: ‘15:15’
The scene is like this:
id: ‘1583303592619’
name: Sofa
entities:
switch.sofa:
friendly_name: Sofa
icon: mdi:sofa
state: ‘on’
switch.stander:
friendly_name: Stander
icon: mdi:floor-lamp
state: ‘on’
Now everything seems to work - and as stated: I edited the scene - deleting the “sofa” switch => save the scene => adding the switch again => and saving again. The seemed to do the trick.
I will be aware of the state under STATES; I can confirmed, that the “slider” WAS deactivated and I have these two switches turning of.
I had a second problem with the scene “film”: It should turn on two things: an ikea bulp + one tplink switch. But it keept on turning three tplink switches on in stead of the one.
Now the scene is:
id: ‘1583263027484’
name: Film
entities:
light.o1:
friendly_name: Ø1
max_mireds: 454
min_mireds: 250
state: ‘off’
supported_features: 35
light.o2:
friendly_name: Ø2
max_mireds: 454
min_mireds: 250
state: ‘off’
supported_features: 35
light.spisebord:
brightness: 1
friendly_name: Spisebord
state: ‘on’
supported_features: 33
light.vaerelse_1_paere:
friendly_name: Værelse 1 pære
state: ‘off’
supported_features: 33
light.vaerelse_2_paere:
friendly_name: Værelse 2 pære
state: ‘off’
supported_features: 33
switch.hjorne:
friendly_name: Hjørne
icon: mdi:lightbulb-on-outline
state: ‘off’
switch.sofa:
friendly_name: Sofa
icon: mdi:sofa
state: ‘off’
switch.stander:
friendly_name: Stander
icon: mdi:floor-lamp
state: ‘off’
switch.tv_lys:
friendly_name: Tv-lys
icon: mdi:television-classic
state: ‘on’
and is works fine now (the same done: deleting and adding a tplink-switch. It is triggered by this automation:
- id: ‘1583261532081’
alias: Film
description: ‘’
trigger:- at: ‘20:10’
platform: time
condition: []
action: - scene: scene.film
- at: ‘20:10’
So: I did not check the STATES section or the content of scenes.yaml or automations.yaml as I thought it was not necessary.
(I have validated the code several times (under config => server-administration).
Thanks for the help.
Best regards, Anders
Hi! Weird… I have the exact same issue. Automation executes, even if it’s off.
and this is the yml
- id: '1511039978527'
alias: Turn bath light off after inactivity
trigger:
- entity_id: binary_sensor.bath_motion_sensor
for: 0:00:180
platform: state
to: 'off'
condition: []
action:
- alias: mqtt.publish
data:
payload: '{"nvalue":0}'
topic: esp/bath/switch_bath/set
service: mqtt.publish
mode: single
And this happens after I’ve updated to latest version 
I’m having this issue. Were you able to figure out the reason?
hello I have this issue as well. i have few automations that are explicitly disabled but triggering still. It is not documented or talked about anywhere.
What are the states of the automations (as shown on the STATES page)? on or off?
What do their traces show? What does it indicate triggered them?
Can you share the YAML code for at least one of the automations that are doing this?
When this happens, are you (via the UI), or something else in the system (via a service call), manually triggering the automation?
Does this happen when reloading things, or when the system is running normally?
Same thing here.
I’ve got an automation that will disable another one (to prevent it from running).
- id: ligar_manutencao
alias: Ligar manutenção da piscina
trigger:
- platform: state
entity_id: input_boolean.manutencao_piscina
to: 'on'
action:
- service: homeassistant.turn_off
target:
entity_id: automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente
- service: homeassistant.turn_on
target:
entity_id: switch.motor
- service: homeassistant.turn_on
target:
entity_id: automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente
The automation being disabled code is:
alias: Desligar manutenção da piscina quando motor for acionado manualmente
trigger:
- platform: state
entity_id: switch.motor
- platform: state
entity_id: switch.hidromassagem
condition:
- condition: state
entity_id: input_boolean.manutencao_piscina
state: 'on'
action:
- service: homeassistant.turn_off
target:
entity_id: input_boolean.manutencao_piscina
Basically the first automation will disable the second, switch on the motor and then reactivate the second automation.
This would prevent the input_boolean.manutencao_piscina disabling when the switch.motor is switched on, but that is not happening. The second automation is still being triggered even though the code has disabled it.
UPDATE:
By adding a delay to the first automation made it work.
action:
- service: homeassistant.turn_off
target:
entity_id: automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente
- delay: 00:00:01
- service: homeassistant.turn_on
target:
entity_id: switch.motor
- delay: 00:00:01
- service: homeassistant.turn_on
target:
entity_id: automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente
Yeah, things can get backed up when there are a lot of events at the same time. And the whole infrastructure of HA is asynchronous, so there’s a lot of tasks running, getting created and exiting, etc., and you can’t always count on the order of things happening. It’s possible in your scenario (and it seems like it was happening), for the state of the switch being updated after the service call taking longer than getting to the next step of the automation which turns the other automation back on.
Delays will probably always work, but a better solution would be:
action:
- service: homeassistant.turn_off
target:
entity_id: automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente
- wait_template: >
{{ is_state('automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente', 'off') }}
- service: homeassistant.turn_on
target:
entity_id: switch.motor
- wait_template: "{{ is_state('switch.motor', 'on') }}"
- service: homeassistant.turn_on
target:
entity_id: automation.desligar_manutencao_da_piscina_quando_motor_for_acionado_manualmente
1 Like
Hi Isaranto, did yo ever figure it out? I am still having the same roblem.
I wrote in another thread that after I made a new totally unrelated automation things improved. But I also added an additional condition check to the automation, stopping it when it’s falsely triggered. It’s basically the same check that is the other automation that is supposed to disable this one.
Hi. I suspect that there is something subtle going on in your systems that you might not be aware of. I don’t doubt that your automations are (or were) firing when you thought they shouldn’t be, but I seriously doubt they were firing incorrectly, erroneously, falsely, etc. But certainly, if they are, we’d like to know so it can be fixed.
So, would it be possible to post at least one of your automations that you think is firing when it shouldn’t be, in its entirety (preferably the text of the YAML code as opposed to pictures)? I would like to get to the bottom of it and either help you fix the issue in your system or identify a bug if there is one so it can be fixed. But prolonging this assertion that automations don’t work without backing it up with actionable evidence isn’t helping anyone.