Automate setting an entity state?

[Stooovie]

I have some RF entities that lose the actual state on HA restart. I’d like to set the state of these manually after HA restart (I don’t ever update HA with front door open for example). I haven’t found a way to do this in automations, only in the Dev menu. Is that right? Thanks.

[123 (Taras)]

@Stooovie

RF entities that lose the actual state on HA restart

Do they use the RFlink integration? Because I saw a PR for it that’s proposing to address this issue.

[finity]

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

rodpayne/home-assistant/blob/88875142d709ed9f0aa738d68f61ab533c6eb9d5/.homeassistant/python_scripts/set_state.py

there is a hacs installable variation of it here:

GitHub - xannor/hass_py_set_state: Home Assistant Python Script to force set...

[Stooovie]

Interesting, thank you!

[Stooovie]

No, just a Sonoff RF Bridge with Tasmota.

[Stooovie]

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.

[finity]

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

[123 (Taras)]

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

Sonoff RF Bridge. Strategies for receiving data

Here are two strategies for receiving payloads published by a Sonoff RF Bridge (flashed with Tasmota firmware). Strategy 1: value_template In this strategy, all sensors are subscribed to the same topic published by the RF Bridge. The topic's structure depends on how you defined it when you configured *your* RF Bridge. This example will use `tele/RF_Bridge/RESULT`. Change that to whatever you have set for your Bridge. Because all sensors are subscribed to the same topic, a sensor will receive pa…

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.

[Stooovie]

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.

[Stooovie]

Thanks, it works.

[123 (Taras)]

@Stooovie

it works.

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

[Stooovie]

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

[Stooovie]

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.

[123 (Taras)]

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.

[finity]

@Stooovie

it doesnt seem to work anyway

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

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.

[Stooovie]

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!

[finity]

@123

what is the strategy you will use to set their states on startup

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

[Stooovie]

Yep. It works as expected.

[123 (Taras)]

@finity

set the state after restart

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.

[Stooovie]

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.