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:

hogyan néz ki a rules.json,
hogyan kell felépíteni a feltételeket (condition),
hogyan működik az időzítés és az ismétlés,
hogyan használhatod a plugin adatokat (PZEM, Shelly, Tasmota, stb.),
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:

ellenőrzi, hogy az url nem üres,
létrehoz egy HTTP kliens objektumot,
GET vagy POST kérést küld,
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).

PZIOT-E02 fogyasztásmérő – natív okosvillanyora.hu támogatással

2025.10.16. 463

A fázismérés svájci bicskája A PZIOT-E02 kétféle helyzetben adhat hatalmas segítséget: 1. Ha nincs P1 portos villanyórád Ilyenkor a PZIOT-E02 önálló fázismérőként működik. Egy fázison képes mérn…

Részletek

Miért fontos az inverter termelést is mérni?

2025.10.16. 379

A háztartási méretű kiserőművek (HMKE) tulajdonosai számára természetes, hogy figyelik a hálózatba történő visszatáplálást. Ez az érték mutatja meg, mennyi megtermelt energiát nem használ fel a há…

Részletek

Több mint ezer háztartásban segít a magyar fejlesztésű ADA P1 Meter a tudatosabb energiahasználatban

2025.12.22. 452

Az elmúlt időszakban egyre több magyar háztartásban vált fontossá, hogy ne csak a villanyszámlát lássák, hanem azt is, mi történik valójában a háttérben. Erre ad választ a debreceni fejlesztésű ADA P1…

Részletek