#Possible bugs in new Bayesian integration (UI-configured) – HAOS 2025.9.1

1 messages · Page 1 of 1 (latest)

lavish heart
#

Hi all,

I think I’ve hit a bug with the new UI-configured Bayesian integration in HAOS 2025.9.1.

What I tested
I have a working YAML Bayesian sensor with:

prior: 0.2, probability_threshold: 0.85

8 observations, all to_state: "off":

group_daytime_doors (0.85/0.15)

Motion: kitchen & bedroom (0.7/0.3), living/hallway/laundry/computer (0.85/0.15)

person_recently_seen (0.85/0.15)
I duplicated this exact setup via the new UI integration (same prior, threshold, and per-sensor likelihoods).

Expected
YAML and UI versions should match: near ~99–100% when all observations are “off,” and drop consistently when “on,” with both sensors staying available.

Actual

YAML: correct math, stable behavior.

UI:

Often logs one update in Logbook then flips to Unavailable.

Recovery is inconsistent.

Why this looks like a bug
Configs are identical (prior, threshold, observations, likelihoods). Only the UI-configured entity misbehaves. It feels like the new config-flow path is mishandling odds multiplication or clamping/rounding, and may also be flaking on entity availability.

System
HAOS 2025.9.1.

Anyone else able to reproduce this with the UI-based Bayesian sensor (same prior/likelihoods), or see what I’m missing? Thanks!

frosty kayak
lavish heart
#

Maybe, but it's an integration. My probably first Discord use. Anyhow, to update, unavailables went away on their own accord. Numbers of a yaml Bayesian vs UI Bayesian do not match, but got closer performance by changing UI numbers over and over. So I'm uncertain if a bug or not.

knotty cradle
#

@zealous mauve

zealous mauve
#

Hmm, odd! The logic side is unchanged so you should be getting identical numbers. I'm also confused as to how it could lead to an unavailable entity. To be clear, when you set up the UI, you used percentages rather than copy and pasting the decimal probabilities right?

#

Can you enable debugging and capture some logs?

zealous mauve
#

@lavish heart

lavish heart
#

@zealous mauve Ok, debug enabled, no I didn't copy anything built it from scratch in the UI to match my yaml sensors.

As mentioned above, unavailable cleared on its on since the first setup. Took a couple days +-.

Numbers for probability and prior do not match as I've been experimenting with numbers, nor do sensor probabilities match anymore, but I got it closer to each other fiddling with the UI numbers.

Anything else I can help with from my end, I'm game to try. But no expert here in HAOS or on Discord. Probably my 3rd post ever. I'll post logs when I've triggered sensors a few times.

lavish heart
lavish heart
#

@zealous mauve Well, having no idea what I'm doing, I changed the UI Bayesian back to match the yaml Bayesian, named different only, used the same sensors, about 8.

They weren't all tripped before, so I'll watch it a couple days.

The next oddity, initially, I just tested with 3 sensors, all were in the UI, but some not triggered.

I have the yaml Bayesian drop to 99% with only one sensor triggered.

The UI hadn't ever dropped to 99 on one trigger. Today even though numbers mismatched, it did drop to 99.

I'll observe a couple days. My apologies in advance for being ignorant as to how or what goes in the background of a Bayesian. 🤔 It may be working as intended and needs time. I'm uncertain actually at this point.

zealous mauve
#

Thanks, it shouldn't need time, the UI and YAML should output exactly the same (yaml 0.99 and UI 99%). They share the updating logic, so as far as I can tell, the only differences could come from how the values are processed and stored on input

zealous mauve
#

OK, I couldn't find a bug. But I might have been able to re-create your issue (by accident). (Only the different numbers issue - not the unavailible sensor issue)
When I recreated my YAML configs in the UI I got some different probabilities because I updated the entity name in both but forgot to reload the YAML.
As such the one of the YAML observations was ignored because the entity was unavailable - producing different odds.
Indeed in your logs we see - but only once per update.

