Čtecí pero IoT MQTT vs HTTP vs CoAP: Jak vybrat správný protokol aplikační vrstvy

Cílová skupina: Tento briefing je určen pro architekty OEM/ODM firmwaru, inženýry MDM/cloud integrace a nákupní manažery, kteří musí rozhodnout, kterým aplikačním IoT protokolem bude flotila čtecích per hovořit. Srovnává MQTT 5.0, HTTP/1.1 REST a CoAP (RFC 7252) na všech aktivních SKU (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6), se změřenými velikostmi payloadu, dopadem na baterii a důsledky pro cloudovou stranu.

Distributorovi v SAE chtěl, aby jeho flotila 8 000 per odesílala telemetrii využívání každých 15 minut na školní BI dashboard. První řešení používalo HTTP POST + JSON; po 30 dnech pera ztrácela 4 % baterie denně a školní MDM konzole zaznamenala 22 % ztrátu paketů kvůli timeoutům NAT. Přechod na MQTT 5.0 s persistent session a QoS 1 snížil denní ztrátu baterie na 0,6 % a ztrátu paketů na 0,3 %. Rozhodnutí o protokolu změnilo provozní ekonomiku celého nasazení.

Tento článek představuje technické zdůvodnění z pohledu firmwaru a BOM: počty bajtů payloadu, odběr proudu, paměťovou náročnost knihoven, chování při retransmisi a co každý protokol skutečně stojí Li-ion článek 700–2 500 mAh.

1. Tři protokoly v jednom odstavci každý

• MQTT — protokol typu publish/subscribe přes broker nad TCP/TLS. Port 8883. Navržen pro nízkou šířku pásma a nespolehlivá spojení. Témata vypadají jako pen/12345/telemetry. Nativní QoS 0/1/2. Persistent sessions a last-will jsou prvotřídními funkcemi.
• HTTP/1.1 — request/response nad TCP/TLS. Port 443. JSON přes REST je univerzální výchozí volba. Payloady jsou upovídané, hlavičky velké a spojení jsou typicky krátkodobá (bez persistent socketu).
• CoAP — request/response nad UDP/DTLS. Port 5683. Navržen pro omezená zařízení. 4bajtová hlavička, observe mode se přibližuje publish/subscribe. Vyžaduje CoAP server nebo proxy.

Všechny tři jsou podporovány ve firmwaru L5, Q8, T2 a Y6. MQTT pouze na B1, B2, F8, K7, KF1, P2, Q6. HTTP je univerzálně dostupné, protože SDK Wi-Fi čipu obsahuje HTTP klienta. MQTT vyžaduje paměťovou stopu zhruba 38 KB ve firmwarové partition Cortex-M4.

2. Realita velikosti payloadu

Jedinou největší proměnnou je JSON upovídanost HTTP. 12políčkový telemetrický paket (ID zařízení, verze firmwaru, procento baterie, časové razítko posledního poklepání, ID knihy, číslo strany, skóre, ID relace, příznaky rodičovské kontroly, region, sync epocha, RSSI) se komprimuje velmi odlišně:

Náklady HTTP na cloudové straně jsou převážně spojení, ne bajty. Každý HTTP POST otevře TLS relaci (6 KB handshake) + TCP handshake (1,4 KB) + HTTP požadavek (412 B). Typický HTTPS POST do AWS IoT je 8 KB na drátě předtím, než vůbec začne váš payload.

MQTT otevře TLS relaci jednou a poté spojení opakovaně využívá pro tisíce publikací. Režie na zprávu klesne na 70 B plus payload. Pro 1 telemetrický paket za 15 minut vítězí MQTT v bajtech čtyřnásobně.

3. Dopad na baterii podle protokolu

Změřili jsme denní dopad na baterii na Q8 firmware 3.3.1, s 96 telemetrickými publikacemi denně a 1 OTA kontrolou každých 24 hodin. Články byly 3× cyklovány, aby se odstranil vliv variability mezi články:

CoAP vítězí v proudovém odběru, protože UDP/DTLS se vyhýbá záplavě TCP ACK. MQTT QoS 0 je reálné produkční nastavení pro školní telemetrii — ztráta paketů nevadí, protože další telemetrický paket nahradí ten předchozí.

Tip pro kupující: "Trvalé HTTP spojení" zní jako bezplatná výhra; v praxi tomu tak je. Školní firewally agresivně ukončují nečinná HTTP spojení po 60–90 s, takže pero musí při každém publikování znovu sestavit TLS handshake. MQTT heartbeat (výchozí 90 s) přežije firewally, protože vypadá jako běžný keep-alive paket.

4. Úrovně QoS a co znamenají pro čtecí pero

MQTT QoS:

• QoS 0 — maximálně jednou. Pošli a zapomeň. Pokud je broker offline, zpráva se ztratí. Dostatečné pro telemetrii.
• QoS 1 — alespoň jednou. Broker odešle PUBACK; pero vysílá opakovaně, dokud nedostane potvrzení. Způsobuje duplicity, pokud broker zprávu již přijal, ale ACK se ztratil.
• QoS 2 — přesně jednou. Čtyřkrokový handshake. Nejvyšší náklady. Používá se pouze pro řídicí příkazy OTA a příznaky rodičovské kontroly.

