I assume your problem is simply that this automation is not working as expected?
Does it work if you manually execute it from the Automations page? If it does, the action is correct.
Does it work if you remove the condition (i.e. immediately turn the heater back off when it is turned on)?
Could you paste a screenshot from Developer Tools / States showing what switch.space_heater looks like? Curious about the attribute: mode which I suspect may be the issue.
You’re absolutely correct: not working as expected. When I execute from Automations, it does as expected–however, independent of the condition. Regardless of the condition of the respective switch, it will still execute.
Is this what you’re looking for?? My gut says no…
Here’s how I have it defined in configuration.yaml:
space_heater:
unique_id: space_heater
value_template: "{{ is_state('input_boolean.ir_heater_onoff', 'on') }}"
turn_on:
- service: scene.turn_on
entity_id: scene.xgzu9izdfgwmqqj4
- service: input_boolean.toggle
entity_id: input_boolean.ir_heater_onoff
turn_off:
- service: scene.turn_on
entity_id: scene.xgzu9izdfgwmqqj4
- service: input_boolean.toggle
entity_id: input_boolean.ir_heater_onoff
FYI: scene.xgzu9izdfgwmqqj4 is the IR Blaster; it’s the power button.
Manual execution bypasses the trigger and condition, and executes the action.
That screenshot is exactly what I needed to see.
There is no mode attribute set up, so remove the attribute: mode line from the trigger to get it to work on the switch state rather than a non-existent attribute [docs]. If there had been such an attribute, it would have been shown in the right-hand column, and would be an odd (but not impossible) way to configure a switch.
The id line suggests it was created by the GUI, so curious to know how that attribute line got there…
I believe the UI editor has a default “attribute” selection box that for some reason people think they need to always fill in with something (even if it doesn’t seem to make sense).
I’m seeing this all the time in “why won’t my automation work?” threads.
It’s definitely a flaw in the docs or the non-intuitive design of the editor tht saeems to be the issue since so many people are doing it.
+1
I have also noticed a recent uptick in support requests featuring State Triggers with unnecessary references to an attribute (and quite often the attribute doesn’t even exist for the specified entity).
It’s unclear to me why people are including an attribute (especially when it doesn’t even exist) given that the field clearly indicates that it is optional. 
Perhaps smibrandon can shed some light on this matter. Why include the mode attribute?
I removed the Attribute, and that fixed it…thanks!
And, as for my utilization of that Attribute field–not intended whatsoever. So, clearly hit something by accident
You would literally have to type the word mode because a switch entity doesn’t have a mode attribute.
This happened here too.
I wonder if there’s some way the GUI auto-populates it, either visibly or behind the scenes. I can’t find any example document or tutorial that could have caused it.
I created a simple automation using the Automation Editor. After completing it, I switched to YAML mode and this is what it displayed:
alias: New Automation 45
description: ''
trigger:
- platform: state
entity_id: binary_sensor.test_1
from: 'off'
to: 'on'
condition: []
action:
- service: light.turn_on
data: {}
target:
entity_id: light.floor_lamp
mode: single
It contains only what I had selected or entered in the UI and nothing more.
yeah, that example really isn’t a good comparison since that is the expected/desired behavior for the UI editors to automatically add an ‘id’ to the automations and scripts. those are required to make them editable via the UI so they get added automatically.
Yeah, I also tried it and it certainly doesn’t do it every time. I was suggesting there may be some sort of edge case where the information gets populated, perhaps invisibly and perhaps with a different type of automation (device, event etc) then not erased when the desired selections are made.
It wasn’t the id I was pointing out, but the superfluous and seemingly wrong attribute: mode line in that code. Seems a bit coincidental that two people would use the same additional automation-breaking line: I suspect either there’s some document somewhere that people are following, or it’s a side-effect of an edge case in the UI.
I REPLICATED WHAT I [PROBABLY] DID!!
I created a dummy automation in the Automation Editor, and checked the YAML, and no attribute. I went back into my automation (GUI), selected an attribute, then tried to remove it by highlighting the text and deleting it. The attribute field appeared empty, however when clicking the dropdown, it still had an item checked…which also appeared in my YAML.
Takeaway: Need to use the X on the right side of the field to actually remove any attribute
Here’s the dropdown after my attempt at removing the Attribute.
Thanks for confirming that it’s difficult to do this “accidentally”. You have to deliberately select an item from the list.
What is misleading is that the editor allows one to backspace/delete the text. It gives the impression that the attribute value has been removed but, in fact, it still remains. That seems to be a bug.
BTW, what kind of entity did you select for the State Trigger that offers all of those attributes? I’ve tried several switches (based on different platforms) and the only attribute offered is FriendlyName.
Which version of Home Assistant are you using?
Those are the standard attributes for an automation entity…
Like I said, I only see FriendlyName in the attribute list (using version 2021.3.4).
Curious to learn why the OP sees more items in the list.
I discovered that if you backspace/delete the attribute, the editor temporarily hides the Save button. The moment you move the focus away from the Attribute field, the Save button re-appears. Switching to YAML mode shows the attribute has indeed been removed.
Select the first entity in the list, which is likely to be an automation, and:
(mine doesn’t have ID as it’s hand-crafted)
The OP’s automation, the one in the first post, contains a State Trigger for a switch along with a mode attribute.
trigger:
- platform: state
entity_id: switch.space_heater #<---- switch, not automation
attribute: mode #<---- this attribute doesn't exist for switch entities
from: 'off'
to: 'on'
How did the OP manage to achieve that combination?
BTW, this investigation is moot if the OP isn’t using the latest version.
Yeah I know. I wonder if @smibrandon started by creating a “skeleton” using the UI and an automation entity (as it’s the first thing on the list), with the attribute: mode inadvertently set, then proceeded to update the entity to a switch in YAML mode without removing the attribute line…
I confirmed that the sequence of events you described will result in the automation entity’s mode attribute mistakenly assigned to a switch entity. I’d call that a bug; changing the entity’s domain (i.e. from automation to switch) should purge the attribute field.
I’m not in agreement with the OP’s characterization of this as being done “accidentally”. One must deliberately perform a very particular sequence of steps to force this bug to appear. Although automations may be the first to appear in the entity list (assuming one doesn’t have an alarm_control_panel), you still have to select one and then select the second (or third) item in the list to get mode.
If anyone wants to write this up as an Issue in the Frontend repo, have at it.
oops.
I was going by the comments of the post not the code in the code block.