Blau Project - ESPNOW based

[CasamaMaker]

Hi Tasmota community 👋

I built a small ESP32 firmware called Blau focused on lighting control (buttons + loads), with ESP-NOW priority instead of MQTT. Just wanted to share it here in case it's interesting to anyone.

---

What it is

Blau is two complementary firmwares:

• BlauClick — battery-powered ESP32-C3 button (~1 year battery life, no wiring needed)
• BlauLux — ESP32-C3 load controller (relay, PWM, AC phase dimmer, NeoPixel/WS2812)

They communicate via ESP-NOW at the MAC layer — no router, no broker, <10 ms latency. One BlauLux can handle up to 8 BlauClick buttons simultaneously.

---

The key design philosophy

Tasmota is MQTT-first — great ecosystem, great integrations. Blau takes the opposite priority: the button-to-light link must work independently of any router or server. MQTT (and Home Assistant auto-discovery) are implemented as a second optional layer, but the core function never depends on network infrastructure.

This is especially relevant for lighting — the light switch should always work, even when the router is rebooting or the broker is down.

The wire protocol is a custom binary format called BlauProtocol (10 bytes, CRC-8, sequence-based deduplication) — designed to be minimal and fast over ESP-NOW.

---

What it supports today:

• Load types: On/Off, PWM, AC phase dimmer (ZCD + triac), NeoPixel
• Multi-platform: ESP32-C3, ESP32, S3, S2, C6
• Web captive portal for configuration (no app needed)
• MQTT + HA auto-discovery when WiFi is available
• Up to 4 targets per button, 8 buttons per load

---

Not proposing any integration or merge — just sharing in case it sparks interest or inspires something. Happy to discuss the design choices if anyone's curious!

GitHub

• BlauClick — the button firmware
• BlauLux — the load controller firmware

---

Some pictures

BlauClick board

BlauClick captive portal

BlauLux captive portal

[s-hadinger]

Thanks for sharing. It looks neat and simple.
However, the lack of any authentication nor encryption sounds like a decent risk to have devices open to the wild. Maybe for a lamp it is acceptable, but not beyond. Or did I miss something?
With ESP32x, there is plenty of room to add a layer of moderately secure authentication. Any possibility on your side?

[CasamaMaker]

Thanks for the valuable feedback — you are absolutely right, and we have been researching how to address it properly.

Our intention for the next version is to implement BlauProtocol v2 using AES-128-GCM with a password-derived key (PBKDF2). Here is the outline we are considering:

Key derivation: The user sets the same password on both the transmitter (BlauClick) and the receiver (BlauLux) during initial setup. Both devices independently derive a 16-byte AES key using PBKDF2-HMAC-SHA256 (salt: "BlauProtocol", 1000 iterations). The password is never stored or transmitted — only the derived key, saved to NVS.

Per-packet encryption: Each packet is encrypted with AES-128-GCM. A monotonic 32-bit nonce (persisted in NVS) is included in the packet and incremented on every send. The receiver rejects any packet whose nonce is not strictly greater than the last accepted one.

