Devlog #4: Retro Robot Enclosure, LED Matrix & Security Backend Integration

🛠️ Summary & Overview

Transitioned RoomOps Zero from a software dashboard into a fully physical retro-tech robot assistant. The physical chassis has been built—featuring an acrylic robot enclosure complete with an integrated LED Matrix display that serves as an expressive face/visual telemetry hub.

On the software side, fully deployed the core security engine in main.py. The backend now supports dynamic system arming/disarming, security PIN verification, automated motion monitoring loops, and immediate smart home alert triggers (escalating room volume, dispatching notifications, and turning Tapo L900 smart light strips red upon motion detection).

---

⚙️ Key Technical Updates

1. Hardware Assembly & Visual LED Matrix (Chassis & Enclosure)

• Robot Frame Assembly: Constructed the physical retro robot enclosure housing the Raspberry Pi Zero W board, internal wiring, and top mounting antenna accent.
• LED Matrix Expression Display: Mounted the bright yellow LED matrix module into the mouth/screen cutout. Configured visual feedback routines to render dynamic waveforms and active telemetry states.
• Hardware Prep: Prepared structural mounting slots for future physical USB camera integration directly alongside the chassis.

2. Security State Management & PIN Logic (main.py)

• State Control: Implemented global state flags (armed = False) to track real-time security modes across all REST endpoints.
• PIN Verification Endpoint: Configured POST /api/verify-pin utilizing Pydantic validation (PinModel) against environment parameters (SECURITY_PIN).
• Direct Action Routes: Added dual-method action endpoints (/api/arm & /api/disarm) for rapid arming/disarming from web controls and action blocks.

3. Automated Threat Detection & Action Escalation (services/camera.py)

• Motion Detection Loop: Built the /api/camera/check-motion endpoint to continuously poll motion sensors when the system is armed.
• Automated Escalation Sequence: Linked motion events to a multi-layered alert workflow:
  1. Triggers desktop notification dispatch via utils.notifier.
  2. Escalates audio volume to maximum (100%) via utils.volume.
  3. Switches room lighting via tapo_control.DeviceFactory by powering on the Tapo L900 light strip and setting its colour directly to Red.
• Snapshot Cache: Serves capture snapshots dynamically at /static/last_motion.jpg for active monitoring logging.

---

📡 Active Routes & API Reference

1. Security State Management

   • Endpoint: GET / POST /api/arm → Sets system status to armed: true.
   • Endpoint: GET / POST /api/disarm → Sets system status to armed: false.
   • Endpoint: GET /api/status → Returns current system state ({"system_armed": armed}).

2. Security PIN Verification

   • Endpoint: POST /api/verify-pin
   • Payload Example:

     {
       "pin": "1234"
     }
     

   • Response Example:

     {
       "status": "success",
       "correct": true,
       "system_armed": false
     }
     

3. Motion Detection Polling Endpoint

   • Endpoint: GET /api/camera/check-motion
   • Response Example (Motion Detected):

     {
       "motion": true,
       "system_armed": true,
       "timestamp": "2026-08-26T15:56:00",
       "image_url": "/static/last_motion.jpg"
     }
     

Devlog #3: Live RSS News Telemetry & TV Dashboard Optimization

🛠️ Summary & Overview

Elevated the RoomOps Zero ecosystem into a 24/7 ambient TV control station by integrating a real-time RSS news telemetry service.

This update includes:

• A dedicated Google News RSS parsing module for the FastAPI backend.
• In-memory response caching to reduce CPU and RAM usage on the Raspberry Pi Zero W.
• A high-visibility, auto-rotating news widget optimized for lean-back TV dashboard viewing.

---

⚙️ Key Technical Updates

1. Google News RSS Integration & In-Memory Caching

Files: services/news.py · main.py

• Integrated feedparser to extract and process localized Google News RSS feeds.
• Added dynamic location-based news queries through:
  GET /api/news/{city}
• Implemented server-side in-memory caching with a 900-second (15-minute) cache duration.
• Reduced redundant external network requests and unnecessary CPU usage on the Raspberry Pi Zero W.
• Added a non-blocking asynchronous API route returning sanitized headlines as JSON.

2. TV Dashboard UI & Headline Rotator

File: templates/index.html

• Designed a dark-themed, high-contrast TV news card optimized for long-distance readability.
• Added an asynchronous JavaScript headline rotator.
• Headlines automatically change every 12 seconds.
• Added smooth CSS opacity transitions using fade-in and fade-out effects.
• Configured automatic background synchronization every 20 minutes to retrieve updated headlines without interrupting the active UI state.

