u/Commercial_Designer5

I've been building an open-source alternative to the usual vendor HMI software, mainly for machine builders who put a Linux-based panel on their equipment.

You design the screens on your laptop, either drag-and-drop or by describing the screen in plain English and letting an AI model do the first layout. You get gauges, value tiles, trend charts, alarm tables, buttons and so on. Then you push it to the panel over SSH with one click. There's no runtime license and no per-tag pricing.

What matters for plant use:

• Alarms: priorities 1 to 4, latching until acknowledged, on-delay, deadband, shelving, and an alarm journal on the panel.
• History: tags you choose are logged to SQLite on the panel, trend charts fill from it, and you can pull a CSV off the panel.
• I/O: a separate daemon handles GPIO, analog inputs, serial and Modbus. On shutdown it drives outputs to configured safe states. The screens never talk to hardware directly, only to tags.
• Operator input: a range-checked numeric keypad, an on-screen keyboard, confirm dialogs on buttons, a "No connection to controller" banner, and screen dimming after inactivity.
• Safe deploys: if a new screen version doesn't come up within 25 seconds, the panel goes back to the previous one by itself. You can't leave a machine with a dead display from a remote update.
• Testing without the machine: every tag can be driven with simulated signals, so you can check alarms and interlocks on screen before the panel is even wired.

On the panel it's a small C program built on LVGL, drawing directly to the display. It runs on 64-bit ARM Linux boards, and I've been running it on a Toradex i.MX8M Plus with a 10" panel.

What it doesn't do yet: no OPC UA, EtherNet/IP or Profinet. Right now it's Modbus and direct I/O. It's early, MIT licensed and free.

I'd really like to hear from people who build HMIs day to day. What would it need before you'd consider it over what you use now? And which protocols should come first?

2 min video: https://youtu.be/h-ITQebSflg
Repo: https://github.com/Hitheshkaranth/EmbeddedDisplayStudio

https://preview.redd.it/e3hy1k5ctvth1.png?width=1600&format=png&auto=webp&s=901d76b0cd87e8d810898b603cb5c459ee3ef11e

I've had this box in production for a week as the shared LLM server for our team, and figured this sub would appreciate the ops side more than the benchmark side.

The box

• DGX Spark (GB10, 128GB unified memory), Ubuntu 24.04
• Serving Ornith-1.5-35B-A3B (NVFP4, 35B MoE with 3B active) on vLLM 0.24 in Docker
• 20 concurrent sequences, 262K context each, MTP speculative decoding

Performance

• 490 tok/s aggregate at 20 users, about 25 tok/s per user
• 79 tok/s single user
• Throughput drops past 20 users because of queuing, so that's the configured cap

Service layout

Port	Service
8004	vLLM (localhost + docker bridge only)
8080	metering gateway, the only client entry point
3000	Open WebUI
3001	Grafana
9090	Prometheus
9400 / 9100	DCGM exporter / node exporter

Old model containers (Qwen3.6, Qwen3.8) stay on the box stopped, for rollback. Swapping models means flipping restart policies and starting the other container. The gateway polls /v1/models on each backend and routes by model name, so clients don't need any changes.

Gateway
This is the piece I'd recommend to anyone running a shared box. vLLM requires an upstream key and isn't reachable from the LAN. Every client hits the gateway, which:

• Issues per-user and per-device keys (one key per tailnet device, generated from a script)
• Counts input tokens exactly using vLLM's /tokenize, and output tokens as they stream
• Exposes per-user and per-device metrics to Prometheus
• Fires a Grafana alert if traffic shows up on vLLM that didn't come through the gateway

Open WebUI forwards the user's email, so web users get attributed individually too, not as one blob. Remote access goes over Tailscale with ACLs. Nothing is exposed publicly.

Reliability notes

• --restart unless-stopped goes on the active model container only. If two 0.70-utilization containers both come up after a reboot, the second one OOMs.
• GPU memory utilization is capped at 0.70. On unified memory, going higher made concurrency collapse under load.
• Cold start to ready is about 5 minutes (weights, MTP drafter, vision tower, compile), so plan maintenance windows around that.
• Gotcha: if prometheus.yml is bind-mounted as a single file and you edit it with sed -i, a SIGHUP won't pick it up. You need to restart the container.

Clients
OpenCode for coding and Open WebUI for chat and PDFs, with RAG embeddings running locally. Everything stays on-prem.

The whole stack is open source: run scripts, gateway, Prometheus scrape config, Grafana dashboard, bypass alert, and benchmarks with raw data.

https://github.com/Hitheshkaranth/Ornith-1.5_A3B_Model_DGX_Spark_Setup

Questions welcome. I'm also interested in how others handle per-user accounting and model hot-swapping on a single-GPU box. Right now my swap is a few docker commands and about 5 minutes of downtime, and I'd love to get that lower.

https://preview.redd.it/vb2ll02hjrth1.png?width=2160&format=png&auto=webp&s=8608d6ec2f12b18329dcaaad2f32eef6421197e4

