Integrace zařízení, posílání dat do cloudu, dálkové ovládání zařízení - to jsou hlavní výhody, které očekávají uživatelé od internetu věcí. Každý výrobce i poskytovatel cloudových služeb se k tomu staví po svém. Najít zařízení dvou různých výrobců, která by bylo možno integrovat do jednoho systému se zdá být téměř nemožné. Společným řešením může být MQTT, protokol, který teoreticky umožňuje uživateli společně monitorovat a ovládat například PLC Siemens, smart home technologii ABB, senzorová zařízení HW group, chytré hodinky s Androidem i Raspberry Pi s využitím Amazon Web Services nebo cloudu ČRA. Na první pohled skvělé.

Výhody

Univerzálnost MQTT je založena zejména na tom, že nevyžaduje žádný speciální hardware. Podobně jako SNMP běží na vrstvě TCP protokolu IP, tedy na standardu nejrozšířenější počítačové sítě. Zařízení (senzory nebo chytrá zařízení) tak mohou být připojena přes Wi-Fi, Ethernet a nepotřebují ani žádná speciální nastavení (s oblibou tvrdíme, že nastavení je stejně složité, jako u domácí Wi-Fi).

Uzel, který z jednotlivých MQTT zařízení dělá síť internetu věcí, se nazývá broker a může mít i plně virtuální podobu, včetně privátního nebo veřejně přístupného serveru. Brokeru stačí říci, která zařízení s ním budou komunikovat. Samotný protokol je jednoduchý a univerzální. Velkou výhodou je intuitivní způsob označování jednotlivých zařízení, která se mohou jmenovat tak, jak uživatele napadne, například devices/Poseidon24002Demo/ nebo HWgroup/Formanska/3patro/ a také to, že posílaná data mohou mít jakýkoli formát (text, binární, CSV data, XML skript....). Komunikace nemá pevně danou topologii, brokerů může být i více a přijaté informace od zařízení mohou sdílet. Znamená to, že například hodnotu teploty ze senzoru najednou obdrží cloudový SW i M2M aplikace, která na teplotu reaguje - nemusí čekat na to, jak data vyhodnotí cloudový software. Tuto vlastnost využívá i HW group pro své jednotky Poseidon2 a Damocles2 a pro propojrní s cloudovými platfromami, např. MS Azure. 

Bezpečnost není povinná

Podobně jako u ostatní IP komunikace protokol MQTT sám o sobě žádné zabezpečení nevynucuje ani nevyžaduje. Jednoduchost, se kterou lze přidávat další a další zařízení a brokery, otevírá bezpečnostní díry. Nezřídka je potom komunikace zcela veřejná. Každý, kdo chce, se k veřejnému brokeru může přihlásit a postupně odchytávat informace, aniž by to jejich skutečný uživatel zjistil. Pozornost je tak potřeba věnovat veřejně dostupným brokerům a aplikacím, zejména z podezřelých nebo neznámých zdrojů. Pokud data svěříme veřejnému brokeru, neexistuje žádná účinná kontrola nad tím, kolik dalších brokerů se k nim třeba i dočasně připojuje.
Na druhou stranu, v uzavřených sítích nebo IT systémech, kde je bezpečnost řádně ošetřena a administrátoři vědí, co se u nich děje, to nepředstavuje žádnou zvýšenou zátěž, ani hrozbu.
Zajištění bezpečnosti v rámci MQTT přenosu je totiž řešeno šifrováním TLS. Z pohledu IT je to rutinní záležitost. Pro vývojáře aplikace na jednoduchém single-chipu ale jeho implementace není nijak jednoduchá. Výsledná komunikace už není tak datově stručná, jako v případě nešifrovaného přenosu. To je spolu s faktem, že TCP/IP musí udržovat spojení, také překážkou pro low-power a bateriově napájené aplikace.

Komunikace jednoduchá, interoperabilita složitá

Pokud je správně ošetřena bezpečnost, je další možnou slabinou MQTT obsah informací. Jak jsme zmínili, posílaná data mohou mít jakýkoli formát (text, binární, CSV data, XML skript....). Broker tato data pouze přijímá a přeposílá, obsah je mu zcela lhostejný, je to jen libovolně dlouhý řetězec. Obsah informace plně definuje uživatel či autor zařízení. I obyčejný senzor teploty, který odesílá pouze údaj o teplotě, tak nemusí být schopen předat informace zobrazovací či řídící jednotce jiného výrobce, který má nastaven svůj řetězec pro payload jinak.
Nemusí jí o vyložený naschvál, je to standardní stav při vývoji software. Jeden program může odesílat 12-ti bitovou informaci, protože to stačí pro daný rozsah stačí, druhý očekává 16 bitů, protože pracuje i se senzory s větším rozsahem. Stejně se může lišit i způsob zápisu a přepočtu záporných hodnot. Standardizaci obsahu zprávy tak má zcela ve svých rukou vývojář aplikace.  Může dojít i k tomu, že výrobce zařízení svůj formát upraví při aktualizaci firmware a pro cizí přijímač se tak stane nečitelným. Stejný rozdíl může nastat u zpracování XML. MQTT informaci prostě přenese tak, jak je, její zpracování je věcí software, který správce systému musí včas a správně modifikovat.
Obecný broker nemá žádný přehled o obsahu informací a ze své podstaty ani o připojených zařízeních a jejich struktuře. Neumožňuje tak vyhledat určitý topic, ani hodnotu. Každý, kdo chce získávat informace z určitého zařízení (Topic), musí znát jeho jméno, které si zjistí jinou cestou. V praxi konfigurace zařízení stejného výrobce s MQTT komunikací znamená spoustu otevřených oken a kopírování jmen z config souborů. V případě aplikace pro mobilní telefon je to téměř nadlidský úkol. Tato zdánlivá maličkost je často překážkou pro použití MQTT ve velkém. Ve chvíli, kdy má broker obsloužit řádově stovky či tisíce zařízení, je nevyhnutelné zajistit jinými IT prostředky správu a dokumentaci topologie jednotlivých bodů. K tomu slouží komerčně dostupná řešení brokeru/receiveru, jako například HiveMQ, který kromě příjmu informací umožňuje spravovat tisícové série zařízení.

Zdrojem nahodilých nedorozumění v MQTT komunikaci je často také časová logika brokerů. Každá zpracovaná zpráva je po publikování označena jako zpracovaná a odložena stranou. Když se do informačního toku připojí nový broker, musí si počkat, až zařízení pošle další zprávu nebo obdrží poslední dosud neuzavřenou zprávu, která může být libovolně stará.

Pro MQTT v zásadě platí to samé, jako pro jakýkoli open-source. Čím jednodušší a otevřenější systém je, tím více práce je potřeba věnovat nejen jeho konfiguraci, ale také údržbě. Skvěle se uplatní jako nástroj komunikace mezi jinak nekompatibilními systémy. Například ve chvíli, kdy do unifikovaného enterprise řešení potřebuje firma přidat zcela atypický senzor, je MQTT dobrou cestou, jak to zajistit. Stejně tak ve fázi vývoje a demo provozu je MQTT jednou z nejrychlejších cest, jak vývojářům software dodat reálná data z čidel, dočasně obsluhovaných např. singleboardem Raspberry.