Docs

Protocol Specification

Binary transport reference for the device-side protocol used by Plynx.

Message structure

Every message starts with a fixed 5-byte header, followed by a body where fields are separated by 0x00.

protocol.h
struct BlynkHeader {  uint8_t  command;  uint16_t msg_id;  uint16_t length;};
  • Byte 0: command code.
  • Bytes 1..2: big-endian message id.
  • Bytes 3..4: big-endian body length.

Typical command flow

  1. Board or app opens TCP/SSL connection.
  2. Client sends login/auth packet.
  3. Server responds with status code.
  4. Hardware and app exchange HARDWARE, APP_SYNC, widget property and ping packets.

Command examples

login.hex
02 00 01 00 20 59 6F 75 72 41 7574 68 54 6F 6B 65 6E 48 65 72 6530 31 32 33 34 35 36 37 38 39 4142 43 44 45 46
hardware-write.hex
14 00 02 00 0A 76 77 00 30 00 31

Core facts

Command header is always 5 bytes.

Body fields are null-separated.

The same route supports both app traffic and board traffic.

Response codes

  • 200 — OK
  • 2 — ILLEGAL_COMMAND
  • 5 — NOT_AUTHENTICATED
  • 9 — INVALID_TOKEN
  • 11 — DEVICE_NOT_IN_NETWORK
  • 13 — NO_ACTIVE_DASHBOARD

Packet path

App tap → PlynxConnector actor → 5-byte header + null-separated body → TCP/SSL socket → server → device BLYNK_WRITE() callback. Echo returns on the same socket for app sync.

Where to inspect implementation

  • PlynxConnector/Protocol/CommandCode.swift
  • PlynxConnector/Protocol/ResponseCode.swift
  • PlynxConnector/Events/Event.swift

MCP usage

If you want AI tooling to explain packets or generate firmware, use the MCP snippets from the right rail and wire credentials later in the web dashboard.