Wiznet makers

lawrence

Published June 07, 2026 ©

155 UCC

9 WCC

33 VAR

0 Contests

0 Followers

0 Following

Original Link

DadosCorpCore

DadosCorpCore is a lightweight library for connecting ESP32/Arduino-class MCUs to the DadosCorp cloud platform

COMPONENTS
PROJECT DESCRIPTION

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:

  1. HMAC-SHA256 authentication header generation — message integrity and sender authentication
  2. 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 providesWhat you implement yourself
dc.authHeader(body)"HMAC device_key:nonce:signature" header stringThe actual HTTP/HTTPS POST/GET transport
dc.metadataBody() → device variable/command metadata JSONChoosing the transport library (WiFi / W5500 Ethernet / LTE, etc.)
dc.ackBody(cmdId, ok) → command acknowledgment bodySocket, retry, and timeout management
dc.parseCommand(code, resp) → extracts a command from the server response and invokes your callbackDeciding whether to use TLS

The DadosCorp service flow is built around the following endpoints:

  • POST /receive — send telemetry
  • POST /device/metadata — register variable/command definitions
  • GET /device/state — sync the last state after a reboot
  • GET /command — poll for server-side commands
  • POST /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.

AspectHMAC-SHA256 (DadosCorpCore)TLS (HTTPS)
Function providedIntegrity + sender authentication (no confidentiality)Confidentiality + integrity + authentication (handshake tunnel)
Operating layerApplication level (per-message signature)Transport level (per-connection encryption)
MCU costOne SHA-256 operation, a few hundred bytes of RAMKey exchange (ECC/RSA) + AES + session buffers, several KB to tens of KB of RAM
Plaintext networksProvides tamper protection even over plain HTTPRequires 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 scenarioWhy
In-factory sensor LANThe network is already closed with physical security in place → less need for encryption; HMAC alone prevents tampering
Battery-powered long-range loggersSaving TLS-handshake power matters; HMAC is a single SHA-256 pass, minimizing current draw
Low-cost 8-bit education kitsFull 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

NameLinkComment
Main CodeGitHub Repositoryexamples/Minimo, ESP32_Completo (WiFi based)
API DocsDadosCorp documentationCloud 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.

Documents
Comments Write