domoticz: JSON v MQTT

 ( roleez | 2019. január 15., kedd - 8:37 )

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Értem. Köszönöm.

Sot a JSON nem is protokoll hanem adat formatum. Nem kotekedesbol, csak pontositas vegett. Amugy jol mondtad.

Ennyi erővel az MQTT is csak egy adat formátum... :)

--
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.

A Domoticz REST JSON API-ja pont így leírja, hogy mi micsoda és mivel mit kell csinálni... nyilván, értem. :)

--
https://iotguru.live

ezért volt furcsa :)

de akkor csak félreértettünk, hogy te most konkrétan arról beszélsz, amit a domoticz hív jsonnak.

Írtam is, hogy a Domoticz hülyén nevezte el az API-t, aztán úgy maradt történelmi okokból, így néz ki:

http://192.168.1.2:8080/json.htm?type=command&param=udevice&idx=$idx&nvalue=0&svalue=79

--
https://iotguru.live

jep, csak utána írtad :)

mondjuk ez így elég... hát érdekes. Szép dolog az url paraméterekkel megtámogatott json.htm.

(egyébként megint majdnem megkérdeztem, hogy miért postolsz nekem privát IPt, lehet abba kéne hagyni :D)

Nem, én ezzel kezdtem, hogy hülyén nevezte el az API-t.

--
https://iotguru.live

> 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.

Hát persze.

Van működő arduino(ESP8266) kódod? küzdök, nem tudok html/json kódot küldeni...

Nekem csak az van, amit itt látsz az aláírásomban, nem használok Domoticz-ot, az API egy hulladék, néhol túl komplex, néhol nagyvonalúan egyszerű.

--
https://iotguru.live

Esp-re tegyel fel egy esp easyt szvsz ha jarhato, es ugy be a domoticz-ba... :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

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

Szóval a szinkron http/json használhatóbb pl. a fűtésvezérlésre?
Jól értem?

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

A kérdező nem fejtette ki hogy a cucca mit támogat, de gondolom HTTP/1.1. Egyébként a websocket hogyan jön ide? :)

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

Emlékeim szerint van a Domoticz-hez WebSocket plugin, ami ugye HTTP/1.1 upgrade.

--
https://iotguru.live

Áá, köszi.

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

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

https://hup.hu/node/95386?comments_per_page=9999#comment-1158994

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin