Skip to content

Web Sockets

There are two WebSocket servers:

  • Terminal WebSocket used to stream data to WebUI and exchange internal data

  • Data WebSocket used to exchange data with external clients (not used by WebUI)

use subprotocol webui-v3 and port is web port +1 (e.g: 80+1=>81)

Reserved Messages between WebUI / ESP Format: (label):(message)

  • from ESP to WebUI

    • currentID:(id) Sent when client is connecting, it is the last ID used and become the active ID

    • activeID:(id) Broadcast current active ID, when new client is connecting, client without this is (id) should close, ESP WS Server close all open WS connections but this one also

    • PING:<time left>:<time out> It is a response to PING from client to inform the time left if no activity (see below)

    • ERROR:(code):(message) If an error raise when doing upload, it informs client it must stop uploading because sometimes the http answer is not possible, or cannot cancel the upload, this is a workaround as there is no API in current webserver to cancel active upload

    • NOTIFICATION:(message) Forward the message sent by [ESP600] to webUI toast system

    • SENSOR: (value)[(unit)] (value2)[(unit2)] ... The sensor connected to ESP like DHT22

  • from WebUI to ESP

    • PING:<current cookiesessionID / none > if any, or “none” if none

Reserved

  • from ESP to WebUI stream data from ESP to WebUI

  • from WEBUI to ESP
    [-> File transfer from WebUI to ESP: not implemented yet]

use sub protocol arduino and port is any defined port (e.g: 8282)

This mode is used to transfer all G-code commands and their responses from the printer/CNC.

This mode is used to transfer files to/from the ESP board.

It uses frames of 1024 bytes and can be increased after testing.

The frame format is: 2 bytes: for frame type 2 bytes: for frame size to check some integrity, currently as already part of frame no checksume is used x bytes : extra data according frame type

type: client -> esp Status Request:

SR00

with hexadecimal values:

0x530x5200

Response frame uses an inverted header: Response Status:

RS01A

with hexadecimal values:

0x520x53010x41

The first byte of the response indicates the state:

CodeHexaMeaning
B0x42busy
O0x4Fidle/ok
E0x45error
A0x41abort
D0x44download ongoing
U0x55upload ongoing

Extra data may be added:

error code and string, 1 byte : error code: 0->255 1 byte : string size 0->255 XX bytes for the string:

RSxxC4X....

Upload information: 1 byte : path size 0->255 XX bytes : the path string 1 byte : the filename size 0->255 xx bytes : filename string 4 bytes : total file size 4 bytes : currently processed bytes 4 bytes : last packet id processed

RSxxUX....X....S1S1S1S1S2S2S2S2

Download information: 1 byte : path size 0->255 XX bytes : the path string 1 byte : the filename size 0->255 xx bytes : filename string 4 bytes : total file size 4 bytes : currently processed bytes 4 bytes : last packet id processed

RSxxDX....X....S1S1S1S1S2S2S2S2

Header is:

SU00

The content is: 1 byte : path size 0->255 XX bytes : the path string 1 byte : the filename size 0->255 xx bytes : filename string 4 bytes : total file size

SUxxDX....X....S1S1S1S1

If the answer is:

US01O

It means transfer can start.

Header is:

UPxxIDIDIDID....

4 bytes is packet id XXXX bytes is data

if packet is received the answer is

PU05OIDIDIDID

Header is:

SD00

The content is: 1 byte : path size 0->255 XX bytes : the path string 1 byte : the filename size 0->255 xx bytes : filename string 4 bytes : total file size

SDxxDX....X....S1S1S1S1

If the answer is:

DS01O

It means transfer can start.

Header is:

DPxxIDIDIDID....

4 bytes is packet id XXXX bytes is data

if packet is received the answer is:

PD05OIDIDIDID

Header is:

CM01X

Commands:

CodeHexaMeaning
A0x41abort

Abort command frame:

CM01A