Every embedded Linux panel project I've worked on ends up in the same place. The UI and the hardware access grow into one binary, so the app can't run anywhere except on the board. Changing a label means rebuilding the image, or scp'ing files by hand and hoping. And when a deploy goes wrong at a customer site, the machine sits there with a black screen.

https://preview.redd.it/6blw6rybccnh1.jpg?width=1600&format=pjpg&auto=webp&s=a5ccc9dc37423635acf9c78a17d6ab6179238ba8

So I built the thing I kept wishing existed. MIT licensed: https://github.com/Hitheshkaranth/EmbeddedDisplayStudio

The idea

Ship the panel image once. After that, anyone — your app team, your customer's app team — drops a Qt/QML application onto it over SSH. No rebuild, no reflash, no hardware code in the app.

Three layers that don't know about each other:

Layer	Owns	Knows nothing about
hmi-hwd	GPIO, ADC, UART, safe states	pixels
hmi-gui	QML, tag bindings, the customer bundle	hardware
deployment	atomic install, health check, rollback	either of the above

The app binds to tags (ai.pot, di.estop, do.relay1) that arrive as JSON over UDP on loopback. That's the whole contract. It's why the same bundle runs on your laptop, in the preview, and on the panel without a single #ifdef.

The deploy pipeline

This is the part I'd defend in a design review:

• Nothing is converted. No build, no freezing, no cross-compilation. The panel carries a complete CPython and the Qt binding the manifest asks for, so your sources run there as-is.
• The dependency check reads your code, not a list. Every packaged file is parsed, imports reduced to top-level names, stdlib and guarded imports removed. What's left, the panel is asked to actually import — because a wheel built for the wrong architecture sits on disk and still kills you at startup.
• The swap can't leave the panel dark. current is promoted with rename(2), never rm then ln. If the new release doesn't signal readiness in 25 s, the symlink swaps back and the previous release restarts. The deploy fails; the machine still has a UI.
• Validation runs twice from one implementation. Host CLI, target installer and desktop tool all call the same schema/manifest.py. They used to be three implementations that had drifted in both directions — a bundle that passes on a laptop and gets refused on the panel is worse than one that fails everywhere.

A successful deploy also becomes the boot default automatically. Nothing to enable by hand afterwards.

https://preview.redd.it/bmt2dsybccnh1.png?width=1919&format=png&auto=webp&s=26d3d5e5bbab1027cb20085bee50446bbeef1f17

The desktop Studio

A Windows exe with its own Python and PySide6 baked in, so it previews a customer's app on a machine with no Python installed.

• Live preview inside a panel bezel, at the panel's real geometry. Not a screenshot — a real QML engine with the same tag engine the device runs. On connect it reads the SOM's DRM connector and adopts the actual pixel size, so nobody lays out widgets against a screen that isn't plugged in.
• Qt Widgets apps preview too. A runtime: python bundle owns its own window, so it's run unmodified in a child process, forced to target resolution, frames streamed into the bezel, window kept unmapped with WA_DontShowOnScreen.
• Qt5 and Qt6 on the same panel. PySide2 bundles get a second interpreter at /opt/hmi-python-qt5 shipping its own Qt 5.15 — because the panel's Qt5 is a GLES build and every aarch64 PySide2 binary is compiled against desktop GL. Loading one against the other dies with undefined symbol: _ZTI18QOpenGLTimeMonitor. Ask me how I know.
• Tag Lab drives the app with sine/square/ramp/noise per tag, so you can exercise panel behaviour before the I/O it binds to exists.
• Panel Logs follows the journal from both services — which is where the fault that shows up an hour after a successful deploy actually lives.
• A visual designer, if you'd rather drag widgets than write QML. Same window previews, generates and deploys what you drew, so the design and the bundle can't disagree.

Already have a Qt app?

Point the Studio at the folder. It finds the entry point, detects the Qt binding from the sources, and writes the manifest for you. Two files is a valid bundle:

{ "schema": 1, "name": "line-controller", "version": "1.4.0", "entry": "main.qml" }

Try it with no hardware

The daemon simulates its I/O, so the whole stack runs on a desktop:

python -m pip install PySide6
python daemon/hmi_hwd.py --config daemon/hwd.json --sim
python gui/hmi_loader/main.py --apps-dir apps/demo-app --windowed
python main.py

https://preview.redd.it/c6gkhsybccnh1.png?width=1918&format=png&auto=webp&s=98fabf86d2826a2a070945c8b56c1d73ff76c848

Honest limitations

• 309 tests, but the installer and cross-validator suites need flock, so on Windows they skip — CI runs the full suite on Linux and fails if anything skips, because a skip is not a pass.
• The designer is v1: .edsui → QML generation only. It doesn't import or round-trip arbitrary QML, and threshold metadata is stored in bindings but not yet turned into visual state expressions.
• The packaged Studio is Windows-only right now. It runs from source anywhere.
• The Qt5 runtime isn't installed by default; it's one script per panel.
• Provisioning is the sharp edge. A base vendor image can ship python3-core alone — no json, no socket, no ctypes — which stops the installer before it starts. provision_panel.py --check surveys the board and names what's missing.

