Automate setting an entity state?

Configuration
3

There is a python script you can use to set any state of any entity here:

there is a hacs installable variation of it here:

3 Likes
4

Interesting, thank you!

5

No, just a Sonoff RF Bridge with Tasmota.

6

Hmm, I’m unable to add python_scripts: to my config yaml, " Integration error: python_scripts - Integration ‘python_scripts’ not found". Installing it in HACS first doesn’t help.

7

You need to manually add the “python_scripts” folder to your config folder then in configuration.yaml add:

python_script:

(without the ‘s’)

then after that is done (and after a HA restart) you should be able to add it via HACS

1 Like
8

If you use one of the two receiving strategies I described in this post, you won’t have that problem.

You should know that set_state.py will set an entity’s state in a manner where the value only persists until the next restart.

9

That’s way too complicated for me, I wasn’t able to set it up. I’ve ordered zigbee sensors that don’t have this issue and until then I’ll just brute-force it like this.

I want to get rid of the shitty RF equipment anyway.

Thanks.

10

Thanks, it works.

11

As long as you don’t mind that the value set by using set_state.py doesn’t survive a restart.

12

I dont. That’s why I’ll just set it on the restart via automation.

13

Hm, it doesnt seem to work anyway. I use this in the Dev menu

service: python_script.hass_entities
data:
  action: set_state_attributes
  entity_id: binary_sensor.kerui
  state: off

It doesn’t change the state. Jesus christ the hoops I have to jump through because HA2022.2 added the “unknown” state to binary sensors… Fuck it, Ill just open and close the doors after restarting HA like an animal, two days of coming up with any solution wasted… Learning about Tasmota rules to set the “retain” flag (couldnt do it), the RF multiplexer (ditto), now this Python script… Ill just throw these RF sensors out.

14

Given that the entities lose their actual state on restart, what is the strategy you will use to set their states on startup?

  1. You will set them to a state regardless of what was their previous state.
  2. You will save their states prior to restart and then restore those saved states on startup.
  3. Something else.

EDIT

I didn’t see your previous post while I was composing this reply. You appear to be in a foul mood so there’s no need to reply to my questions. Good luck.

15

I’m confused…

where did you get this from?:

service: python_script.hass_entities
data:
  action: set_state_attributes
  entity_id: binary_sensor.kerui
  state: off

the service for the set_state.py should be:

service: python_script.set_state
data:
  entity_id: binary_sensor.kerui
  state: off

:man_shrugging:

EDIT:

TBH, I don’t use it anymore and no longer have any personal examples of its use but there is a thread that covers it’s use linked in the github for the HACS integration (at the bottom) but using examples from there should still work.

16

It does work, I got too worked up (trying to find a solution for two days) and confused it with a similar script in HASS ( Entities Script: Python script to handle state and attributes of existing sensors and entities).

The Set State script does work and provides a good workaround to my issue.

Thanks!

1 Like
17

I think the strategy was to use this script to set the state after restart. Which was the point of the thread.

1 Like
18

Yep. It works as expected.

19

Which means to set the entity’s state on startup. So what is the state value that will be used? It can only be a default value, like all binary_sensors are set to off (regardless of their actual state, prior to restart), or to their last known state which would require saving it (somewhere) prior to restart.

I’m assuming they’re being set to a default value regardless of whatever it was prior to the restart.

20

Yes, assumed close. The door is almost always closed, and 100% when HA is restarting, so it’s safe to assume.

Also, no, the RF sensors now have state “unknown” until first change. That’s the original issue. It was never an issue until 2022.2.

It’s a quick and dirty fix until I get the zigbee sensors that report the actual states, not only stage changes.

21

If the RF bridge doesn’t publish its payloads as a retained message, the payload is not stored on the MQTT Broker. When Home Assistant restarts it re-connects to the MQTT Broker and receives no information about the binary_sensor’s current value. As of 2022.2 that situation is reported, quite truthfully, as unknown.

In previous versions, it wouldn’t reflect the actual situation (that it didn’t know the device’s state because it didn’t receive any information) but simply fake it and report (without any evidence) that it’s off.

This issue of “not knowing” is eliminated if the RF bridge publishes its payload as a retained message because it’s stored on the MQTT broker. On startup, Home Assistant connects to the broker and immediately receives the stored value.

22

I understand. I wasn’t able to make the RF Bridge send MQTT with the retain flag. I’m not learning intricacies of Tasmota rules and payloads for this. Tried with help of Tasmota Discord, couldn’t do it.