The Smart Home Paradox

A smart home is, by definition, a machine that senses people and acts on what it senses. That is precisely the behavior a Sabbath-observant household needs to stop for twenty-five hours. So building a kosher smart home is not a matter of adding a setting — it is an architectural decision to give the system a second, explicitly defined operating state in which sensing continues but actuation does not, all timing is pre-scheduled, and no user action produces an electrical effect. Done properly, the house still works: lights come on, climate runs, doors open. It just does all of it on a schedule set before Shabbat began, and nothing a resident does changes what happens next. Halachic rulings and certification come from a rabbinic authority or a kosher certification agency; this article covers the engineering that makes such a ruling possible.

Start With a State, Not a Feature List

The failure mode in most attempts is treating Shabbat compatibility as a checklist of things to switch off. The result is a system where nobody can answer "what happens if I walk into that room?" with confidence. Instead, model an explicit Shabbat state in the firmware: a first-class mode with defined entry and exit conditions, its own event handling, and a documented list of every automation that is permitted to fire inside it.

The engineering test is simple and strict: for every input the system can receive in that state, the specification must say what happens — and for user-originated inputs, the answer must be "nothing." "Probably nothing" means the feature is not finished. This is the same standard applied to appliances in Sabbath mode appliances, and it belongs in the requirements document from the start, not in a later patch.

What Gets Disabled and What Keeps Running

  • Motion and presence sensors — keep sensing and keep logging, but disconnect the sensor from any actuation path. The point is that a person walking through a room changes nothing physical.
  • Lighting — schedule only. Every fixture that will be on during Shabbat is set by the pre-computed schedule, including dim night lighting. No occupancy triggers, no daylight-level triggers, no scene buttons.
  • Voice assistants — fully disabled, at the microphone. A device that listens and responds is direct activation in every meaningful sense, and muting it in software while the wake-word engine still runs does not solve the problem.
  • Smart locks and entry — mechanical key backup, or a scheduled unlock window. Cameras, doorbells, and intercoms that respond to a visitor need the same treatment; the design patterns overlap heavily with those in how Sabbath elevators work.
  • Apps and touch interfaces — locked, including read-only status views. A screen that updates because you looked at it is still a screen you activated.
  • Notifications and alerts — suppressed on the device, not merely on the server. Suppressing them centrally while the handset still buzzes achieves nothing.
  • Climate, water heating, and irrigation — thermostatic and timed control running independently of occupancy, with setpoints fixed before Shabbat rather than adjustable during it.
  • Safety systems — smoke, gas, leak, and security alarms stay fully active. Life-safety functions are never part of what gets disabled.

Architecture: Local First, Cloud Never

A kosher smart home has to be deterministic, and cloud dependency destroys determinism. If the schedule lives on a remote server, then a network outage, an API change, or a vendor's decision to push an update mid-Shabbat can change what the house does — and nobody in the house can intervene. Four architectural commitments follow:

  • Run the scheduler locally, on the hub, with the entire Shabbat schedule computed and stored before entry into the state. No lookups, no remote decisions, no dependency on connectivity.
  • Fail safe and fail predictably. Define behavior for power loss, network loss, hub reboot, and clock drift. After a reboot the hub must resume the pre-computed schedule without user interaction, which means persisting it to non-volatile storage.
  • Block updates in the state. Firmware and configuration updates must be refused during Shabbat on every node. Over-the-air update logic needs an explicit inhibit — see OTA firmware updates for where that gate belongs.
  • Enforce at the gateway. Do not rely on each device behaving well. The hub should refuse to forward commands and refuse to publish actuation messages in the Shabbat state, so a misbehaving device or a stray app request cannot get through.

Practically, this pushes you toward local protocols and a local controller rather than a cloud-account-based ecosystem. Local interoperability standards help, though they solve addressing rather than intent — see Matter protocol firmware development. And because the hub is now the single point of enforcement, it needs to be hardened properly: IoT security for connected products applies with extra force when a compromise means unwanted actuation in a room.

The Pre-Shabbat Setup Interface Decides Everything

Everything the house does for the next twenty-five hours is determined by one configuration session. That makes the setup UI the most important screen in the product, and it is where most implementations are weakest. It must:

  1. Compute times by location and date, including candle lighting and nightfall, and handle the long multi-day sequences of holidays that run into Shabbat.
  2. Show the complete resulting timeline — every scheduled event, room by room, in plain language, so a resident can review it before it becomes irrevocable.
  3. Report what is disabled, explicitly, including devices the hub could not reach and therefore cannot guarantee. Silent partial coverage is the worst outcome.
  4. Validate the schedule for conflicts, gaps, and impossibilities, and refuse to arm an incoherent configuration.
  5. Commit and lock. After entry, the configuration is read-only until the state ends.

Third-Party Devices You Do Not Control

Every real installation contains devices from vendors who never considered this use case. Three honest options: exclude the device from the Shabbat state and power it from a scheduled circuit; keep it but strip it of any trigger-driven behavior at the hub level; or refuse to integrate it at all. What you cannot do is assume a cloud-connected device is quiet because you turned off its automations in your app — its own service may still act. Documenting which devices are covered, and which are simply de-energized, is part of the deliverable.

Where Indirect Action Fits

Some functions genuinely need to happen during Shabbat in response to a person — a water dispenser, an accessible door, a medical monitor. Those are not solved by scheduling but by indirect-action design, where the user's action does not complete the circuit and the device's own independent cycle does. That is a distinct engineering discipline covered in grama mechanisms and indirect-action engineering. Combining a well-defined Shabbat state for the house with indirect-action design for the few interactive devices inside it covers nearly every requirement a household has.

What Is Worth Building

The market gap is not in individual devices — plenty of appliances now ship with a Sabbath mode. It is in the controller: a hub that enforces one coherent state across a mixed installation, proves what it is doing, and behaves predictably when things go wrong. That is a firmware and systems-architecture product, and it is the piece observant households consistently cannot buy. More on the discipline in our kosher product development hub.

Design the Mode Correctly From Day One

Retrofitting a Shabbat state into a finished automation product is far harder than architecting it in from the beginning, because the constraint touches event handling, scheduling, persistence, and the update path. Projects House builds electronics and firmware for Sabbath-compatible systems and has taken these products from specification through certification support. Tell us about your system through the contact form and we will help you architect it properly.