3. 24/7 TV Display Safeguards

• Optimized DOM rendering by displaying only the currently active headline instead of rendering a large vertical list.
• Added fallback status handling with the “Εκτός σύνδεσης” message.
• Improved resilience during temporary local network outages.
• Kept the dashboard lightweight for continuous 24/7 operation.

Devlog #2: Frontend Dashboard Interface & Asset Orchestration

---

🛠️ Summary & Overview

Elevated the RoomOps Zero ecosystem by transitioning from a headless microservice layer to an interactive web dashboard. Resolved Starlette/FastAPI ASGI rendering exceptions, eliminated recursive 404 image load loops, and consolidated CSS styling alongside asynchronous JavaScript directly into the template architecture. The dashboard now renders real-time telemetry, handles local clock synchronization, and triggers remote hardware states directly through non-blocking API requests.

---

⚙️ Key Technical Updates

1. Template Engine & Middleware Refactoring (main.py)

• Resolved a breaking TypeError: unhashable type: 'dict' caused by Starlette context signature updates in newer FastAPI releases.
• Standardized Jinja2Templates rendering by explicitly passing keyword parameters (request=request).
• Updated UI endpoints to serve templates/index.html seamlessly alongside existing JSON routes.

2. Dashboard UI & Self-Contained Assets (templates/index.html)

• Built a dark-themed CSS interface featuring custom Flexbox dashboard layouts, action controls, and responsive widget containers.
• Embedded styling and frontend execution logic directly inside <style> and <script> blocks to bypass static pathing overhead and network latency.
• Implemented live client-side date/time formatting with automated per-second ticker loops.

3. Asynchronous Fetch Integration & Network Handling

• Abstracted API routing using window.location.origin to allow dynamic REST execution across varying local IPs and ports.
• Linked hardware action triggers (turn_on / turn_off) to POST /api/tapo/control payloads.
• Built automatic polling loops for environmental telemetry (GET /api/weather/{city}) with fallback status handlers.
• Fixed an infinite recursive onerror fallback loop by decoupling broken image streams and nullifying error handlers.

---

📡 Active Routes & UI Bindings

1. Served Web Interface

• Endpoint: GET /
• Response: Rendered Jinja2 HTML Dashboard (index.html)

2. Hardware & Telemetry Action Bindings

• Telemetry Trigger: fetch('${API_BASE_URL}/api/weather/kavala')
• Control Payload: POST /api/tapo/control with {"device_name": "l900", "action": "turn_on"}

Devlog #1: RoomOps Zero Core API & Smart Device Integration

Date: August 23, 2026
Project: RoomOps Zero
Status: In Progress (Backend Microservice Layer)

---

🛠️ Summary & Overview

Implemented the foundational REST API layer for RoomOps Zero using FastAPI to handle local hardware control and environmental telemetry. Integrated Tapo smart devices (L900 Light Strip & L535 Smart Bulb) using an asynchronous client library (tapo), structured via the Factory Design Pattern for modularity. Added an asynchronous weather integration module to feed current climate data directly to the central dashboard.

---

⚙️ Key Technical Updates

1. Asynchronous REST API (main.py)

• Configured a FastAPI application running on 0.0.0.0:8080 via Uvicorn.
• Defined explicit request validation models using Pydantic (TapoBaseModel).
• Created non-blocking asynchronous routes for weather retrieval (GET) and smart device state management (POST).

2. Smart Lighting Integration (tapo_control.py)

• Created async device wrappers (L900, L535) leveraging ApiClient from the tapo library.
• Externalized hardware credentials (IPs, usernames, passwords) into a local .env file using python-dotenv.
• Implemented a Singleton pattern for L535 to avoid redundant object instantiation.
• Designed a DeviceFactory class to standardize turn_on and turn_off operations across varying hardware models based on incoming payloads.

3. Weather Telemetry Module (weather.py)

• Integrated python_weather using metric units ($^\circ\text{C}$).
• Structured as an async utility (get_temperature) to prevent blocking the primary event loop during HTTP requests.

---

📡 API Endpoints Reference

1. Get Current Weather

• URL: GET /api/weather/{city}
• Parameters: city (path parameter, string)
• Response: Current metric temperature integer/float.

2. Control Tapo Device

• URL: POST /api/tapo/control
• Headers: Content-Type: application/json
• Payload Example:

  {
    "device_name": "l900",
    "action": "turn_on"
  }

Devlog: AERIS Backend & Fleet Management Architecture

Overview

