Trust modifiers: reduce a sensor's weight while a confounder (printer, fan, wind, etc.) is active

[BobMcGlobus]

Hey, been playing with AOD for a bit now and there's one consistent pain point where I think the model has a gap — wanted to float an idea before writing it up as an FR.

So I've got an Everything Presence Lite mmWave in my office, which sits between 4 3D printers and a desk fan that runs in summer. The mmWave is by far the best occupancy signal I have in that room — when it works it's brilliant. But it false-triggers semi-regularly: fast printer travel moves, fan kicking on, HVAC pushing air through. Living room is the same story with two FP2s and curtains flapping when there's wind. PIRs misfire when the robovac is out.

And just to drive home that this isn't only my weird setup — a bunch of other situations that come to mind where the same pattern would matter:

• Ceiling fan or AC running → mmWave gets noisy from the air movement (same as my desk fan, probably way more common)

• Robot vacuum doing its rounds → PIR and mmWave going wild in whichever room it's currently in

• Adjacent shower → humidity bleeds into the hallway through the open door, taking out hallway humidity as evidence

• Open window → CO2 equalises to outdoor levels, humidity follows outdoor, outside sound bleeds in — three environmental sensors compromised simultaneously

• Pets → PIR and motion-classifying cameras trigger on cats/dogs, FP2 sometimes too (related to Add support for ignoring animals #93 but different mechanism)

• 3D printer (mine, but applies to anyone with a print farm) → mmWave catches the print head motion, or table vibrations

• Vibrating washing machine or dishwasher → any vibration/mmWave sensor useless, sound sensors triggered for the entire cycle

• Range hood / extractor fan on → air movement again, plus messes with air quality readings

• Outside wind or rain on windows → noise on sound sensors, sometimes false motion on outdoor-facing cameras

Some of these you'd ideally solve with better sensor placement, but a lot are structural — if you have a robot vacuum, no PIR placement in that room is going to be reliable while it's running. If your CO2 sensor is in a room with an openable window, it will sometimes be useless. There's no placement fix for that.

The thing is, none of these sensors are broken. They're noisy under very specific, fully-observable conditions. The mmWave is super reliable maybe 80% of the time and unreliable for the other 20%, and AOD currently has no way to tell the difference — it just learns one averaged likelihood that's permanently slightly compromised. Dropping the entity-type weight in config helps a little but hurts the sensor during the clean majority too, which is the wrong trade-off.

What I'd actually want is something like:

- entity: binary_sensor.mmwave_office
  trust_modifiers:
    - condition:
        type: state
        entity: binary_sensor.any_printer_running
        state: "on"
      multiplier: 0.3
    - condition:
        type: state
        entity: switch.office_fan
        state: "on"
      multiplier: 0.5

While the condition holds, this entity's contribution to the calculation gets scaled. Multipliers stack multiplicatively. Mute falls out as multiplier: 0.0, no extra concept needed.

Reason I think this could fit cleanly: AOD already does context-dependent likelihood weakening — the decay interpolation in the [calculation docs](https://hankanman.github.io/Area-Occupancy-Detection/features/calculation/#decay-interpolation) is the same shape of operation (p_t_adjusted = 0.5 + (p_t_learned - 0.5) * decay_factor), just with the factor coming from an exponential time function. So conceptually trust modifiers would be a generalization of a pattern that's already there, not a new mechanism. Alternatively you could apply the modifier directly to the entity weight in the log-space aggregation, also works — just a different place in the pipeline. Haven't dug into the actual code so I might be missing constraints.

Side thought: if confounded windows could also be excluded from prior/likelihood learning (some flag like exclude_from_learning: true per modifier), each sensor would actually learn its clean likelihood instead of the noisy average. Feels like a sensible default tbh — right now my mmWave's learned numbers are basically averaged over both states, which seems already a bit off.

Looked through existing stuff — #93 (ignore animals) and #458 (per-motion weight) are adjacent but different (negative evidence and static weights respectively), and discussion #334 is about hard prediction overrides which is its own thing. So I don't think this is a duplicate, but flag me if I missed something.

Curious if this feels sensible or if there's a structural reason it wouldn't work that I'm not seeing.