Hlavní navigace

Vlákno názorů k článku Protokol MQTT: komunikační standard pro IoT od ehmmmm - No dobre, tak dalsi relativne novy protokol. Asi to...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 6. 2016 20:59

    ehmmmm (neregistrovaný)

    No dobre, tak dalsi relativne novy protokol.

    Asi to sam tusim, ale bylo by nejake srovnani s vyse zminenym OPCUA, nebo KNX/EIB, LonWorks/LonTalk a podobnymi? Stoji to za to venovat tomu pozornost? Jaka je pravdepodobnost, ze se to bude pouzivat i za 10 let? (Rozumejte, z pohledu konzervy, ktery uz napr. cca 5 let pokukuje po IPv6, ale chape, ze to ma dalsich 5 let jeste cas.)

    A co teda ten MQTT vlastne umi? Jenom ten subscribe a publish obecnych dat? Nebo jeste neco?
    (Na druhou stranu prave to by mohlo mit sanci na uspech. Kdyz si predstavim, jak dlouho tu jsou a jeste dlouho budou ruzne RS232/RS485 a k nim treba i Modbus prave diky tomu, ze jsou fakt trivialni...)

    Potom primo v clanku je veta: "V BigClown jsme implementaci MQTT-SN zvažovali, ale protože potřebujeme optimalizovat i payload, pustili jsme se do vlastního protokolu."
    Tak k cemu potom takovy standard je, kdyz i autor clanku si radsi vymysli neco jineho?
    Asi tomu treba nechat jeste nejaky cas, nez si to sedne. Mame rok 2016, tak treba do roku 2020-2025?

  • 29. 6. 2016 23:20

    robotron (neregistrovaný)

    "relativne novy"??? 17 let. Uznavam, vuci treba TCP je to mimino,... ale vuci treba nanomsg nebo 0MQ je MQTT hodne starobyla zalezitost.

  • 30. 6. 2016 10:04

    M. (neregistrovaný)

    Myslím, že MQTT používá toršku jiný princip, než 0MQ a nanomsg, který je daný tím, z čeho vzešel.
    Každá z těchto dvou skupin protokolů má trošku jiné vhodné použití a my to třeba máme mixováno, že se používají paralelně vedle sebe pro různé druhy přenosů podle toho, zda je pro danou věc vhodný pub/sub nebo req/rep atd princip. Přímí soupeři jsou spíše 0MQ a nanomsg.
    Co by mě ale zajímalo, zda už pro 0MQ a nanomsg exisutje nějaká jendoduchá implementace pro možnost komunikvat mezi aplikací běžící jako javascript klient v prohlížeči a něčím běžícím někde jinde na nějakém relativně omezeném HW. Pro MQTT je to hezky řešeno a funkční, kdy dneska MQTT mosquitto brooker umí fungovat přímo jako websocket proxina a i static content HTTP server (i když máme nasazeno stále z histrických důvodů lighttpd a mod_websocked na MQTT) a javascript knohovna šlape celkem OK. Pro nanomsg v této chvíli stále neexistuje javascript knihovna (jen bind pro node.js), pžřstože ten protokol používá i Websocket trasport a pro 0MQ je pár proxin, ale jde většinou o různé Python, Flash atd frameworky.

  • 30. 6. 2016 11:06

    robotron (neregistrovaný)

    Casem bych rad provozoval nanomsg (na mistni prepravu v ramci pametoveho prostoru jednoho pocitace) pripojene bridgem na MQTT (na komunikaci s ostanimi uzly). Koukam, ze existuji bridge mezi dbus a nanomsg a dbus a MQTT, ale asi bude lepsi bridgovat primo ;-)

  • 30. 6. 2016 0:43

    BigClown

    Ano, MQTT je přesně takto triviální.

    U toho MQTT-SN jsem to napsal trošku nejasně. MQTT-SN je pokus přivést MQTT do bezdrátové non-IP komunikace, který nám moc nevyhovoval, proto jsme zvolili vlastní řešení, které je technicky stále MQTT s přidaným zabezpečením pro "zónu rádio", který se pro "zónu linux server" překládá do MQTT.

  • 30. 6. 2016 9:46

    M. (neregistrovaný)

    Zmíněné protokoly OPCUA, nebo KNX/EIB, LonWorks/LonTalk atd vychází z průmyslového prostředí a často jsou pro průmyslové sběrnice.
    Kdežto MQTT vyšel z jiné oblasti obecných velkých MQ systémů a byl zjednodušován tak, aby se dal použít aspoň ten pubsub MQ princip i v jednoduchých zařízeních, pokud jsou schopna TCP/IP (a v případě MQTT-SN i bez toho IP).
    MQTT tu je už od roku 2000 a ještě nějakou dobu určitě bude, s přehledme do roku 2025 (s ohledme na to, kde jej máme v technologických systémech nasazen a jaké doby provozu/servisu jsou k tomu nasmlouvány). :-)

  • 1. 7. 2016 7:11

    Sid (neregistrovaný)

    Konkretne opcua nema s priemyselnymi zbernicami nic a publish subscribe model ma vyrieseny povrdal by som este o cosi lepsie ako mqtt. Aj ked zalezi od pohladu samozrejme. Napr zmeny mozu byt posielane iba pri zmene hodnoty o nejaku stanovenu hodnotu (ci uz absolutnu alebo relativnu). Nevyhodu ktoru treba ale spomenut je ze opcua funguje systemom client request server response takze server sam o sebe neposiela nic toto bolo zvolene z ohladom na firewall na strane klienta.

  • 1. 7. 2016 7:49

    M. (neregistrovaný)

    Ano, OPC UA není sběrnicový protokol, ale ty další už ano. Musím brát, že OPC standard a MQTT přišly z jiných světů a řeší něco jiného. OPC UA je komplexnější, složitější (těch 11 knih speciikace proti "pár" stranám MQTT), protože se snaží podchytit celý proces předávání technologických dat, včetně řešení datového modelu, kdežto MQTT je v podstatě jen transportní vrstva což je někdy plus a někdy mínus. OPC UA dodnes nemá řada software ze SCADA oblasti implementováno v použitelném stavu. Je to stále "horká novinka", ale díky za něj, proti původnímu OPC nad Windows COM (nepoužitelný vtip s OPC-XMLDA je jen tak pro předávání pěti hodnot po minutě), takže dosti problém na ne-Windows platformách.
    Pokud potřebuji komplexnějí datové struktury předávat, které zapadají do modelu OPC, tak je to super, pokud chci jen jednoduše formátované parametry, kde není žádná složitost, tak MQTT je také super na použití, zvláště pokud mám všechny komunikující strany pod kontrolou, a v porovnání s jinými jednoduchými technologickými protokoloy řeší další problémy navíc. Je to zkrátka něco na půli cesty mezi Modbus/TCP a OPC UA, který dokáže zvládat celkem slušné objemy dat.
    A nakonec mlůžu použít i nějakou bráno mezo MQTT a OPC (ale viděl jsme jen na staré Win COM OPC a ne na OPC-UA). :-)