PDF Toolkit — DevLog 3

Text Extraction & Final Polish

The PDF Toolkit is starting to feel like a real application now.

After finishing the main PDF operations and the interactive CLI, I focused this time on adding text extraction and improving the overall reliability of the program.

PDF → Text

I added a new PDF → Text operation using PyMuPDF.

The tool goes through the pages of a PDF, extracts the text and saves everything into a .txt file.

This makes it possible to quickly get the text from a PDF without manually copying it page by page.

The extracted text keeps the content from all pages in the document.

CLI Improvements

I also spent some time making the CLI more reliable.

The program now handles common problems such as:

• Cancelled file selection
• Missing input files
• Missing output paths
• Invalid page numbers
• Invalid page ranges
• Errors during PDF operations

Instead of crashing immediately, the CLI can display an error and return to the main menu.

Better User Feedback

The CLI now gives clearer feedback when an operation finishes.

For example:

✓ PDF merged successfully!

If an operation fails, the user gets an error message instead of being left with a Python traceback.

This makes the tool much easier to use, especially for someone who doesn’t know how the code works internally.

Command-Line Options

I also added basic command-line options to make the program easier to use outside of the interactive menu.

The application now supports:

--help

for displaying information about the available commands and options, and:

--version

for displaying the current version of PDF Toolkit.

These are small additions, but they make the project feel much more like a proper command-line application.

Current Features

At this point, PDF Toolkit supports:

• Merge PDFs
• PDF → Image
• Split PDF
• Extract Pages
• PDF → Text
• Interactive CLI
• --help
• --version
• Input validation
• Error handling
• Cancel handling

The project is now much more complete than when I started.

Testing

I’ve been testing the different operations both individually and through the CLI.

The main goal is to make sure that the normal workflow works correctly while also handling common user mistakes without crashing the application.

There are still things I want to test more thoroughly before calling the project finished, especially when packaging it for other computers.

What’s Next

The core functionality is now basically finished.

The next step is no longer about adding lots of new features. I want to focus on actually shipping the project.

The next stage will be:

• Final testing
• Packaging PDF Toolkit as a Windows .exe
• Cleaning up the project
• Final README updates
• Preparing the first release

Next milestone: v1.0.0 🚀

The goal is to have a version that someone can download and use without needing to manually set up the Python environment.

PDF Toolkit — Development Log 2

CLI Complete

The first usable version of the PDF Toolkit CLI is now complete.

I created cli.py and connected all of the PDF operations that were already implemented to a single interactive interface.

The CLI is built using Questionary for the terminal menu and Tkinter file dialogs for selecting input and output files.

Available Operations

The CLI currently supports:

• Merge PDFs
• PDF → Image
• Split PDF
• Extract Pages
• Exit

Each operation can now be selected directly from the terminal.

File Selection

Instead of requiring users to manually type file paths, the CLI uses Tkinter file dialogs to select files and folders.

For example, when merging PDFs, the user can:

1. Select multiple PDF files
2. Choose the output location
3. Create the merged PDF

The same approach is used for the other operations where appropriate.

PDF → Image

The CLI asks the user for the page number and then allows them to choose where the generated image should be saved.

Split PDF

For splitting PDFs, the user can select:

• The input PDF
• The output folder
• The output filename prefix

This keeps the generated files organized.

Extract Pages

The CLI also supports the page selection syntax implemented in the extraction function.

For example:

1-5

or:

1,3,5-8

The selected pages are then saved into a new PDF.

Current Status

The core PDF operations are now implemented and accessible through the CLI.

The project has moved from individual PDF functions to an actual usable command-line application.

What’s Next

The next step is to improve the CLI experience and make the tool more reliable.

Possible improvements include:

• Better error handling
• Input validation
• Success/error messages
• Cleaner terminal output
• More tests
• Additional PDF operations
• Packaging the project for easier installation and distribution

PDF Toolkit — Devlog 1

Current Progress

I’ve started building PDF Toolkit, a small Python command-line utility for working with PDF files.

The goal is to keep it simple and modular, while gradually adding useful PDF operations.

Project Structure

PDF-Toolkit/
├── main.py
├── requirements.txt
├── operations/
│   ├── __init__.py
│   ├── merge.py
│   ├── convert.py
│   ├── split.py
│   └── extract.py
└── tests/
    ├── __init__.py
    └── test_merge.py

The PDF operations are separated into individual modules instead of putting everything into one file.

Implemented Features

Merge PDFs

Added support for combining multiple PDF files into a single PDF.

The merge operation uses PyMuPDF and accepts multiple input files.

PDF → Image

Added support for converting a specific PDF page into an image.

Current options include:

• Selecting a specific page
• PNG output
• JPG output
• Custom DPI

Split PDF

Added support for splitting a PDF into individual pages.

For example, a multi-page PDF can be split into separate files:

page_1.pdf
page_2.pdf
page_3.pdf
...

Extract Pages

Added support for extracting selected pages into a new PDF.

Pages can be specified individually or as ranges.

Example:

2,5,8-10

This creates a new PDF containing pages 2, 5, 8, 9 and 10.

CLI

The next step is to connect all the existing operations through a simple CLI interface.

The user will be able to start PDF Toolkit and select an operation from a menu:

PDF Toolkit

1. Merge PDFs
2. PDF → Image
3. Split PDF
4. Extract Pages
5. Exit

This will make the current features easier to use without having to call the Python functions manually.

What’s Next

After the CLI is working, I plan to continue expanding the toolkit with more PDF operations.

Planned features:

• Rotate Pages
• Delete Pages
• Reorder Pages
• Images → PDF
• PDF information / metadata
• PDF compression
• Password protection

For now, the focus is on getting the existing features working properly and making them easy to use through the CLI.

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.