Nearly every product with a microcontroller now has a screen on it, and for the Shabbat-observant market the screen is often the hardest component to get right. A thermostat, an oven, an infusion pump, an elevator panel, and a hotel room controller all face the same question: what happens on that display when a person interacts with the product, and what happens when nobody does. The answer decides whether the product is usable at all in an observant home or institution.
Projects House works on these products as engineers. Halachic rulings come from a qualified posek, not from a supplier. What we can do is build a display subsystem whose behavior is fully specified and measurable, so a posek is evaluating the actual mechanism rather than a description of it. The material below is design guidance, not a ruling.
The Question Is Causation, Not Technology
Engineers tend to reach for the display technology first. That is the wrong starting point. The review question is what causes a pixel to change state and how directly. A display that refreshes on a fixed schedule regardless of user input presents a very different mechanism from one whose pixels change because someone pressed a button, even if both use the same panel.
So the design work splits into two independent decisions. First, what drives the update: a free-running timer, or a user action. Second, what physically happens in the panel when an update occurs. Both matter, and they are usually reviewed separately.
Display Technologies and What Actually Changes
The physics differ enough between panel types that the distinction is worth understanding before you choose. Our general comparison of LCD, OLED, and e-ink for products covers the commercial tradeoffs; here is what matters for this specific constraint.
| Technology | What happens on update | Idle behavior | Notes for this market |
|---|---|---|---|
| Segment LCD | Segment electrodes are driven; no light is created or extinguished | Holds image with continuous AC drive | Common in appliance panels; needs a backlight to be readable at night |
| Graphic TFT LCD | Pixel transmission changes; backlight stays on independently | Backlight typically on continuously | Backlight and image are separable subsystems, which is useful |
| E-ink / electrophoretic | Charged particles are physically moved by a driving waveform | Image persists with zero power | No light emission at all; slow refresh is a feature here |
| OLED | Each pixel emits light when driven | Dark pixels are fully off | The most direct light-creation case; usually the hardest to accommodate |
| LED segment / dot matrix | Discrete emitters are switched | Off unless driven | Similar considerations to any lighting element |
E-ink is popular in this market for an obvious reason: it holds an image without power and creates no light. It is not automatically simpler, though. Electrophoretic panels need a driving waveform to change state, they age with refresh count, and full-refresh cycles flash the panel in a way that is very visible. If the product needs a readable display in the dark, e-ink still needs a front light, which puts you back in the lighting conversation covered in lighting and light control for Shabbat observance.
Always-On Displays and Pre-Rendered State
The most robust pattern is a display that never changes in response to a user and only changes on its own schedule, or does not change at all.
Frozen display
The simplest version. When the mode is engaged, the display is written once and then locked. Nothing a user does alters it. Setpoints, timers, and status all continue working internally; the panel just stops reporting them. This is common on appliances and is one of the behaviors behind Sabbath mode on appliances. The usability cost is real: users lose feedback, so the product must fail safe and its behavior must be predictable without the screen.
Timer-driven refresh
The display updates at fixed intervals from a free-running clock, for example once a minute, whether or not anyone is present or has touched anything. The content shown at each tick is whatever the internal state happens to be. Crucially, the update does not accelerate, delay, or change because a user acted. This is the same scheduling discipline used for sensor-driven scheduled operation controllers.
Pre-rendered state sets
A more sophisticated variant. Before the observance period begins, the firmware renders every screen the product could need into a fixed set of frames. During the period, the scheduler selects among already-prepared frames rather than composing new content. Nothing is generated on demand. This costs memory and forces a bounded state space, which is good discipline anyway: if you cannot enumerate the screens in advance, the product's state machine is probably underspecified.
Backlight Behavior Is a Separate Design
On any transmissive LCD, the backlight is an independent subsystem and should be treated as one in the specification. Three approaches show up in practice:
- Continuously on. Simplest to reason about, worst for power and for panel life, and sometimes objectionable in a bedroom. Common on institutional wall panels that are mains powered.
- Continuously off. The panel remains readable in daylight or under room light. Requires a transflective or reflective LCD, which is a component decision made early, not a firmware setting.
- Scheduled. Backlight follows the same free-running timer as the rest of the system, for example on during known waking hours. This ties into calculating halachic times inside the product, since the schedule usually needs to track sunset and nightfall rather than clock hours.
What almost never survives review is a backlight that comes up because a proximity sensor saw a hand or because a button was pressed. If a product has that behavior, it needs a documented way to disable it in firmware, not just a menu option a user could toggle back.
Touchscreens, Buttons, and Feedback
A capacitive touchscreen is both an input and a display, which makes it the most difficult interface for this market. Capacitive sensing is continuous by nature, but the visual response is immediate and directly caused. Products intended for observant use frequently move to physical controls specifically so that the input and the display can be decoupled, a tradeoff we cover more generally in physical buttons versus touchscreen interfaces.
Removing visual feedback creates a real usability problem, especially for hospital equipment and senior living installations where a confused user is a safety issue. Solutions include mechanical detents that confirm a press by feel, controls that physically stay where they were set so position itself is the readout, and clear labeled markings that make the current mode obvious without a screen. Medical products carry the additional constraint set described in designing medical devices for halachic use, where the alarm and display requirements of the device standard are not negotiable.
Specifying It So It Can Be Reviewed
Write the display behavior as an explicit table: for each input event, what happens on the panel, after how long, and driven by what. Then measure it. A logic analyzer capture of the panel's chip-select and data lines during a user press is far more persuasive than a paragraph claiming nothing happens. Include the failure cases: brownout, watchdog reset, and what appears on the panel when power returns mid-period. Institutions running hotel and campus deployments will ask about all of it, as will the review process behind a halachic endorsement.
Projects House designs display subsystems for products intended for observant users, from panel selection and driver firmware through the timing evidence a posek needs to evaluate the mechanism. Describe your product through our contact form and we will tell you which display architecture fits it.