Všechnu telemetrii standardně nastavujeme na QoS 0 a OTA na QoS 2. Bouře opakovaného připojování Wi-Fi na školní chodbě nikdy nepřepíše flash firmwaru.

5. Režim CoAP Observe: Podceňovaná možnost

Režim CoAP Observe (RFC 7641) je v jádru publish/subscribe přes UDP. Pero zaregistruje zájem o zdroj; server posílá změny stavu. Pro školní MDM, která chce zrcadlit stav pera v reálném čase bez cloudového brokeru, je Observe vynikající.

Implementovali jsme CoAP observe na firmwaru Y6 2.6.4 pro program 22 000 per v jednom brazilském státě. Každé pero registruje pero/<id>/state na místním CoAP serveru ve škole. Server posílá delta aktualizace; průměrná frekvence push je 2.4 zprávy za minutu během hodiny, v nečinnosti klesne na 0. Energetická spotřeba je stejná jako u MQTT QoS 0, protože UDP se vyhýbá TCP retransmisím.

6. Náklady na cloudový broker: Proč MQTT škáluje levněji

MQTT brokery jsou stavoví, ale velmi efektivní. HiveMQ Cloud, EMQX Cloud i AWS IoT Core účtují podle minut zařízení a podle zpráv. Flotila 10 000 per s QoS 0 při 96 zprávách/den vygeneruje 35 milionů zpráv měsíčně. AWS IoT účtuje po bezplatném tarifu 1,00 $ za milion zpráv, takže účet je přibližně 35 $/měsíc. HTTP by se účtovalo podle požadavků, ale režie na požadavek je 6× vyšší, takže se účet zhruba zdvojnásobí.

EMQX na vlastním 4jádrovém VM zvládne 50 000 současných MQTT klientů s propustností 100k zpráv/s. Stejná zátěž přes HTTP potřebuje 8 VM a load balancer. Pro distributory, kteří prodávají cloudový back-end jako službu, je MQTT jedinou ekonomickou volbou.

7. Zastoupení firmwaru a BOM

Zastoupení protokolového stacku ve firmwarové imagi:

U cenově citlivých modelů B1, B2, F8, P2, Q6 dodáváme pouze HTTP. Pro L5, K7, KF1, Q8, T2, Y6 dodáváme MQTT. CoAP je volitelné firmware, které přidává 32 KB k bitové kopii OTA; dovozci jej musí požadovat při zadání objednávky.

8. Příběh OTA: vyhrává řídicí téma MQTT

Doručování firmwaru přes OTA je jediná operace s nejvyšší sázkou. Používáme MQTT QoS 2 s tématem specifickým pro dodavatele pen/<id>/ota, které nese URL adresu bitové kopie firmwaru a hash SHA-256. Pero stahuje přes HTTP(S) — ano, HTTP — protože hromadný přenos je efektivnější přes prosté HTTP/2 s požadavky range, zatímco řídicí rovina jede přes MQTT.

Úplný postup OTA je popsán v TC-034 Aktualizace firmwaru OTA. Stručná verze:

1. Cloud publikuje {"cmd":"fetch","url":"...","sha256":"..."} do pen/<id>/ota (QoS 2).
2. Pero odpoví PUBREC, PUBREL, PUBCOMP.
3. Pero otevře požadavek HTTPS range a stáhne bitovou kopii po 64 KB blocích.
4. Pero ověří SHA-256, zapíše do neaktivního oddílu a restartuje se.
5. Pero publikuje {"cmd":"ack","status":"ok"} do pen/<id>/ota/ack.

Průměrný čas OTA pro bitovou kopii firmwaru 8 MB na školní Wi-Fi 1 Mbps je 75 s. Režie MQTT činí pouze 1,8 s.

9. Firewall a průchod přes NAT

Školy blokují příchozí TCP; otevřený je pouze odchozí 443/8883. MQTT přes 8883 s TLS funguje. CoAP přes UDP 5683 je často blokován. CoAP přes DTLS-PSK na 5684 někdy funguje; na 5684 s WebSocket transportem funguje téměř všude. Pro zaručenou cestu napříč sítěmi MQTT přes 8883 s WebSocket záložním řešením je spolehlivou volbou.

Náš firmware 3.3.1 na Q8 a T2 podporuje cestu MQTT-over-WebSocket; L5 a Y6 podporují pouze nativní MQTT. K7, KF1, F8 a Q6 využívají jako zálohu HTTP/HTTPS.

11. Kdy zvolit hybridní architekturu

Čistě MQTT flotila je v provozu vzácná. Nejodolnější školní architektury, které v letech 2025–2026 vidíme, využívají hybrid:

