domoticz: JSON v MQTT

Elektronika, Elektromos eszközök

Szia!

Előre bocsátom, hogy nagyon kezdő vagyok a témában, most kezdem megismerni.
Pár szenzorral figyelném/irányítanám a ház bizonyos elemeit (fűtés, kisállatok, öntözőrendszer - kút).
Domoticz-ba JSON alapon és MQTT brókeren keresztül is lehet adatokat adni.
Melyik a megbízhatóbb? Gondolok itt áramszünet esetére. Minden maradjon az áramszünet előtti állapotban (ez ok, megoldom) és ha
a domoticz szerver indul újra, az is a leállás előtti állapotot mutassa.
Szóval MQTT vagy JSON?

Köszönöm,
Roland

  • 1518 megtekintés

( _Franko_ v | 2019. 01. 15., k – 07:46 )

Először is: az MQTT és a JSON nem egy szinten lévő protokoll, MQTT-n küldhetsz például JSON-t... szóval szerintem te itt a HTTP-re (és REST-re) gondolsz, csak a Domoticz hülyén nevezte el az API-t.

Elvileg teljesen mindegy... amelyik kényelmesebb vagy jobban érthetőbb. MQTT kompaktabb protokoll, a HTTP meg átmegy akár proxy-n is.

--
https://iotguru.live

nem igazán. Az mqtt protokol, leírja, hogy milyen üzenetek vannak, azokat hogyan kell használni, milyen actorok vannak a protokollban, nekik mit kell csinálni ezekkel az üzenetekkel, meg azt, hogy hogyan kell ezeket on-wire rakni.

Ezzel szemben a json leírja, hogy hogyan kell jsonul reprezentálni adatot.

( uid_4263 v | 2019. 01. 15., k – 10:37 )

Az MQTT, mivel broker/queue alapú, ezért aszinkron, míg a http/json szinkron. Előbbi azt jelenti hogy az események forrásától érkező üzenetek bekerülnek a csőbe, és akkor folynak csak ki amikor a feliratkozó kéri, egyébként bent rohadnak, akár hosszabb ideig is (de gondolom a message retention konfigható, nem ismerem a részleteit, másfajta queue implementációkat használtam eddig).

Mivel itt real time dolgokról beszélünk, ezért ezt vedd figyelembe. Például a fűtés vezérlés nem jó, ha 3 órás lagokat mutat be.

A szinkron hívás annyiból jobb hogy a kérések és válaszok kötelező csoportokat alkotnak egymással, és a hívó azonnal értesülhet, ha a szerver nem érhető el / nem jó statust ad / stb.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

A HTTP kérés-válasz alapú protokoll, nincs cső és nincs broker. Tehát a kliens kér, megvárja a választ és elgondolkozik rajta mit jelent. Úgy gondolom hogy megfelelőbb az ilyen "real time" jellegű dolgokhoz. Ha pl. a szerver lefagyott, és lehet hogy 2 napig offon lesz, akkor az üzeneteket küldő alkalmazás erről biztos értesülni fog, mert minden kérése hibára fut. Queue esetén meg annyi történik hogy beteszi a csőbe az üzenetet és onnantól kezdve nem tudja, mi történik majd és mikor. (persze lehet ezen reszelni, kötelező válasszal, correlationnel, alacsonyan tartott retention timeouttal stb, de minek karatézni? :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Tökmindegy. Ha nincs kapcsolat a kliens-szerver vagy a kliens-kliens között, akkor nincs kapcsolat. Ha van kapcsolatra lehetőség, akkor mind a két módszer működik. Vannak bizonyos korlátai mindegyiknek, amelyekkel együtt kell élni, de mindegyik működni fog.

MQTT esetén lesz kettő topic, az egyikben jön a beállított hőmérséklet, a másikban meg a mért hőmérséklet. Plain HTTP esetén meg a kliensed időnként bekérdez, hogy mi az éppen aktuális beállított hőmérséklet és a mért hőmérséklet. WebSocket esetén meg ugyanaz van, mint MQTT esetén.

Szóval mindegy. Ami és ahogy tetszik.

--
https://iotguru.live

"Az MQTT, mivel broker/queue alapú, ezért aszinkron, míg a http/json szinkron."

A HTTP is lehet aszinkron... főleg, ha WebSocket (vagy HTTP/2), a JSON csak utazik benne. :)

"de gondolom a message retention konfigható, nem ismerem a részleteit, másfajta queue implementációkat használtam eddig"

MQTT esetén három QoS van:
0, at most once - vagyis egyszer küldi, aztán vagy megkapod vagy nem
1, at least once - vagyis egyszer legalább megkapod, de lehet, hogy többször is
2, exactly once - vagyis legfeljebb egyszer kapod meg, de azt biztosan megkapod

Ezen túl az üzenet lehet retained, de ebből maximum egy lehet per topic és a legfrissebb őrződik meg. Szóval nagyon másképp működik, mint mondjuk a többi queue/topic implementáció.

"Például a fűtés vezérlés nem jó, ha 3 órás lagokat mutat be."

A kérdés szerintem itt nem a lag, hanem az, hogy mekkora probléma a kommunikációs csatorna kiesése. Nem probléma: az MQTT visszakapcsolódik, a WebSocket újra felépül, a polling megoldás meg majd bekérdez, éppen melyik van használva.

Amire fel kell készülni, az mondjuk egy degraded/fallback működés kitalálása, hogy akkor se maradj fűtés nélkül, ha problémák vannak. Például nálam most nincs internet kapcsolat (https://iotguru.live/status/4ca6ff41-4408-11e8-94bd-3dd310e71935), a fűtés és a "termosztát" viszont külön egységet képeznek:
a, normál működés esetén a kazánt kapcsoló eszköz elkéri a nappali hőmérsékletét a felhőből és a beállításoknak megfelelően vezérli a kazánt
b, ha nem tudja lekérni a hőmérsékletet, akkor a saját hőmérője alapján vezérli a kazánt
c, a nappaliban lévő eszköz vezérli a klímát, ha nagyon lecsökkenne a hőmérséklet (meghibásodik a kazán)

--
https://iotguru.live

( HalfDemon v | 2019. 01. 15., k – 11:58 )

A kisállatok irányítása azért érdekelne, itt nagyon kontroll nélkül működnek!
(Ez egy feliratkozás volt)