This devlog details the core backend infrastructure, API endpoints, and real-time mapping interface developed for the AERIS-Rover (Autonomous Eco-Robotic Intelligence System) project. The system is designed to coordinate outdoor AGVs (Autonomous Ground Vehicles) for environmental data collection and automated Return-to-Base (RTB) operations[cite: 1].

---

1. Core Backend Architecture (server.py)

Built using Python (Flask), the backend acts as the central command node running on a Raspberry Pi 5 (8GB)[cite: 1, 2]. It handles multi-robot telemetry, dynamic mission routing, and real-time client requests.

Key Technical Features:

• RESTful API Endpoints:
  • /api/robot/location (POST): Receives real-time latitude, longitude updates from rovers and calculates operational distances[cite: 2].
  • /api/robot/status (POST): Tracks live health metrics including battery percentages, internet connectivity, error flags, and active mission states[cite: 2].
  • /api/robot/missions/set & /api/robot/missions (GET/POST): Manages mission generation, payload parsing, and waypoint distribution[cite: 2].
  • /api/robot/request (GET/POST): Handles asynchronous command queues for individual robot agents[cite: 2].
• Haversine Distance Calculation: Implemented mathematical spatial formulas to compute precise ground distances in meters between rovers and designated zones (such as the main Base)[cite: 2].

---

2. Real-Time Map & Telemetry Dashboard (index.html)

The frontend dashboard provides visualization of the robot fleet operating in outdoor environments[cite: 1].

Key Technical Features:

• Leaflet.js Integration: Renders dynamic interactive maps centered around defined operational sectors[cite: 1].
• Geo-fencing & Zones: Programmatically draws circular zones (Base, Parks, Stadiums) with custom radius parameters and color codes[cite: 1].
• Dynamic Polling & Marker Tracking: Asynchronously fetches active robot positions from the Flask backend every 2 seconds, updating marker coordinates, status popups, and battery indicators on the fly[cite: 1].

AutoStudy AI — Interactive Flashcards & UI/UX Polish

Today I expanded AutoStudy AI’s study pipeline by introducing AI-generated flashcards with an interactive flip-card interface, alongside a cleaner and more polished user experience.

What works

• AI Flashcard Generation: Integrated structured JSON generation via local Qwen2.5:3b (Ollama) to automatically parse PDF text into 5–8 study flashcards (Questions & Answers).
• Interactive Flashcard Viewer: Built a smooth, 3D CSS-flipped card component allowing users to click to reveal answers and navigate seamlessly through their study deck.
• Safe State & JSON Parsing: Implemented robust backend cleaning and frontend IIFE scoping to securely pass and render dynamic JSON datasets without client-side conflicts.
• UI/UX Overhaul: Upgraded the visual hierarchy with modern card containers, responsive controls, clear progress counters (Card X of Y), and sleek loading animations during document processing.

Why this matters

AutoStudy AI is evolving from a basic text extractor into a true, active-recall study tool. By combining local AI intelligence with interactive flashcards, users can now test their knowledge directly from their study materials while maintaining 100% data privacy and offline capability.

Tech stack

• Flask (Python backend)
• Ollama (Qwen2.5:3b for local structured JSON extraction)
• PyMuPDF (PDF text processing)
• Vanilla HTML5, CSS3 (3D transforms & transitions), & JavaScript (IIFE modules)

Next step

Implement custom study tool selection on the homepage (allowing users to choose between summaries, flashcards, or AI assistants per upload) and build a history sidebar for quick access to past documents.

---

Second milestone achieved: active recall study workflows are now fully operational offline. 🚀

AutoStudy AI — PDF Explanation via AI

Today I integrated Ollama with Qwen2.5:3b to generate AI-powered summaries directly from extracted PDF text.

What works

• Upload a PDF via the web interface
• Extract text from all pages using PyMuPDF
• Generate 5-point AI summaries using local Qwen2.5 via Ollama
• Display both summary and extracted text in the browser
• Fully offline — zero cloud API calls, complete privacy

Why this matters

AutoStudy AI now has local intelligence. The model runs locally on GPU (~4GB VRAM), allowing fast iteration and proving that small open-source LLMs handle Greek/English PDFs effectively for flashcards, quizzes, and concept extraction.

Tech stack

• Flask
• PyMuPDF (fitz)
• Ollama + Qwen2.5:3b
• Python 3.11
• Vanilla HTML/CSS/JS

Next step

Add CSS styling for a polished UI (dark mode, card layouts, mobile responsiveness, and loading animations).

AutoStudy AI — PDF Upload & Text Extraction

Today I implemented the core document pipeline for AutoStudy AI.

What works

