Skip to main content
A device connects to NervesHub over a Phoenix Channels WebSocket and speaks the device protocol. Nothing about that protocol is Elixir-specific, so a client is whatever software on the device speaks it — reporting the firmware it is running, accepting update assignments, and handing the download to whatever writes firmware on that platform. Several clients already exist. Which one you want follows from what the device runs.

​
The options

meta-nerveshub is a packaging layer rather than a separate client. It builds the Rust Linux agent into a Yocto image; the agent is what actually connects.

​
Choosing

Running Nerves? Use NervesHubLink. It is the reference client, the one the protocol is designed against, and the one every other client is measured by. On an ESP32 with AtomVM? Use the AtomVM agent. Be aware that it needs AtomVM built from source rather than a stock build — the WebSocket transport is an ESP-IDF component, so a stock VM cannot reach NervesHub at all. On Linux, but not Nerves? Use the Linux agent. It is a single Rust binary that leaves your application alone in whatever language it is already written in, and shells out to fwup or rauc to write firmware. Building that Linux image with Yocto? Add meta-nerveshub to package the agent, alongside meta-rauc and meta-rust-bin.

​
Writing your own

None of these are privileged. The server has no notion of an official client — it speaks the documented protocol, and anything that speaks it back is a device. If you are targeting a runtime none of the above covers, the Device WebSocket Protocol and WebSocket Channel Events references describe the connection, the join, and every message in both directions. The existing clients are also worth reading as reference implementations, particularly for reconnect behaviour and update progress reporting.