Hardware Checklist
Anedya is flexible and can support almost any type of IoT hardware. But there are some points, and keeping them in consideration can make your IoT journey smooth when using Anedya
Device Identity
Each device should have a unique Identity that can be used to refer to that device later on. In Anedya, it is a mandatory condition to have a 128-bit UUID as a unique ID of the device. The UUID must comply with RFC 4122. This condition is kept to standardize the way devices are identified and still provide collision-resistant IDs to all devices.
For enhanced security, we recommend storing the physical device ID in One-Time Programmable memory or unique identification chips. It's important to note that the device identity should be fixed for the entire lifespan of the device and should be discarded and never used again upon decommissioning of the device.
We strongly recommend using UUIDs as unique device identities, But what if your organization does not use UUIDs as a unique identifier for devices? No problem! We suggest registering IDs generated through UUIDv5. This provides a reproducible way to generate UUID from existing IDs and a namespace.
Let's assume that you use serial numbers (Numeric or Alphanumeric) as unique IDs for your devices, like XXXX0001, XXXX0002, and so on. First, a random UUIDv4 is chosen as an organization or division-wide namespace which is hardcoded in the firmware of all devices. That namespace and serial number of the device are then used as inputs to generate Version 5 UUID. You can register this ID with Anedya. Consider the following example:
Namespace UUID (Fixed for all devices): 71dbc335-b93a-40f7-9c52-5ae550abc272
Device Serial No: ABC000123
Unique Version 5 UUID of Device: fb72dd64-c85e-56f7-8303-d99f42d38f75
In this way, you don't need to change your existing ID system and you can still register your devices with Anedya using generated Version-5 UUID
Server Certificates
When your device or other client attempts to connect to the Anedya Platform, our server will send an X.509 certificate that your device uses to authenticate the server. This certificate then can be used by your device to validate that the device is connecting to an authentic Anedya server and not any other spoofed server. Authentication takes place at the TLS layer through validation of the X.509 certificate chain. This is the same method used by your browser when visiting an HTTPS URL
Anedya Platform uses SSL/TLS for all device-facing endpoints and does not allow insecure connections. Make sure that your hardware supports the SSL/TLS stack. If your hardware is utilizing Microcontrollers with restricted memory and computational power, it might not be possible to include a large number of Root CA certificates used for server validation.
Anedya uses self-signed Root certificates for all device-facing services. Our endpoints support both ECC and RSA Certificates. Please install relevant root CAs on your devices.
- 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)
We recommend:
- Install both RSA and ECC Root certificates
- If it is not possible to store all certificates, depending on your hardware capability you can omit RSA or ECC Certificates
- Explicitly add Anedya CA certificates to your devices' trusted Certificates
As CA certificates have finite validity, they can expire and verification of expired certificates will fail. There can be a situation where CA certificates need to be updated or rotated. We strongly recommend keeping the provision of updating the CA certificate remotely in deployed devices to ensure uninterrupted connectivity with the Anedya platform
All Anedya SDKs, depending on the hardware platform, bundle Anedya Root CA certificates by default. Check the SDK documentation for more details.
Protocol
The choice of protocol to connect your devices impacts a lot. Understanding the pros and cons of each protocol can improve the performance of your end devices. Anedya provides MQTT over TCP as well as WS and also provides HTTPS endpoints for connection. Each method comes with a set of advantages and limitations. Anedya uses TLS v1.2 and v1.3 for encryption, hence it is required to support either TLS v1.2 or v1.3 in your device. Other factors to consider are the frequency of data submission, feature requirements, power-saving requirements and communication overhead
MQTT
MQTT protocol is a very lightweight and widely adopted protocol for IoT devices. Anedya supports MQTT v3.1.1 and MQTT v5 with certain limitations. If your devices will be submitting data at a high frequency, say every second or every 5 seconds then it is recommended to use MQTT endpoints, which can result in a reduction of communication overhead added by frequent TLS handshaking compared to HTTPS. This also means that your device can receive updates from the Anedya platform with minimal latency without polling the server.
The drawback of using MQTT is the power consumption. Depending on the hardware, it might not be possible to put processors in power-saving mode without dropping the MQTT connection. Refer to your hardware datasheet for more details. Opening MQTT connections frequently just to publish data may result in increased power consumption instead! Consider HTTPS if power saving is important, where you can put your device in a deep power-saving state after submitting the data and periodically waking up to submit data.
MQTT Connections are also not suitable when a device is operating in poor network conditions, where a connection might get closed unexpectedly and can result in frequent reconnections. Consider using HTTPS for such scenarios.
HTTPS
HTTPS is the de-facto standard of the internet and is used by all websites including this one. As based on TCP/IP, HTTPS provides robust error-free transmission of messages. You can submit the data using Anedya's HTTPS endpoints. Consider using HTTPS if:
- Data submission frequency is low
- Realtime update from the platform is not required
- Devices have power constraints
HTTPS might not be suitable when data submission frequency is high, as it can result in a lot of overhead due to frequent TLS handshakes. This method is also not suitable if real-time messages from your application are critical and must be delivered with minimal latency.
Certain Anedya features are available in the MQTT protocol only and may not be available in HTTPS.
Time
Timekeeping and measurement is a very important aspect of any IoT Application. Carefully plan how your IoT Device will synchronize time depending on the capabilities of your hardware. If your hardware has a battery-backed RTC that can perform timekeeping when power is not available, it is not required to synchronize the time with internet time that frequently, but it is recommended that time should be synchronized at least once every 24 hours.
If your device doesn't have any timekeeping mechanism for power failure, it is advisable to perform time sync on every bootup, and after successful time synchronization only, the device resumes routine operation.
Anedya provides two ways to synchronize time for your device. You can use the Anedya Time Service(ATS) NTP endpoint time.anedya.io for accurate time information.
A simple approach is also available at the expense of accuracy of a couple of tens of milliseconds. A time API is provided. Refer to Device APIs for more details.
Time Format
Anedya enables you to submit IoT data at a resolution of 1 second. In all device-facing APIs, the time is accepted in the Unix millisecond epoch. Millisecond level epoch is used considering the future possibility of supporting sub-second resolutions. Anedya expects time in UTC. Ideally, your device should:
- Measure the time in the Local Time zone if RTC is kept in local time.
- Convert the time to UTC by applying a suitable timezone conversion
- Calculate the Unix epoch for the UTC
We recommend using UTC in devices and implementing time zone conversions in your Application or dashboard. It will ensure the widest compatibility and will provide flexibility to process data in multiple timezones.