A motion sensor in a hallway is a solved engineering problem everywhere except in a home, hospital wing, or hotel corridor used by Shabbat-observant people. There the question is not whether the sensor works. It is whether walking past it constitutes the user performing an action that switches a circuit. That single question reshapes the architecture: where the sensing happens, what triggers the actuator, how much delay sits between them, and whether the system was already running before anyone walked in.
Projects House builds these systems as an engineering firm. We do not issue halachic rulings, and neither should any vendor. Rulings come from a qualified posek. Our job is to build a mechanism whose behavior is precisely defined and fully documented, so a posek can evaluate what the device actually does rather than what a marketing sheet claims. Everything below is design vocabulary, not a ruling.
The Vocabulary Engineers Need
Three distinctions drive almost every design decision in this space.
Direct versus indirect causation
In a conventional design, a user action closes a circuit: a hand breaks an infrared beam, the controller sees an edge, a relay pulls in, a light turns on. The chain is immediate and deterministic. Designs intended for Shabbat use are built to avoid that chain. Instead the user action changes a stored value, and something else, running on its own schedule, later reads that value and decides what to do. This family of approaches is generally discussed under the heading of grama, or indirect-action mechanisms, and it is the single most important concept in the field.
Already-running versus newly started
A sensor that begins sampling because a person appeared is engineered very differently from a sensor that has been sampling continuously since before Shabbat began. In the second case, presence does not start anything; it only changes what the already-running process observes. Continuous operation costs power and component life, which is why these products often use mains power or an oversized battery budget rather than the aggressive sleep strategies that dominate ordinary low-power firmware design.
Necessary versus incidental result
Engineers are trained to make outputs deterministic. Here, determinism is the thing under examination. A design where the light unavoidably comes on the instant a person is detected is a different object of review from one where detection only makes a state change more likely at the next scheduled evaluation. Whether either is acceptable is a question for a posek; the engineer's obligation is to make the difference explicit and measurable.
Continuous-Scan Architectures
The workhorse pattern looks like this:
- The sensor front end runs continuously at a fixed rate, set before Shabbat. It never sleeps and never wakes on an event.
- Detections are written into a memory location. Nothing downstream is triggered by the write.
- A separate scheduler, driven by a free-running timer, evaluates that memory location at a fixed interval, for example every 15 or 30 seconds.
- Only the scheduler commands the actuator. The actuator has no path back to the sensor.
The architectural rule is that no interrupt line, no wake-on-motion pin, and no event callback may run from sensor to actuator. In practice this means disabling exactly the hardware features that make a normal IoT device efficient: interrupt-driven wake, edge-triggered GPIO, and adaptive duty cycling. Firmware written for these products is polling firmware by design, which is why generic smart-home stacks are usually rebuilt rather than configured. The same logic underpins timer-based controllers that run scheduled operation.
Delay, Randomization, and Decoupling
Beyond the scan loop, three techniques appear repeatedly.
| Technique | What it does | Engineering cost |
|---|---|---|
| Fixed delay | Actuation happens a set interval after the scan reads a changed value | Users perceive the system as slow; needs clear indication |
| Interval quantization | Actuation can only occur at scheduled tick boundaries | Worst-case latency equals the tick period |
| Randomized evaluation | The scheduler's decision point varies within a window | Requires a defensible entropy source and full documentation |
| Physical decoupling | Sensing and actuation live in separate units with no direct link | Higher BOM, more installation work |
Randomization deserves care. A pseudorandom sequence seeded from a fixed value is deterministic in principle even if it looks random, and any competent review will ask about the seed. If randomization is part of the design, document the entropy source, the distribution, and whether the sequence is reproducible.
Sensor Choices and Their Side Effects
Not every sensing technology fits this architecture equally well. Passive infrared modules are cheap but commonly ship with a built-in comparator and a latching output pin, which is precisely the direct trigger the design is trying to avoid; they often need to be used in raw analog mode. Ultrasonic and time-of-flight distance sensors emit continuously whether or not anyone is present, which fits the always-running model neatly. Millimeter-wave radar can detect presence through a wall, which changes where the sensor can be mounted and removes some of the awkward geometry. Camera-based occupancy raises a separate set of questions covered in our discussion of alarm and security systems.
Documenting the Mechanism for Review
This is where most projects fail, and it is not a technical failure. A posek cannot evaluate a device from a datasheet. What is needed is a plain-language description of causation that a non-engineer can follow, backed by evidence. A usable review package includes:
- A one-page causal diagram: what the user does, what changes, what reads the change, what acts, and what the timing is at each hop.
- A written statement of every path from sensor to actuator, including the ones that were deliberately removed, and how removal is enforced in firmware and hardware.
- Measured timing: oscilloscope or logic analyzer captures showing the actual interval between detection and actuation across many trials, not the nominal value.
- Failure behavior: what the device does on power loss, on sensor fault, on watchdog reset, and when the schedule rolls over at the end of the observance period.
- A configuration lock statement: which settings can change during operation and which are frozen when the mode is engaged.
These items belong in the specification from the beginning, not assembled at the end. We treat them the way any regulated project treats design inputs, and the practice is described in more detail in our guide to writing halachic requirements into a product spec. Products that will carry an endorsement should also plan for the review cycle described in halachic certification for products.
Where This Shows Up in the US Market
The demand is concentrated but real. Residential automation in Brooklyn, Lakewood, Monsey, Los Angeles, and Miami drives most consumer volume, and those installations look a lot like ordinary Shabbat-compatible home automation with the sensing layer rearchitected. The institutional market is larger per project: hospitals with observant patient populations, senior living communities, hotels running Shabbat programming, and school and campus buildings. Institutional buyers care about two things consumers do not, namely how the system integrates with an existing building management system and how it behaves when the fire alarm or emergency lighting takes over. Both belong in the spec on day one.
If you are developing a sensor-driven product for this market, Projects House can architect the sensing and actuation chain, write the firmware so the causal path is what the documentation says it is, and prepare the review package your posek will need. Tell us what the product does through our contact form and we will map the constraints against your design.