New payload (20 bytes, well within ESP-NOW's 250-byte limit):

[0]    version (0x02, in clear — allows v1 receivers to detect incompatibility)
[1–8]  AES-128-GCM ciphertext (the original 8 payload bytes, encrypted)
[9–12] nonce (uint32, monotonic counter)
[13–20] GCM authentication tag (8 bytes, truncated)

This is still at the design stage — I have not yet worked out all the implementation details for the next release. But the goal is to cover the three attack vectors you mentioned: sniffing (payload encrypted), replay (monotonic nonce), and forgery (GCM tag authenticates without transmitting the key). The ESP32 has hardware AES acceleration, so there should be no meaningful latency or power impact per packet.

The intended user experience stays simple: enter the same password on both devices once during setup, and everything else is automatic.

Does this approach seem correct to you? Any obvious pitfalls or suggestions before we move forward with the implementation?

[s-hadinger]

You may want to look at how Matter Counters work, here is a very high level summary: https://github.com/arendst/Tasmota/blob/development/lib/libesp32/berry_matter/specs_for_ai/MATTER_1.4.1_CORE_SPEC_COMPACT.md#46-message-counters

And the implementation in Tasmota: https://github.com/arendst/Tasmota/blob/development/lib/libesp32/berry_matter/src/be_matter_counter.cpp

The problem with nonce monotonic counter is that the device needs to save to flash after each received message, which can wear out very quickly the flash if the devices is specifically attacked.

[CasamaMaker]

Thanks for pointing that out — you are absolutely right. The naive approach of writing to NVS on every received packet is a real vulnerability: at 1,000 packets/s an attacker can exhaust the ESP32 flash in roughly 100 seconds.

---

What Matter (Tasmota) actually does

Looking at be_matter_counter.cpp, Matter keeps replay protection entirely in RAM using a 32-bit sliding window bitmap — no flash writes at all:

max_counter = 150
window_bitmap = 0b...11010111   ← which of the last 32 nonces have been seen
Range covered: [119 .. 150]

A packet is accepted if its nonce is above max_counter (shifts the window) or falls within the window with its bit unset. No NVS involved — a flood attack cannot wear out the flash.

The trade-off: after a reboot, both max_counter and window_bitmap are gone. Matter leaves the post-reboot counter problem to the upper protocol layers (session management). For a sessionless IoT device like BlauLux, this gap remains unaddressed if Matter's counter is used as-is.

---

My proposal: deferred write + witness + acceptance window

To cover the post-reboot gap without the UX cost of an ahead-increment scheme, I combined two mechanisms:

1. Deferred NVS write, capped at 1 write/hour

The receiver stores the real max_nonce (not max_nonce + N) to NVS.

Write conditions: (max_nonce != flash_nonce) AND (millis() - last_write >= 3_600_000).
This caps flash writes at 24/day, giving a flash lifetime of ~11 years under normal use. Combined with rate limiting (max 10 packets/s + exponential backoff: 10 s → 60 s → 10 min), a flood attack cannot drive more than one NVS write per hour.

2. Post-reboot: witness packet + acceptance window

After a reboot, X (the last saved nonce) is loaded from NVS. Rather than accepting any nonce > X blindly (which would allow replay of packets sent since the last hourly save), the receiver uses a two-step handshake:

Acceptance window:  X < nonce < X + 100

Step 1 — Witness:
  First packet with nonce in (X, X+100):
    → AES-GCM verified ✅
    → stored as witness_nonce in RAM
    → NOT executed (command dropped)

Step 2 — Confirmation:
  Next packet where: B > witness_nonce  AND  X < B < X + 100:
    → accepted and executed ✅
    → boot_phase = false → normal monotonic operation resumes

From the user's perspective: press the button once (absorbed as witness), press again — device responds. Two presses to recover from a reboot.

Why the window upper bound matters

Without the upper bound (X + 100), any captured packet with nonce > X would be accepted after reboot. The window (X, X+100) limits the replay surface to at most the last ~100 nonces sent before the reboot (roughly the last hour of button presses). Packets captured earlier — or far ahead of the saved counter — fall outside the window and are rejected.

For an attacker to exploit this residual window they would need: (a) two previously captured valid AES-GCM packets, (b) both with nonces inside (X, X+100), and (c) a reboot event to trigger the boot phase. For a domestic lamp this is a negligible threat.

---

Comparison: Matter (Tasmota) vs my proposal

	Matter (Tasmota) — sliding window RAM	My proposal — deferred write + witness
Flash writes under flood	✅ none (RAM only)	Max 1/hour (regardless of pkt rate)
Flash lifetime (normal use)	N/A	~11+ years
Replay protection (normal)	✅ 32-bit sliding window	✅ strict monotonic
Replay protection post-reboot	❌ not addressed	⚠️ window of ~100 nonces
Recovery after reboot	❌ not addressed	✅ 2 button presses

---

This is still a design proposal — I have not yet started the implementation. Any feedback on the witness + window approach, or vulnerabilities I may have overlooked, would be very welcome.

[s-hadinger]

Yes I prefer it this way, it preserves Flash and avoids basic replay. Well done.

[CasamaMaker]

Thank you very much for your guidance! This topic is not my strongest area, and your feedback has been really helpful in pointing me in the right direction.