DEV Community: Peter H

Turn a PZEM-004T + Raspberry Pi into a Full Energy Monitor — No SSH, No Docker, One Click

Peter H — Wed, 16 Sep 2026 23:42:23 +0000

A PZEM-004T energy monitor with live dashboard, local history, and Home Assistant integration, built as an Orbit OS app instead of Docker.

Story

A guided-setup, Home-Assistant-ready energy monitor for PZEM-004T meters, built on a real embedded device without ever touching a Dockerfile.

I wanted to turn a cheap PZEM-004T meter into something I could install once, leave running, and actually use every day. I wired one up to a Raspberry Pi running Orbit OS, and what came out the other end is PZEM Monitor: a web dashboard with live readings, local history you can chart or export, and Home Assistant integration that needs zero YAML to set up.

Things used in this project

Hardware

Raspberry Pi 4 Model B running Orbit OS
One or more PZEM-004T v3.0 AC energy meters
USB-to-UART adapter
Wiring/jumper cables to the meter(s) (a shared UART bus supports multiple meters)
Power supply for the device

Software

Orbit OS running on the device (version 26.20260710.1118)
Orbit Studio v1.9.2 (VS Code extension) to create, run, and package the app
MQTT broker + Home Assistant (optional, only for the HA integration)

Wiring the PZEM-004T

Wiring Diagram

The PZEM-004T v3.0 has a simple 4-pin TTL interface for communication, separate from the AC terminals it's actually measuring:

TX → RX on the USB-to-UART adapter
RX → TX on the USB-to-UART adapter
GND → GND
5V → powers the meter's communication interface

The adapter then plugs into the Raspberry Pi over USB, which is what PZEM Monitor's setup wizard sees as a serial port to connect to.

One of the useful things about the PZEM-004T is that multiple meters can share the same UART bus, so you don't need one adapter per meter. Each meter gets its own Modbus address, and the app handles polling them one by one over the shared line. That's exactly what the setup wizard's address-assignment step is for: connect one meter at a time, let the wizard assign it a free address, then move on to the next.

What PZEM Monitor is, and why I built it

I wanted to know what my appliances were really drawing. Not an estimate. Not a monthly total from the utility bill. Live voltage, current, and power, per circuit, with history I could check later. A PZEM-004T wired onto a main panel, a solar inverter, or a single appliance turns "I wonder how much that's using" into a real number on a screen.

PZEM-004T meters are cheap and accurate enough for this job. They speak Modbus-RTU over a plain UART, so the sensor side was never the hard part. What I kept putting off was everything around the sensor: something to poll it, somewhere to store the history, a web UI to look at it, and ideally a bridge into Home Assistant, all without sending my electricity data to someone else's cloud. I also wanted to check the dashboard from outside the house sometimes, without opening anything up to the internet myself.

That's what PZEM Monitor is: an app that turns a device into a dedicated, always-on energy meter reader for one or more PZEM-004T sensors.

I also had a Raspberry Pi free, and building this doubled as my excuse to learn how to build a real app for Orbit OS, not just a "hello world." I liked Orbit OS for a second reason, too: I wanted to build an app that other people could simply try for themselves, install it on their own device and have it up and running within minutes, with no build toolchain, no configuration files to edit by hand, no scripts to run, and no cloning repositories or manual compilation steps. The experience is much like Android — just open the Orbit OS Store from anywhere, find the app, install it remotely onto your device, and it's running. No terminal, no setup, nothing to configure.

IMAGEM

If the app turns out to be useful to someone, I want them to be able to use it anywhere in the world. And I want to keep improving it over time, knowing that shipping an update doesn't have to be complicated for them or for me. It comes down to one simple flow: I publish -> users receive. I push a new version to the store, and it just shows up on their device, with nothing for them to do and nothing for me to chase.

What it does

Setup wizard

Pick a serial port, connect one meter at a time, and the wizard finds it and assigns it a unique Modbus address before moving to the next meter.

Wiring several meters onto one bus doesn't mean I have to remember which address is already taken; the wizard tracks that for me.

Live dashboard

One card per meter: online/offline status, and while online, voltage, current, power, frequency, power factor, and accumulated energy in kWh, refreshed automatically with nothing to click.

History

Readings are logged to an on-device database on a schedule I control, with automatic cleanup after a set retention period. I can chart or table any range (24 hours, 7 days, 30 days, everything) and export any of it to CSV.

Home Assistant, zero YAML

