Connection Status

Boards have several simple states:

State	Description
`CONNECTED`	Board is connected to the system.
`DISCONNECTED`	Board is disconnected from the system.
`DEGRADED`	Board is connected, but not operating because something went wrong during boot.
`MAINTENANCE`	Board is connected, but in bootloader. It is pending a firmware update.

This section describes how to move from one to another, depending on Board’s connectivity. This may help you to understand the information returned by the Data Platform.

More than a simple connection status, this status provides the information that the Board is healthy and is capable of running as expected.

This includes network performance, supply stability, Wi-Fi bandwidth…

1. Network Connection (Wi-Fi or Ethernet)

💡 A Board is indicated as CONNECTED as soon as it has published a Hello message to the Centiloc Data Platform.

To reach this state, the Board follows the same basic sequence, regardless of the connection type:

flowchart TD

classDef class_blue stroke:#fff,fill:#190b7e,color:#fff;
classDef class_lightblue stroke:#fff,fill:#a7b3d6,color:#fff;
classDef class_success stroke:#fff,fill:#23e700,color:#190b7e;
classDef class_orange stroke:#fff,fill:#ff781e,color:#fff;
classDef class_red stroke:#fff,fill:#e03131,color:#fff;

%% nodes
test("1. Perform sanity checkup"):::class_blue; 
ntp("2. Connect to NTP Server"):::class_blue; 
network("2. Connect to Network"):::class_blue 
mqtt("3. Connect to MQTT Broker"):::class_blue 
default("2. Fetch default parameters"):::class_blue; 
ntp2("3. Connect to NTP Server"):::class_blue; 
network2("4. Connect to Network (default)"):::class_blue 
mqtt2("5. Connect to MQTT Broker (default)"):::class_blue 
connect("4. Publish (CONNECTED)"):::class_success
degraded("6. Publish (DEGRADED)"):::class_orange
disconnected("DISCONNECTED"):::class_red

test --->|OK|ntp --> network --> mqtt --> connect
test -->|FAIL|default --> ntp2 --> network2 --> mqtt2 --> degraded
ntp -->|FAIL|default
network -->|FAIL|default
mqtt -->|FAIL|default

default -->|FAIL|disconnected
ntp2 -->|FAIL|disconnected
network2 -->|FAIL|disconnected
mqtt2 -->|FAIL|disconnected

1.1. Network connection details

Both Wi-Fi and Ethernet provide access to the Data Platform, with a few differences:

Network type	Requirements	Notes
Wi-Fi	2.4 GHz network, password required.	Password must be configured before deployment.
Ethernet	Physical connection to a switch or router.	DHCP automatically assigns an IP address.

If Ethernet is connected but fails, the Board automatically tries to connect via Wi-Fi (unless Wi-Fi has been disabled when ordering).

1.2. NTP server connection

The Board attemps to connect to UDP port 123 of either:

Standard ntp fr server pools
Host Data Platform (⬅️ important in case on OnPremise disconnected from internet)

1.3. MQTT broker connection

Depending on its configuration, all these steps must be successful to complete MQTT Broker connection:

TCP Plain (mqtt)

The Board connects using User and Password

SSL (mqtts)

v5+ Boards:

The Board attempts to establish SSL handshake
- Check Server certificate validity and signature by Centiloc CA
- Presents its Certificate, signed by Centiloc CA
The Board connects using User and Password

v4- Boards:

The Board attempts to establish SSL handshake
- Check Server certificate validity and signature by Let’s Encrypt CA
The Board connects using User and Password

SSL with Trust Server (mqtts)

v5+ Boards:

The Board attempts to establish SSL handshake
- Skip check of Server certificate validity and signature
- Presents its Certificate, signed by Centiloc CA
The Board connects using User and Password

🚫 v4- Boards: not supported

1.4. Publish “Hello”

Finally, the Board attempts to publish a “Hello” message on a specific topic.

The Board must have the authorization to publish.
The message must be correctly formatted.

1.5. Disconnection

There are some conditions that could make the Board turns to DISCONNECTED status.

1.5.1. Transport Layer disconnection

MQTT manages to check the good connection of its registered clients by standard KeepAlive exchanges.

In case the Board disconnects from MQTT Broker (because of Wi-Fi or ethernet…), and doesn’t answer KeepAlive procedure, the Board will turn into DISCONNECTED status (internally, a LastWill is generated).

🕰 This only happens at the end of the KeepAlive procedure (which includes timeouts and retries), which takes few minutes (up to 4 minutes worse case).

1.5.2. Application Layer disconnection

In addition to this MQTT timeout, the Data Platform checks the connection of Boards which sound inactive.

To do so, it automatically pings every mute Boards at regular period (🕰 approximately 10 minutes).

If a Board doesn’t answer Ping, it will be turned into DISCONNECTED status.

2. Serial Connection

💡 A Board is indicated as CONNECTED as soon as the gateway it is connected to publishs a Hello message to Centiloc Data Platform and the Board answers a Ping.

Indeed, in the schema, the Gateway is responsible of the connection of the Board with the Data Platform which tracks its Board Connection status.

Therefore, the Gateway must first manage its own Connection Status (the same way as a Wi-Fi Board). Then it can transmit Data Platform pings to its connected Boards, on demand of the Data Platform (See Gateway documentation).

In other words, the Connection Status of Serial Board is only updated after Pings, whether they are automatic or generated by users.

3. User Ping

User can check a Board connection by pinging it. The Board doesn’t need to be CONNECTED to send a ping.

If the Board’s status is DISCONNECTED and the Board answers to the ping, its status will be automatically updated to CONNECTED or DEGRADED.
The opposite is the same, if the Board’s status is CONNECTED or DEGRADED and the Board doesn’t answer to the ping, its status will be automatically updated to DISCONNECTED.