2025-09-08 14:45:57.429 DEBUG (MainThread) [homeassistant.components.bayesian.binary_sensor] Observation for entity 'binary_sensor.aqara_computer_room_motion_motion' returned None, it will not be used for Bayesian updating
2025-09-08 14:45:57.430 DEBUG (MainThread) [homeassistant.components.bayesian.binary_sensor] Observation for entity 'binary_sensor.aqara_bedroom_motion_motion' returned None, it will not be used for Bayesian updating

You have some enities that are unavailible, either because they are or because the entity name is wrong - can you see if they are equally wrong in YAML and the UI?

zealous mauve
zealous mauve
#

You can compare and contrast in the developer tools -> states page

lavish heart
#

@zealous mauve Ok, I'll work on this. The way the sensors were chosen, I'd type a partial name, ie, computer room motion, or bedroom motion and select each with just a click. I'm confident on the sensors, but will investigate all suggestions.

I hadn't ever deleted them in the Bayesian UI, the none as mentioned just went away on its on.

Maybe this makes sense;

Observation about None states in Bayesian UI vs YAML

When first setting up the Bayesian binary sensor in the UI, I saw repeated debug logs like:

Observation for entity 'binary_sensor.aqara_computer_room_motion_motion' returned None, it will not be used for Bayesian updating
Observation for entity 'binary_sensor.aqara_bedroom_motion_motion' returned None, it will not be used for Bayesian updating

These sensors are Aqara motion sensors, which don’t truly go unavailable, but they do “sleep” when idle.

At those times, Bayesian seems to read them as having no usable state (None).

After a day or two, once every sensor had been physically triggered at least once, the None messages disappeared and the UI and YAML Bayesian outputs converged.

So the difference in percentages between UI and YAML models at the start may be explained by the UI version seeing more None values, while the YAML version already had cached states. Doesn't explain why they're still different.

Now that all sensors have been triggered at least once, the None messages are gone.
But the YAML and UI Bayesian gauges still show different percentages, even though the binary sensor thresholds and “on/off” behavior match. So this seems to be a separate issue beyond the None handling.

In case you have no Aqara motion sensors, they come factory set for on 30 seconds, medium sensitivity, and most if not all Aqara sensors sleep to save battery.

Technically, I've never had an unavailable sensor.

Maybe the Bayesian needs to look a none as no change. or something.

zealous mauve
#

As far as I know the UI and YAML versions should treat none values just the same and should listen for changes in the same way (it's the same code)

The only reason they would be different is if you'd configured the entity name incorrectly in the YAML

zealous mauve
lavish heart
#

@zealous mauve Here's mine, with another sesnor question. Only difference I'm aware of. see below.

“In YAML, the observation for my doors is added as binary_sensor.daytime_doors, but in the UI it shows up as group.daytime_doors. I added them correctly from the entity picker (motion icon etc.), so I don’t think it’s a selection error. Could that difference in entity type handling be why the probabilities don’t always match?"

lavish heart
#

@zealous mauve One last bother.

To test, I deleted the doors group in yaml Bayesian and added them individually and added them individually in the UI Bayesian.

No groups.

So, I'll compare them again, but theoretically they should completely match with seperate individual sensors. Same observations. and follow up, if I see any difference.

zealous mauve
lavish heart
#

@zealous mauve Pardon my ignorance, what i see that's different. Have no idea why.

Looking at both Bayesians in Developer tools, UI version observes all 10 sensors, observed true.

Yaml version observes only 8 as true.

Which, if it means anything could explain the probability differences.

The why the Yaml version only see 8 of 10, same sensors, I've looked. I have no idea.

zealous mauve
#

Two must be configured incorrectly in yaml

lavish heart
#

@zealous mauve lol, my bad and my apologies, they finally match. Dang yaml.👍

lavish heart
#

@zealous mauve My apologies for dragging you thru this when it was my own fault. At least you were helpful to me and I appreciate it, and your time.