Many times, the value of a sensor or binary sensor needs to be calculated based on various conditions and events. Writing automations to determine when these states should change is, obviously, an exercise left to each user and their use case, however, there’s no easy way to actually set a binary_sensor from an automation. So, instead, workarounds are used. Like…:
- Use input_boolean instead of a binary_sensor even though the boolean should never be toggled by a user. This provides restored state and is settable via a service call.
- Use input_text instead of a sensor, even though the value should never be set by a user. This provides restored state and is settable via a service call.
- Write a python_script that calls hass.states.set(). This provides a better entity type (sensor, or binary_sensor), however, state is not restored, it requires the additional python_script, and the entity_id is not changable in the UI. There is also the risk that a future integration will create an entity with the same name and thus, you will be overwriting those values with this call.
- Publish a MQTT discovery message at startup, and then publish the desired state to MQTT via an automation. This is cumbersome and requires and MQTT server, but, provides the correct entity_type and restores state (because it’s preserved in MQTT).
Having a service call dedicated to this task would solve a lot of these issues. The data would be in an appropriate domain (binary_sensor, or sensor, depending). The UI would allow the entity_id to be changed (presumably because the service call would operate on a unique ID and not the entity_id). And state could be restored on Home Assistant restart.
Even if only implemented as a custom_component, it would be advantageous.