The Fusion Node

The Fusion Node runs on a computer of yours — a workshop PC, a Raspberry Pi, a server in the rack — and connects what a browser cannot: a COM port with nobody at the screen, an MQTT broker on the LAN, a local WebSocket or HTTP service, Bluetooth devices the operating system has paired, Wi-Fi and network state, CPU, memory and temperature.

Discover, connect, run

It lists what the machine can reach — COM3 Arduino Uno, a paired Bluetooth sensor, the wireless adapter — and you choose what belongs in which pool. Then it runs, as a service if you want, and publishes over one outbound connection with a key scoped to that pool.

Local first

Observations go to a local outbox before they go anywhere. If the connection drops, the node keeps collecting and catches the pool up when it returns. A local stream on the machine lets an application on the same LAN read the pool with no cloud in the loop at all.

Where it stands today

The node is built as a single binary per platform on the same lane as LeumasNode, and the publish lane for a new product is a deliberate owner change — so the binaries are not on a download page yet. It runs from the repository today, and this page will carry the downloads the day they ship.

Questions

Can a single binary open a serial port?

A single-file binary cannot load the native serial driver. The node's console verb serves a local page where the browser opens the port; the folder install reads the port directly, headless.

Does it need the fabric?

No. The Fusion Node dials the public API with a pool key. LeumasNode is Studio's agent for running work; this one only publishes readings.