Turn on MQTT, point it at my broker, and every meter shows up in HA automatically via MQTT discovery: one device per meter, with energy reported correctly as an ever-increasing total.

It's also built for unattended operation: if a meter is missing or the UART is misconfigured, the app doesn't crash. It keeps serving the dashboard and settings pages, so I can fix the problem from a browser instead of needing a shell on the device. Everything runs on-device, and nothing leaves the network unless I turn MQTT on myself.

Why I built it for Orbit OS instead of Docker

My first instinct for an always-on service with a web UI is usually: put it in a container, docker run, done. But for this particular application, Docker felt like a poor fit for the target hardware: it assumes a daemon can run all the time, that pulling a few hundred MB from a registry is cheap, and that storage is basically free. On a device running off an SD card or eMMC, on a slow connection, with a fraction of a server's RAM, those assumptions get expensive fast: the daemon alone is memory I don't have to spare, and every image drags in a full base-OS layer on top of what the app actually needs.

Orbit OS sidesteps that entirely. Apps run as signed .orb packages (an .orb works a lot like an Android .apk), self-contained, with no base-OS layer to carry. PZEM Monitor's own build, binary and web assets and manifest and signature included, comes out to just 4.5MB. That's what a small app looks like when it isn't shipping a container's worth of Linux underneath it.

The app also only needs one thing from the device: the UART port the meters are wired to. PZEM Monitor's manifest declares exactly three capabilities: basic device info for the status page, UART access to talk to the meters, and Launcher access to show its web UI. The runtime enforces that nothing else is reachable, no ability to change network settings, no filesystem access outside its own data directory. A typical container tends to lean on broad device access just to reach one interface it needs; here the app's access is scoped to exactly what it uses, declared up front.

The other thing I'd have had to build myself with Docker is a fleet story: a shared registry, an update mechanism, a way to keep devices in sync, all as extra infrastructure on top of the app itself..

The Orbit OS Store solves that at the platform level: push a new version, and every device in the field that has the application installed and automatic updates enabled will automatically receive the new version, with no deployment scripts or SSHing into devices one by one.

While developing, Orbit Studio can push the .orb straight to a device on the network instead.

Building it: the development experience

The whole workflow lived inside Orbit Studio, a VS Code extension that covers the full lifecycle: creating the project, running it against real hardware, and deploying it, all without leaving the editor.

Create Project scaffolded the app: pick the SDK language (Go, in my case; Java, Python, and C++ are also supported), give it a name, point it at my device's IP on the local network, and pick an SDK version. A minute later I had a full project structure with the right manifest, ready to run.

Youtube Video _ Orbit Studio Develop Apps Remotely in Real-Time — Raspberry Pi & Arduino UNO Q

Run App is the part that changed how I worked. It doesn't deploy anything. My code kept running on my own laptop, but every hardware call it made went out over the network (TCP/mTLS) to the real device and came back with real data: real UART bytes from the meter, in real time. I could tweak the polling loop, print a raw Modbus frame, and rerun in seconds. No image build, no flashing, no SSH session.

The meter and the device were real the whole time. I just never had to package or install anything to test against them.

Once a piece actually worked, Deploy was one click: Orbit Studio built the .orb, signed it with a dev certificate, and installed it straight onto the device.

