A purpose-built household operating screen for an older Windows laptop: five RTSP cameras, media, weather, traffic, calendars, Yankees automation, and daily modes designed to keep working without constant attention.
ClosetCast started with a practical constraint: turn an old Windows laptop into a useful all-day dashboard customized to my home. The goal was not a generic smart-home demo. It was a calm, durable screen that could run every day without needing attention.
The hardest part was translating how I wanted the dashboard to behave into clear product rules. Morning mode needed weather, traffic, and calendar context. Normal mode needed to stay useful without becoming noisy. Yankees mode had to take over at the right time, and wind-down mode needed a different pace.
Contribution boundary
I designed, built, configured, and operate the application. Camera hardware, Apple Calendar, Open-Meteo, media sources, and sports data remain external dependencies.
Current versionCamera feeds and personal information intentionally sanitized for security and privacy
02 / System
Simple stack, explicit security boundaries
The stack stays intentionally straightforward: Electron, plain HTML, CSS, JavaScript, JSON configuration, FFmpeg, and focused Node modules. That keeps the system understandable and maintainable on the older laptop it was built to use.
01Private local configuration
Lorex and Ring RTSP URLs, feature flags, and local paths stay outside git; a public example file documents the expected shape.
02Independent services
Camera bridging, calendars, weather, traffic, media, schedules, and time rules fail separately.
03Kiosk renderer
The interface coordinates modes and layouts while keeping unavailable services visible but contained.
Calendar privacy
Calendar support uses user-provided .ics or webcal:// feed URLs. The application does not store Apple ID credentials or depend on account passwords.
03 / Operation
What runs every day
Five RTSP camera feeds—including Lorex cameras and a Ring doorbell—bridged through FFmpeg with focus, split, grid, and primary-camera layouts.
Morning, normal, Yankees, and wind-down modes that change the information and media shown throughout the day.
Weather, traffic, calendar events, local media, and configured YouTube ambiance with explicit unavailable states.
Schedule-driven Yankees behavior that detects the game window, opens the configured stream page, resolves matching links during prepare and live windows, and returns to the dashboard afterward.
Windows Task Scheduler support for wake behavior, scheduled relaunch, and a friendly setup entry point for the target laptop.
Local logs, private configuration, and an isolated test profile for troubleshooting without real household data or disruptive kiosk behavior.
04 / Verification
Recovery is part of the interface
Feeds reconnect
Exited RTSP processes wait and retry while the camera tile remains visible.
Data degrades safely
Calendar data is cached, while failed weather, traffic, schedule, or media requests are logged without taking down the display.
Failures stay isolated
A broken camera, media source, or Yankees lookup does not collapse the rest of the kiosk.
Tests avoid side effects
The isolated profile disables fullscreen, sleep, autostart, wake tasks, and real private configuration.
The interface below is preserved as a version-history artifact. It shows the earlier ClosetCast 1.0/beta design, before the current layout and feature set shown above.
ClosetCast 1.0 / betaEarlier interface retained to show the product's evolution
05 / Result
From experiment to active household system
ClosetCast now runs as an operated display on the machine it was designed for, waking on schedule, presenting five camera feeds and the right household context for each part of the day, and degrading visibly when an external service is unavailable.
The biggest lesson was that implementation speed is not the same as product judgment. AI helped me generate and modify code, but I still had to define the architecture, daily behavior, security boundaries, failure modes, and tradeoffs that made the application useful instead of a pile of features.
