Remote-Kit: Pocket Router for Remote Hardware Bring-up

A compact "lab-in-a-box" that turns a $30 GL-MT300N-V2 pocket router into a remote hardware bring-up station. You get serial console, PoE power control, SD card image swapping, USB power cycling, PiKVM video/keyboard, and a camera feed over a single box.

Last updated: February 2, 2026

Quick start: Flash the Remote-Kit firmware, log in at http://192.168.20.1, wire in PoE switch + PiKVM, then update port-forwards to match device IPs.

What Remote-Kit does

• Serial terminal to the DUT over SSH (screen)
• Virtual SD card image loading via SDWire (no physical card swaps)
• Remote USB power cycle (Tasmota-based XY-WSUSB)
• PoE power on/off and power measurements (Netgear GS308EP)
• PiKVM remote display + USB keyboard/mouse emulation
• Optional USB webcam stream for bench visibility
• FTP/TFTP for bootloader RAM loading

System overview

Example bench wiring for a Pi 4 DUT with PoE power, PiKVM, SDWire, and camera.

Security note: Default credentials — Remote-Kit SSH: root / remote-kit-000, PoE switch (GS308EP): password, WiFi SSID/key: remote-kit-000 / remote-kit-000. Change all default passwords before exposing any service to your corporate or public network.

Hardware (Bill of Materials)

Below is a reference setup for a Raspberry Pi 4 as DUT. Prices are from the time of writing and will vary.

Item	Qty	Unit Price (EUR)	Notes
GL.iNet GL-MT300N-V2	1	30	Remote-Kit router
5V MicroUSB PSU (router)	1	10	5V/3A adapter
Netgear GS308EP PoE switch	1	90	PoE power control + measurements
5V PoE splitter (USB-C)	2	15	Power PiKVM + DUT
3-port USB hub	1	5	Any basic hub
USB flash drive (16 GB)	1	10	Image storage
Raspberry Pi 4	2	50	One for PiKVM, one as DUT
MicroSD card (16 GB+)	1	10	PiKVM image
Geekwork PiKVM kit	1	85	PiKVM hardware
USB webcam (UVC)	1	70	Bench visibility
Tasmota WiFi smart socket	1	10	Power control (alt to PoE)
USB-TTL serial adapter	1	15	Serial console
Sinilink XY-WSUSB dongle	1	8	USB power cycle (Tasmota)
SDWire (SD card mux)	1	90	Virtual SD card swapping

Firmware and services

• Custom OpenWrt image for GL-MT300N-V2
• Port forwarding for PiKVM, PoE switch, camera, and smart plugs
• SSH access for scripted automation
• Utilities: screen, ntgrrc, SDWire scripts

Setup steps

1. Flash the Remote-Kit firmware to the GL-MT300N-V2 (source on GitHub).
2. Connect your PC to the LAN side and log in to http://192.168.20.1.
3. Connect WiFi accessories (smart socket, XY-WSUSB) to SSID remote-kit-000 (key: remote-kit-000).
4. Wire PoE switch, PiKVM, SDWire, and camera to the LAN ports.
5. Change the default GS308EP password from password to something secure.
6. Update port-forwards in OpenWrt to match your device IPs.

The firmware ships with these default port-forward rules (all via the router's LAN IP):

Service	Port
OpenWrt UI	80
USB webcam	8080
PoE switch (GS308EP)	8081
PiKVM	4433
Nous smart socket	8082
XY-WSUSB dongle	8083

Setup diagram for overwriting OEM firmware and wiring up the Remote-Kit router.

Access points: OpenWrt UI on http://remote-kit-000, PiKVM on https://remote-kit-000:4433, PoE switch on http://remote-kit-000:8081.

Common remote workflows

1) Load a new SD image onto the DUT

ssh root@remote-kit-000  #pw: remote-kit-000
root@remote-kit-000:~# wget -O /mnt/sda1/libreelec-image.img.gz https://releases.libreelec.tv/LibreELEC-RPi4.aarch64-11.95.1.img.gz
root@remote-kit-000:~# ntgrrc login --password Remotekit000 --address GS308EP
root@remote-kit-000:~# ntgrrc poe set -p 1 --power disable --address GS308EP
root@remote-kit-000:~# sd-wire-load-image.sh /mnt/sda1/libreelec-image.img.gz
root@remote-kit-000:~# ntgrrc login --password Remotekit000 --address GS308EP
root@remote-kit-000:~# ntgrrc poe set -p 1 --power enable --address GS308EP
root@remote-kit-000:~# #LibreElec will now boot on Pi-4-DUT - you can see this booting from a remote location using PiKVM's WebUI.