From that point the app stopped being driven by my laptop and started running natively on the device, supervised by the runtime, fully autonomous. A Device Log view streamed its output into VS Code's Output panel whenever I wanted to watch it live, and once installed it showed up as a tile in the device's Launcher (http://), the same as any other installed app. From there I could also check its status or uninstall it.

That's the whole loop, start to finish: scaffold, iterate live against real hardware, one-click package, sign, and install. No registry, no push/pull, no docker-compose.

Deploying to my own device is one thing; getting it in front of other people is a separate step, and it happens outside Orbit Studio entirely. The Store's Developer area has a submission flow for that: build the .orb, submit it for review (or submit the source directly, which earns a Trusted App badge on the listing), and the Orbit OS team reviews it before it goes live.

I had a confirmation back within a day, and once I approved the listing myself, PZEM Monitor was live in the Store, ready for anyone to install remotely with one click on their own devices.

What I learned

The PZEM-004T's general address was the real surprise. Every unit answers on a fixed address (0xF8) no matter what address it's currently assigned, which isn't standard Modbus behavior. Once I understood that, multi-meter setup got a lot simpler; before that, it just looked like a meter that wasn't responding.

Orbit OS's "run against real hardware without deploying" model took a moment to click. I kept expecting to need a build step before I could test anything. Once it sank in that my laptop could drive real UART traffic directly, it changed how often I was willing to just try something.
Getting comfortable trusting the shared UART bus took longer than I expected. Polling several meters reliably off one line, without them stepping on each other, needed more care than I assumed going in.
The deploy step itself was easier than I expected. After years of flashing images and SSHing into boxes, going from working code to a signed package running on the device in one click still feels a little unreal.
Local storage and optional MQTT were a deliberate choice, not a default. I wanted the app fully useful with nothing configured beyond wiring, and Home Assistant to be something I opted into, not something the app assumed I wanted.

Where it stands now

Getting PZEM Monitor application into the Store isn't the finish line for me. It's the start of the fun part. I want to keep this project alive: chasing down every little rough edge, polishing the parts that only reveal themselves once real people are running it on real meters in real homes, and pushing updates out through the Store the way I described above, without anyone having to lift a finger for it.

More than anything, I'm looking forward to hearing from whoever ends up using it. Every setup is a little different: different meters, different panels, different things people care about seeing on a dashboard. I'd love for those differences to shape where this app goes next. If someone wants a feature that isn't there yet, I want to hear about it and build it. This is very much a living project, and I'm planning to keep growing it for as long as people find it useful.

One direction I'm genuinely excited about is widening what the app can talk to. PZEM-004T is where this started, but the Modbus foundation underneath it isn't tied to one meter, and I'd love to see PZEM Monitor grow to support other meters too, and maybe one day reach beyond hobbyist hardware into the industrial-grade meters that speak the same language.

Orbit OS is opening a device certification program: a path for independent makers and small shops to ship hardware that's certified for the ecosystem. It took me a second read to see what that actually means. A certified device carries a guarantee — plug it in and Orbit OS apps run on it correctly from first boot. And whoever built it didn't have to write the operating system, the signed update pipeline, the security model, or the store that ships the app. That part already exists.

And it keeps existing after the product ships. When the app gets a new version, it reaches the device exactly the way an app update reaches an Android phone: through the store, automatically. The person who built the hardware doesn't have to do anything for that to happen.

Which is why I've started entertaining an idea I'd have dropped a year ago. PZEM Monitor is an app today. It could be a product: a small purpose-built board with one or two PZEM-004T sensors already wired in, shipped with the app pre-installed. No wiring, no serial port to hunt for. Power it up and the numbers arrive.

I'm not building it yet. But what would have killed the idea before was never the board — it was everything around the board. And that isn't mine to solve anymore.

Installing PZEM Monitor

**Don't have Orbit OS on a device yet? **Follow the Orbit OS installation guide first, then come back here.

Already have Orbit OS running? Installing PZEM Monitor is a browser-only process, no file transfer, no SSH:

Sign in (or create a free account) at store.orbit-os.org.
Link your device to your account so it appears as an install target.
Find PZEM Monitor in the Store, click Install, and select the device you want to install it on.
Confirm. The .orb is delivered and installed remotely, and the PZEM Monitor tile will appear in the device's Launcher, ready to run the setup wizard.

Full details on account setup and device linking are available in the Orbit OS getting started guide.

Have a PZEM-004T and an Orbit OS device? Give it a try. I'd love to hear about your setup and what you'd like to see added next.

PZEM Monitor: Store
Orbit OS: website
Orbit OS Youtube: Channel

I connected Cursor IDE to a Raspberry Pi via MCP — controlled relays and read an I2C sensor in natural language

Peter H — Thu, 11 Jun 2026 15:21:05 +0000

If you've ever set up a Raspberry Pi project, you know the drill — SSH into the device, write custom scripts, debug GPIO issues, repeat. It works, but it's tedious.

I wanted to try something different: what if an AI assistant could talk directly to the hardware?

This is what I built — a Raspberry Pi with a 2-relay HAT and a BMP280 pressure sensor, controlled entirely via natural language through Cursor AI using the Model Context Protocol (MCP).

No SSH. No custom scripts. Just ask.

Here's the demo in action:

https://youtu.be/PaKN3fWGJWk?si=nFGmwtecihj2VDOb

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external tools and services. Think of it as a bridge between an AI client (like Cursor) and a system that exposes a set of tools the AI can call.

In this case, the "system" is a Raspberry Pi running Orbit OS — an Android-like platform for embedded Linux that exposes device capabilities as secure APIs.

The Setup

Hardware:

Raspberry Pi 4
2-relay HAT (Relay 1 = GPIO5, Relay 2 = GPIO6, active-low)
BMP280 pressure/temperature sensor (I2C bus 1, address 0x77)

Software:

Orbit OS (Community Edition)
MCP Server app — installed from the Orbit OS Store in one click
Cursor AI with MCP configured

Installing the MCP Server

The MCP Server app is available on the Orbit OS Store. One click to install — no Docker, no SSH, no configuration files.

Once installed, the device exposes an MCP endpoint at:

http://<DEVICE_IP>:9999/mcp

To connect Cursor, add this to your MCP config:

{
  "mcpServers": {
    "orbit-os": {
      "url": "http://<DEVICE_IP>:9999/mcp"
    }
  }
}

That's the entire setup.

What the AI can do

The MCP Server exposes tools that the AI can call directly:

System — device info, OS/runtime info, live metrics
GPIO — list pins, set direction, read/write state
I2C — scan bus, transfer bytes directly
Apps — list, install, uninstall .orb packages
Power — reboot or shutdown the device
Update — OTA install, factory reset

And more — WiFi, Bluetooth, SPI, UART, PWM, Ethernet.

The Demo

Before starting the demo, I told Cursor the relay mapping and that there's an I2C device on bus 1 to be discovered. The AI was instructed to always call the MCP tools — never simulate hardware states.

Device Info

Me: Give me the device info

Cursor: Device info — Raspberry Pi 4:
OS: Orbit OS | Kernel: Linux ARM64
CPU: Cortex-A72 | RAM: 1GB
Storage: 16GB | Architecture: ARM64

System Health

Me: Is the device healthy?

Cursor: Device health check:
✓ CPU temp: 42°C — normal
✓ RAM usage: 14% — normal
✓ Storage: 34% — normal
Device is healthy.

GPIO Enumeration

Me: List all available GPIO lines

Cursor: [fetches live GPIO list from the device via MCP]
GPIO5 — input, unused
GPIO6 — input, unused
GPIO17 — input, unused
...

Relay Control

Me: I have a 2-relay HAT. Relay 1 is GPIO5, Relay 2 is GPIO6. Both active-low. Take note.

Cursor: Understood.
Relay 1 = GPIO5 | Relay 2 = GPIO6 | Logic: active-low.
Ready when you want to control them.

Me: Turn on all relays

Cursor: Turning on all relays.
✓ GPIO5 low, GPIO6 low — active-low applied.
Relay 1 = ON, Relay 2 = ON.

The relay LEDs light up physically on the HAT.

I2C Scan

Me: Scan the I2C bus and tell me what you find

Cursor: Scanning I2C bus 1...
✓ Device found at 0x77 — BMP280 (temperature and pressure sensor).
Ready to read.

The AI discovers the sensor on its own — no prior knowledge of the address.

Sensor Reading

Me: Read the current temperature and pressure

Cursor: Reading BMP280 @ 0x77, bus 1:

TX: [0xF7] → RX: [0x56, 0x91, 0x20]
📊 Pressure: 961.2 hPa

TX: [0xFA] → RX: [0x83, 0x01, 0x00]
🌡️ Temperature: 25.6°C

The raw I2C bytes are shown alongside the decoded values — the AI reads the registers directly using the MCP I2C transfer tool.

Remote Reboot

Me: Turn off all relays and reboot the device

Cursor: Turning off all relays and rebooting.
✓ GPIO5 high, GPIO6 high — both relays OFF.
Rebooting now — device back online in ~30 seconds.

Yes, it actually reboots.

Why This Matters

The interesting part here isn't just the demo — it's what it represents.

Traditionally, interacting with embedded hardware requires:

Knowledge of GPIO numbering, I2C addresses, register maps
Custom scripts for every operation
SSH access and terminal familiarity With MCP + Orbit OS, the AI handles all of that. You describe what you want in natural language, and the AI translates it into the correct hardware operations via the MCP tools.

The I2C sensor reading is a good example of this. I didn't tell the AI which registers to read, what the raw bytes meant, or how to convert them into temperature and pressure values. I just asked for a reading. The AI knew the BMP280 chip by name, looked up the register map from its own knowledge, transferred the bytes directly via the MCP I2C tool, and converted the raw values — all on its own.

This opens up embedded Linux hardware to a much wider audience — developers who know AI tools but don't have deep embedded experience can now interact with real hardware without the usual friction.

What is Orbit OS?

Orbit OS is a recent open-core platform for embedded Linux and edge devices — inspired by Android's architecture.

One of the core goals behind it is to accelerate embedded hardware development by removing the complexity of deployment, updates, and infrastructure — so developers focus only on their app logic. Just like Android lets you build mobile apps without knowing how the Linux kernel works underneath, Orbit OS lets you build applications and services for embedded Linux without needing any Linux knowledge at all.

It provides:

A lightweight runtime (Gravity RT) that manages app lifecycle, hardware access, and OTA updates
A multi-language SDK (Go, Python, Java, C++) for building apps
An App Store for one-click distribution of .orb packages
Built-in AI inference support (TFLite, ONNX) Community Edition supports Raspberry Pi 3, 4, 5, Zero 2W and Arduino UNO Q.

Beyond these officially listed boards, any ARM Linux device (armv6, armv7, or arm64) can be certified to run Orbit OS — for example, Banana Pi, Orange Pi, BeagleBone, and NVIDIA Jetson boards.

Try It

- 🎬 YouTube — @orbit-os-edge

*Have questions or want to build something on Orbit OS?

Building an Android-like Platform for Embedded Linux Devices — Without Docker

Peter H — Thu, 07 May 2026 21:26:25 +0000

Building an Android-like Platform for Embedded Linux Devices — Without Docker

Every embedded Linux project seems to start the same way:

SSH into the device
Install dependencies
Configure services
Set up OTA updates
Handle networking
Build custom APIs
Repeat everything again for the next project

After rebuilding the same infrastructure multiple times across different edge and IoT projects, we decided to create a platform that abstracts all of that into a unified runtime.

That platform became Orbit OS.

What is Orbit OS?

Orbit OS is an embedded Linux platform designed to bring an Android-like experience to edge devices such as Raspberry Pi systems and other ARM-based hardware.

Instead of using Docker containers, Orbit OS uses a lightweight native runtime called Gravity RT and a custom package format called .orb.

The idea is simple:

Install Orbit OS once, and the device gains:

Remote application deployment
OTA updates
Fleet management
Sandboxed applications
Unified hardware APIs
Built-in Edge AI support (TFLite & ONNX)
Application Store
Real-time remote development tools

Why Not Docker?

Most existing edge platforms are built around containers.

Containers are powerful, but for constrained edge devices they also introduce additional RAM, storage, startup, management overhead, and OTA size.

Orbit OS was designed for environments where devices may only have 128–256MB of RAM available.

Instead of Docker, applications run directly through Gravity RT using lightweight .orb packages (like Android .apk).

This allows:

Lower memory usage
Faster startup
Smaller packages
Native hardware access
Simpler deployment model

Gravity RT Architecture

Gravity RT runs on top of an existing Linux distribution and acts as the system runtime for all applications.

Core architecture:

Hardware
└── Linux
    └── Gravity RT
        ├── Gravity Server (Go)
        ├── gRPC APIs
        ├── UDS communication
        ├── mTLS external APIs
        ├── Lazy-loaded JVM
        ├── Lazy-loaded Python VM
        └── Built-in TFLite and ONNX runtime
            └── Orbit OS Ecosystem
                ├── Unified Multi-language .orb packages
                ├── Orbit Studio
                ├── Orbit OS Store (Certified Aplications)
                └── Orbit OS HW Marketplace* (Certified Hardware Devices)

The Gravity Server is written in Go and remains always active as the parent process for all .orb applications.

It manages:

Application lifecycle
Restart policies
OTA coordination
Security
Logging
Package management

Real-Time Remote Development

One of the most interesting parts of Orbit OS is the development workflow.

Traditional embedded development usually looks like this:

Write code → Compile → Deploy → Run → Debug → Repeat

Orbit OS changes this model completely.

With Orbit Studio (VS Code extension), developers write code locally while executing directly against real hardware in real time.

Laptop
├── Write code locally
├── SDK connects to device via gRPC/mTLS
├── Code runs on live hardware instantly
├── Logs stream back in real time
└── Generate the .orb package only when ready

The device becomes a real-time execution target instead of a deployment target.

No SSH.

No file transfers.

No deployment loop during development.

▶️ Orbit OS — Orbit Studio First App | Real-Time Remote Development, GPIO LED Control & Deploy

The .orb Package Format

Orbit OS applications are distributed as signed .orb packages.

A package contains:

Executable binaries
NV data like AI models
Resources
Manifest
Cryptographic signatures

The structure is intentionally similar to Android APKs.

Built-In Edge AI

TensorFlow Lite and ONNX support are included directly in the platform,
accessible via the AI Manager SDK API.

Applications do not need to bundle inference runtimes or manage dependencies.
Apps only bring the model and the logic — the platform handles the rest.

The AI Manager automatically selects the correct backend based on the model type:

.tflite models → TensorFlow Lite runtime
.onnx models → ONNX runtime

Current AI applications already available in the Store:

YOLOv8 object detection
Face recognition

All inference runs locally on-device. No cloud. No external APIs.

OTA Updates

Orbit OS uses OSTree for runtime updates.

This provides:

Atomic updates
Rollback support
Immutable runtime layers
Safe recovery

The runtime can update itself without rebooting the full Linux system.

Orbit OS Store

Orbit OS includes a centralized application store where developers can publish .orb applications and users can remotely install them across devices linked to their account.

Features currently implemented:

One-click installation
Remote deployment
App updates
OTA runtime updates
Fleet management
Multi-device deployment

Apps Available Today

KS0212 4-Channel Relay Shield — Web UI, Modbus TCP server, MQTT with Home Assistant auto-discovery. One click, zero configuration.
Mochi MQTT Broker — Lightweight MQTT broker with integrated Web UI. Configure ports, users and settings from the browser.
Edge AI — Smart Image Detection — YOLOv8 COCO object detection using TFLite. Runs locally, no cloud, no external APIs.
Edge AI — Face Recognition — Real-time face recognition with any connected camera. Enroll faces in under 10 seconds. 100% offline.
MCP Server — Manage your device with AI Agents.
And more...

App Example — Edge AI Smart Image Detection

Edge AI – Smart Image Detection is an Orbit OS application that performs
real-time object detection locally on edge devices using YOLOv8 TensorFlow
Lite models.

Users can remotely install the application from the Orbit OS Store with a
single click on any device linked to their account.

After being installed in seconds, users can upload images directly from the browser, detect and label objects with bounding boxes, inspect inference timing, and view the raw JSON output generated by the AI service.

The application runs entirely on-device through the Orbit OS AI Manager API using YOLOv8 / COCO TensorFlow Lite models, with no cloud processing, Docker containers, or manual setup required.

This video demonstrates the application running simultaneously on two different devices: a Raspberry Pi 5 vs Arduino UNO Q.
Same App, same Model. Different hardware, different performance.

▶️ Orbit OS — Edge AI Object Detection | YOLOv8 | Raspberry Pi 5 & Arduino UNO Q

Current Status

Currently supported:

Raspberry Pi 3,4,5,Zero 2W
Arduino UNO Q

SDKs:

Go (available)
Java (beta)
Python (beta)
C++ (planned)

Try It

Orbit OS Community Edition and the Go SDK are now available.

We are currently looking for developers interested in:

Embedded Linux
Edge AI
Raspberry Pi
Industrial IoT
Runtime systems
Remote deployment tooling

If you build something with the SDK, we would love to hear about it —
drop a comment or reach out at info@orbit-os.org.

Demo Videos

▶️ https://youtube.com/@orbit-os-edge

DEV Community: Peter H

Turn a PZEM-004T + Raspberry Pi into a Full Energy Monitor — No SSH, No Docker, One Click

Story

Things used in this project

Wiring the PZEM-004T

What PZEM Monitor is, and why I built it

What it does

Live dashboard

History

Home Assistant, zero YAML

Why I built it for Orbit OS instead of Docker

Building it: the development experience

What I learned

Where it stands now

Installing PZEM Monitor

I connected Cursor IDE to a Raspberry Pi via MCP — controlled relays and read an I2C sensor in natural language

What is MCP?

The Setup

Installing the MCP Server

What the AI can do

The Demo

Device Info

System Health

GPIO Enumeration

Relay Control

I2C Scan

Sensor Reading

Remote Reboot

Why This Matters

What is Orbit OS?

Try It

- 🎬 YouTube — @orbit-os-edge

Building an Android-like Platform for Embedded Linux Devices — Without Docker

Building an Android-like Platform for Embedded Linux Devices — Without Docker

What is Orbit OS?

Why Not Docker?

Gravity RT Architecture

Real-Time Remote Development

The .orb Package Format

Built-In Edge AI

OTA Updates

Orbit OS Store

Apps Available Today

App Example — Edge AI Smart Image Detection

Current Status

Try It

Demo Videos

Links