• Upload a PDF through the web interface
• Save the file locally
• Extract text from all pages using PyMuPDF
• Display the extracted text in the browser

Why this matters

This is the first end-to-end workflow of the project. AutoStudy AI can now take a document and convert it into machine-readable text, which will be the foundation for:

• AI summaries
• Flashcards
• Quiz generation
• Spaced repetition

Tech stack

• Flask — web backend
• PyMuPDF (fitz) — PDF text extraction
• Python 3.11

Next step

Integrate Ollama + Qwen3 to generate local AI summaries directly from the extracted text.

---

First milestone achieved: documents can now enter the AI pipeline completely offline. 🚀

🧪 Reliability & CI Improvements

This update also focuses on improving the project’s reliability and development workflow.

What’s New

• 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.

Why It Matters

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 Setup: 100% Functional

Docker support for the Edge-AI Home Monitoring System is now fully working end-to-end.

What’s New

• First-Run Setup via HTML: Instead of manual configuration steps, the very first launch now opens a lightweight HTML setup page that walks through the initial configuration once (credentials, device registration basics, etc.). After this one-time run, it’s never needed again — the container remembers everything through the persisted config volumes.
• One Command to Rule Them All: The whole system — Flask backend, Docker container, and now the first-run setup — is launched with a single script:
  • Windows: start.bat
  • Linux: 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.

Why It Matters

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.

🚀 One of the Biggest Updates: Docker-Based Setup & Minimal Installation

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.

---

🐳 What’s New: Containerized Architecture

By migrating the platform to a fully containerized backend, we’ve moved away from fragile local setups closer to a production-grade deployment.

Key Improvements:

• Isolated Environment: The Flask backend and all its core libraries run inside an isolated Docker container, completely immune to host-system configuration drifts.
• Automated Dependency Management: All heavy-lifting dependencies are resolved and cached automatically inside the image.
• State & Configuration Persistence: Your custom devices_config.json, automation rules, and local database models are securely mapped via Docker volumes, meaning they persist perfectly across container restarts and updates.
• High Portability: Moving the hub from a development PC to a dedicated home server (like a Fedora Linux box or a Raspberry Pi) is now completely seamless.

---

⚡ Setup: Before vs. After

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

The New Minimal Installation Path:

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

Enchanse CLI app using questionary and start making a clean README with clear explanation on how to use it

Fix some bugs and create a clean repository with a good README and the github release.

UI Modernization & Native Sonos Integration 🎵🎨

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.

---

What’s New

1. High-End Minimalist UI & CSS Token Architecture

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.

