Názory k článku Tasmota a protokol MQTT: komunikácia klientov so serverom

Uz dlhsiu dobu sa chystam upgradovat niektore vypinace v dome pomocou sonoff (pripadne shelly), takze Vase clanky mi pridu velmi vhod, ked sa do toho konecne pustim. Mozno by som potom na Vas nadviazal s tym ako to zintegrovat pre zmenu cez openHAB, ktory pouzivam ja (ak sa donutim).
Kazdopadne dakujem za clanok a tesim sa na pokracovanie...

Budem rád ak napíšete niečo o openHAB, ja používam Home Assistant a openHAB ani iné "haby" nepoznám. Neviem ako je na tom openHAB, ale HA je v takom rýchlom vývoji (aspoň z môjho pohľadu), že medzitým čo by som o ňom niečo napísal sa to určite zmení. Vlastne poriadne nestíham sledovať ani zmeny v Tasmota.

My používáme pro komunikaci Mosquitto (MQTT) a logiku mám v Node-RED.

ma MQTT komunikace se Sonoff nejakou vyhodu oproti wget/curl?
pro ovladani on/off a vycteni status (z Sonoff POW) pouzivam:
wget -qO- http://${Sonof­fIP}/cm?cmnd=${Pri­kaz}
ve spojeni s bash scriptem pro generovani html s tabulkou informaci a vypinacema(=php/cur­l), pri nacteni stranky detekuje "vypinac" stav kazdeho sonoffu, stranku generuju po 1s+cas_potreb­nej_ke_sberu(0­.5-1s per sonoff(ktere nejsou v lokalni siti ale po (ne moc rychlem) netu), chapu ze MQTT bude mit vyhodu(nutnost?) pro hotove reseni nejakeho HA, ale muzu si s tim nejak pomoc i v me situaci?

Protokol MQTT (tak, ako je implementovaný v Tasmota, teda vo verzii 3.1.1 s obmedzeniami) ponúka oproti Vášmu riešeniu navyše tieto vlastnosti:

- mechanizmus keep alive ako ochranu proti čiastočne otvoreným TCP spojeniam a s tým spojené publikovanie závetu (špecifikácia v časti 3.1.2.5 Will Flag spomína aj ďalšie situácie).

- možnosť publikovať uložené správy (napr. Tasmota to využíva na správy discovery pre HA)
- QoS (tasmota dokáže využiť len čiastočne)
- možnosť nastaviť používanie mena a hesla

Možno Vám pomôže ak si pozriete priamo knižnicu - Tasmota v súčasnosti využíva PubSubClient, v zdrojovom kóde Tasmota je v adresári Tasmota/lib/de­fault/PubSubCli­ent-EspEasy-číslo.verzie.

Ale necítim sa byť v tejto oblasti odborníkom, v seriáli sa len snažím zhrnúť nadobudnuté informácie a skúsenosti s cieľom ušetriť čitateľovi čas stratený prehľadávaním neprehľadných diskusií, tutoriálov, ktoré dávno neplatia (ani nemusia byť staré - veci sa rýchlo menia) a dokumentácie, ktorá nie je vždy celkom presná ani úplná, zrejme je len poskladaná z príspevkov v diskusiách.

diky, "keep alive" mi zaroven rika ze to spojeni je normalne navazane na 60s a nenavazuje se tedy znovu pri dalsi zprave, to by byla vyhoda proti "curl http...", meno+heslo muze mit i web dotaz na sonoff/tasmotu...

nevyhodu obecne s MQTT v mojim reseni vidim ze pro php nevidim dostupnej balik, ale aspon sem nasel neoficialni :)

Má stromovou strukturu, takže třeba světla lze ovládat přes celé logicky vnořené segmenty.
Rozsviť lampičku v ložnici, rozsviť všechna světla v ložnici, rozsviť celý dům, zhasni celý dům.

Navíc má i QoS a počítá s velmi špatnou linkou a o doručení zprávy se netřeba příliš starat. Navíc počet klientů na jednom endpointu není omezený, takže víc zařízení může poslouchat jednu zprávu atd.

diky, to by byla urcite vyhoda, ale pri mem usecase je kazdej sonoff zvlast zarizeni, a on/off skupinu naraz asi nevyuziju, velmi spatna linka by mi udelala problem driv protoze komunikaci s sonoffama mam pres ssh tunnely ktere navazuje remote_router na server kde pak prej jednotlive protunelovane porty pristupuju k sonoffu za remote_routerem...

Klient muze serveru pravidelne posilat urcite statistiky.. v pripade sonoff s tasmotou treba aktualni spotrebu, uptime, firmware atd. Neni treba se ma tato data dotazovat.

diky, to zni zajimave, jak casto pravidelne? jestli by to slo vyuzit na "realtime", ted mam sbirane data z 8x SonoffPow kazdych 5s, nevim zda by se vyuzil teda realtime, ale zas pokud by tech Sonoffu bylo vice uz by to (tak jak to mam ted) nebylo kazdych 5s ale nasobne podle poctu Sonoffu, resp. nez "prisla rec" na MQTT tak sem si rikal ze bych ty http dotazy paralelizoval pri navyseni Sonoffu :)

Ak mal kolega na mysli posielanie telemetrických údajov, predvolená hodnota je 300s a dá sa zmeniť príkazom TelePeriod od 10s do 3600s. Nižšia hodnota ako 10s by sa asi dala nastaviť pri kompilácii (namiesto predvolenej), ale to som neskúšal.

Inak aj fw Tasmota je možné ovládať pomocou požiadaviek http, spomínam to v treťom dieli seriálu (info o stave vracia v json). Možno by stálo za to vyskúšať na jeden spínač nahrať firmvér Tasmota (pri napaľovaní sa dá zálohovať pôvodný firmvér) a vyskúšať komunikáciu oboma spôsobmi - Vašim súčasným a môžete experimentovať aj s MQTT.
Viac o ovládaní pomocou http je dokumentácii: https://tasmota.github.io/docs/Commands/#with-web-requests
prípadne tu: https://stevessmarthomeguide.com/control-smart-home-devices-http/

to sme si nerozumeli, ja mam prave uz roky flashle tasmotou SonoffPOW (fw kompilovanej s zmenenejma parametrama, prednastavenou wifi atd),
a to co sem psal pouziva prave ty Web prikazy volane pres wget pri generovani skriptu a pres php/curl pri nacitani stranky a/nebo tukani na prepinac on/off na strance :)

ta generovana stranka vypada takto

MQTT může být dobrý pomocník, ale podle mne zanáší do systému další možný poruchový prvek.
Většinou nevystačíte jen mqtt brokerem, ale máte nad tím ještě nějaký další controller.
A když se kterýkoliv z nich vysype, tak nemáte funkční nic.
Více se mi líbí cesta, kdy prvky, které mají komunikovat navzájem, komunikují přímo spolu.
Prostě vzdálený spínač pošle příkaz žárovce a žárovka pouze reportuje svůj aktuální stav do (např. v mém případě ) Domoticz. Stejně tak může Domoticz měnit její stav. A když vypadne ten Domoticz, pořád půjde ovládání žárovky vzdáleným spínačem - stačí, když bude fungovat síť.
Podobně ovládání rolet, garážových vrat atd.
A aktuální data pošle prvek pomocí htp volání do Domoticz kdykoliv je potřeba, nemusí čekat na dotaz.
Jen musíte použít skript když chcete poslat data nějakému prvku, který se probudí jednou za čas, třeba po uspání. To asi řeší mqtt automaticky.