Occupancy sensors need an inference firewall, not just a privacy toggle

I want occupancy sensors to expose an “inference firewall”: automations get only a coarse local state such as occupied, vacant, or unknown, while raw motion timelines, sound events, distance readings, and presence patterns stay inaccessible—even to the vendor cloud. A camera feed is not required to infer sleep schedules, work hours, or household routines; event sequences can be sensitive on their own.

A DIY version seems plausible with an ESP32, ESPHome, and an LD2410: publish one filtered presence entity, keep the detailed sensor entities disabled, and block internet access. But should the boundary be enforced in hardware/firmware, by the operating system’s permissions, or merely offered as a user setting? Hardware is harder to bypass; settings are easier to ship. Coarse data may reduce advanced features and some automation reliability, but that trade-off seems more honest than collecting everything by default. Disagree, have examples, or propose a better permission model?

The important word is “inaccessible.” A UI toggle that hides detailed entities is not an inference firewall if firmware still retains or uploads the data. I would want a small trusted component that emits an enum and has no API for the underlying stream. Otherwise this is mostly an access-control promise made by the same software being restricted.

The routine inference point is reasonable, but I would distinguish demonstrated possibility from guaranteed behavior. Sensor-event sequences can reveal activity patterns; that does not mean every occupancy product is building a sleep model. The proposed boundary is still useful precisely because it limits what future firmware could infer from historical data.

I would put the enforcement in two places: firmware for the default boundary, then local OS permissions for composition. Home Assistant can work locally, but “local” should not automatically mean every local integration gets the raw feed. A capability token for “occupied” is a better abstraction than a hidden collection of sensor entities.

User settings win on adoption because people understand a slider better than a hardware trust model. The problem is defaults and recovery: setup flows tend to enable whatever makes the demo impressive. Maybe ship coarse-only by default, with a deliberate unlock for richer data and a visible audit trail.

Blocking the device’s internet access helps, but it is not proof that proprietary firmware cannot leak through another path. I would want packet-level verification plus a device that can still perform its core function offline. “No cloud” and “no detailed local access” are separate claims.

The LD2410 example is exactly where this gets practical. It exposes moving/still targets and engineering values, which are handy while tuning detection. I would run a separate ESPHome node that publishes only a binary sensor and keep the tuning interface on a maintenance VLAN. Not elegant, but achievable.

I’m not convinced coarse occupancy is always safer. A long-lived occupied/vacant history can still reveal routines, especially if the automation platform stores it indefinitely. The firewall needs retention limits too, or we protect the input while quietly preserving the same inference downstream.

There is also a social permission problem: one resident may want fall detection or room-to-room automation, while another objects to detailed sensing. A single household-level setting hides that conflict. Per-person consent is difficult without identification, but the design should at least acknowledge multiple people share the space.

“Unknown” is doing useful work here. Sensors fail, networks partition, and people move behind furniture. If automations treat every missing reading as vacant, the privacy-preserving mode becomes a reliability bug. Three states are not overdesign; they prevent a bad fallback.

Support will be the ugly part. When an automation misfires, people will ask for logs, and logs are exactly where the timeline sneaks back in. A good implementation needs short-lived diagnostic traces, explicit export, and automatic deletion rather than an always-on history nobody remembers enabling.

I like the distinction between raw sensing and derived data. “No camera” is not the same as “no behavioral information,” and the latter is the relevant privacy boundary. I would avoid calling the proposal a standard, though; it is a useful design term, not an established Matter feature.

For procurement, a hardware-enforced boundary is easier to audit than a vendor promise, but it can complicate support and feature updates. I would ask for a documented data-flow diagram, offline operation, signed firmware, and a way to verify that the cloud receives neither raw nor derived telemetry.

One implementation trap: filtering at the automation layer still leaves the detailed values available to every process that can read the sensor. The filter has to happen before publication, ideally with separate credentials or a physically isolated service. Otherwise someone will eventually add a dashboard and call it debugging.

I can see customers accepting coarse occupancy for lights and heating, but advanced safety features are harder to explain without richer signals. The honest product choice may be two modes: privacy-first by default, and an explicit high-function mode with clear retention and sharing consequences. At least people can choose knowingly.