Yes I tried that. It will show ‘on’ instead of true.
I’m not using turn_on because I don’t want to turn them on.
The reason is that I have 5 wifi lights that I control with a wifi switch but the switch itself never cut the power to the lights so I can control them at any time. Instead I’m using mqtt to turn off all lights using the switch. My problem is that if I open one lights. It will not put the state of the switch to on. Does it makes sense?
I’m afraid it doesn’t…
What is “wifi switch” and “open one light”?
It would be easier if you described your configuration in more details.
I have one Shelly 1 Switch turning on/off 5 yeelights. Since I want the switch the turn on/off the yeelights and not the power to lights (because objvously if there is no electricity, the lights wont be connected to wifi) i’m using automation to turn on/off the lights if the switch is pressed but not close/opening the circuit. Now, let say, i open one light from home-assistant interface, i want the shelly1 switch to report “on” but not turn on all other lights.
Is it more clear ?
If I get it right, you use your shelly as a controller.
I’m not sure it’s a good idea to show the controller itself in the UI - why wouldn’t you show appropriate lights instead? Otherwise it’s a lot of fiddling and what for?
We are getting out of focus here,
Im using the switch to turn off the lights, that’s why i want it…
I am using this script for Insteon Keypad buttons. Insteon Keypad buttons can be linked to another Insteon device and turn that device on or off directly. HA gets a notification that the keypad button was pressed, but does not know explicitly that the other device is now “on”. The linked device does not report its state immediately to the Insteon modem.
In this case, HA is now in the state where the button is “on”, and the linked light (or lights) is “on” but HA still thinks it’s “off” (until the next poll).
However, I don’t want to simply send another “turn_on” request, since Insteon messages are serial and slow, and I don’t want to clog up the network, especially since some buttons may control 4 other lights. So this script is perfect, it allows HA to be updated to the current status without sending any messages through the Insteon component. Here is how I use it in my automation:
- alias: Kitchen Pendant Keypad Button Turned On
trigger:
platform: state
entity_id: switch.kitchen_keypad_button_2
to: 'on'
from: 'off'
condition:
condition: template
value_template: "{{ is_state('light.kitchen_pendant_lights', 'off') }}"
action:
- service: python_script.set_state
data:
entity_id: light.kitchen_pendant_lights
state: 'on'
brightness: 255
1 Like
Also, I agree that this should definitely be part of core HA. I am coming from OpenHab, and that was a vital feature of item state management - for each item, you can either sendCommand() or postUpdate(), where sending a command tells the device to perform the action, and posting an update just changes its state directly. Certain functionality for certain components requires this ability.
2 Likes
Aha, thx for the script, I was using curl commands to accomplish it… Gonna try our script instead…
I also want to change the friendly name, like the icon attribute…
If I want the same friendly name when I change state, does your script takes the old one how it was? Or should i specify it like you do with icon?
This is exactly what I was looking for. I am shocked this isn’t built-in.
My use case is to set custom attributes in one automation and use them as a condition in another automation (and clear them if condition is met).
More specifically, I have an automation that sends me a notification if a door is left open more than 15 minutes. The same automation handles all my doors. I intend to set a custom attribute on the door entity that it was open too long, then in the door close automation, check that attribute and send a notification that it has been closed. That solves the case of being away from the house and not knowing if someone closed the door after I got a notification that it had been open too long. I don’t want a notification every time a door is closed, just when it is closed after having been open too long.
1 Like
Following up: my intended automation worked beautifully. It turns out I don’t need to clear the custom attribute because the entity state change clobbers the custom attribute.
Examples:
In the doors-left-open automation I use the set_state as my first action and add the custom attribute to the triggering entity:
#notify homeowners if any door is open more than 15 minutes
- id: doors-left-open
alias: Doors Left Open
trigger:
platform: state
entity_id: binary_sensor.garage_door, binary_sensor.patio_door, binary_sensor.garage_tilt_single, binary_sensor.garage_tilt_double #, binary_sensor.front_door
to: 'on'
for: '0:15:00'
action:
- service: python_script.set_state
data_template:
entity_id: "{{ trigger.entity_id }}"
open_too_long: "true"
- service: persistent_notification.create
data_template:
title: '{{ trigger.to_state.name|title }} {{ trigger.to_state.state|replace("on", "open")|replace("off","closed")|title }} too long'
message: >
{{ trigger.to_state.name }}
{{ trigger.to_state.state|replace("on", "open")|replace("off","closed")|upper }}
{{ trigger.for }}
as of {{ now()|as_timestamp|timestamp_custom("%X on %x") }}.
In the doors-closed automation, the condition section is where the custom attribute is checked on the triggering entity’s from_state:
- id: doors-closed
alias: Doors Closed
trigger:
platform: state
entity_id: binary_sensor.garage_door, binary_sensor.patio_door, binary_sensor.garage_tilt_single, binary_sensor.garage_tilt_double #, binary_sensor.front_door
to: 'off'
condition:
condition: template
#NOTE: it's important to check attributes on from_state rather than to_state because device state changes clobber the custom attributes
value_template: "{{ trigger.from_state.attributes.open_too_long == 'true' }}"
action:
- service: persistent_notification.create
data_template:
title: '{{ trigger.to_state.name|title }} {{ trigger.to_state.state|replace("on", "open")|replace("off","closed")|title }}'
message: >
{{ trigger.to_state.name }}
{{ trigger.to_state.state|replace("on", "open")|replace("off","closed")|upper }}
at {{ now()|as_timestamp|timestamp_custom("%X on %x") }}.
2 Likes
glad you solved your issue 
I wanted to add that I “borrowed” @rodpayne s script and modified it to support creating a sensor as well as putting it in a HACS friendly repository. If anybody is interested it is available at https://github.com/xannor/hass_py_set_state
2 Likes
I’ve used this script, but if i set a state it is in this state for 1 sec and then goes back to the state it was in.
Is it possible to let the device in the state i have set with this script?
Are you setting a switch? Then configure a assumed state to false …
I want to use the somfy api for my covers. But the covers have the status unknown with this api.
So I want to set the state to open or closed.
Then I think you need to make template covers , and make a binary switch, that one keeps the value after a reboot,. Then set the state of your binary sensor… So the value template of your cover is the state of the binary sensor
Ok thanks, i will have a look into it.
I have home assistant only for a few week so still learning.
Well, I tried this code to change attribute of a trend binary sensor, namely - to change value of min_gradient attribute (as this attribute does not support templates and therefore is limited to hardcoded values - not very useful), and it also reverts to the original one after a while.
I know it’s slightly out of scope of this topic, but could anyone enlighten us why does that happen?
if you change the state of an existing/known entity that is managed by another component, the code that manages it will periodically update the state, likely wiping out any changes you have made. It really depends on how the component handles/updates its information, but likely any attribute that is meant to be read-only (i.e. the component only pushes its value) will be reset whenever the component refreshes.
The code here is more useful for custom attributes, or for entities that are only refreshed by events that are infrequent or manual. For most entities you would be better off with a template based entity wrapper. (i.e. a template switch or the like.)
You could “force” the value you want by having an automation that fires whenever the state of the entity changes and re sets the value, though you would have a minor blip when this occurs I belive.
Thanks for your explanation!
I think it’s HA code, not a component(integration?) one.
Agree. Just used it to see if it can help in my situation.
It would most likely happen.
Well, I want to use Trend Binary sensor, and it does not support setting its min_gradient attribute as a template - pretty silly as you can only have hardcoded values.
So currently I have a trend sensor without min_gradient, a template sensor that captures gradient attribute of the trend sensor every 10 seconds and a template binary sensor that compares state of that template sensor with input_number value - pretty long way if we cannot permanently modify that min_gradient, isn’t it?