Lights off at bedtime, curtains open in the morning: a RuView and Jev smart home

You settle into bed and the lights gradually dim. In the morning, the curtains open within the hours you have chosen. If you get up for a drink during the night, only a soft pathway light comes on.

A home needs some understanding of everyday activity to do this, but continuous bedroom video is not necessarily the right input. Inspired by this post about RuView, we explore a practical design: wireless sensing supplies clues, Jev helps interpret the situation, and a home automation controller executes actions residents have allowed.

This is a product design and integration proposal. RuView has sensing and integration code, but the RuView + Jev routines below have not been tested together on hardware and are not ready-made features you get simply by installing the project.

Separate the demonstration from deployment evidence

Video from the post by @make_claude, served by this site with the source preserved. It shows node, motion-energy and skeleton interfaces; the clip does not establish sensing accuracy or demonstrate the Jev home routines proposed in this article.

RuView works with changes in Wi-Fi signals. Channel State Information, or CSI, is more detailed than a signal-strength indicator and can provide inputs for estimating human activity. Signal processing and specialized models turn measurements into estimates of the environment. See the project repository.

That process depends on supported hardware and environmental conditions. An ordinary laptop network adapter should not be treated as a complete CSI sensor. The project's automatic mode can also fall back to simulated data when hardware is unavailable. A running dashboard, skeleton display or changing measurement does not by itself establish that it is sensing a real room. See the user guide.

The post's demonstration helps explain the idea; it does not replace a documented hardware setup, real data provenance and measured errors. This article does not adopt the post's price, accuracy, health-monitoring or compliance claims as evidence for purchasing or deploying a system.

Three jobs: sensing activity, interpreting context, controlling devices

“Activity recognition” can describe several different questions: what happened in a room, what that means in context, and whether a device should respond now.

1. RuView and sensors provide evidence. Possible inputs include occupancy, changes in movement and data quality. The available outputs depend on the actual hardware, model and integration path.
2. Ordinary code prepares the facts. It calculates durations, checks freshness and allowed hours, and reads household preferences, lighting state and recent manual actions.
3. Jev chooses among bounded interpretations. Proposed options might be preparing for sleep, still active, brief nighttime activity, starting the morning or insufficient information. It judges prepared evidence and context; it does not directly compute human movement from raw Wi-Fi measurements.
4. The automation controller decides whether to act. Only commands that pass permission, schedule, quality and device checks reach the lights or curtains.

Jev's documented Choice, Score and Noul primitives produce structured judgments about supplied state. Choice is a useful fit for selecting among a few situations or responses. Its outputs still require evaluation on real household data; a model's numerical output is not a guarantee of device reliability. See the official introduction.

The situation labels above are proposed options, not a list of events already supplied by RuView. Likewise, an existing Home Assistant integration does not mean every capability advertised by the project is exposed through that one path. See the integration documentation.

Routine one: gradually dim the lights at bedtime

Imagine that residents have enabled a sleep routine for a particular room and time window. The system observes continued occupancy with reduced movement, then considers bedtime mode and whether someone recently turned the lights up manually.

Being still is evidence, not proof of sleep. Reading, using a phone or having an awake partner can all make an automatic blackout unwelcome. If the routine needs to distinguish a bed from a chair, an optional bed-pressure sensor or bedside button could supply additional input. Those are extra devices and design choices, not assumed RuView features.

A trial sequence could dim the lights first, provide a short opportunity to cancel, and only then turn off the selected fixtures. A manual switch-on should suspend that automatic shutdown so the person and the system do not fight over the light. Missing evidence or conflicting occupants should leave the current lighting unchanged.

RuView already includes a sleep-related state machine. The flag turning off does not establish wakefulness: it also clears immediately when presence disappears, or after 30 seconds of sustained higher motion. Simple, stable thresholds and durations may be sufficient without Jev. A judgment model becomes more useful when the routine must account for preferences and exceptions such as reading tonight or a partner still working. See the sleeping state-machine implementation.

Routine two: open the curtains after the morning starts

Opening curtains should require more than one movement event. We propose checking that the resident's morning window has begun, activity has persisted, blackout or sleep-in mode is off, and nobody else still needs darkness.

The current Home Assistant guide says bed_exit is not published by the sensing server and its wake-up blueprint will not fire yet. This curtain routine needs a separately verified signal or user confirmation. See the current wake-up blueprint limitation.

Given that context, Jev could choose to recommend the morning routine, keep waiting or report insufficient information. Residents preconfigure the allowed opening amount and speed; the controller checks device state, permitted control range and manual overrides. On an error, it preserves the existing state instead of repeatedly issuing commands.

Shared bedrooms need particular care. An occupancy estimate should not be treated as identification of a specific family member. If the system cannot establish whether someone else is still asleep, use a confirmation button or retain an existing schedule. Inferring that morning activity has begun is also not evidence that reliable bed-exit detection has been implemented.

Routine three: nighttime activity only enables a nightlight

The same increase in movement calls for different responses at night and in the morning. During night mode, activity could enable a preconfigured low-brightness pathway light while the curtains remain closed. A local rule can turn it off after activity has ended and the configured delay has elapsed.

Without reliable bed-zone and room localization, describe this as a nighttime activity trigger rather than claiming to know who left a bed and where they went. Short, predictable lighting rules can run entirely locally. Jev only needs to participate when preferences, context or exceptions require interpretation.

Privacy is a design choice, not a consequence of removing cameras

Avoiding bedroom images reduces exposure of faces, clothing and visual details of the room. Occupancy, sleep-related clues and arrival or departure times can still reveal personal routines. Camera-free does not mean free of personal data, and it does not establish compliance with a particular regulation.

For this proposed system, privacy should become something residents can understand and control:

• Process at home where possible. Keep raw wireless measurements local. Use the state needed for the current automation and avoid retaining a long-term activity history by default. Let residents opt into time-limited diagnostic recording when needed.
• Send only what a decision needs. If using a hosted Jev API, send minimized events and preferences without names, addresses or raw CSI. Even a reduced event summary can disclose household activity; show residents exactly which fields leave the home network.
• Give everyone a choice. Provide a guest mode, room-level controls and an obvious pause switch. Household members and visitors should know when sensing is enabled and which areas it covers.
• Keep people in control. Manual switches take precedence. Short, readable action records explain what triggered a routine and let residents disable it.

These are requirements we recommend implementing, not a claim that an existing RuView or Jev installation automatically supplies them. If a cloud judgment service is used, retain local rules and manual controls when the connection fails. Basic lighting should not depend on a successful model request.

Start with a prototype that can be evaluated

Begin with one room, one light and one clearly defined routine. Confirm that the sensor data comes from the actual environment, then consume existing events through an interface such as MQTT while tracking source, time, quality and missing values. The MQTT bridge implementation is a useful starting point for understanding event conversion.

Initially, record what the system would have done without controlling devices. Ask residents whether each suggestion was appropriate. Compare simple rules with Jev-assisted recommendations on the same replay: unwanted shutdowns, manual corrections, delay, behavior when data is missing, and the exact information sent outside the home.

Once the agreed acceptance criteria are met, enable cancellable gradual dimming before expanding to curtains or other devices. The goal is fewer interruptions, retained human control and less unnecessary data collection—not a more detailed record of domestic life.

Prepared from public documentation and code, reviewed on October 27, 2026. No sensing hardware was connected, and sleep detection, bed exits and device routines were not field-tested. The household automation scenarios are proposals.