Holyiot 21014-B (nRF52810)

Curiosity

L’unico beacon Holyiot con una board definition ZEPHYR ufficiale (holyiot_21014). Stesso nRF52810 del 21011, ma tondo Ø30 × 8.4 mm, IP66 (il 21011 è rettangolare) — e soprattutto: pulsante, LED e accelerometro sono già mappati nel devicetree, niente reverse engineering.

⭐ Al banco (17/07/2026): firmware Visla flashato sulla board VERA, pulsante OK al primo colpo. A differenza del 25027 (compilato per una board sbagliata, aspettava pressioni fantasma) o del 21011 (board Zephyr assente), qui -b holyiot_21014 e tutto combacia.

🛒 AliExpress — HOLYIOT-21014-B · €10.99 · IP66 · recensioni HA: “~6 mesi con una CR2032”

Specs

🔔 Firmware Visla — sulla board giusta (17/07/2026)

🔔🔔 21014-B [C7F134BA] PREMUTO!  cnt 1→2

Compilato per la board canonica, niente pin da indovinare:

west build -p -b holyiot_21014 visla-beacon

💻 visla-beacon/ — lo stesso identico sorgente del 25008/21011/25027. Device ID C7F134BA dal silicio (hwinfo) → anti-clonazione gratis.

⚠️ RAM al 92% (22.720 / 24.576 B): lo stack BLE di Zephyr riempie quasi tutto. Funziona, ma 1.8 KB liberi — come il 21011, è il limite reale del nRF52810 (non la flash).

⭐ Il pulsante ACTIVE_HIGH è gestito dal devicetree senza toccare il codice: se lo cablassi a mano con la logica del 25008 (ACTIVE_LOW), impazziresti. È il valore di avere la board definition giusta.

🔓 SWD + backup

Found SW-DP with ID 0x2BA01477     ← Cortex-M4 (come il 21011)
AP[0]: Core found                  ← APPROTECT non attivo

Backup: backup/holyiot_21014b_stock.bin — 192 KB, 76% pieno (firmware Holyiot = nRF5 SDK classico, come il 21011).

⚡ Gotcha del banco: DIO/CLK invertiti al primo tentativo → VTref buono ma Could not connect. Scambiati → connesso a 4 MHz. È l’errore che si ripete su questi pad minuscoli.

🐛 Bug LED bloccato — il pulsante ACTIVE_HIGH senza pull-down (17/07/2026)

Sintomo (segnalato al banco): premendo il tasto, a volte il LED rosso restava fisso e non tornava normale.

Causa doppia:

1. Il pulsante del 21014 è ACTIVE_HIGH (gpio0.31) senza pull-down → da rilasciato il pin resta a livello alto (floating) → il firmware lo legge come “sempre premuto”.
2. Il primo tentativo di fix (loop che rilegge il pin) credeva a quel pin bugiardo → LED e flag advertising inchiodati a 0x01.

Fix definitivo: il LED non insegue più lo stato del pulsante (inaffidabile su un pin floating), ma fa un lampo momentaneo di 150 ms guidato da un timer. Un evento momentaneo non può restare bloccato. Idem per il flag nell’advertising.

prima:  flag 0x01 FISSO (bloccato)     LED sempre rosso
dopo:   flag 0x00 a riposo · 0x01 solo nell'istante del click · LED lampeggia
        contatore pulito 1→2→3→4 · campanello intatto

⭐ Lezione: è lo stesso principio del press_count e del debounce — non fidarsi di un singolo stato/evento, usare qualcosa di robusto. E soprattutto: la polarità del pulsante cambia tra le board Holyiot (25008 ACTIVE_LOW + pull-up · 21014 ACTIVE_HIGH senza pull) → un firmware che assume la polarità sbagliata legge il pulsante al contrario. Il devicetree gestisce la logica, ma il pull mancante resta una trappola hardware.

🗂️ La famiglia beacon Holyiot testata da Visla

Quattro modelli, tre chip, un solo firmware Visla — ognuno col suo device ID dal silicio, quando di fabbrica erano tutti cloni (UUID FDA50693-..., Major 10011).

🎯 Note per Visla

• ⭐ La board di riferimento per prototipare in Zephyr sul nRF52810: definizione ufficiale, niente reverse engineering. Se il Tag adottasse un 52810 (improbabile — troppo poca RAM), si partirebbe da qui.
• IP66 → l’unico della serie adatto a un uso non protetto.
• ⚠️ Ma per il Tag di produzione resta il nRF54L15 (25008): 1.5 MB flash e 256 KB RAM contro i 192/24 di questo. Il 52810 va bene per un beacon, non per il tracker.

🔗 Risorse

• 💻 firmware Visla beacon · backup stock
• 📖 Zephyr — board holyiot_21014
• 🛒 AliExpress
• Fratelli: 21011 rettangolare · 25008 nRF54L15 · 25027 buzzer