Most smart homes are leased, not owned. Every command you send travels to a cloud you don't control, owned by a company with interests misaligned to yours. This system proves that meaningful control of your physical space doesn't require surrendering it to a vendor. Edge-AI Home Monitoring is a locally-governed, vendor-independent home automation platform designed to answer: can a household be sovereign over its own infrastructure?
This update also focuses on improving the project’s reliability and development workflow.
Added 20 Pytest test cases covering the core functionality of the system, helping verify that critical components behave correctly and reducing the risk of regressions.
Configured GitHub Actions to automatically execute the entire test suite after every commit and pull request, ensuring new changes don’t break existing functionality.
Automated testing and Continuous Integration (CI) make the project more robust, maintainable, and production-ready. Every code change is now automatically validated before it becomes part of the project, providing faster feedback during development and increasing confidence in future updates.
Docker support for the Edge-AI Home Monitoring System is now fully working end-to-end.
start.bat
start.sh
No more manually running docker compose, checking dependencies, or following multi-step instructions. Just run the script for your OS and the entire stack comes up ready to use.
This closes the loop on the Docker migration from a few devlogs ago. Before, Docker removed the Python/venv/dependency headaches but still required knowing the right compose commands. Now the onboarding experience is genuinely “clone → run one script → done,” with the HTML first-run page handling the last bit of manual setup that used to require touching config files by hand.
The Edge-AI Home Monitoring System has just received its most significant infrastructure overhaul yet!
We have completely re-engineered the deployment workflow. Instead of dealing with manual environment configurations, matching Python versions, and tracking down dependency conflicts, the entire ecosystem can now be spun up instantly with a single command.
By migrating the platform to a fully containerized backend, we’ve moved away from fragile local setups closer to a production-grade deployment.
devices_config.json, automation rules, and local database models are securely mapped via Docker volumes, meaning they persist perfectly across container restarts and updates.The difference in onboarding friction is night and day. Look at how the installation footprint has shrunk:
Old Manual Setup New Docker Workflow ❌ Install Python manually & match versions 📦 Pre-configured runtime environment ❌ Create virtual environments (venv)
📦 Isolated container filesystems
❌ Debug pip dependency conflicts
📦 One-time automated image build
❌ Manually set environment variables
📦 Declarative configuration via Compose
❌ Run background scripts step-by-step
📦 Single-command multi-service launch
Now, launching your privacy-first smart home hub requires nothing more than standard container tools:
# Clone the repository
git clone https://github.com/travletothefurureprogramming/Edge-AI-Home-Monitoring-System
# Navigate to the project root
cd Edge-AI-Home-Monitoring-System
# Spin up the entire system in detached mode
docker compose up -d
A massive structural and visual update has landed! The Edge-AI Home Monitoring System dashboard has been rewritten into a production-grade, single-page interface using the modern Inter typeface family. Alongside this visual overhaul, we are introducing native, local-only support for Sonos Smart Audio Devices.
The new interface shifts away from crowded layouts to a highly scannable, component-driven architecture featuring a strict color and spacing utility system built directly into :root.
#fafafa), precise surface modules (#ffffff), and structural crisp border outlines (#e7e7e7 / #d9d9d9)..topbar): A sticky system header utilizing backdrop-filter: blur(8px) that embeds the new brand mark (A Home) alongside a live status strip displaying the total device count, registered automations, and an immediate visual green heartbeat indicator (.live-dot)..grid): Devices are rendered dynamically using a responsive auto-fill layout (minmax(240px, 1fr)) with explicit styling classes for device actions (.btn.on for soft green feedback, .btn.off for soft red, and .btn.accent for special triggers)..ai-panel): A dedicated section housing the local LLM interaction logic, optimized with a smooth CSS-animated text typing loop (@keyframes dotfade) to indicate processing states without blocking UI interactions.Audio control joins our local device tree. The system now natively communicates with Sonos devices over the local network via unified backend hooks, matching our privacy-first design patterns.
The control grid maps the specific target API endpoints directly to native UI inputs, enabling immediate transmission of core execution parameters:
play — Resumes audio streaming (.btn.on)pause — Pauses current media layout trackingstop — Breaks audio buffering completely (.btn.off)volume_up & volume_down — Alters hardware volume stepsSonos control cards now dynamically build and inject an interactive media HUD element (.now-playing).
/api/music/current endpoint via explicit POST JSON payloads ({ room, type, number, command: 'get', device })..now-playing.playing) that shift asset opacity states depending on network audio feedback..np-refresh) relies on an isolated asynchronous CSS loop wrapper (@keyframes spin) allowing updates without triggering full dashboard asset re-renders.
The Edge-AI Home Monitoring System now includes full support for Samsung Smart TVs running Tizen OS, expanding the platform’s smart device ecosystem with another major TV manufacturer.
This integration uses the Samsung TV WebSocket API, allowing the system to communicate directly with compatible TVs over the local network without requiring additional hardware such as IR blasters.
Added a new Samsung TV backend integration using the samsungtvws Python library.
Implemented support for:
Samsung TVs are now registered as a native device type inside the system, following the same architecture used by other integrations such as LG WebOS, Daikin, Tapo, Hue, Yeelight, Shelly, and Broadlink.
Until now, TV support was mainly focused on LG Smart TVs and IR-controlled televisions through Broadlink.
With Samsung Smart TV support, the system can now directly control another major smart TV ecosystem using its official network interface.
This improves:
The integration communicates with Samsung TVs through:
The system keeps the same device abstraction model used by the rest of the project, making Samsung TVs behave like any other controllable smart device.
Some challenges during implementation:
Future improvements:
Samsung Smart TVs are now another fully supported platform in the Edge-AI Home Monitoring System, bringing the project closer to becoming a complete privacy-first smart home hub.
The Edge-AI Home Monitoring System now includes complete support for Broadlink Universal Remotes, allowing the platform not only to learn IR commands but also to transmit them directly to infrared-controlled devices.
/api/broadlink endpoint for controlling Broadlink devices from the dashboard and automation engine.Broadlink device class responsible for:
broadlink_codes.json.device.send_data().TVs
Air Conditioners
TV Decoders / Set-Top Boxes
This is a major milestone because the system is no longer limited to devices with official APIs.
Thousands of legacy appliances—including older televisions, air conditioners, and cable/satellite decoders—can now be integrated into the smart home ecosystem using only their existing infrared remote controls.
Users can control these devices from:
This significantly expands compatibility while maintaining the project’s privacy-first, local-control philosophy.
The Edge-AI Home Monitoring System now has its own tool for learning IR signals, as well as voice guidance throughout the setup process.
Broadlink IR Learning App
broadlink.discover() and authenticates automatically.broadlink_codes.json — file-library of all codes per room/device/command.devices_config.json — so that the device is automatically registered as an entry in the system’s main config, with flag is_broadlink_device: true.Voice Guidance in Setup Wizard
pyttsx4, in a separate thread so as not to block the UI) to each step of the setup wizard: installing dependencies, downloading AI model, creating password, setting Tailscale, Telegram token/chat ID, and registering devices.broadlink as a new device type in the setup wizard dropdown, which opens the Learning App directly when selected.Until now, the system only supported devices with official APIs (Tapo, Hue, Yeelight, LG WebOS, Daikin). Many “dumb” devices at home (old ACs, decoders, TVs without smart features) are controlled only via IR remote — the Broadlink learning app paves the way to integrate virtually any device with an IR remote into the ecosystem, without the need for a special library per brand.
Voice guidance also makes setup more accessible — less need to read README step by step, the system tells you what to do live.
async_connect of the Kasa class has incorrect syntax (await self.device = ... instead of self.device = await ...) — same problem as previous devlog, still pending.broadlink_codes.json and devices_config.json) — care must be taken to ensure that they do not become out of sync if a write fails in the middle.devices[0] by broadlink.discover() — if there are multiple Broadlink devices on the network, the app will always connect to the first one found, without selection.CoInitialize/CoUninitialize on each thread (Windows-specific), which makes the code less portable to other OSes./api/broadlink endpoint and Broadlink class in the backend that will read the stored hex codes from broadlink_codes.json and send them via device.send_data().emit_device_event to Broadlink sends, so they can also be trigger sources.Kasa.async_connect before any other work on Kasa progresses.
The Edge-AI Home Monitoring System now supports TP-Link Kasa smart plugs/switches, using the python-kasa library’s async Discover API for device communication.
Kasa class that discovers a device by IP via Discover.discover_single() (with optional username/password for cloud-authenticated devices) and wraps turn_on / turn_off / execute_command behind the same asyncio.run() pattern already used for Daikin and the Tapo devices./api/kasa endpoint, gated behind @auth.login_required like the rest of the device APIs.kasa in DEVICE_ENDPOINTS and wired it into create_device_action, so Kasa devices can already be used as automation actions from day one.send_kasa and send_daikin helper functions alongside the other device senders, for consistency across the codebase.Kasa is one of the most common smart plug ecosystems out there, so this adds another affordable device family to the system without needing a proprietary hub — anything plugged into a Kasa switch can now be turned on/off from the dashboard or from an automation rule, the same way Tapo and Shelly devices already are.
async_connect: await self.device = Discover.discover_single(...) isn’t valid — assignment has to come first, i.e. self.device = await Discover.discover_single(...). Needs fixing before this can actually run.handle_kasa currently points at a config path (/config/device_config.json) that doesn’t match the filename (devices_config.json) or the relative-path convention used by every other handler — needs to be corrected to "config/devices_config.json".data["Room"][room][dev_type][number][ip] with ip unquoted (a variable reference instead of the string key "ip"), which will throw a NameError rather than the intended KeyError.emit_device_event still isn’t wired into the Kasa (or Shelly) handler, so — same as the other non-TV devices — Kasa state changes can’t yet act as automation triggers.await/assignment order bug in Kasa.async_connect, the config path, and the unquoted "ip" key in /api/kasa before testing against a real device.emit_device_event into Kasa, Shelly, and the remaining handlers so any device can act as both an action and a trigger.
The Edge-AI Home Monitoring System now supports Shelly smart relays, using the ShellyPy library to control relay-based devices (plugs, switches, etc.) over the local network.
Shelly class wrapping ShellyPy.Shelly, with turn_on_relay / turn_off_relay methods and an execute_command dispatcher for on/off commands./api/shelly endpoint that reads the device’s IP and relay_number from devices_config.json and forwards the command to the relay.shelly in DEVICE_ENDPOINTS and wired it into create_device_action, so Shelly devices can already be used as automation actions (schedule or event triggered), same as every other device type.Shelly relays are a common, cheap way to add “dumb” appliances into the automation system — a fan, a boiler, anything behind a relay can now be toggled from the dashboard or from a rule, without needing a dedicated smart-device ecosystem.
/api/shelly is currently missing the @auth.login_required decorator that every other device endpoint has — since authentication was added, this is the one route that slipped through. Needs to be fixed before this ships anywhere network-exposed.relay_number rather than an id/model like the other integrations, so the config schema needed a small variation (relay_number field) instead of reusing the existing device pattern exactly.emit_device_event isn’t wired into the Shelly handler yet, so — like the other non-TV devices — a Shelly state change can’t currently act as a trigger for other automations.@auth.login_required to /api/shelly.emit_device_event into the Shelly (and remaining) handlers so any device can be both an action and a trigger source.
The Rule Engine already supported schedule triggers and one hardcoded event source (the YOLO “person_detected” signal). This update adds a much more general capability: automations can now trigger off of any device state change, not just security events.
Until now, “smart” behavior meant either a fixed schedule or a single special-cased sensor event. This generalizes the pattern: any device action can become a trigger for any other device action, which is the actual foundation of “automation chaining” (TV on → lights on, plug on → AC on, etc.) rather than a one-off integration.
The Rule Engine I mentioned as “next steps” in the last few devlogs is now fully working. The Edge-AI Home Monitoring System can now react on its own, without me touching the dashboard.
AutomationManager class that manages rules independently of the Flask request lifecycle, running on its own background threadThe trickiest part wasn’t the scheduling logic itself — it was making sure automation actions don’t accidentally go through the same path as normal API requests. Since every device endpoint is gated behind session-based login, having the automation thread call itself over HTTP triggered 401s (a background thread has no browser session, obviously). Fixed by having automation actions call the device classes directly instead of looping back through HTTP — cleaner and faster anyway, since it skips a full request round-trip for something that’s technically internal.
Energy monitoring for the Tapo smart plugs, so automations can eventually be built around actual consumption data too.
Create Autoation Manager class
The Edge-AI Home Monitoring System now extends into climate control. I’ve added full support for Daikin air conditioners, using the pydaikin library for asynchronous communication with the device over the network.
DaikinAC class with full control: on/off, increase/decrease temperature, and mode switching (auto, cool, heat, dry, fan)/api/daikin endpoint for device communication@auth.login_required), so no new device ecosystem opens a security gapSince pydaikin is fully asynchronous (async context managers), each client call had to be wrapped with asyncio.run() to fit into the rest of the synchronous Flask backend — the same approach used for the Tapo devices.
Rule Engine / Automations system, followed by energy monitoring for the Tapo smart plugs.
One of the biggest challenges in the project was the lack of organization. As the codebase grew, it became harder to navigate and maintain.
Today I reorganized the project into a much cleaner structure, making the code easier to understand, extend, and maintain. While there’s still room for improvement, this is a solid step toward a more scalable architecture.
Up until now, the dashboard and all API endpoints were completely open to anyone on the network — a serious problem for a system that controls cameras, smart devices, and even has Remote PC Control capabilities.
I implemented a single-admin authentication layer using Flask sessions and password hashing (werkzeug), gating access behind a login page.
Key changes:
This closes the biggest security gap in the project — previously, anyone with access to the local network or Tailscale IP could control devices or the PC without any barrier. Now, all of that is locked behind credentials only I know.
Next steps: Rule engine for automations (trigger-based actions), followed by energy monitoring for Tapo smart plugs.
One of the biggest improvements in this update is the error handling system.
Originally, the project had very minimal error management, which could lead to unstable behavior and unclear debugging.
I refactored multiple modules to introduce structured exception handling, improved logging, and more consistent API responses.
This makes the system significantly more stable and easier to debug in real-world usage.
Integration of Remote PC Control & Monitoring
into Edge-AI Home Monitoring System. This way the user can control the system remotely. There is a problem with the management of Processes due to an error in the backend.
I added support for Yeelight. It may have only taken me 15 minutes but that was because the Yeelight library I used was very simple. Also because the system is easily extensible I managed to do it in a very short time.
Add fully suppourt for phue devices
Make the main class and logic for the Philips Hue lights
Add suppourt for Tapo Smart Plugs
Add model selection for tapo led strip and tapo light bulbs and make a more clear README.md
Setup the server! The project will be fully ready soon!!!
A better setup and run for servers and a more clear README.md
Make a functional server App
LG TVs in Edge AI Home Monitoring System from now!!!!!!
Working on LG TV suppourt
From now Edge-AI Home Monitoring System suppourt tapo smart bulbs!!!!
Make a telegram bot for easily security and device control
Making a sequrity system using YOLO and Telegram
Make a better README.md file and finalize the setup proccess
Make better readme
Make a setup script
Make an app for easy use of AI and also ad functional control for the L900 tapo ledstrip
A new modern dashboard and more devices
Performance Optimization & Frontend Integration
After intensive testing, the communication system with Android TV devices has been fully upgraded. The latency observed in command execution has been eliminated, and the project now features its own Web Dashboard.
Key Achievements:
ADB Server Persistence: Resolved the critical issue regarding the continuous restart of the ADB server. By adopting the Registry Pattern, connections are now maintained (persistent), drastically reducing response time from 5+ seconds to near-zero (real-time).
Scalability: The backend has been developed to support the simultaneous control of multiple Android TVs. The system now dynamically manages connections via a central dictionary, allowing for the addition of unlimited devices through devices.json.
Frontend Dashboard: Developed a minimal and responsive interface (HTML/JS) that provides full device control. Communication with the server is now handled via the Fetch API with proper CORS and JSON payload handling.
Robust Error Handling: Upgraded the error reporting mechanism. The server now actively monitors module status and allows for automatic reset in case of connection restoration.
Next Steps:
Integration of real-time status feedback to monitor whether a TV is ON/OFF directly on the dashboard.
Further optimization of utils.py for more secure inter-module communication.
Establishing the Backend Infrastructure for Edge AI Home Monitoring System
Today, I successfully built the core communication layer for my Edge AI Home Monitoring System. I focused on creating a robust backend using Flask, enabling the system to act as a central hub for my home devices.
Key Achievements:
API Orchestration: Developed Flask endpoints (/api/light and /api/tv) to handle state management and device control requests efficiently.
Hardware Integration: Implemented an abstraction layer for AndroidTV control, allowing the server to issue commands like power toggles, volume adjustment, and channel navigation over the network.
Dynamic Configuration: Built a utility module to handle JSON-based device mapping, ensuring the system can scale easily by reading device IPs and types from a central devices.json configuration file.
Logging System: Integrated a custom logger to monitor command execution in real-time, which is essential for debugging my edge-computing setup.
Next Steps: Now that the server is successfully running and handling commands, the next phase is to add more devices and create the frontend dashboard.
