DadosCorpCore
DadosCorpCore is a lightweight library for connecting ESP32/Arduino-class MCUs to the DadosCorp cloud platform
DadosCorpCore + W5500 — Bringing a Zero-Network-Dependency HMAC IoT Library to a Wired Link
Project Overview
DadosCorpCore is a lightweight library for connecting ESP32/Arduino-class MCUs to the DadosCorp cloud platform. Its defining trait is a "zero network dependency" design: the library performs no communication of its own. Instead, it provides only two things:
- HMAC-SHA256 authentication header generation — message integrity and sender authentication
- JSON helpers — building telemetry payloads, parsing commands, and assembling ACK bodies
The actual HTTP/HTTPS transport is handled by the developer using their own networking library. It is precisely this structure that lets you swap WiFi for WIZnet's W5500 hardware TCP/IP, delivering an uninterrupted wired IP link even in congested wired/wireless environments.
Note: The examples in the official repository (
Minimo,Basico,ESP32_Completo) are all ESP32 + WiFi based. This article leverages the library's network-agnostic structure to show how to switch the transport medium to a W5500.
Core API — What It Does for You, and What You Do Yourself
| What the library provides | What you implement yourself |
|---|---|
dc.authHeader(body) → "HMAC device_key:nonce:signature" header string | The actual HTTP/HTTPS POST/GET transport |
dc.metadataBody() → device variable/command metadata JSON | Choosing the transport library (WiFi / W5500 Ethernet / LTE, etc.) |
dc.ackBody(cmdId, ok) → command acknowledgment body | Socket, retry, and timeout management |
dc.parseCommand(code, resp) → extracts a command from the server response and invokes your callback | Deciding whether to use TLS |
The DadosCorp service flow is built around the following endpoints:
POST /receive— send telemetryPOST /device/metadata— register variable/command definitionsGET /device/state— sync the last state after a rebootGET /command— poll for server-side commandsPOST /command/ack— confirm command execution
Security Mechanism — HMAC vs TLS
The two technologies operate at different layers and are complementary. Rather than one being a subset of the other, they play different roles.
| Aspect | HMAC-SHA256 (DadosCorpCore) | TLS (HTTPS) |
|---|---|---|
| Function provided | Integrity + sender authentication (no confidentiality) | Confidentiality + integrity + authentication (handshake tunnel) |
| Operating layer | Application level (per-message signature) | Transport level (per-connection encryption) |
| MCU cost | One SHA-256 operation, a few hundred bytes of RAM | Key exchange (ECC/RSA) + AES + session buffers, several KB to tens of KB of RAM |
| Plaintext networks | Provides tamper protection even over plain HTTP | Requires an encrypted channel |
An important fact: the DadosCorpCore ESP32 examples actually layer HMAC on top of HTTPS (TLS). TLS protects the entire communication channel, while HMAC adds an application-level guarantee that "this message truly came from a device holding the secret key." In other words, they are not competitors but a two-layer defense operating at different levels.
Two Operating Modes
- Lightweight mode (HMAC-only): A severely resource-constrained MCU sends plain HTTP with only an HMAC attached, as far as a closed LAN or a local proxy; the proxy then terminates TLS for the internet-facing leg.
- End-to-end mode (HMAC over TLS): An MCU capable of handling TLS (e.g., ESP32) terminates HTTPS directly and adds HMAC on top, securing per-message authentication as well.
Why W5500?
- Hardware TCP/IP offload → the MCU doesn't have to deal with IP fragmentation or retransmission, freeing up that much memory for TLS when needed.
- Wired-link stability → shielded cabling blocks EMI and wireless interference, making it well suited to factory and industrial environments.
- Deterministic latency → less jitter than WiFi, which is advantageous for periodic telemetry.
- Multiple sockets → the W5500's hardware sockets let you design configurations that handle telemetry transmission and command polling concurrently.
W5500 Integration Examples
Option A — ESP32 + W5500 + HTTPS (End-to-end)
The ESP32 Arduino core supports the W5500 as an SPI Ethernet interface. If you swap the WiFi client for an Ethernet-based secure client, the DadosCorpCore calls can stay exactly the same.
#include <ETH.h> // ESP32 + W5500 (SPI)
#include <HTTPClient.h>
#include <DadosCorpCore.h>
DadosCorpCore dc("DEVICE_KEY", "SECRET_KEY");
void sendTelemetry() {
String body = "{\"temp\":23.5}";
String auth = dc.authHeader(body); // ← the library's core: generate the auth header
HTTPClient http;
http.begin("https://dadoscorp.com.br/receive?fmt=json"); // over the W5500 wired link
http.addHeader("Authorization", auth);
http.addHeader("Content-Type", "application/json");
int code = http.POST(body);
String resp = http.getString();
http.end();
dc.parseCommand(code, resp);
}
The SPI pins, CS, and INT settings for
ETH.begin()must be configured to match your board. (Illustrative example.)
Option B — Constrained MCU + W5500 + Plain HTTP + HMAC (Lightweight)
In environments with established physical security, such as a closed industrial LAN, you can skip TLS and rely on HMAC alone for tamper protection, dramatically reducing power, memory, and code footprint. You build the POST directly with the standard Ethernet library and EthernetClient, placing the value produced by authHeader() in the Authorization header.
#include <SPI.h>
#include <Ethernet.h> // standard WIZnet Ethernet library
#include <DadosCorpCore.h>
DadosCorpCore dc("DEVICE_KEY", "SECRET_KEY");
EthernetClient client;
void sendTelemetry() {
String body = "{\"temp\":23.5}";
String auth = dc.authHeader(body); // prevents tampering/forgery even over plaintext
if (client.connect("192.168.0.10", 80)) { // on-premise proxy/server
client.println("POST /receive?fmt=json HTTP/1.1");
client.println("Host: 192.168.0.10");
client.println("Authorization: " + auth);
client.println("Content-Type: application/json");
client.print("Content-Length: "); client.println(body.length());
client.println();
client.print(body);
}
// after receiving the response, call client.stop();
}
Where Lightweight HMAC-Only Security Shines
| Application scenario | Why |
|---|---|
| In-factory sensor LAN | The network is already closed with physical security in place → less need for encryption; HMAC alone prevents tampering |
| Battery-powered long-range loggers | Saving TLS-handshake power matters; HMAC is a single SHA-256 pass, minimizing current draw |
| Low-cost 8-bit education kits | Full TLS is effectively impossible on 32 KB Flash / 2 KB RAM; HMAC fits in a few KB of code |
| Field sites with a local proxy (e.g., a Raspberry Pi) | The MCU↔Pi leg runs over plaintext LAN while the Pi terminates TLS toward the internet → lower deployment cost |
Considerations When Measuring Performance
This article deliberately omits unverified figures. When you actually deploy a W5500 + DadosCorpCore configuration, we recommend measuring the following yourself.
- TLS handshake time (per cipher suite)
- RTT per telemetry message
- Long-run (e.g., 30-day) packet loss rate
- MCU RAM usage including TLS session and buffers
- Power-consumption difference versus HMAC-only mode
Lessons Learned
- Once IP/TCP is offloaded to the W5500 silicon, the freed-up MCU resources widen the room to host a TLS library.
- Because the library carries no networking layer of its own — a "network-agnostic" design — you can swap the transport medium (WiFi ↔ W5500 Ethernet) without changing application logic.
- HMAC-only mode is a practical choice for conserving power and memory on closed-network, ultra-low-power devices.
Future Improvements
- MQTT over Ethernet (W5500 sockets + a lightweight MQTT client)
- PoE power integration (W5500 + PoE module)
- A porting guide for
_hmacSha256()on other MCU platforms (AVR/STM32/RP2040, etc.)
Documents
| Name | Link | Comment |
|---|---|---|
| Main Code | GitHub Repository | examples/Minimo, ESP32_Completo (WiFi based) |
| API Docs | DadosCorp documentation | Cloud dashboard and HMAC specification |
| Circuit Diagram | (to be added) | W5500 SPI wiring, RJ45 MagJack |
In summary: DadosCorpCore is a "network-agnostic" HMAC+JSON library that does no communication itself. That structure lets you readily swap the ESP32 WiFi examples for a WIZnet W5500 wired link, and depending on the environment you can choose HMAC over TLS (full security) or HMAC-only over plain HTTP (ultra-lightweight) — yielding a flexible IoT reference that spans everything from closed networks to low-power devices.
Q&A: DadosCorpCore + W5500
Q1. What is DadosCorpCore?
DadosCorpCore is a lightweight Arduino/ESP32 library for connecting microcontroller-based devices to the DadosCorp cloud platform. It provides HMAC-SHA256 authentication and JSON helper functions, but it does not include its own networking stack.
Q2. What is the main idea of this project?
The main idea of this project is to use the network-agnostic design of DadosCorpCore and apply it to a wired Ethernet environment using the WIZnet W5500. Since DadosCorpCore does not depend on Wi-Fi or any specific network library, the communication layer can be replaced with W5500-based Ethernet.
Q3. Why is DadosCorpCore described as “zero network dependency”?
DadosCorpCore is described as “zero network dependency” because it does not perform HTTP, HTTPS, Wi-Fi, Ethernet, or socket communication by itself. Instead, it only generates authentication headers and JSON payloads. The developer is responsible for choosing and implementing the actual transport layer.
Q4. What does DadosCorpCore provide to developers?
DadosCorpCore provides helper functions such as HMAC-SHA256 authentication header generation, metadata JSON creation, command ACK body generation, and command parsing from server responses. These functions help simplify the application layer of an IoT device.