1. MQTT 5.0 jako primární cestu pro telemetrii a příkazy (TLS 1.3, QoS 0 pro telemetrii, QoS 2 pro OTA).
2. HTTPS jako kanál pro stahování OTA (rozsahové požadavky, akcelerace přes CDN).
3. CoAP observe jako místní zálohu uvnitř školní LAN, kde cloudový broker není dosažitelný, ale školní MDM je online.
4. BLE GATT jako offline konfigurační cestu – když Wi-Fi nefunguje, učitelova tabletová aplikace konfiguruje pera přes BLE.

Firmware na L5, Q8, T2 podporuje všechny čtyři cesty. Z výroby jsou všechny povoleny, přičemž protokol je automaticky vybrán na základě schématu URL. Pero, které detekuje mqtts:// používá MQTT; coap:// používá CoAP; https:// používá HTTPS; ble:// používá BLE GATT.

12. Schémata zpráv a zpětná kompatibilita

Telemetry payload MQTT na Q8, T2, Y6 odpovídá našemu publikovanému schématu JSON v3.2. Každé pole je zdokumentováno v referenci Smart Reading Pen MQTT Schema, včetně jednotky (sekundy, mAh, dBm, strany), rozsahu (min, max) a informace, zda je povinné či volitelné. Zlomy schématu vyžadují zvýšení hlavní verze a 6měsíční období vyřazení.

Typický telemetrický paket na Q8 firmware 3.3.1 vypadá takto:

{
  "v": 3,
  "ts": 1735689600,
  "id": "Q8-23A47C"
  "fw": "3.3.1",
  "bat": 87,
  "rssi": -52,
  "page": 12,
  "score": 8,
  "ctrl": { "parental": "on", "language": "en-US" }
}

Celý paket má v nekomprimovaném JSON 142 bajtů. CBOR jej komprimuje na 58 bajtů. Oba formáty jsou podporovány na Q8, T2 firmware 3.3.1+; starší firmware (1.9.x, 2.x) rozumí pouze JSON. Importéři provozující vícegenerační flotily musí udržovat cestu JSON povolenou nejméně 24 měsíců po zavedení CBOR.

Továrna přiřazuje každé značce jedinečný prefix tématu: pen/<brand-slug>/<pen-id>/telemetry. Distributoři privátních značek si mohou vyžádat vlastní prefix; dodací lhůta je 2 pracovní dny.

13. Kalkulačka nákladů na cloud podle regionu

Pro OEM odběratele, kteří vyhodnocují celkové náklady na vlastnictví, vedeme kalkulačku cloudových nákladů, která zohledňuje regionální ceny brokerů, objem zpráv a úložiště. Ukázkové výsledky pro flotilu 5 000 per, 96 zpráv/den, uchování 24 měsíců:

On-premise varianta Mosquitto je nejdražší, protože vyžaduje instanci EC2 v provozu 24/7 ($112/měsíc) plus čas operátora. AWS IoT Core je nejvýhodnější pro flotily nad 1 000 per. Self-hosted brokeři vyhrávají pouze u požadavků na umístění dat (GDPR, PIPL, LGPD), kde cloudový region nedokáže splnit právní hranici.

Kalkulačka je k dispozici ke stažení ve formátu XLSX z našeho engineering portálu. Distributoři mohou požádat o přístup odpovědí na jakýkoli e-mail od Smart Reading Pen se slovem PROTO.

14. Konvence pojmenování témat napříč značkami

Distributor privátní značky provozující více značek na stejném brokeru by měl pečlivě jmenný prostor MQTT témat. Naše doporučené schéma:

pen/<region>/<brand>/<pen-id>/<channel>

Kde <region> je dvoupísmenný kód ISO, <brand> je kebab-case slug značky, <pen-id> je 16znakové sériové číslo a <channel> je jedno z telemetry, command, ota, ack, event. Typické téma: pen/us/acme-publishing/Q8-23A47C/telemetry.

Tovární MQTT broker ověřuje strukturu tématu při každém publikování; neplatná témata jsou odmítnuta s návratovým kódem 0x95. To zabraňuje nesprávně se chovajícímu peru náhodně publikovat do tématického prostoru jiné značky. Cena validace je 0,4 mAh na pero a den u Q8 – zanedbatelné.

Dovozci provozující více než 5 jmenných prostorů značek by si měli od továrny vyžádat konfiguraci multi-tenant brokera; zřizovací poplatek je $240 jednorázově plus $0,02 za pero a rok za multi-tenant certifikát.

10. Rozhodovací matice

Pro OEM odběratele bez brokeru náš seznam partnerů zahrnuje HiveMQ Cloud Starter (zdarma pro 100 zařízení), EMQX Cloud Starter (9 USD/měsíc pro 1 000 zařízení) a vlastní Mosquitto na Ubuntu LTS. Broker nedodáváme; dovozci si musí zvolit vlastní cloudovou architekturu.

Související články

• Wi-Fi roaming a opětovné připojení
• Mechanismus aktualizace firmwaru OTA
• TLS 1.2 vs 1.3 a certifikáty
• Šifrování dat AES-128 vs AES-256
• Architektura firmwaru vysvětlena
• Spotřeba energie a test výdrže