• Unified Palette System: Built entirely on minimal token foundations: light-mode canvas backgrounds (#fafafa), precise surface modules (#ffffff), and structural crisp border outlines (#e7e7e7 / #d9d9d9).
• Blur-Effects Navigation Header (.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).
• Decoupled Grid Control (.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).
• Asynchronous AI Assistant Component (.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.

2. Native Sonos Smart Audio Core Integration

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 tracking
• stop — Breaks audio buffering completely (.btn.off)
• volume_up & volume_down — Alters hardware volume steps

Real-Time “Now Playing” UI Subview

Sonos control cards now dynamically build and inject an interactive media HUD element (.now-playing).

• Dynamic Media Binding: Communicates with the new /api/music/current endpoint via explicit POST JSON payloads ({ room, type, number, command: 'get', device }).
• Visual Playback Flags: Implements dynamic active toggles (.now-playing.playing) that shift asset opacity states depending on network audio feedback.
• Non-Blocking Control Pulls: The inline manual update button (.np-refresh) relies on an isolated asynchronous CSS loop wrapper (@keyframes spin) allowing updates without triggering full dashboard asset re-renders.

Samsung Smart TV Support Added 📺

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.

What’s New

Added a new Samsung TV backend integration using the samsungtvws Python library.

Implemented support for:

• Power control (ON/OFF)
• Remote key commands
• Volume control
• Device information retrieval

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.

Why It Matters

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:

• Response time compared to IR control
• Local-only communication (no cloud dependency)
• Compatibility with more homes

Technical Details

The integration communicates with Samsung TVs through:

• Samsung Tizen WebSocket API
• Local network TCP communication
• Device authentication pairing

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.

Challenges

Some challenges during implementation:

• Handling Samsung’s first-time pairing approval system
• Managing WebSocket connections reliably
• Ensuring compatibility between different Tizen TV models
• Mapping Samsung remote key codes into the existing device command structure

Next Steps

Future improvements:

• Add automatic Samsung TV discovery
• Add real-time TV status feedback (power state, current app, volume)
• Add voice assistant commands for Samsung TVs - Add more controls

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.

Full Broadlink Universal Remote Support

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.

What’s New

• Added a dedicated Broadlink backend integration for sending stored IR commands.
• Implemented a new /api/broadlink endpoint for controlling Broadlink devices from the dashboard and automation engine.
• Added a Broadlink device class responsible for:
  • Connecting and authenticating with Broadlink RM-series devices.
  • Reading learned IR codes from broadlink_codes.json.
  • Sending IR packets using device.send_data().
• Full support for controlling:

  • TVs
    

  • Air Conditioners
    

  • TV Decoders / Set-Top Boxes
    

• Broadlink devices are now treated like any other supported smart device and can be used throughout the entire system.

Why It Matters

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:

• The Web Dashboard
• Automation Rules
• Future Voice Assistant integrations
• Any API client connected to the system

This significantly expands compatibility while maintaining the project’s privacy-first, local-control philosophy.

Challenges

• IR packets must be converted back into raw byte format before transmission.
• Maintaining synchronization between learned codes and registered Broadlink devices remains important as the number of supported devices grows.
• Multiple Broadlink hubs on the same network still require a device selection mechanism, which will be addressed in a future update.

Next Steps

• Add automatic Broadlink hub discovery and selection.
• Integrate Broadlink commands into the Rule Engine as event triggers.
• Add support for macro commands (multiple IR signals with delays).
• Improve the dashboard with command management and testing tools.

Broadlink IR Learning App + Voice Guidance in Setup

The Edge-AI Home Monitoring System now has its own tool for learning IR signals, as well as voice guidance throughout the setup process.

What’s Added

Broadlink IR Learning App

• New desktop application (customtkinter) that connects to a Broadlink device (RM-series) via broadlink.discover() and authenticates automatically.
• Device type selection (TV / AC / Decoder) with dynamic list of commands depending on the type (on/off, channel up/down, volume, direction, menu, etc.).
• “Learn & Save” function: Broadlink enters learning mode, waits for the signal from the real remote control and saves the hex packet.
• The signals are stored in two places:
• 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

• Added text-to-speech (via 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.
• Each device type during registration (Tapo, Philips Hue, Shelly, Broadlink, etc.) now “explains” vocally which fields need to be filled in, making the process more accessible for someone who is setting up the system for the first time without reading documentation.
• Also added broadlink as a new device type in the setup wizard dropdown, which opens the Learning App directly when selected.

Why It Matters

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.

Challenges

• async_connect of the Kasa class has incorrect syntax (await self.device = ... instead of self.device = await ...) — same problem as previous devlog, still pending.
• In the Learning App, the device data is temporarily stored in two separate files (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.
• The Broadlink device is always identified as 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.
• TTS requires CoInitialize/CoUninitialize on each thread (Windows-specific), which makes the code less portable to other OSes.

Next Steps

• Full support for sending signals via Broadlink devices (not just learning) — i.e. new /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().
• Integrate Broadlink devices as actions in the Rule Engine, so they can be used in automations like any other device.
• Wiring emit_device_event to Broadlink sends, so they can also be trigger sources.
• Fix bug in Kasa.async_connect before any other work on Kasa progresses.

Kasa (TP-Link) Support Added

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.

What’s New

• New 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.
• New /api/kasa endpoint, gated behind @auth.login_required like the rest of the device APIs.
• Registered kasa in DEVICE_ENDPOINTS and wired it into create_device_action, so Kasa devices can already be used as automation actions from day one.
• Added send_kasa and send_daikin helper functions alongside the other device senders, for consistency across the codebase.

Why This Matters

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.

Challenges

• Ran into a syntax issue in 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".
• Same route also references 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.

Next Steps

• Fix the 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.
• Wire emit_device_event into Kasa, Shelly, and the remaining handlers so any device can act as both an action and a trigger.
• Once event emission is consistent across all device types, move on to energy monitoring for the Tapo smart plugs.

Shelly Support Added

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.

What’s New

• New Shelly class wrapping ShellyPy.Shelly, with turn_on_relay / turn_off_relay methods and an execute_command dispatcher for on/off commands.
• New /api/shelly endpoint that reads the device’s IP and relay_number from devices_config.json and forwards the command to the relay.
• Registered 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.

Why This Matters

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.

Challenges

• Noticed /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.
• Shelly relays are addressed by 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.

Next Steps

• Add the missing @auth.login_required to /api/shelly.
• Wire emit_device_event into the Shelly (and remaining) handlers so any device can be both an action and a trigger source.
• Once event emission is consistent across all device types, move on to energy monitoring for the Tapo smart plugs.