2) Power cycle the DUT (PoE)

ssh root@remote-kit-000  #pw: remote-kit-000
ntgrrc login --password Remotekit000 --address GS308EP
ntgrrc poe set -p 1 --power disable --address GS308EP
ntgrrc poe set -p 1 --power enable --address GS308EP

3) Open serial console

ssh root@remote-kit-000  #pw: remote-kit-000
screen -R serial /dev/ttyUSB0 115200

4) Simulate Ethernet cable unplug

ssh root@remote-kit-000  #pw: remote-kit-000
ntgrrc login --password Remotekit000 --address GS308EP
ntgrrc port set -p 1 -s 'Disable' --address GS308EP  #unplug
ntgrrc port set -p 1 -s 'Auto' --address GS308EP     #plug

5) Measure PoE power draw

ssh root@remote-kit-000  #pw: remote-kit-000
ntgrrc login --password Remotekit000 --address GS308EP
ntgrrc poe status --address GS308EP       #print status in table format
ntgrrc poe status --address GS308EP -f json  #print in json format

Large images: The router has limited RAM — do not decompress multi-GB images on it. For large files (e.g. raspios-bookworm-arm64.img.xz at 2.4 GB): decompress on your PC first, then scp the raw .img to /mnt/sda1/, and run sd-wire-load-image.sh.

Use cases

• Remote OS image testing for embedded boards
• Regression testing of bootloaders and kernels
• Remote lab access for distributed teams
• Automated power and peripheral cycling in CI pipelines

DOWNLOADS

github.com/hackboxguy/remote-kit

Remote-Kit firmware (.bin)

Related posts

• Pocket Router as an AWS IoT Edge Device
• Pocket Router as a Portable DLNA Media Server
• Remote Home Access with a 5-Euro Pocket Router
• Getting Started with AWS IoT on OpenWrt Routers

CAN Bus Multi-Sensor Node with ESP32 and KiCad PCB

Ambient Light + Air Quality + More — a reliable, low-cost sensor network for home, lab, and in-vehicle prototypes, built around CAN with OTA updates and multi-node management.

Last updated: January 25, 2026

Why CAN for sensors?

CAN was designed for noisy, distributed environments and it shines when you want dependable, multi-drop communication over long cables. That makes it a strong backbone not only for vehicles, but also for home automation and lab setups where Wi-Fi can be unreliable or too power-hungry.

This project builds a CAN-based sensor node and a companion display client that together provide:

• Ambient light, temperature, humidity, pressure, IAQ, CO₂eq, VOC
• Multi-node addressing (up to 16 nodes on the same bus)
• OTA firmware updates over CAN (~3.3 KB/s)
• Device management and automated sanity testing with a CLI tool

System overview

The system has three pieces:

1. Sensor nodes — ESP32-C3 + ALS + BME680/BME688 + CAN transceiver
2. Monitor/display node — ESP32-C3 + OLED + CAN transceiver
3. Host tool — can-sensor-tool for monitoring, management, and OTA (Linux / SocketCAN)

All nodes communicate at 500 kbps over a standard CAN bus.

System overview: sensor nodes + monitor node + CAN-USB adapter + RJ-11 junction board.

Hardware design

Core components

• ESP32-C3 SuperMini (~$2 board)
• SN65HVD230 CAN transceiver (3.3 V native — no level-shifting needed)
• ALS sensor: VEML7700 or OPT3001 (board footprint supports either; mount only one)
• BME680/BME688 for temperature, humidity, pressure, and IAQ data
• On-board buck converter: 6–30 V input (12 V typical), generates stable 5 V / 3.3 V locally

Power-over-CAN using 6P4C (RJ-11)
The system uses a two-pair telephone cable: one pair for CAN-H / CAN-L, one pair for power. Simple, low-cost, and practical. Tested reliably to 15 m with standard RJ-11 cables.

RJ-11 junction board — low-cost two-pair power + CAN distribution. This is a ready-made off-the-shelf board available from common electronics marketplaces.

Sensor board

Sensor board: ESP32-C3, ALS footprint, BME680, SN65HVD230 transceiver, buck converter, and RJ-11 connector.

3D render of the sensor board PCB.

Sensor board sub-modules: base PCB with ESP32-C3 SuperMini, SN65HVD230 CAN transceiver, BME680 environmental sensor, VEML7700/OPT3001 ALS, buck converter, and RJ-11 connector.

