Többször hangoztattam ugyan, hogy a Tasmota nem igazán alkalmas szenzorok készítésére, hiszen kapcsolónak készült, és az egész logikája így is épül fel, ellenben az utóbbi évek során sok érdekes képességet belefejlesztettek, valamint egészen jó a támogatása a régi 1MB méretű flash-el szerelt ESP8266-okra.

Különösen az integrálható automatizmusok, a szkriptelhetőség terén fejlődött sokat. Nehezítés egy kicsit, hogyha valami extrát szeretne az ember, jó eséllyel forrásból kell fordítania. 

Lássuk hát!

A szkripteknek három fajtáját támogatja a Tasmota, de nem mindet egyszerre és nem mindegyik eszközön.

1. Rules ("Szabályok")

Ezt minden előre fordított hivatalos bináris tartalmazza, aki ismeri az ESPEasy-t, hallatlan hasonlóságokat fedezhet fel az ON - DO - ENDON eseménykezelőkön alapuló működésben. Nincs új a nap alatt? :)

Például így veszünk fel egy szabályt, ami induláskor az RGBW izzót max fehér színre állítva bekapcsolja: (Consoles-Console alatt)

Rule1 on Dimmer#Boot do white 100; endon

És így engedélyezzünk ezt az az egyes számú szabályt:

Rule1 1

2. Scripting

Ez nincs belefordítva alapértelmezetten egyetlen Tasmota kiadásba sem, magunknak kell fordítanunk. Ez viszont kicsit más, működésében hasonlít a Rules-ra, de annál bővebb és más a szintaxisa. A blokkok/eseménykezelők nevei rövidek pl a >B blokk indításkor hajtódik végre a >S pedig másodpercenként, stb. Elég komplex dolgokat hozhatunk létre, ezzel oldottam meg például az áramkimaradást jelző e-mail küldő eszközömet.

3. Berry

Minden hivatalos Tasmota32 bináris tartalmazza. A Berry szkriptek már inkább valóságos programok, sokrétű dolgokat meg lehet vele oldani, akár egy új I2C eszköz támogatását is megoldhatjuk ilyen módon, tetszőleges ütemezést állíthatunk be, akár még új szabályokat is hozhatunk létre futásidőben.. 
Némileg hasonlít a nyelv a python-ra, így aki ismeri, előnyben van a használatakor.

Ami nagyon fontos:

• Rules vagy Scripting! A kettő közül egy időben csak az egyiket tudjuk belefordítani a Tasmotába, választanunk kell
• a Berry kizárólag ESP32-n működik

Akadt is egy feladat, nosza próbáljuk megoldani:

Arra gondoltam mi lenne, ha hőmérséklet adatokat küldenék át egy Teams csoportba. Megoldható a dolog, egy Incoming Webhook-ot kell felvenni a Teams-ben egy adott csoportra és már mehet is a küldés. A Webhook szolgáltat egy HTTPS címet, amire POST metódussal lehet JSON formában küldeni az adatokat.

HTTPS?

Nos igen, jellemzően ahhoz, hogy a saját belső hálózatunkban elérjük a helyileg telepített szerverünket, a sima HTTP teljesen elegendő, viszont ha támadna egy olyan gondolatunk, hogy milyen jó lenne egy önálló Tasmota eszköz, ami e-mailt küld vagy más módon jelez nekünk közvetlenül (Teams, Pushover, Thingspeak...), ahhoz már bizony kell az SSL támogatás.
Nem célom teljes tanfolyamot tartani az SSL-ről, fogadjuk el, hogy ez egy olyan titkosítási forma, ami az eszközünk és a szerver közti kommunikációt titkosítja, így külső figyelő nem láthatja például a jelszavainkat... egyúttal a kulcs egy tanúsítvány is, ami csak az adott webhelyre érvényes, ez a HTTPS (SSL+HTTP) lényege.
Hasonlóan működik ez az IoT eszközök által használt kétirányú MQTT / MQTTS kommunikáció, illetve a GMail által megkövetelt SMTPS (SMTP+SSL) esetén is.

A Tasmotával kapcsolatban azt kell tudni, hogy az ESP8266 esetén olyan kevés erőforrás áll rendelkezésre, hogy ez a valós idejű titkosítás nem csak lassítja, de a rendelkezésre álló memória is igen szűk, tehát csak korlátozottan alkalmas ezekre a dolgokra. Ellenben a fejlesztők beleégettek egy minimális MQTTS és SMTPS támogatást, így képesek lehetünk kapcsolódni olyan publikus MQTT szerverekre, mint például a HiveMQ vagy az AWS IOT, illetve GMail szolgáltatón keresztül e-mailt küldeni.

Az ESP32 erőforrásai sokkal jobbak, és gyorsabb is az eszköz (ráadásul az SHA/AES/RSA titkosítást hardveresen gyorsítja), így a fenti MQTTS és SMTPS támogatáson kívül a HTTPS is működik benne!

Fontos dolog még, hogy a fenti képességeket tipikusan a Tasmota forrásból történő fordításával és megfelelő paraméterezésével tudjuk elérni, mert ezek nem a normál kiadások képességei.

Ezek alapján aki HTTPS kérést szeretne elérni egyedi címre, csak ESP32-vel fog boldogulni. Illetve szólok előre, hogy a Rules nem tud POST-ot, csak GET-et, a Scripting tud POST-ot, de levágja a 120 karakternél hosszabb szövegek végét, a Teams webhook pedig hosszú, és amikor azt írom hosszú, úgy értem 200 karakter feletti... amit viszont a Berry kitűnően kezel, tehát meg is van az irányvonal, ESP32 + Berry!

A szkript készítése

Ugyan aránylag sok leírás van a Berry-vel kapcsolatban a Tasmota online dokumentációban, viszont a legtöbb elég általános, nagyon kevés példakóddal, pedig azokat én nagyon szeretem, érthetőbb mi, miért, mit csinál és hogyan kell paraméterezni. Különösen a Tasmota-specifikus dolgokra nehéz rábukkanni, azt például csak a github hibajelzések közt találtam meg véletlenül, hogy kell a szenzorinformációkat kinyerni. :D

Íme a szkript:

Feltettem github-ra is, hátha még lesz néhány ötlet, ami elfér mellette:

https://github.com/enesbcs/tasmota-custom-scripts

És akkor némi magyarázat a szkripthez:

A "wurl" változóba kell bemásolni az egyedi webhook címet, amit a Teams-ben létrehoztunk. A "callweb()" eljárás a paraméterként kapott "text" változó tartalmát egy JSON "text" mező értékévé teszi, és POST módon elküldi a megadott webcímre, ami ennyit fog kapni:

A "gettemp()" eljárás az, ami kinyeri a SENSOR tömbből a hőmérsékletadatot. A Tasmota Consoles-Console menüpont alatt lehet parancsokat beadni, illetve az eseménynaplót megtekinteni, ebben láthatjuk például, hogy az adott TelePeriod által meghatározott időben milyen szenzoradatok érkeztek, alapból az ESP32 belső hőmérője látszik csak, valahogy így:

Ám ha kötünk rá egy I2C hőmérőt, példának okáért egy HTU21-est, akkor azt is látni fogjuk a SENSOR nevű JSON-ban: (persze ha olyan firmware-t használunk, ami tartalmazza az I2C hőmérők támogatását és a Berryt is)

Tehát, ha egy HTU21 hőmérő adatait szeretnénk továbbítani, akkor a .be szkriptben erre kell módosítani a gettemp() megfelelő sorát:

Az utolsó sor pedig az add_cron segítségével beütemezi, hogy 30 másodpercenként történjen meg az adatküldés. Ezt egyébként talán célszerű ritkítani 5-10 percre, attól függően mennyire szeretnénk, hogy a Microsoft korlátozza a Teams szerverhez való hozzáférésünket. :D ("0 */10 * * * *")

Ha a "Manage File system" menüponton keresztül feltöltöttük a szkriptet, akkor az alábbi konzolparanccsal tudjuk is tesztelni:

Ha jól működik, akkor automatikusan indítani egy szabály segítségével tudjuk:

Rule1 ON System#Boot DO br load('teams_webhook.be') ENDON
Rule1 1

Vagy ha Scripting támogatású binárisunk van, akkor az alábbi szkripttel:

>D

>BS
=>br load("teams_webhook.be")

Ez persze csak egy egyszerű példa volt, rengeteg lehetőség van még a Berry-ben, saját I2C driver írásától kezdve a webes felület futásközbeni átalakításán át, akár egy saját UDP kezelő démon írásáig.