new spreadsheet for generating configs (only works for entities that are binary at the moment)
2 Likes
The Bayesian sensor could benefit from being able to set a Unique ID so we can manage some settings in the UI. Other then that, great work on the new spreadsheet, it makes configuring the Bayesian sensor a lot easier.
1 Like
Still awaiting approval. HA team are (understandably) not keen on people continuing to develop YAML configs in the age of UI.
1 Like
Are you getting on ok with the 2022.10 updates?
1 Like
I really like the journey you are on improving the Bayesian integration. I think it has a lot to offer, but as you think it’s a bit hard to use. I am currently using it to guess if anyone is showering (used to ramp up the ventilation), if I work from home (adds heat and does not turn off the light in my office even though the motion sensor does not react), turn the home into day mode and recognising if the cleaning lady is in the house (should not trip the alarm).
I find it’s fun to setup a new bayesian sensor and see how it behaves, but tuning it is a bit hard (and almost always necessary). I envision the ability to plot the posterior probability and threshold over time along with all the observations state changes. This would be an awesome feature for tuning (and understanding) the sensor. It could possibly be done in the attributes section if the info dialogue box, but in the history section would probably be even cooler. What do you think?
PS! another small thing… would it be possible to fix home assistant to not round posterior probability to 0 and 1?
1 Like
I think this is a good idea. I think the best way would be to turn each Bayesian configuration into a ‘device’ and then both the on/off state and the probability can be entities. Although I’m not sure if the HA team approve of virtual objects being devices in their own right, so we may need to find another solution, like this Add helper - Attribute as Sensor by gjohansson-ST · Pull Request #79835 · home-assistant/core · GitHub
This would be cool, but hard to achieve, I’m not sure of any integrations that allow the overlaying of events on a history plot. That being said, if you open up a Bayesian sensor then under the state history it will show a logbook of events that changed the state.
Have a go with this spreadsheet (would obviously be great to not need the spreadsheet
I’ll take a look at this and why it happens. Probably just rounding once it gets past 0.999
I created a posterior template sensor to test what I would want to show when analyzing bayesian sensors:
Template:
sensor:
- platform: template
sensors:
bayesian_home_office_posterior:
friendly_name: 'Home office posterior'
unit_of_measurement: '%'
value_template: "{{ state_attr('binary_sensor.bayesian_home_office', 'probability')|float * 100 }}"
2 Likes
I for one just came across the sensor… I’m digging it!
I would like to be able to put a template in the “prob_given_true:” field because I want to put an equation that relates to outside temperature. The lower the temperature, the higher the probability that my house HVAC system needs to switch to heating. I had a work around by dividing temperature ranges into groups and using the numeric state platform, but this working solution was broken by the update. The “hacky” work around ((posted in Bayesian sensor fundamentally changed#79694)) doesn’t work:
“The hacky work around for template observations would be to re-write the template to return None instead in place of when it would return False - to again induce Bayesian to ignore a negative observation as it used to.”
I tried this as below:
- platform: template # Needs to have 'None' in else clause so Bayesian ignores if not true
value_template: > # Checks to see if outside hourly weather is greater than or equal to 72 degrees
{% if states('sensor.test_hourly_weather') | float >= 72 %}
True
{%- else -%}
None
{%- endif %}
prob_given_true: .05
prob_given_false: 0.95
But this seems to just read as False when temperature is < 72 (even though I used “None” as suggested) and rather than just be ignored, it significantly effects the Bayesian probability outcome
1 Like
FWIW, I recently got into Home Assistant and I was happy to see there’s a Bayesian thingy. I’ll be playing with it soon.
I was using the bayesian sensor for over 3 years for detecting presence at home.
I can’t get it working anymore as before 2022.10, so I created a custom_component for it.
If you wan’t to use it, add GitHub - gieljnssns/bayesian: The bayesian binary sensor for Home-Assistant to HACS and search for bayesian.
It should work again as before…
I am working on a pull request to enable exactly this functionality using the numeric state entity:
Accept more than 1 state for numeric entities in Bayesian by HarvsG · Pull Request #80268 · home-assistant/core · GitHub
This is a great sensor. I use it for presence in rooms and I’m thinking about using it for presence in the house. I see all the changes that have been made and they are great. I’m loving it.
1 Like
Hi,
100% agree with you. I’m using Bayesian for things like “should the home heat?”, “should it cool?”, “home sleeps?”, presence etc. Yes, like mentioned somewhere here, we have a lot of sensors … but … Making decision if to heat or cool based only on ext and int temperatures is not as great (and sophisticated) as using it with Bayesian together with some other data like season, month, presence etc. It is like kind of AI 
and works much better then simple if > then.
I vote for it - for me it is an essential part of any automation.
M.
1 Like
Hi,
so, my remarks from top of the head to think about …
-
Rename “Bayesian” to something like “Probability” as I mentioned here: Bayesian rename
-
Add some linear observation - at least templatable threshold. The higher/lower result the higher/lower threshold of the whole sensor or higher/lower given_true/given_false values.
Nothing else is crucial to me, I covered my needs so far
Generally I wish more integrations like this, more “soft” decision HA capabilities, like kind of machine learning, easy access to history values, AI etc.
Thanks, have a nice day,
M.
Can you expand on this, I am not quite sure what you mean? Allow the probability threshold to be variable/template-able?
If so can you explain in what situations you would want this?
Hi @HarvsG ,
OK.
I mean to control the probability sensor state not only by binary input states, but also by int/float values:
- The more is the Sun set the higher probability is turning lights on while observing also decreasing indoor illuminance.
- The faster I’m approaching home (different speed by car, by walk, etc.) the higher probability is to start heating to have comfort at the right time (maybe a bit overkill example).
- The farther are home members from home, the higher probability is to switch my Vacation state sensor on and do relevant actions.
- The more is night coming up the higher probability is that the home goes to sleep.
So would be nice to integrate also non-binary observations. Or at least have an option to control values which are currently fixed:
I can see useful when we could control the “probability_threshold” programmatically. So instead of using just one “hard” float value in sensor definition, would be nice to have an option to use a template for this value.
probability_threshold: "{{ template returning the value }}"
F.e. the probability threshold of heating switch could slightly decrease with decreasing outdoor and indoor temperatures. While one feels good when inside is 19°C and outside is 25°C, different feeling is when inside is 19°C and outside -5°C.
The same is with “prob_given_true” and “prob_given_false” properties to control particular observed sensors.
Best,
M.
1 Like
This might be a neat idea. I could see some logic behind it.
What you are proposing is similar to what I’m trying to achieve in Bayesian - Accept more than 1 sate for numeric entities by HarvsG · Pull Request #80268 · home-assistant/core · GitHub
Except in this case it is organised into buckets rather than a continuous function.
If I understood correctly negative observations are taken into account to determine the propability since 2022.10? And the prop_given_true when observation is False is 1 minus prop_given_true when observation is true?
In that case I have some doubts if this is correct. Of course statistically this make sense but in the physical world this can cause some faults.
I noticed this with my Bayesian sleeping sensor which I use. To predict if everyone in my house is sleeping one of the observations I use is a template to check the time delta since the last time a motion sensor was updated. When this delta is less than 30min it is very unlikely that everyone is sleeping (Prop_given_true= 0.05). But when the delta becomes 31 min the observation becomes False and results in a very high propability that everyone is sleeping which is not correct.
Another generic example:
If I see a man with an umbrella walking on the street it is very likely that it is raining, P is for instance 0.99. But if I don’t see that man with an umbrella I can’t say that the probability is very low that it is raining because not every man is carrying an umbrella when it’s raining. Of course it says something but definitely not 1-0.99 = 0.01
Maybe it is an idea that the user can set all 4 propabilities (true positive, true negative, false positive and false negative)