I am working on a UI set up - it will come with time
4 Likes
In my Search around Bayesian sensor adding to person entity I bumped into this post. @HarvsG any thoughts on the possibility to make it available for the person entity hence it improves presence/person detection.
Combining bayesian with the person would make Automations (for me) less vulnerable to false positieves or device malfunctions (simply replace tracker linked to person.x instead of changing al entities in several automations.
Ooo, think is an interesting and good point.
I’m not sure what the entity filter is on the person entity
Edit: it seems that it is filtered for device_trackers only and I’m not sure of a built-in way I could optionally turn the Bayesian sensor into a device tracker.
In the meantime there is some discussion of doing this with an automation here that you might find helpful:
It relies on a little know action device_tracker.see which allows one to manually change the state of a device_tracker.
If you find a simple, elegant and ideally blueprint able way of doing this then I could add it to the Bayesian Docs.
1 Like
This is quite an old thread (I see the number of active installations is down to 254 since it started 
) and things have probably (heh) moved on, but…
I use the integration quite a lot (without, I confess, understanding much of the theory) and I find that one of its limitations is the fact that the HA sensors it generates are binary - which seems counter-intuitive, given you’re trying to decide whether something is probably true.
In practical terms, the probability attribute is extremely useful and the integration would benefit from making it a sensor in its own right.
For room-level presence detection, for example, I have a Bayesian entity for each room and a template which compares their probability attributes and picks the highest. This compensates for phones being left in the other room, dogs triggering motion sensors and all the other stuff that makes binary presence detection go wrong.
Just a thought…
2 Likes
Not sure if it’s a good Idea when the bayesian is fed by the Same device_tracker that is going to be changed by the .see action
Yes, I agree with this. Especially as the probability could be converted into a binary sensory with the aid of a threshold helper.
However it would be a big breaking change to switch this. So I think the solution in future is going to be to create a template sensor from the probability attribute. I believe these can now be blueprinted, so my plan is to make an official blueprint and add it to the docs.
See this PR Add template blueprint for Bayesian by HarvsG · Pull Request #130376 · home-assistant/core · GitHub
I expect the user base to pick up once the Config Flow UI PR is merged
3 Likes
@hastaboera No that is not a good Idea.
The idea would be to create a new device tracker and create an automation that couple the state of Bayesian sensor to the new device tracker using the .see action.
1 Like
I really like the idea of this. But it seems to me that it needs to be a component of something else. I am a developer and have two computer Science degrees so I am OK putting it together. I would think that most HA users just want it to work. For example, I have sensors of various sorts throughout my house. I could use the Bayesian Integration to calculate the probability of my wife or me being in each room. I could then combine the to specify which room I am in.
Maybe a blueprint would work for this. I have used blueprints but not delved into creating one. I will have to investigate this.
4 Likes
As the template sensor now (and has for some time) supported actions, you could also use that to call device_tracker.see based on changes in the binary sensor whilst also implementing logic that mimics the ‘consider_home’ behaviour
Exactly this - I extract this with a template sensor for all my Bayesian Sensors
It would have to be quite complex to handle all the observations correctly - I’ve been using a spreadsheet to do it and it still takes a lot of thought.
Edit: The spreadsheet comes from here:
2 Likes
Well, I’m one of the few people who are using it!
@HarvsG do you have any plans to tackle the FR about dynamic priors?
I’d love to be able to do bayesian updating but I can’t see any way to accomplish it with the current implementation.
The only other thing I was wondering was whether just setting the prior to 0.5 and then having the “real” dynamic prior as a heavily-weighted observation might work, but it feels like (and probably is) a horrible hack which wouldn’t be anything like as accurate.
Any thoughts? Have I missed a way to achieve this?
1 Like
Thanks for pointing me towards that FR. I hadn’t seen it before.
I’m struggling to understand why one would want to update the prior rather than just using another (template) observation. I think that it also violates some of the principles of Bayesian stats… maybe.
I’m no statistician so I might have this totally wrong, but I thought the concept of Bayesian updating was all about using the posterior as the new prior as more information becomes available?
The Wikipedia article seems to suggest so:
The sequential use of Bayes’ theorem: as more data become available, calculate the posterior distribution using Bayes’ theorem; subsequently, the posterior distribution becomes the next prior.
Exactly, this process of updating is what the component does with each “observation”, which is why I would argue to include this as another observation rather than altering the prior.
That being said a prior could change, e.g a room occupancy prior would likely change if it changes use from let’s say a study to a nursery, and in those cases it would be sensible to adjust a prior.
Rather than templating would there be any objections to implementing this as an action? E.g (bayesian.change_prior). And so perhaps this could be automated.
I fully admit to being out of my depth in terms of the maths and logic on this one - I’m just trying to make the best use of the tool (and hopefully understand it at the same time).
Perhaps it’s simpler if I explain the simple test setup I’m trying to get working before using this in more complex ways.
Setup:
- I have a mm-wave presence sensor in one of my rooms
- I’ve created a numeric helper based on the binary state of the real sensor, which reports 100% when the room is occupied and 0% when it isn’t
- The reason I did this is to get the values recorded in Home Assistant’s long-term statistics database, which they now are
- I’ve created an SQL sensor which reads the LTS data looking back over the last 12 weeks to see if the room was occupied on this hour of this weekday
- e.g. if it’s 8pm on a Friday, the sensor looks back at the last 12 instances of “8pm on Friday”, takes the mean of the mm wave sensor values for those 12 instances, and reports that as the percentage likelihood the room is currently occupied
Believe it or not this all actually works, and it’s this SQL sensor I want to use as my prior because, as best I can understand it, that’s literally what it is.
It’s just that instead of being a static prior, it’s 168 individual priors (one for each hour of each day of each weekday) and the current presence sensor state changes the value of the prior next time that particular prior rolls around in 168 hours’ time.
This is the “simple” version in that the next step - if I can get this integrated into the Bayesian sensor somehow - is to use it for a much more complex prediction scenario with an additional feedback loop of whether the prediction was correct or not.
2 Likes
I was writing out my Bayesian sensors yaml with an automation using SQL sensors to change the prior for room occupancy weekly as room usage changes over the school year for my family.
If there are any devs on this thread that are interested in seeing a ConfigFlow enabled for Bayesian, there is an open PR awaiting review:
1 Like
Imho the bayesean is the heart of a lot of future in HA.
LLMs lie.
Ok in fairness it’s hallucinating. But they only do it in absense of information. The secret of a well behaved well mannered info is access to the right information.
One can use Bayesians to smooth out the noise. But most of us don’t have a clue what to actually put in to make them work.
Did you know with a sensor per room per person you can model the most likely room you are in? And when tipped by sensor data you have a rock-solid room tracker? 
Is this thing that is represented by a bunch of maybes likely to be happening. It’s intuition.
Oh it’s a good time to go to bed. (aggregate motion + Time of day + maybe vacation and a few others)
What rooms are my people in (the sensor series above with a template wrapped around it)
I’m using the stove (a combo of presence heat and energy)
Build enough of these and expose the to your AI and it gets light years smarter. It infer and tells stories. Don’t make it guess about fact. Let Bayesian do the heavy lift math on anything that is likely to but you need a solid answer.
So config flow yeah easier is good but we really need to invest time in a guided tour.
1 Like
I agree with everything you’ve said and some interesting ideas there
Yeah, in the config flow I have started to use values from the first page to populate hint text when setting the observations to help users to understand the config variables a bit better, you can see in the video in the PR.
Agreed that in an ideal world we would automate it, by asking users to select a time range that their sensor should have been true and then HA does some lovely maths to work out which sensors have the highest correlations and then auto-generate prob_given_true etc from that data. (Maybe the new recorder.get_statistics action is a step in the right direction)
Realistically, we are not going to get features like that until Bayesian has a bigger user base as the changes would require external modifications to how config flows etc work.
Would love to see your yaml for this.