Monitor board

Monitor board with OLED display showing live values: 22 lux, 25.9 °C, 32 % RH, 989 hPa, IAQ 51 (Good).

3D render of the monitor board PCB.

Monitor board sub-modules: base PCB with ESP32-C3 SuperMini, SN65HVD230 CAN transceiver, SSD1306 OLED display, buck converter, and RJ-11 connector.

Sensor auto-detection (one firmware, many boards)

The sensor firmware auto-detects what's connected at boot:

• ALS: VEML7700 (0–120 K lux) or OPT3001 (0–83 K lux)
• Environmental: BME680 or BME688

A single firmware image works across all hardware variants — no build-time configuration needed.

CAN architecture (high-level)

Each node gets 32 CAN message IDs (0x20 spacing):

• 0x100–0x10F: sensor data for Node 0 (ALS at +0x00, ENV at +0x01, AIQ at +0x02, …)
• 0x110–0x11F: control/management for Node 0 (stop, start, reboot, OTA, discovery, …)

The same layout repeats at +0x20 per node, supporting up to 16 nodes on a single bus. Reserved offsets are available for future sensor types (gas selectivity, mm-wave presence, etc.).

Full frame layouts and byte-level formats are documented in the repo README.

Real measurements (sample log)

Below is a snippet captured with can-sensor-tool monitor:

[Node 0] ALS (OPT3001): 79 lux, seq=13, config=201, status=OK
[Node 0] ENV: 24.83°C, 38% RH, 991.2 hPa, status=OK
[Node 0] AIQ: IAQ=50 (Good), accuracy=0, CO2=500 ppm, VOC=0 ppm, status=OK
...
[Node 0] ALS (OPT3001): 192 lux, seq=20, config=203, status=OK
[Node 0] ENV: 25.09°C, 36% RH, 991.2 hPa, status=OK
[Node 0] AIQ: IAQ=50 (Good), accuracy=0, CO2=500 ppm, VOC=0 ppm, status=OK
...
[Node 0] ALS (OPT3001): 0 lux, seq=24, config=200, status=OK
[Node 0] ENV: 25.15°C, 35% RH, 991.2 hPa, status=OK

Over this run, light levels ranged from 0 (near-dark) to ~192 lux while temperature stayed around 25 °C. IAQ reported "Good" with CO₂eq at 500 ppm throughout.

Automated sanity testing

The can-sensor-tool includes a sanity-test command that exercises the full node lifecycle in one shot — discovery, start/stop, interval accuracy, reboot, node-ID change, factory reset, OTA update, and final re-discovery:

$ can-sensor-tool sanity-test ./build/esp32-can-sensor.bin

[1/9] Discovery...         PASS: Node 0 responds to PING
[2/9] Device Info...       PASS: FW v1.0.1, sensors=0x13, ALS=OPT3001, partition=ota_1 (valid)
[3/9] Start/Stop...        PASS: Received 3 ALS msgs in 3s, 0 after STOP
[4/9] Monitor Interval...  PASS: Average interval: 977 ms (target: 1000 ms)
[5/9] Reboot...            PASS: Node rebooted and recovered in 2005 ms
[6/9] Set Node ID...       PASS: Successfully changed 0->1->0
[7/9] Factory Reset...     PASS: Factory reset completed in 2204 ms
[8/9] OTA Update...        PASS: OTA OK, node booted v1.0.1 on ota_0 (3.2 KB/s, 106369 ms)
[9/9] Final Discovery...   PASS: Node 0 still responds after all tests

Results: 9/9 passed, 0 failed

This makes it practical to validate firmware changes end-to-end before deploying to multiple nodes.

Device management + OTA over CAN

The can-sensor-tool handles discovery, monitoring, and A/B OTA firmware updates over the CAN bus.

The ESP32 uses an A/B partition scheme: each OTA update writes to the inactive slot, reboots into it, and keeps the previous slot as a rollback target. If the new firmware fails to validate on first boot, the bootloader automatically reverts.

In testing, OTA reached ~3.2–3.3 KB/s, and a ~345 KB firmware image completed in ~106 seconds. This makes it feasible to update multiple nodes on a live bus without physical access.

Use cases

Home & Lab

• Multi-room light + environment monitoring
• Low-cost wiring with RJ-11 and a junction board
• Central monitoring on OLED or a PC via SocketCAN

In-vehicle prototype (POC)

