FUXA is a full-stack web-based SCADA/HMI builder and runtime for industrial automation and IoT. It provides a visual editor (Angular + SVG) to create real-time dashboards, connect to field devices via 13+ protocols (Modbus, OPC UA, BACnet, Siemens S7, MQTT, etc.), and manage alarms, data acquisition (DAQ), scripting, scheduling, and user permissions. The backend (Node.js/Express) communicates with the frontend via Socket.IO for real-time device value updates. The system supports multiple time-series databases (SQLite, InfluxDB, QuestDB, TDengine) and can be deployed as a web server, Docker container, or Electron desktop app. It also integrates with Node-RED for low-code automation flows. The architecture is modular with a device driver factory pattern, JWT-based authentication, and a plugin system for extensibility. While the codebase is large and contains some monolithic components, it demonstrates solid engineering practices and has a rich set of reusable UI components and utility patterns.
This is an embedded firmware application for ESP32-based AI voice assistant devices. The code implements a full voice interaction pipeline: microphone input via I2S/PCM, Opus audio encoding/decoding, WebSocket/MQTT communication with a server, wake-word detection (ESP-SR), an LVGL-based user interface with emoji and chat display, an MCP (Model Context Protocol) server exposing device tools to the AI, and support for OTA updates. The architecture is a monolithic FreeRTOS application using ESP-IDF, with a strong board abstraction layer that allows support for over 130 hardware variants (ESP32-S3, C3, C6, P4, etc.) with different audio codecs, displays, cameras, and network modules (WiFi, 4G, Ethernet). The codebase is actively maintained with regular commits and a large community, but suffers from significant code duplication across board definitions, especially in power management and display initialization, which increases maintenance burden.
This is a Home Assistant custom component (integration) for controlling Gree-compatible air conditioners over the local network via UDP. It implements the Gree reverse-engineered protocol, supporting two encryption versions (AES-128 ECB and AES-128 GCM), device discovery, key negotiation, and full HVAC control (temperature, fan, swing, modes). The architecture follows Home Assistant's platform pattern: a climate entity as the core, with additional switch, sensor, number, and select entities for auxiliary features like X-Fan, lights, health mode, temperature step, and external temperature sensor selection. The integration communicates directly with the AC unit on UDP port 7000, encrypting commands with device-specific keys obtained during setup. It supports both UI config flow (with auto-discovery and cross-VLAN unicast scanning) and YAML configuration. The codebase is well-structured for a custom component, with clear separation of protocol logic (gree_protocol.py), temperature math (helpers.py), and entity definitions. Notable craftsmanship includes the TempOffsetResolver class for auto-detecting sensor offsets, the retry logic with progressive backoff and diagnostic failure classification, and the use of dataclass-based entity descriptions for switches and sensors. However, the main climate.py file is large (912 lines) and there are no automated tests, which is typical for community Home Assistant integrations.
BatMON is a Home Assistant add-on and standalone Docker application for monitoring battery management systems (BMS) over Bluetooth Low Energy (BLE) and serial connections. It decodes telemetry from ~25 BMS families (Daly, JK, ANT, Renogy, Seplos, etc.) and publishes normalized data to MQTT for Home Assistant, or directly to InfluxDB. The architecture is a Python asyncio application with a BMS abstraction layer (`bmslib`) that defines a common interface (`fetch()`, `fetch_voltages()`) and model-specific decoders. The main entry point is `main.py`, which dispatches to HA add-on or standalone mode via `entrypoint.sh`/`addon_main.sh`. Data flows from BMS hardware through BLE/serial adapters into decoder classes, then to MQTT/InfluxDB via a GUI wire format (`bmslib/wire/model.py`). External dependencies include bleak (BLE), paho-mqtt, influxdb, and Home Assistant add-on infrastructure (bashio, supervisor). The project includes a Helm chart, Docker multi-arch builds, and a test suite with known-answer vectors for CRC/AES and protocol decoders.
This repository is a Home Assistant custom component that integrates Amazon Alexa/Echo devices into Home Assistant. It allows users to control media playback (play, pause, volume, source selection), manage alarms and timers, control smart home devices (lights, switches, sensors, alarm control panel for Alexa Guard), and send notifications (TTS, announcements, mobile push). The component authenticates with Amazon's unofficial internal API via the `alexapy` library, supporting OAuth, TOTP, and 2FA. Architecture follows Home Assistant's component pattern: a config flow for setup, multiple entity platforms (media_player, sensor, switch, light, alarm_control_panel, binary_sensor, notify), a `DataUpdateCoordinator` for polling with HTTP2 push fallback, and custom services. Data flows from Amazon's cloud to HA via either polling (configurable interval) or push updates (WebSocket/HTTP2), with caching and debouncing to reduce API calls. External dependencies include `alexapy`, `packaging`, `wrapt`, and `dictor`. The component is distributed via HACS (Home Assistant Community Store) and supports multiple Amazon accounts with extensive localization.
This repository provides embedded firmware for the ESP8266 that bridges Chinese solar inverters (Voltronic/Axpert, PIP, EASUN, Deye, Anenji, Must PV/PH18) to MQTT and a local web interface. It communicates with inverters via RS232 serial (using proprietary ASCII protocols like PI30, PI18) or RS485 Modbus RTU, parses real-time status (grid, battery, PV, loads, faults), and publishes structured JSON to configurable MQTT topics including Home Assistant auto-discovery. The firmware also hosts a full web-based configuration portal with captive portal for WiFi setup, OTA updates, a live JSON endpoint, and LED status indication. Architecturally, it is a monolithic embedded application written in C++ for the PlatformIO build system. Key entry points are `src/main.cpp` (setup/loop), the web server endpoints, MQTT callbacks, and the serial/Modbus polling loop. The code is organized into a serial protocol handler (`PI_Serial`), an abstract Modbus device layer (`modbus_device`) with concrete implementations, a settings manager using EEPROM with versioning and fallback, and a chunked HTML serving mechanism to avoid heap fragmentation on memory-constrained ESP8266 devices. Notable strengths include the modular Modbus device interface that allows adding new inverter models by subclassing and providing register tables, and the auto-detection logic that probes protocols in sequence. The web UI is built with Bootstrap and jQuery loaded from CDN, and the project actively supports Home Assistant integration and multiple hardware configurations (Wemos D1 Mini, ESP-01, WiFi dongle). While the code is well-structured for an embedded project, it relies on dynamic `String` objects and large JSON documents on a limited memory platform, which could cause heap fragmentation over long periods. The license (CC BY-NC-ND 4.0) restricts commercial use and derivative works, limiting community contributions.
This is a high-level C++ library for building LoRaWAN end-devices on Arduino-compatible platforms. It wraps the MCCI LMIC stack and provides a structured API for OTAA/ABP provisioning, sending uplinks, receiving downlinks, link-check management, and persistent session-state save/restore. The library supports nine network operators (TTN, Actility, Helium, ChirpStack, Generic, machineQ, Senet, Senra, Swisscom) across eight LoRaWAN regions, selected at compile time via preprocessor macros. The architecture uses a two-level inheritance hierarchy: an abstract `Arduino_LoRaWAN` base class, network-specific base classes, and region-specific concrete classes. The LMIC C callback `onEvent()` is routed through a singleton to `DispatchEvent()`, which drives a standard event processor and up to four registered listeners. Application code subclasses a concrete network/region class and overrides virtual methods for provisioning and persistence. Key entry points are `begin()`, `loop()`, `SendBuffer()`, `RegisterListener()`, and `SetLinkCheckMode()`. The session-state subsystem is notably sophisticated: it serializes frame counters, channel masks, band duty-cycle state, and MAC parameters into versioned, tagged structures that can be stored in arbitrary non-volatile memory and restored after reboot. The code is generally well-structured and professional, with clean separation of concerns and careful handling of LMIC internals. However, the repository contains many near-empty per-network/per-region boilerplate files, and the CI pipeline still relies on Travis CI with an old Arduino IDE version. There are no unit tests; regression coverage comes from compile-testing example sketches across multiple boards and regions. The library is actively maintained, but release metadata (library.properties vs. header version) and CI infrastructure lag behind the code itself.
Linus Dashboard is a Home Assistant custom integration that auto-generates a plug-and-play Lovelace dashboard from the entity, device, area, and floor registries. The frontend is a TypeScript strategy that dynamically builds views, chips, cards, and popups based on device class and domain, while the Python backend creates nested group entities (area → floor → global) for each domain, aggregates numeric sensors, and provides a configuration flow for exclusions and embedded dashboards. It integrates optionally with Magic Areas and Linus Brain for entity resolution, falling back to native registry data. The system is bilingual (EN/FR) and heavily automated with release scripts, CI workflows, and a fake-house test environment. Architecturally, the project is a hybrid: a Python backend following Home Assistant component patterns and a TypeScript frontend built with Rspack, relying on external cards (Mushroom, Browser Mod, Card Mod, Swipe Card, Stack-in-Card). Core engineering patterns include abstract base classes (AbstractCard, AbstractChip, AbstractView), factory classes with dynamic imports, a central Helper class that acts as a registry cache, and memoization/performance profiling utilities. The backend uses a shared NestedGroupMixin to build hierarchical entity groups and pure aggregation logic in aggregate.py. The codebase is well-tested with Vitest and pytest, and includes extensive documentation and release automation, but also suffers from a large god object (Helper.ts >1600 lines), duplicated platform boilerplate, vendored minified third-party bundles, and partial French localization. It is actively maintained with recent commits, a responsive issue tracker, and regular beta/stable release cycles.
This repository provides ESPHome firmware configurations and custom components to control LoctekMotion/FlexiSpot standing desks via Home Assistant. The core functionality is implemented as two custom ESPHome sensor components: `loctekmotion_desk_height` for reading desk height from a 7-segment display protocol over UART, and `loctekmotion_desk_command` for detecting keypad button presses. The primary entry points are the YAML package files (`packages/office-desk-esp32.yaml` and `packages/office-desk-esp32-passthrough.yaml`) which wire up UART communication, GPIO control for the screen wake pin (PIN20), and expose cover, button, switch, and number entities to Home Assistant. The architecture is a typical ESPHome device: a single microcontroller (ESP32/ESP8266) running the ESPHome firmware, communicating with the desk controller via a 9600 baud UART serial link. The repo also contains archived Arduino and Raspberry Pi implementations, but the active development is focused on the ESPHome components. It is a well-structured IoT integration project with CI/CD, linting, and test compilation for multiple board variants.
This repository is a Home Assistant custom component for integrating Xiaomi Smart Pedestal Fans (and several other fan models) into the Home Assistant ecosystem. The code in `fan.py` defines a hierarchy of Python classes, starting from a generic `XiaomiGenericDevice` base and specializing through `XiaomiFan`, `XiaomiFanP5`, `XiaomiFanMiot`, and many model-specific subclasses (e.g., `XiaomiFanZA5`, `XiaomiFanP76`). Each subclass maps the device-specific miIO/MIoT properties to Home Assistant's `FanEntity` interface, providing controls for power, speed percentage, preset modes, oscillation angles, LED brightness, buzzers, child locks, and timer delays. The integration also includes custom service definitions (e.g., `fan_set_oscillation_angle`, `fan_set_buzzer_on`) declared in `services.yaml` and `strings.json`. The architecture cleanly separates device communication logic (MiotDevice subclasses with property mappings) from Home Assistant entity logic (FanEntity subclasses). The code is well-structured, uses type hints, follows Home Assistant best practices, and includes CI workflows (HACS validation, hassfest, mypy, pre-commit, yamllint). It targets Python 3.13 and modern HA versions (2024.8+). There are no data research or analytics elements; it is strictly an application integration.
ESP3D is a feature-rich embedded firmware for ESP8266/ESP32 microcontrollers, designed to serve as a Wi-Fi/Ethernet bridge and full-featured controller for 3D printers, CNCs, and similar equipment. The firmware provides a modular architecture with support for multiple network protocols (HTTP, WebDAV, FTP, Telnet, WebSocket, Bluetooth), a web-based user interface, file system management (SD card, flash filesystems like LittleFS/SPIFFS), sensor integration (DHT, BMP280), Lua scripting, and graphical displays via LVGL or TFT_eSPI. It includes a comprehensive command system (ESPxxx commands) for configuration and control, with authentication levels and persistent settings. The codebase demonstrates solid engineering for an embedded Arduino project, with clear separation of concerns between core services (serial, network, display, filesystem) and a message-passing inter-module communication pattern. It bundles many well-known third-party libraries (LVGL 8.2.0, TFT_eSPI 2.5.43, SdFat 2.2.3, EspLuaEngine, arduinoWebSockets) directly in the repository, ensuring reproducible builds but also creating a maintenance burden. The firmware is actively maintained with a responsive issue tracker and regular commits, though the reliance on pinned library versions and heavy conditional compilation introduces some technical drift.
SpyGuard is a network traffic analysis tool designed for detecting signs of compromise, particularly stalkerware and spyware, by monitoring WiFi traffic from connected devices. It consists of a frontend Vue.js 3 application for user interaction and capture initiation, and a backend Flask API for managing configuration, threat intelligence, and analysis. The core analysis engine processes PCAP files using Suricata, checks traffic against IOC databases and whitelists, performs heuristic and active checks (passive DNS, WHOIS, SSL validation), and generates JSON/PDF reports. External watchers periodically update threat intelligence feeds from sources like Cisco Umbrella and IP-to-ASN mappings. The architecture separates concerns: frontend handles capture UI and device management, backend provides authenticated APIs for system administration, and the analysis engine performs the detection logic. Key entry points include server/frontend/main.py (frontend service), server/backend/main.py (backend API), server/backend/watchers.py (threat intelligence updater), and analysis/analysis.py (analysis trigger).
FarmBot Web App is the cloud-based control panel for FarmBot, an open-source CNC farming robot. It provides a full-stack web application (Rails API + React/TypeScript SPA) for managing devices, creating automated sequences via a visual CeleryScript AST editor, scheduling farm events, monitoring telemetry and logs, managing plants/weeds/tools, and viewing real-time 2D/3D garden maps. The backend is a monolithic Rails app with PostgreSQL, RabbitMQ/MQTT for device communication, and DelayedJob for background processing. The frontend is a complex Redux SPA with extensive 3D visualization using Three.js. The system supports multiple hardware variants and includes firmware update management, camera calibration, and AI-assisted feedback. The codebase is actively developed with a large test suite, but exhibits some technical debt like legacy AST storage paths, future-dated migrations, and heavy mocking in tests.
This repository provides the firmware for a LoRa-based APRS iGate/digipeater station running on ESP32 microcontrollers. It bridges amateur radio APRS packets between LoRa RF and the internet (APRS-IS), and can also operate as a digipeater, TNC (KISS), weather station, and GPS tracker. The firmware includes a full web-based configuration UI, live map, MQTT integration, syslog, OTA updates, and support for dozens of hardware variants (Heltec, TTGO, etc.). The code is organized into modular C++ namespaces (LoRa_Utils, DIGI_Utils, APRS_IS_Utils, etc.) and uses a JSON-based configuration store. While the project is actively maintained, it shows some technical drift through vendored esptool binaries, dependency on older libraries (ElegantOTA), and heavy use of compile-time conditionals across board variants. The architecture is a classic embedded monolith targeting a single firmware binary, with strong hardware abstraction via pinout headers and a common configuration object. Several components—such as the KISS protocol encoder/decoder, the NetworkManager abstraction, and the Configuration class—are well-isolated and potentially reusable in other ESP32/ham radio projects.
ESPAtherma is an embedded firmware application (PlatformIO/Arduino) for monitoring and basic control of Daikin Altherma heat pump systems via an ESP32 or ESP8266 microcontroller. In production, it connects to the heat pump's X10A serial port, queries specific register addresses (reverse-engineered Daikin I and S protocols), converts raw bytes into human-readable values using configurable label definitions, and publishes the data over MQTT to a Home Assistant instance. It also provides Home Assistant MQTT auto-discovery for seamless integration. The architecture is a single-threaded loop: setup reads model-specific definition files and MQTT/WiFi config, then repeatedly queries registers, converts data, and publishes to MQTT. Key entry points are `src/main.cpp`, `include/comm.h` (serial query), and `include/homeassistant.cpp` (discovery payload generation). External dependencies include PubSubClient, ArduinoJSON, and board-specific libraries (M5Unified for M5Stick). The project also includes reverse-engineering scripts, serial log dumps, and a heat pump emulator, making it a hybrid of embedded application and protocol research. However, the primary usage and codebase character are that of an IoT monitoring/control application.
This repository contains the hardware design files, documentation, and support materials for the SIM7000 LTE Shield, an Arduino-compatible shield that adds LTE CAT-M1/NB-IoT connectivity and GNSS capabilities. The repository does not contain the actual software library (which resides in a separate Botletics-SIM7000 repo), but focuses on the hardware implementation, including PCB design files, schematics, AT command documentation, and firmware update tools. The hardware design features the SIM7000 series module from SIMCom, integrated with a uFL antenna connector for LTE, a separate uFL for GNSS (GPS/GLONASS/BDS/Galileo), a SIM card holder, USB interface for debugging/firmware updates, level shifting circuitry (TXB0104) for 3.3V/5V compatibility, status LEDs, and an MCP9808 I2C temperature sensor. The power supply design includes appropriate filtering and regulation for the cellular module. The PCB layout demonstrates attention to RF considerations with proper component placement and routing. Documentation includes comprehensive AT command logs showing how to configure the module for various network operations (registration, TCP/IP, SSL/TLS, MQTT), GNSS functionality, and sensor interfacing. These logs serve as practical examples for developers looking to implement cellular IoT applications. The repository also provides firmware update procedures using Qualcomm's QPST tool, though this is specific to the module manufacturer's update process. While the actual firmware/software for running applications on the shield is in a separate repository, this hardware repository provides a complete, validated reference design that enables developers to create IoT applications requiring cellular connectivity and location tracking. The design appears to be current, well-executed, and suitable for reuse as a starting point for similar LTE/GNSS shield projects.
This is a Homebridge plugin (`@switchbot/homebridge-switchbot`) that bridges SwitchBot IoT devices (lights, curtains, locks, sensors, vacuums, etc.) into Apple HomeKit using both HAP and Matter protocols. It communicates via Bluetooth Low Energy (BLE) and the SwitchBot OpenAPI cloud API, with configurable fallback and rate-limiting. The plugin provides a rich configuration UI served through Homebridge Config UI X, including device discovery, credential management, and advanced polling settings. The architecture follows a platform plugin pattern with two platform classes (HAP and Matter), a resilient client layer (debounce, circuit breaker, daily budget tracking), a device factory and abstract base class for device-specific implementations, and extensive Matter cluster mappings. While the codebase is well-structured and actively maintained, it suffers from a large monolithic platform file (~2800 lines), low test coverage (~1.36%), and a dependency conflict requiring `--legacy-peer-deps` during installation. ESLint configuration also fails in CI. Nonetheless, the plugin is feature-rich, handles edge cases like BLE encryption and OpenAPI rate limits, and includes a polished custom UI.
This repository is a comprehensive IoT device driver library for .NET nanoFramework. It provides bindings for hundreds of sensors, actuators, displays, and communication modules (e.g., BME280, SSD1306, NFC, Modbus, cellular modems, GPS). The architecture is a collection of independent driver projects, each with its own samples, tests, and documentation. Shared utility libraries (e.g., System.Device.Model, NumberHelper, SpanByte compatibility shims) support cross-cutting concerns. The codebase is actively maintained with frequent commits, but the sheer number of drivers (300+) leads to varying quality, some code duplication (e.g., SpanByte classes in multiple locations), and partially auto-generated code. Networking components like DHCP server, DNS server, and Home Assistant MQTT integration extend the library beyond raw sensor access. The primary use case is building embedded IoT applications on microcontrollers (ESP32, STM32) running nanoFramework.
MQTT-SN Tools is a suite of four command-line applications for working with the MQTT-SN (MQTT for Sensor Networks) protocol. The system provides mqtt-sn-pub for publishing messages, mqtt-sn-sub for subscribing to topics, mqtt-sn-dump for monitoring packets, and mqtt-sn-serial-bridge for serial-to-UDP bridging. All tools share a common C library (mqtt-sn.c/h) that implements the MQTT-SN protocol handling, including socket management, packet encoding/decoding, keep-alive mechanics, and topic mapping. The architecture is modular with clear separation between the protocol library and application-specific logic. Each tool follows a standard pattern: parse command-line arguments, establish UDP connection to an MQTT-SN broker, perform protocol operations (connect, publish/subscribe, etc.), handle incoming/outgoing packets, and clean up resources. The project has active maintenance with recent commits and a test suite.
IBM TJBot is a Raspberry Pi-based robotics application that interacts with IBM Watson AI services through various 'recipes'. Each recipe demonstrates a different AI capability: conversation (chatbot using Watson Assistant, Speech to Text, and Text to Speech), sentiment analysis (monitoring Twitter tone and changing LED color), speech to text (voice-controlled LED), and translation (speech-to-speech language translation). The architecture consists of a core TJBot library that abstracts hardware and service interactions, with each recipe being a standalone Node.js application. Key entry points are the recipe-specific JavaScript files (conversation.js, sentiment.js, stt.js, translator.js) and the bootstrap script for Raspberry Pi setup. Data flows involve capturing input (audio, Twitter stream), processing through Watson services, and triggering hardware actions (LED, servo, speaker) based on results.