What I'd like feedback on

• If you ship panels commercially: is "one image, many customer apps" how you'd actually want to work, or does your certification story make field-deployable app bundles a non-starter?
• Is 25 s the right health-check window? It's generous for QML and tight for a heavy Widgets app with a slow first paint.
• UDP-on-loopback for tags — anyone want to argue for a Unix domain socket instead? I went with UDP so anything can speak it, but I'm open.

https://preview.redd.it/b8a3c32kdlih1.png?width=1536&format=png&auto=webp&s=161d065cebe771ba3826ea510f79de0ff4a71990

Following up on my previous work with OpenTerminalUI and OpenTokenMonitor, I am shifting focus to the embedded and hardware space. Built specifically for the Claude Community Events @ Impact Lab, NETRA is an ESP32-C6 spatial-sensing firmware designed for a wearable safety system.

https://preview.redd.it/r5k3x8hudlih1.png?width=1919&format=png&auto=webp&s=6a72c786f1e850a3aa77e20010516c63fb95217d

As an Engineering Manager, I value robust, clean architecture, and this project was a great opportunity to build a highly responsive sensor node from the ground up.

Under the Hood:

• Hardware Stack: Powered by a PCBCupid Glyph C6 (ESP32-C6), integrating an HC-SR04 for ultrasonic obstacle ranging (2–400 cm) and an MPU6050 for 6-axis motion telemetry. MD
• Wearer Movement Tracking: Continuously captures the wearer's 3-axis acceleration and rotation to monitor live movement state, posture, and orientation. MD
• Data Pipeline: Streams high-speed telemetry as a clean CSV over USB serial. MD
• Digital Twin Integration: The data pipes directly into a companion PySide6 3D debugger to animate the user's motion inside a closed or indoor tracking environment. MD
• Mechanical Build: The repository includes complete 3D-printable STL files for the enclosure and wearable belt system, plus an interactive assembly viewer. MD

Whether you are interested in embedded C++, IoT wearables, or real-time spatial visualization, check out the repository. It includes full wiring diagrams, code, and mechanical guides!

https://github.com/Hitheshkaranth/Netra_Device_Firmware_V1.git

https://github.com/Hitheshkaranth/Netra_System_Debugger_V1.git

#ESP32 #EmbeddedSystems #OpenSource #WearableTech #IoT #Hardware #Engineering #Cplusplus

Built an open-source project called OpenTerminalUI — a terminal-inspired trading and market research workstation for NSE/BSE + US markets.

https://preview.redd.it/sijmazhm6q1h1.png?width=972&format=png&auto=webp&s=1ee3fb3914506a5562949bf33f1774ffadf108aa

GitHub: OpenTerminalUI GitHub Repo
Live Landing Page: OpenTerminalUI Demo Site

The idea started from frustration with fragmented tooling, expensive subscriptions, and dashboards that try to look modern but slow down serious workflows.

So I started building a keyboard-first, locally hosted, Bloomberg-inspired terminal experience focused on:
• Multi-chart workstation
• Quant/AST-based screeners
• F&O analytics
• Portfolio + risk tooling
• Backtesting workflows
• Command palette / GO bar navigation
• Model lab + stress testing
• Mock-data support for offline/local development
• Docker-first deployment

Tech stack:
• FastAPI + Python backend
• React + TypeScript frontend
• Dockerized setup
• Playwright + automated testing

One interesting part of this build:
A significant portion of the development workflow was AI-assisted using orchestrated multi-agent prompting across Claude Code, Codex CLI, and Gemini CLI running in parallel task flows. AI was extremely useful for scaffolding, repetitive implementation, and refactors — but still struggled heavily with domain-specific trading logic, real-time data flows, derivatives workflows, and edge-case reasoning.

https://preview.redd.it/xp79qdiu6q1h1.png?width=3360&format=png&auto=webp&s=192f8472c3b7feca561e7a199695024d437bd848

That balance between “AI-generated velocity” and “human-engineered architecture” became one of the most interesting parts of the project.

This is still actively evolving, and I’d genuinely love:
• Feedback on UX/workflows
• Criticism from traders or engineers
• Ideas for terminal workflows
• Contributors interested in frontend/backend/quant infra
• Collaboration around open financial tooling

https://preview.redd.it/rcrzn56v6q1h1.png?width=3232&format=png&auto=webp&s=e2b65813c4217bbe5f0a051f5080eb6f27cf90af

If you try it out, I’d be really happy to hear what feels useful, broken, overengineered, missing, or worth improving.

Would also love to collaborate with people interested in:
• Open-source fintech infra
• AI-assisted software engineering
• Trading systems
• Quant tooling
• Terminal-style UI/UX
• Self-hosted platforms

Feedback, PRs, architectural discussions, and harsh critiques are all welcome.