• Rugged wiring and noise-tolerant communication
• Deterministic update rates across multiple nodes
• OTA updates without pulling nodes from the vehicle

In-vehicle smart ambient sensing

• Monitor cabin temperature, humidity, IAQ, CO₂eq, VOC, and BME688-based gas signals for passenger comfort and safety
• Feed IVI/ADAS systems with real-time ambient conditions for alerts or policy decisions
• Use ambient light data to adjust in-vehicle displays — HDR10+ Adaptive and Dolby Vision perform real-time dynamic tone-mapping that requires a continuous ambient light input to optimize frame rendering on the display (the HDR10+ Automotive spec mandates this ambient light feed)
• Add human presence detection (planned) to enable occupancy-aware safety and convenience features

Enterprise / larger infrastructure

• CAN as a reliable wired sensor backbone
• Up to 16 nodes per bus today; extendable with multiple bus segments

Current limitations and roadmap

Current

• No formal environmental or long-term reliability testing yet
• Human presence detection (mmWave) not implemented

Planned

• Add mmWave human presence sensor
• Expand other sensor types using reserved CAN offsets

BSEC licensing note

BME680/BME688 air-quality outputs use Bosch Sensortec's BSEC 2.x library, which is proprietary and not included in this repo. To enable it, download the BSEC zip from Bosch, accept their license, and pass it to build.sh (see BME680_SETUP.md in the repo).

Build and flash (sensor board)

1. Install ESP-IDF and download the Bosch BSEC library (e.g. bsec2-6-1-0_generic_release_22102024.zip).
2. Connect the ESP32-C3 board to your PC via USB.
3. Clone the sensor firmware repo and build:

git clone https://github.com/hackboxguy/Esp32-CAN-ALS.git
cd Esp32-CAN-ALS
./build.sh --target=esp32c3 --idfpath=$HOME/esp/esp-idf/ \
           --version=1.0.1 \
           --bsecpath=/path/to/bsec2-6-1-0_generic_release_22102024.zip
./build.sh --flash

Build and flash (monitor board)

1. Install ESP-IDF.
2. Connect the ESP32-C3 board to your PC via USB.
3. Clone the display client repo and build:

git clone https://github.com/hackboxguy/Esp32-CAN-Disp-Client.git
cd Esp32-CAN-Disp-Client
idf.py set-target esp32c3
idf.py build flash

SOURCE CODE

github.com/hackboxguy/Esp32-CAN-ALS — sensor node firmware + can-sensor-tool

github.com/hackboxguy/Esp32-CAN-Disp-Client — OLED monitor client firmware

KICAD PCB FILES

CAN-Sensor-Board.zip — sensor board KiCad project + gerbers

CAN-Monitor-Board.zip — monitor board KiCad project + gerbers

Related posts

• Measuring PREEMPT_RT Latency with an Oscilloscope
• Build a $2 IoT/MQTT Node with a Bare ESP-12F
• Pogo-Pin Programming Dock for ESP-12F Modules

Alexa Controls Domoticz via Philips Hue Emulator

If you run Domoticz and have an Amazon Echo, this is one of the simplest ways to get voice control while keeping device commands on your local network — no cloud subscriptions, no Alexa skills, no Philips account.

Last updated: January 18, 2026

Note: Alexa still uses the internet for speech recognition, but device control stays on your LAN.

Architecture overview: voice command → Echo discovers a Hue-bridge emulator → commands are translated to Domoticz API calls → devices respond (locally).

What you get

• No Philips Hue cloud — emulates a Hue Bridge locally
• No third-party Alexa skills — Echo's native Hue support handles discovery
• No subscriptions — runs on any Raspberry Pi or Linux box you already own
• Local device control — commands stay on your LAN (Echo → Emulator → Domoticz)

The problem with typical Alexa integrations

A lot of smart-home voice control flows through vendor clouds and Alexa skills: you install a skill, link accounts, and every action takes a detour through the internet. That can add latency, create privacy concerns, and introduce dependencies on services that can change, break, or become paid.

If you already run Domoticz, the question is natural: why can't Alexa talk to your system directly? The answer is: it can — if you present your devices in a way Alexa already understands.

What is Domoticz Hue Emulator?

Domoticz Hue Emulator is a lightweight Python service that emulates a Philips Hue Bridge on your local network. Amazon Echo devices have native support for Hue bridges, which means Alexa can discover and control devices without an Alexa skill.

The emulator makes Alexa believe it's talking to a Hue bridge, but behind the scenes it translates those requests into Domoticz API calls for your switches, dimmers, RGB lights, and scenes/groups.

How it fits together

Voice Command
   →
Amazon Echo
   →  (local Hue protocol)
Hue Emulator (Python)
   →
Domoticz API
   →
Switches / Dimmers / RGB Lights / Scenes

Features at a glance

• On/Off control for switches
• Dimming (brightness control) for dimmers and RGB lights
• RGB color control (e.g., "set lamp to red", "warm white")
• Scenes/Groups support for controlling multiple devices at once
• Easy YAML configuration
• Runs as a systemd service (auto-start)

Voice command examples

Basic on/off

• "Alexa, turn on Living Room Light"
• "Alexa, turn off Kitchen Light"

Dimming (dimmer/rgb types)

• "Alexa, set Bedroom Light to 50 percent"
• "Alexa, dim Living Room Light"
• "Alexa, brighten Bedroom Light"

Colors (rgb type only)

• "Alexa, set Lamp to red"
• "Alexa, set Lamp to blue"
• "Alexa, set Lamp to warm white"

Scenes and groups

• "Alexa, turn on All Lights"
• "Alexa, turn off All Lights" (groups only)

Requirements

• Raspberry Pi or any Linux server on the same network as your Echo
• Domoticz running with devices configured
• Python 3.7+
• Port 80 available (required by the Hue Bridge protocol)

Tip: if port 80 is in use by Apache, Nginx, or another service, you must stop or reconfigure it for the emulator to work.

Installation & setup

1) Clone the repository

git clone https://github.com/hackboxguy/domoticz-hue-emulator.git
cd domoticz-hue-emulator

2) Install (or test with a dry run)

# Test installation (dry run)
sudo ./install.sh --domoticz-user=YOUR_USER --domoticz-pw=YOUR_PW --dryrun

# Install
sudo ./install.sh --domoticz-user=YOUR_USER --domoticz-pw=YOUR_PW

3) Configure your devices in alexa-devices.yaml

Add your Domoticz devices by name, IDX, and type (switch, dimmer, rgb). You can find IDX values in Domoticz under Setup > Devices.

domoticz:
  url: "http://localhost:8080"
  username: "admin"
  password: "yourpassword"

devices:
  - name: "Living Room Light"
    idx: 10
    type: dimmer

  - name: "RGB Lamp"
    idx: 30
    type: rgb

4) Restart the service

sudo systemctl restart domoticz-hue-emulator

5) Discover devices

Now the fun part:

"Alexa, discover devices"

Within seconds, your Domoticz devices should appear inside Alexa as controllable lights.

Scenes vs groups: In Domoticz, Scenes only support ON (activate), while Groups support ON and OFF. If you need voice control to turn devices both on and off, create a Domoticz group.

Scenes, groups, and routines

The emulator supports Domoticz scenes/groups so you can control multiple devices with a single command. It also pairs nicely with Alexa Routines for custom phrases like "Alexa, let's start the party" — mapped to a Domoticz scene or group.

Troubleshooting

Alexa doesn't discover devices

• Confirm the service is running: sudo systemctl status domoticz-hue-emulator
• Verify port 80 is available: sudo ss -tlnp | grep :80
• Check logs for SSDP activity: sudo journalctl -u domoticz-hue-emulator -f

Device shows "not responding"

• Verify Domoticz is reachable: curl http://localhost:8080
• Confirm the device IDX is correct in alexa-devices.yaml
• Review logs for API errors: sudo journalctl -u domoticz-hue-emulator -f

Port 80 already in use

Stop or reconfigure the conflicting service (often Apache, Nginx, or another bridge).

How it works (under the hood)

1. SSDP discovery: the emulator answers Alexa's UPnP/SSDP discovery requests (UDP 1900), announcing itself as a Hue Bridge.
2. Hue API emulation: Alexa reads Hue-compatible JSON describing your Domoticz devices as "lights".
3. Command translation: Alexa commands are translated into Domoticz API calls (on/off, brightness, color).
4. Local device control: commands stay on your LAN (Echo → Emulator → Domoticz). Alexa still uses the internet for speech recognition.

SOURCE CODE

github.com/hackboxguy/domoticz-hue-emulator

Related posts

• Vendor-Neutral Zigbee Gateway with Raspberry Pi
• $20 Pocket Router as Domoticz Smart Home Gateway
• Control Home Devices via XMPP Chat with Raspberry Pi