Anedya MQTT Endpoints
Anedya provides MQTT Endpoints to which you can connect your devices to submit data in realtime and get realtime messages from the platform.
Endpoints
The devices can connect to following endpoint:
mqtt.<region-code>.anedya.io
The devices can connect through:
| Port | Connecton Method |
|---|---|
| 8883 | TCP Connection |
| 8804 | Websocket Connection |
You can get region codes from here
Version
Anedya supports MQTT v3.1.1 and v5.0 with certain features not available.
Topics
Devices can publish and subscribe to a reserved set of topics. For now devices are not allowed to publish to arbitary topics.
All topics starting from $anedya are reserved for Anedya platform.
Following two topics can be subscribed by devices to get response or errors from the platform.
$anedya/device/{deviceID}/errors
$anedya/device/{deviceID}/response
Devices can perform the actions by publishing to relevant topics given in Device APIs section. In addition to standard request body,
all endpoint support an additional field reqID which is included in response to that request. This ID can be used to corelate request and response
when using MQTT. If no reqID is specified, platform will generate one randomly. The maximum size of reqID is 36 characters. Any extra length will be truncated to first 36 characters and message will be dropped if
total length exceeds 100 characters
Credentials
Devices can get connected using following Credentials:
| Client ID | Device UUID string |
| User | Device UUID string |
| Password | Connection key of the node |
TLS
Anedya platform supports TLS 1.2 and TLS 1.3. We recommend using TLS 1.3 for improved security. Anedya Platform uses Self-Signed certificates, hence it is required to add Anedya Root Certificates to the trusted certificates of you device. You can download certificates from:
- Anedya Root CA 1 (RSA - 2048) (PEM, DER)
- Anedya Root CA 2 (RSA - 4096) (Reserved) (PEM, DER)
- Anedya Root CA 3 (ECC - 256) (PEM, DER)
- Anedya Root CA 4 (ECC - 384) (Reserved) (PEM, DER)
Anedya supports both RSA and ECC certificates. During TLS handshake appropriate certificate is used according to cipher suites specified in client hello information. If supported cipher suites contains both ECC and RSA support, ECC is given priority over RSA. If your device supports only ECC or only RSA, you are required to configure supported cipher suites in your TLS stack configuration, or attempt to connect will result in TLS handshake error.
Limits
There are quotas and limits on account level as well as on device level which you need to consider:
| Actions | Description | Limit | Account/Device |
|---|---|---|---|
| Max connection rate | The rate at which connections can be made by devices. It adjusts dynamically according to the number of nodes registered in your account | 100 Connections/second | Account Level |
| Max connection rate per client ID | The rate at which a device can create connections. Connections made at higher rate will be rejected | 1 Connection/Second | Device level |
| Max unauthorized connection retries | Maximum unauthorized connection retries a device can make before temporarily banned for period of 1 minute | 5 retries/minute | Device level |
| Max messages per second | Maximum rate at which a device can publish messages. Any messages above this rate will be dropped. | 100 Messages/second | Device level |
| Max unauthorized events | Each unauthorized connection attempt, device binding attempt, variable data submission attempt will be considered as 1 event , crossing the rate can result in dropping on further messages on random basis | 50 Events/second (Adjusted for total number of nodes registered) max 500 Events/Second | Account level |
| Max message payload size | Maximum size of MQTT payload | 128 kB | N/A |