Accept more than 1 state for numeric entities in Bayesian (#33186)

* Add example for multi state home-assistant/core#119281

https://github.com/home-assistant/core/pull/119281

* corrects typos

* see if it stops netflify build breaking

* wrap jinja2 in raw to keep liquid happy

* typos

* Update bayesian.markdown

* Add a hint for multistate template observations

* tweaks

* Update bayesian.markdown

---------

Co-authored-by: c0ffeeca7 <38767475+c0ffeeca7@users.noreply.github.com>
This commit is contained in:
HarvsG 2024-09-17 07:30:05 +01:00 committed by GitHub
parent 321d7c30ba
commit 15a75801a6
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -125,6 +125,10 @@ observations:
## Full examples
These are a number of worked examples which you may find helpful for each of the state types.
### State
The following is an example for the `state` observation platform.
```yaml
@ -163,6 +167,8 @@ binary_sensor:
to_state: "ac"
```
### Numeric State
Next up an example which targets the `numeric_state` observation platform,
as seen in the configuration it requires `below` and/or `above` instead of `to_state`.
@ -181,7 +187,9 @@ binary_sensor:
below: 50
```
Finally, here's an example for `template` observation platform, as seen in the configuration it requires `value_template`. This template will evaluate to true if the device tracker `device_tracker.paulus` shows `not_home` and it last changed its status more than 5 minutes ago.
### Template
Here's an example for `template` observation platform, as seen in the configuration it requires `value_template`. This template will evaluate to true if the device tracker `device_tracker.paulus` shows `not_home` and it last changed its status more than 5 minutes ago.
{% raw %}
@ -202,3 +210,66 @@ binary_sensor:
```
{% endraw %}
### Multiple state and numeric entries per entity
Lastly, an example illustrates how to configure Bayesian when there are more than two states of interest and several possible numeric ranges. When an entity can hold more than 2 values of interest (numeric ranges or states), then you may wish to specify probabilities for each possible value. Once you have specified more than one, Bayesian cannot infer anything about states or numeric values that are unspecified, like it usually does, so it is recommended that all possible values are included. As above, the `prob_given_true`s of all the possible states should sum to 1, as should the `prob_given_false`s. If a value that has not been specified is observed, then the observation will be ignored as it would be if the entity were `UNKNOWN` or `UNAVAILABLE`.
When more than one range is specified, if a value falls on `below`, it will be included with the range that lists it in `below`. `below` then means "below or equal to". This is not true when only a single range is specified, where both `above` and `below` do not include "equal to".
This is an example sensor that can detect if the bins have been left on the side of the road and need to be brought closer to the house. It combines a theoretical presence sensor that gives a numeric signal strength and an API sensor from local government that can have 3 possible states: `due` when collection is due in the next 24 hours, `collected` when collection has happened in the last 24 hours, and `not_due` at other times.
```yaml
# Example configuration.yaml entry
binary_sensor:
name: "Bins need bringing in"
platform: "bayesian"
prior: 0.14 # bins are left out for usually about one day a week
probability_threshold: 0.5
observations:
- platform: "numeric_state"
entity_id: "sensor.signal_strength"
prob_given_true: 0.01 # if the bins are out and need bringing in there is only a 1% chance we will get a strong signal of above 10
prob_given_false: 0.3 # if the bins are not out, we still tend not to get a signal this strong
above: 10
- platform: "numeric_state"
entity_id: "sensor.signal_strength"
prob_given_true: 0.02
prob_given_false: 0.5 #if the bins are not out, we often get a signal this strong
above: 5
below: 10
- platform: "numeric_state"
entity_id: "sensor.signal_strength"
prob_given_true: 0.07
prob_given_false: 0.1
above: 0
below: 5
- platform: "numeric_state"
entity_id: "sensor.signal_strength"
prob_given_true: 0.3
prob_given_false: 0.07
above: -10
below: 0
- platform: "numeric_state"
entity_id: "sensor.signal_strength"
prob_given_true: 0.6 #if the bins are out, we often get a signal this weak or even weaker
prob_given_false: 0.03
below: -10
# then lets say we want to combine this with an imaginary sensor.bin_collection which reads a local government API that can have one of three values (collected, due, not due)
- platform: "state"
entity_id: "sensor.bin_collection"
prob_given_true: 0.8 # If the bins need bringing in, usually it's because they've just been collected
prob_given_false: 0.05 #
to_state: "collected"
- platform: "state"
entity_id: "sensor.bin_collection"
prob_given_true: 0.05 # If the bins need bringing in, then the sensor.bin_collection shouldn't be 'due'
prob_given_false: 0.11 # The sensor will be 'due' for about 1 day a week (the 24 hours before collection)
to_state: "due"
- platform: "state"
entity_id: "sensor.bin_collection"
prob_given_true: 0.15 #All the prob_given_true should add to 1
prob_given_false: 0.84 # All the prob_given_false should add to 1
to_state: "not due"
```
To achieve a similar result for multiple `template` observations targeting a single entity, write your templates to return `True` or `None` rather than `True` or `False`.