Baysesian Config Flow #122552
Baysesian Config Flow #122552
Conversation
|
I don't think this should use subentries as in managing observations (which I think is the driver here). |
Thank you for this advice, perhaps you could explain in a little more detail? I have had a look at the scape component. Each Bayesian sensor may have none, one or many of a |
This comment was marked as outdated.
This comment was marked as outdated.
| STATE_SUBSCHEMA = vol.Schema( | ||
| { | ||
| vol.Required(CONF_ENTITY_ID): selector.EntitySelector( | ||
| selector.EntitySelectorConfig(domain=[SENSOR_DOMAIN, BINARY_SENSOR_DOMAIN]) |
There was a problem hiding this comment.
Are these the only sensor domains we want to support? Or is this too constraining?
There was a problem hiding this comment.
In 5b0d09f I have enabled many more domains in the absence of a centrally managed list of all possible domains. Broadly I have enabled all domains for state observations that a user could reasonably predict e.g those that are not timestamps
For numeric domains I have included all those that I can find which have a state that is usually a number.
This comment was marked as resolved.
This comment was marked as resolved.
Co-authored-by: G Johansson <goran.johansson@shiftit.se>
I will do this tomorrow Edit: Done, videos uploaded to YT as they are too large for github. Links in the Proposed changes. |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
|
Not stale |
|
#117355 Is merged and subconfig entries are enabled, so I may re-write |
Proposed change
Implement a config flow for the Bayesian Helper
Will likely require #117355Not requiredSince this may increase the user base I am keen to merge #119281first as it is breaking. ✅ DONEExplanation for reviewers:
The Bayesian helper is used to create a virtual binary sensor that gets its state by from a combination of other sensor states. For example a user could predict whether
binary_sensor.bayesian_cookingisonfrom a variety of correlated, but imperfect sensorssensor.kitchen_humidity,{{(sensor.kitchen_temperature - sensor.avergae_temperature) > 3}},sensor.gas_usage,sensor.electricity_use_power,binary_sensor.no_one_homeRather than using "if this, then that" logic, Bayesian uses a statistical/probability technique called Bayes' Rule.
Essentially, the user configures these imperfect sensors and an expected states e.g.
binary_sensor.no_one_home == Trueand provides the probability of these being True if bayesianbinary_sensor.bayesian_cookingisonand if it isoff. Each of these is known as anobservationand in nearly all cases users will specify >1 observation for each Bayesian binary sensor. Observations may be configured asstate(checks for exact matching of a state),numeric_state, which checks if a sensor is in a range andtemplatewhich evaluates the template and coerces it into a Boolean.There are also variables which apply to the Bayesian binary sensor rather than per-observation;
priorandprobability_threshold.prioris the baseline probability that sensor should beon, andprobability_thresholdis the probability at which the sensor would be consideredon.Because of this one-to-many relationship of Bayesian binary sensors to their constituent observations this is a complex ConfigFlow. A similar thing has been achieved before by the 'Scrape' component.
ConfigFlow Example video
OptionsFlow Example video
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: