• A kosarad üres!

Automatizálás ADA P1 Meterrel – így működik a JSON alapú szabályrendszer

Az ADA P1 Meter (és a hozzá kapcsolódó ADA rendszer) nem csak adatot gyűjt a mérőóráról és plugin eszközökről, hanem saját szabályrendszert is futtat.
Ez a szabályrendszer egy JSON fájlban él (általában rules.json), és egy beépített értelmező (interpreter.cpp) dolgozza fel.


Ezzel a felhasználó:

  • feltételekhez köthet HTTP hívásokat (pl. Shelly, Tasmota, saját REST API),

  • be tud avatkozni fogyasztók működésébe,

  • egyszerűen, kódelőismeret nélkül építhet automatizációt.

Ebben a cikkben végigmegyünk:

  1. hogyan néz ki a rules.json,

  2. hogyan kell felépíteni a feltételeket (condition),

  3. hogyan működik az időzítés és az ismétlés,

  4. hogyan használhatod a plugin adatokat (PZEM, Shelly, Tasmota, stb.),

  5. kapni fogsz több konkrét szabálymintát.

1. A rules.json felépítése

A szabályrendszer egy JSON objektum, benne egy rules tömbbel:

{
  "rules": [
    {
      "id": "egyedi_azonosito",
      "enabled": true,
      "condition": "kifejezes",
      "min_timer_seconds": 0,
      "repeat": false,
      "repeat_delay_seconds": 0,
      "actions": [
        {
          "method": "GET",
          "url": "http://pelda-eszkoz/valami",
          "body": ""
        }
      ],
      "name": "Beszédes név"
    }
  ]
}

1.1. Egy rule mezői

Kötelező / fontos mezők:

  • id
    Egyedi azonosító. Ha üres vagy hiányzik, a rule gyakorlatilag kihagyásra kerül.

  • enabled
    true → aktív, false → teljesen figyelmen kívül hagyja a firmware.

  • condition
    Szöveges feltétel – akkor futnak az akciók, ha ez a kifejezés igaz (nem 0).

  • min_timer_seconds
    Minimum idő (mp-ben), ameddig a feltételnek folyamatosan igaznak kell lennie, mielőtt az akció lefut.

    • 0 → nincs késleltetés, „azonnali” rule.

  • repeat

    • false → egyszeri szabály: ha egyszer lefutott, vége.

    • true → ismétlődő szabály: a megadott késleltetéssel többször is lefuthat.

  • repeat_delay_seconds
    Ismétlődő szabály esetén a két egymást követő végrehajtás között kötelező szünet (cooldown) másodpercben.

  • actions
    HTTP hívások listája, sorban végrehajtva:

    • method: "GET" vagy "POST".

    • url: hívandó URL (ha üres, az akció kimarad).

    • body: POST esetén a küldendő JSON / adat (GET-nél üres lehet).

Opcionális, de hasznos:

  • name
    Csak embernek szóló név, UI-ban, logban jól jön („Kávéfőző bekapcsolás”, stb.).

2. Miből dolgozik a szabályrendszer? – a dataJson

A szabályok nem a levegőbe lőnek: minden ciklusban kapnak egy aktuális „adatcsomagot” egy JSON-ben (itt hívjuk dataJson-nak). Ez tartalmazza többek között:

  • P1 mérő adatok:

    • pl. voltage_phase_l1, current_phase_l1,

    • instantaneous_power_import, instantaneous_power_export,

    • active_import_energy_total, stb.

  • metaadatok:

    • os_version, local_ip, timestamp, meter_serial_number…

  • plugin adatok egy plugins objektum alatt.

Példarészlet (rövidítve az általad küldöttből):

{
  "local_ip": "192.168.31.139",
  "timestamp": "251204110620W",
  "voltage_phase_l1": "238.000",
  "current_phase_l1": "3.000",
  "instantaneous_power_import": "0.668",
  "instantaneous_power_export": "0.000",
  ...
  "plugins": {
    "PZEM_ip_l1":        { "value": "192.168.31.17" },
    "PZEM_power_l1":     { "value": "0.705" },
    "Shelly_power_02":   { "value": "0.075" },
    "Shelly_status_02":  { "value": "true" },
    "Tasmota_voltage_01":{ "value": "233" }
  }
}

A feltételekben ezekre a kulcsokra tudsz hivatkozni.

3. Feltételnyelv: mit tud a condition?

A condition egy szöveg, amit az interpreter kiértékel.
Az eredmény egy szám, és akkor számít igaznak, ha nem 0.

3.1. Támogatott operátorok

  • Logikai:

    • || – VAGY

    • && – ÉS

  • Összehasonlítás:

    • ==, !=

    • >, <, >=, <=

  • Aritmetika:

    • +, -, *, /

  • Zárójelezés:

    • (...) – ahogy megszoktad

3.2. Változók, literálok

  • Ha az egész kifejezés egy kulcs név (pl. instantaneous_power_import),
    akkor az interpreter a JSON-ból kiolvassa.

  • Ha pontot tartalmaz (plugins.Shelly_power_02.value), akkor
    beágyazott objektumokon mászik végig: plugins → Shelly_power_02 → value.

  • Ha nem kulcs, akkor megpróbálja számként értelmezni:

    • "10" → 10

    • "0.705" → 0.705

    • "true" → 1

    • "false" → 0

    • nem értelmezhető string → 0

Tehát ilyeneket simán írhatsz:

instantaneous_power_import > 3000
voltage_phase_l1 < 220 && current_phase_l1 > 5
plugins.PZEM_power_l1.value > 1500
plugins.Shelly_status_02.value == 1   // "true" → 1

Ha egy kulcs nem létezik, az értéke gyakorlatilag 0 – ezért a feltétel soha nem lesz igaz, ha csak arra támaszkodsz. Ilyenkor érdemes ellenőrizni, jól írtad-e a nevet.

4. Időzítés és ismétlés: min_timer_seconds, repeat, repeat_delay_seconds

Itt jön a „varázs” rész: a szabály nem csak azt tudja, hogy most igaz-e a feltétel, hanem azt is, hogy mióta az.

A firmware minden rule-hoz belső állapotot tart fenn (RuleState), amiben tárolja:

  • fut-e timer,

  • mikor indult,

  • lefutottak-e már az akciók,

  • ismétlődik-e, mikor volt az utolsó futás.

4.1. min_timer_seconds – mennyi ideig legyen igaz a feltétel?

  • Ha min_timer_seconds = 0:

    • a feltétel első igaz pillanatában azonnal lefutnak az akciók (ha még nem futott le korábban).

  • Ha min_timer_seconds > 0:

    • amikor a feltétel először igaz lesz, elindul egy belső timer;

    • ha a feltétel folyamatosan igaz marad, és letelik ez az idő, akkor futnak az akciók;

    • ha közben a feltétel „leesik” (hamis lesz), a timer reset, kezdheti elölről, ha újra igaz.

Ezzel tudsz olyat csinálni, hogy:

„Csak akkor lépjen közbe a rendszer, ha már legalább 10 másodperce 3 kW fölött vagyok.”

"min_timer_seconds": 10

4.2. repeat + repeat_delay_seconds – újrafuttatható szabály

  • Ha repeat = false:

    • a szabály egyszer fut – ha az akció lefutott, completed = true, többé nem fut.

  • Ha repeat = true:

    • a szabály többször is futhat,

    • de két futás között legalább repeat_delay_seconds-nek el kell telnie,

    • plusz minden futásnál újra érvényesülnie kell a min_timer_seconds logikának (ha nem 0).

Példa: ha percenként egyszer akarod ellenőrizni és kapcsolgatni a valamit:

"repeat": true,
"repeat_delay_seconds": 60

5. Akciók: HTTP GET/POST

A actions tömbben definiálod, mit csináljon a szabály, ha a feltétel igaz (és az időzítés is letelt).

Egy akció:

{
  "method": "GET",
  "url": "http://192.168.31.185/relay/0?turn=on",
  "body": ""
}

  • GET: tipikusan eszköz parancsokhoz (Shelly, Tasmota, saját endpointok).

  • POST: ha JSON-t vagy más payloadot küldesz (pl. valami REST API-nak).

Az interpreter minden akcióra:

  1. ellenőrzi, hogy az url nem üres,

  2. létrehoz egy HTTP kliens objektumot,

  3. GET vagy POST kérést küld,

  4. logolja a sikert / hibát a belső naplóban.

6. Példa: kávéfőző konnektor ki- és bekapcsolása

Vegyük a konkrét példádat egy Shelly pluggal (IP: 192.168.31.185). A kávéfőző be-kikapcsolását két rule-zal oldjuk meg.

6.1. Kávéfőző BE – ismétlődő szabály

{
  "id": "coffee_on_0730",
  "enabled": true,
  "condition": "voltage_phase_l1 != 0",
  "min_timer_seconds": 0,
  "repeat": true,
  "repeat_delay_seconds": 120,
  "actions": [
    {
      "method": "GET",
      "url": "http://192.168.31.185/relay/0?turn=on",
      "body": ""
    }
  ],
  "name": "SHELLY BE"
}

Mit csinál?

  • Feltétel: voltage_phase_l1 != 0
    → gyakorlatban „van feszültség a mérő szerint”.

  • min_timer_seconds = 0
    → amint igaz a feltétel és éppen „szabad” a szabály, azonnal hívja az URL-t.

  • repeat = true, repeat_delay_seconds = 120
    → max. 120 másodpercenként egyszer fut újra, ha közben a feltétel végig igaz marad.

Ez így egy „időnként bekapcsoló” rule, amit tipikusan valamilyen extra feltétellel kombinálsz (pl. konkrét időablak, PV termelés, stb.).

6.2. Kávéfőző KI – késleltetett kikapcsolás

{
  "id": "coffee_off_0750",
  "enabled": true,
  "condition": "voltage_phase_l1 != 0",
  "min_timer_seconds": 60,
  "repeat": true,
  "repeat_delay_seconds": 120,
  "actions": [
    {
      "method": "GET",
      "url": "http://192.168.31.185/relay/0?turn=off",
      "body": ""
    }
  ],
  "name": "SHELLY KI"
}

Itt:

  • ugyanazt a feltételt használod (voltage_phase_l1 != 0), ami tipikusan „mindig” igaz, amikor a mérő online,

  • de a min_timer_seconds = 60 miatt csak akkor kapcsolja KI a kávéfőzőt, ha legalább 60 másodperce folyamatosan fennáll a feltétel,

  • a repeat + repeat_delay_seconds miatt pedig ez a KI parancs 120 mp-es cooldown-nal ismétlődhet (ha így van értelme).

Reálisan egy ilyen „BE/KI” párost érdemes még további feltételekkel finomítani (időablak, plugin teljesítmény, stb.), de a mechanika jól látszik:

  • az egyik azonnali indítás,

  • a másik késleltetett visszakapcsolás / kikapcsolás.

7. Példák plugin alapú szabályokra

A plugins részben dinamikus kulcsok vannak, pl.:

"plugins": {
  "PZEM_power_l1":   { "value": "0.705" },
  "Shelly_power_02": { "value": "0.075" },
  "Shelly_status_02":{ "value": "true" }
}

Az interpreter ponttal tagolt kulcsfeloldást használ, tehát ilyen condition teljesen legális:

plugins.PZEM_power_l1.value > 2000

7.1. PZEM – túlterhelés L1-en

{
  "id": "pzem_overload_l1",
  "enabled": true,
  "condition": "plugins.PZEM_power_l1.value > 2000",
  "min_timer_seconds": 5,
  "repeat": true,
  "repeat_delay_seconds": 60,
  "actions": [
    {
      "method": "GET",
      "url": "http://192.168.31.170/cm?cmnd=Power%20Off",
      "body": ""
    }
  ],
  "name": "PZEM L1 túlterhelés"
}

Itt:

  • ha az L1-en mért teljesítmény (PZEM) 5 másodpercnél tovább 2000 W felett van,

  • a rendszer kikapcsol egy Tasmota plugot (Power Off),

  • és ezt legfeljebb percenként egyszer teszi meg ugyanarra a feltételre.

7.2. Kombinált feltétel – hálózati limit + plugin

{
  "id": "limit_import_or_shelly",
  "enabled": true,
  "condition": "(instantaneous_power_import > 2500 && voltage_phase_l1 < 220) || plugins.Shelly_power_01.value > 1000",
  "min_timer_seconds": 10,
  "repeat": true,
  "repeat_delay_seconds": 120,
  "actions": [
    {
      "method": "GET",
      "url": "http://192.168.31.185/relay/0?turn=off",
      "body": ""
    }
  ],
  "name": "Hálózat védelem + Shelly túlterhelés"
}

  • Ha vagy:

    • túl nagy az import (2,5 kW felett) ÉS beesik a fesz L1-en,

    • vagy az 1-es Shelly plug 1 kW felett van,

  • akkor 10 mp után lekapcsolja a Shelly 0. reléjét.

8. Tippek a szabályok tervezéséhez

  • Ne spammelj eszközöket
    Ha repeat = true, mindig állíts be ésszerű repeat_delay_seconds-t (pl. 30–300 mp), különben nagyon sűrűn kaphatnak parancsot.

  • Használj minimális időt zajos / billegő értékeknél
    Áramszint, teljesítmény gyakran átugrik a határ körül → ilyenkor a min_timer_seconds kisimítja a zajt.

  • Mindig ellenőrizd a kulcsneveket
    Ha elgépeled (pl. instantanous_power_import), az érték 0 lesz, és a condition soha nem igaz. A legjobb, ha a /json vagy /telegram válaszából copy-paste-elsz.

  • Először csak logolj / tesztelj
    Ha félsz az azonnali kapcsolgatástól, csinálhatsz olyan szabályt, ami egy saját HTTP endpointot hív (pl. egy debug szerverre), hogy lásd, milyen gyakran lenne akció.

  • Egyszeri vs ismétlődő logika tisztán

    • repeat = false jó egyszeri eseményekre (pl. „ha először léptem át ezt a küszöböt, csinálj valamit, aztán soha többé”).

    • repeat = true kell, ha folyamatos felügyeletet akarsz (pl. fogyasztás limitálása, töltés szabályozása).


Hozzászólások

Még nincs hozzászólás, légy te az első!