Egy mondatban
A GRID egy saját üzemeltetésű elektromos-autó töltőhálózat, amelynek teljes szoftveres hátterét házon belül fejlesztettük: a töltőhardver OCPP-vezérlésétől a felhasználókezelésen és fizetésen át a partneri elszámolásig. Nem újraértékesített dobozos megoldás, hanem önálló szellemi tulajdon (IP), amely 2020 óta éles üzemben, bevételt termelve működik az evdirect.hu alatt.
Mit nyújt a platform
Valós idejű vezérlés
Távoli töltés-indítás/-leállítás, kábelkioldás és élő telemetria bármely OCPP 1.6 töltőponton, 5 másodperces szinkronciklussal.
Automatizált fizetés
Banki szintű, tokenizált kártyás fizetés (Stripe), off-session terhelés, automatikus tartozás- és chargeback-kezelés.
Partneri (channel) modell
Többszereplős platform automatikus jutalék- és számlázómotorral, minden új partner új, skálázható bevételi csatorna.
Integrált zöld energia
Napelem (PV) és akkumulátoros tároló (BESS) valós idejű telemetriája ugyanazon a platformon, pl. a világelsők között zöldenergiás DC-töltő Aszófőn.
Az architektúra dióhéjban
Az új stack három saját szoftverkomponensből és egy háromplatformos kliensből áll, közös, HMAC-aláírással védett integrációs réteggel:
| Komponens | Szerep | Technológia | Állapot |
|---|---|---|---|
| GRID Backend | A „vezérlő agy”: OCPP-töltésvezérlés, valós idejű szinkron, energiamenedzsment, domain-adatok | Python · Django 5.2 · DRF · Celery · Redis · PostgreSQL | Új |
| User & Payment | Felhasználó-identitás, fizetés (Stripe), webshop, white-label tartalom | Python · FastAPI · SQLAlchemy 2.0 · PostgreSQL | Új |
| TOLTO.app | Üzemeltetői és partneri admin: jutalékmotor, riportok, ESS-monitor | PHP webalkalmazás · MySQL · HMAC REST-integráció | Új |
| Grid Töltő mobilapp | Végfelhasználói kliens: térkép, töltés, fizetés, shop, RFID | React Native 0.81 · Expo SDK 54 · TypeScript | Élesítés 1–2 hét |
| evdirect.hu | A jelenlegi éles rendszer (traction forrása) | WooCommerce + OCPP/STEVE | Kivezetés alatt |
Éles üzem, bizonyított, növekvő kereslet
A GRID nem koncepció: 2020 óta éles, bevételt termelő EV-töltőhálózat az evdirect.hu alatt. Az alábbi számok az éles szerverről (WooCommerce + OCPP/STEVE adatbázis) származnak, 2025. 12. 31-i adatzárással (a tört 2026-os évet kihagytuk az éves összevetésből).
Töltőpont-darabszám
A jelenleg élő, üzemelő töltőcsatlakozók száma 14; a due diligence során ezt a tényleges, üzemi számot tekintjük irányadónak. A hálózat fizikai bővítése a tőkebevonás egyik közvetlen felhasználási területe.
Üzleti modell (röviden)
| Csatorna | Leírás | Bevétel |
|---|---|---|
| B2C töltés | Regisztrált ügyfelek töltenek és töltésenként fizetnek mentett kártyával | Tranzakciós díj (Ft/kWh) |
| B2B / partner | Partnerek a saját töltőiket a GRID rendszerében üzemeltetik (partner-vezérlő) | Jutalék / üzemeltetési díj |
| Webshop | Kiegészítő termékek (töltők, kábelek, adapterek) ugyanazon ügyfélbázison | Termékárrés |
| Hirdetés | Helyszín-alapú, dinamikusan kezelhető hirdetési felületek a mobilappban | Hirdetési díj |
A cég rendelkezik minden szükséges, elektromos autó töltőberendezés üzemeltetői és e-mobilitás szolgáltatói MEKH-engedéllyel.
Egy integrált stack, tiszta rétegekkel
A rendszer a végfelhasználói és partneri csatornák, valamint a fizikai töltőhardver közötti központi vezérlőréteg. A jelenlegi állapot egy folyamatban lévő migráció: a 2020 óta éles, WooCommerce-alapú rendszert egy modern, három-komponensű saját stack váltja fel, fokozatosan, az éles üzem és a meglévő felhasználói bázis megzavarása nélkül.
Adatfolyam, hogyan illeszkednek a komponensek
A GRID Backend (Django) a rendszer „agya”: közvetlenül olvassa az OCPP-réteget tápláló STEVE MySQL adatbázist, a saját üzleti adatait viszont egy PostgreSQL adatbázisban tárolja, és ezt szolgálja ki, biztonságos, HMAC-aláírt REST API-n keresztül, a felsőbb rétegek (mobilapp, TOLTO.app) felé. A User & Payment (FastAPI) komponens a felhasználói identitást és a fizetést kezeli saját PostgreSQL adatbázisban, és HMAC-aláírt proxyn át éri el a GRID Backend töltőhálózati funkcióit. A TOLTO.app partner-admin mindkét backendhez hozzáfér: a hálózati/telemetria-adatokat a Django API-ból, a partneri üzleti logikát (jutalékkulcsok, hozzárendelések) pedig a saját adatbázisából szolgálja ki. A mobilapp a két backendre épül. Ez a tiszta szétválasztás teszi lehetővé, hogy az üzleti logika független legyen a fizikai hálózat technikai adataitól, és hogy a rendszer új hálózatokra és partnerekre is skálázható legyen.
Többadatbázisos integráció
A platform egyik erőssége, hogy öt adatforrást fog össze egyetlen koherens rendszerré, intelligens adatbázis-útválasztással (a dedikált router: gridbackend/routers.py). Ez teszi lehetővé, hogy az új stack a meglévő rendszerekre (STEVE, WordPress) kockázatmentesen ráépüljön, és a migráció ezeket ne zavarja meg.
| Adatforrás | Technológia | Szerep |
|---|---|---|
| Központi adatbázis | PostgreSQL | GRID Backend üzleti adatai: töltőhelyek, oszlopok, munkamenetek, árazás, szerepkörök |
| OCPP cache | MySQL (STEVE) | A töltőhardver állapota, tranzakciók, mérési értékek, Django közvetlen olvasással |
| User & Payment | PostgreSQL | FastAPI: felhasználók, kártyák, tranzakciók, webshop, tartalom (~24 tábla) |
| Frontend szinkron | MySQL | A webes/mobil fizetési adatok szinkronja (a kivezetés alatt álló WooCommerce frontend) |
| WordPress import | MySQL | A meglévő felhasználói bázis átemelése a régi rendszerből (migráció) |
| Cache / üzenetsor | Redis | Gyorsítótár + Celery aszinkron feladatütemezés és elosztott zárolás |
A migráció: régi → új
A WooCommerce-alapú rendszer minden funkcióját átveszi az új stack egy-egy dedikált, jól körülhatárolt komponense. A WordPress-import adatbázis kifejezetten azért létezik, hogy a meglévő felhasználói bázis adatvesztés és üzemszünet nélkül kerüljön át.
| Képesség | Régi, evdirect.hu (WooCommerce) | Új stack |
|---|---|---|
| Felhasználókezelés | WordPress felhasználók | User & Payment (FastAPI), 4 belépési mód, SMS-hitelesítés |
| Fizetés | WooCommerce fizetés | Stripe tokenizáció, off-session terhelés, automatikus tartozáskezelés |
| Töltésvezérlés | STEVE + részben kézi | GRID Backend OCPP-API, 5 mp valós idejű szinkron |
| Partneri elszámolás | kézi / hiányzó | TOLTO.app automatikus jutalék- és számlázómotor |
| Végfelhasználói kliens | reszponzív weboldal | háromplatformos natív mobilapp + web |
| Tartalom / arculat | WordPress | white-label CMS, távolról, app-frissítés nélkül |
A migráció nem „big bang” újraírás, hanem ráépülő modernizáció: a régi rendszer addig él, amíg az új komponensek élesednek, és a STEVE/WordPress adatbázisok read-only integrációja garantálja, hogy a 6 év alatt felépített felhasználói bázis és töltési előzmény ne sérüljön. Ez jelentősen csökkenti a technológiai átállás kockázatát.
Technológiai stack, összefoglaló
| Réteg | Technológia | Megjegyzés |
|---|---|---|
| Programnyelv (backend) | Python 3.11+ | Széles fejlesztői munkaerőpiac |
| Vezérlő backend | Django 5.2 · DRF 3.16 | Iparági standard, automatikus OpenAPI/Swagger |
| User & Payment | FastAPI · SQLAlchemy 2.0 · Alembic | Aszinkron, nagy teljesítményű; verziózott séma |
| Aszinkron feldolgozás | Celery 5.5 · django-celery-beat | Perzisztens, ütemezett háttérfeladatok |
| Cache / bróker | Redis | Gyorsítótár, elosztott zárolás |
| Adatbázisok | PostgreSQL ×2 · MySQL ×3 (STEVE/legacy) | Tranzakciós integritás + read-only integráció |
| Partner-admin | PHP webalkalmazás · MySQL | HMAC REST-integráció a backendekhez |
| Mobil/web kliens | React Native 0.81 · Expo SDK 54 · TypeScript | Egy kódbázis, három platform |
| Üzemeltetés | Nginx · systemd · SSL (Let's Encrypt) | Saját szerveren, teljes kontroll |
A teljes stack nyílt forráskódú, érett, jól dokumentált technológiákra épül, nincs vendor lock-in, nincs egzotikus függőség.
A vezérlő agy: valós idejű töltésvezérlés
A GRID Backend a fizikai töltőoszlopok (charge box-ok) és a végfelhasználói csatornák között álló központi réteg. Kezeli a töltési folyamat teljes életciklusát az indítástól a valós idejű mérésen át a leállításig és archiválásig, OCPP 1.6 protokollon, gyártófüggetlenül.
Domain modell
A platform a valós fizikai elrendezést tükröző, hierarchikus modellt valósít meg:
| Entitás | Szerep |
|---|---|
| Töltőhely (Location) | Földrajzilag elhelyezett töltőállomás GPS-koordinátákkal; ez jelenik meg a térképen |
| Töltőoszlop (ChargeBox) | Fizikai töltőegység; kezeli a beépített napelemes termelést és akkumulátoros tárolást is (napi/heti/havi/éves PV-energia, akku-töltöttség); automatikusan érzékeli az offline állapotot |
| Csatlakozó (Connector) | Konkrét töltőaljzat (Type2 AC / CCS DC); rögzíti a teljesítményt, feszültséget, áramot, és valós idejű státuszt tart fenn 11 lehetséges állapottal |
| Töltési munkamenet (ChargingSession) | Az éppen folyó töltés; befejezéskor CompletedCharge rekordként archiválódik |
| Felhasználó (User) | Szerepkör-rendszer: végfelhasználó, admin, partner, affiliate; céges adatok (adószám), kedvezmények, több autó |
| Autó (Car) | Felhasználóhoz rendelt jármű (rendszám, márka, akkukapacitás), pontosabb SoC-becslés |
| Fizikai azonosító (PhysicalIdentifier) | RFID-kártya, MAC-cím vagy Bluetooth-azonosító; akár ingyenes töltési jogosultság is köthető hozzá (partneri/munkahelyi töltés) |
| Árazás (Pricing) | Időalapú, kWh-ra vetített tarifa; egy csatlakozóhoz több sáv is rendelhető (idősávos tarifázás) |
A töltési munkamenet életciklusa
- Indítás kéréseA felhasználó (appon vagy RFID-vel) töltést kér; a rendszer ellenőrzi, szabad-e a csatlakozó, és automatikusan indítja a töltést.
- Távoli indításOCPP
RemoteStartparancs a fizikai oszlopnak; a töltő elindul. - Aktív töltésÉlő munkamenet jön létre, 5 mp-enként frissülő adatokkal: teljesítmény, energia, költség, akku-töltöttség (SoC).
- LeállításOCPP
RemoteStopparancs; a töltés befejeződik. - Archiválás
CompletedChargerögzül a végleges energia-, idő-, költség- és telemetria-adatokkal.
Vezérlési műveletek
API-műveletek
- Töltés indítása, adott csatlakozón, felhasználó- és autóhozzárendeléssel
- Töltés leállítása, folyamatban lévő töltés távoli lezárása
- Csatlakozó kioldása, a kábelzár feloldása (
UnlockConnector) - Aktív munkamenet lekérdezése, valós idejű adatok
- Élő hálózati állapot, a teljes hálózat pillanatképe egy lekérdezéssel
Intelligens üzleti logika az indításnál
- Automatikus autóválasztás egy jármű esetén
- Állapotellenőrzés: töltés csak valóban szabad/előkészített csatlakozón indítható, megelőzi a hibás vezérlést
- Árrögzítés: az indításkori ár a munkamenethez „befagy”, így nincs meglepetés az árváltozásból
Valós idejű szinkronizációs motor
A rendszer egyik kulcsképessége a folyamatos, 5 másodperces szinkronizáció, amely a fizikai hardver állapotát közel valós időben tükrözi a digitális platformon. Egy háttérfolyamat 5 mp-enként lekéri az OCPP-réteg legfrissebb állapotát, frissíti a gyorsítótárat, és kezeli a munkamenetek életciklusát: új töltés indulását érzékelve automatikusan létrehozza a munkamenetet (RFID-azonosító alapján beazonosítva a felhasználót), a futókat valós időben frissíti, a befejezetteket archiválja.
Párhuzamos feldolgozás
Egyetlen 5 mp-es ablakban frissül a teljes hálózat: csatlakozó-státuszok, akku-telemetria, PV-termelés, tranzakció-indítások/-leállítások, mérési értékek.
Elosztott zárolás
Redis-alapú lock biztosítja, hogy a szinkronciklusok ne fussanak egymásra; chunkolt betöltés kezeli a nagy adatmennyiséget (pl. PV-naplók 10 000 rekordos kötegekben).
„11 másodperces szabály”
Intelligens versenyhelyzet-feloldás arra az esetre, amikor a töltő leállítása és a munkamenet létrehozása időben átfedi egymást.
Beragadt munkamenet kezelése
Ha a töltő fizikailag befejezte a töltést, de a munkamenet „beragadt”, a rendszer automatikus kényszerleállítást (force-stop) küld.
Energiamérés fallback-logikája: ha a tranzakció záró mérőértéke hiányzik vagy nulla, a rendszer az utolsó valós mérési adatból számolja a fogyasztást, így soha nem vész el bevétel.
Integráció és kiterjeszthetőség
| Képesség | Részletek |
|---|---|
| Gépi (service-to-service) API | HMAC-SHA256 hitelesítés megosztott kulccsal, kérésaláírással, 30 mp-es időablakkal (replay-védelem), időzítés-rezisztens kulcsösszehasonlítással; kliensenként külön kulcspár, granuláris hozzáférés |
| Webhook (push) értesítések | Partneri rendszerek feliratkozhatnak egy oszlop eseményeire; állapotváltozáskor a rendszer automatikusan értesíti a klienst, eseményvezérelt integráció, nincs folyamatos lekérdezés |
| Nyilvános app-végpontok | Térképes megjelenítéshez optimalizált, beágyazott struktúra (helyszín → oszlop → csatlakozó); élő hálózati pillanatkép; távolról vezérelt app-konfiguráció (támogatás, min. verzió, karbantartási mód) |
| Automatikus dokumentáció | OpenAPI 3.0 séma, Swagger UI és ReDoc, gyors partner-onboarding |
Szimulációs motor, fejlesztési és üzleti gyorsító
A teljes töltési folyamat, indítástól a valós idejű energianövekedésen át a leállításig és archiválásig, fizikai hardver nélkül is lejátszható. A szimulált munkamenet valósághű teljesítményértékeket vesz fel (AC: 7,4 / 11 / 22 kW, DC: 50 / 100 / 150 kW), gyorsított időben futtatható (idő-szorzóval), és ugyanazt az üzleti folyamatot járja be (archiválás, webhook), mint egy valós töltés.
Demózhatóság
A teljes folyamat bemutatható befektetőknek, partnereknek valós töltő nélkül is.
Fejlesztési sebesség
Új funkciók tesztelhetők drága hardver és helyszíni jelenlét nélkül.
Terheléses tesztelés
A hálózat skálázhatósága szimulált munkamenetekkel vizsgálható.
Üzemeltetés és megfigyelhetőség
- Strukturált kérésnaplózás, minden API-hívás JSON-formátumban (módszer, útvonal, státusz, válaszidő, felhasználó)
- Érzékeny adatok automatikus maszkolása, jelszavak, API-kulcsok, aláírások soha nem kerülnek naplóba
- Futásidejű konfiguráció, debug-módok és beállítások adatbázisból, újraindítás nélkül
- Karbantartási üzemmód, a felhasználói réteg távolról „karbantartás alatt” állapotba helyezhető
- Perzisztens ütemezés, Celery + django-celery-beat, adatbázis-alapú feladatok, amelyek túlélik az újraindítást
Identitás, fizetés és bevétel-motor
A komponens végigkíséri a teljes ügyféléletutat a regisztrációtól a töltés kifizetésén át a kiegészítő termékek vásárlásáig, és egyetlen ügyfélbázison több bevételi forrást támogat: töltés, webshop, hirdetés. Réteges felépítésű (modellek, sémák, routerek, szolgáltatások, middleware), integráció-központú, API-first.
Identitás és onboarding
Rugalmas, többcsatornás belépés minimalizálja a regisztrációs súrlódást, ez közvetlenül növeli a konverziót.
Belépés (4 csatorna)
- E-mail + jelszó, erősség-ellenőrzéssel (min. 8 karakter, kis/nagybetű, szám)
- Google (OAuth 2.0, szerveroldali token-ellenőrzés)
- Apple Sign-In (App Store-követelmény; anonim e-mail relay)
Identitás-megerősítés
- E-mail-megerősítés időkorlátos tokennel (24 óra)
- Kötelező telefonszám-ellenőrzés SMS-kóddal, a fizetési kockázatkezelés alapja
- Jelszó-visszaállítás biztonságos, 1 órás tokennel
A fiókkezelés támogatja a profilképet (max. 5 MB, formátum-validáció), a magán- és céges (B2B) fióktípust (cégnév, adószám), a számlázási/szállítási címet, a fiók-állapotokat (aktív / deaktivált / felfüggesztett) és a soft delete-et (adatmegőrzési megfelelés).
Fizetés és számlázás
A rendszer soha nem tárol bankkártyaadatot, minden kártyaművelet a Stripe tokenizált infrastruktúráján keresztül történik (PCI-DSS megfelelés). Minden pénzügyi összeg egész számként, forintban (HUF) tárolódik, ez kizárja a lebegőpontos kerekítési hibákat.
| Képesség | Részletek |
|---|---|
| Kártyakezelés | Biztonságos mentés (Stripe SetupIntent), több kártya, alapértelmezett kártya |
| Off-session terhelés | A töltés befejezésekor a rendszer ügyfél-interakció nélkül levonja a díjat a mentett kártyáról |
| Visszatérítés | Teljes és részleges |
| Tranzakciós előzmény | Státuszkezeléssel: függőben / sikeres / sikertelen / visszatérített; valós Stripe-hibakódok (elutasítva, fedezethiány, lejárt kártya) |
| Automatikus tartozáskezelés | Sikertelen fizetésnél UnpaidCharge képződik; a felhasználó addig nem indíthat új töltést, amíg nem rendezi, megakadályozza a behajthatatlan követelések felhalmozódását |
| Chargeback-védelem | A Stripe webhookok automatikusan feldolgozzák az eseményeket; vita esetén a rendszer automatikusan felfüggeszti a fiókot |
Töltési integráció és RFID
A komponens a GRID Backenddel HMAC-aláírt proxyn keresztül kommunikál, így a mobilapp egyetlen API-n át fér a teljes töltőhálózathoz: helyszínek és élő állapotok lekérdezése, töltés indítása/leállítása, aktív munkamenet követése, RFID-kártyás (tap-to-charge) töltés, befejezett töltések előzménye telemetriával, PDF-számlák és nyilvános ártáblázat.
Beépített webshop, bevételdiverzifikáció
- Termékkatalógus (fizikai termék + szolgáltatás), kiemelt és akciós (áthúzott) árak, háromnyelvű leírások
- Rendelés a mentett kártyával; rendeléskövetés, jótállás-nyilvántartás, GLS csomagkövetés
- „Charging offers”, töltés közben megjelenő, helyszín-alapú termékajánlatok és időszakos kampányok
- Készletkezelés (raktárkészlet + korlátlan készlet szolgáltatásokhoz)
Engagement, értesítések és white-label tartalom
Többcsatornás kommunikáció
- Push (Firebase/Android + APNs/iOS)
- E-mail (Microsoft Graph / Office 365)
- SMS (SeeMe Gateway)
- Eseményvezérelt értesítések, felhasználó által csatornánként szabályozva; alkalmazáson belüli értesítési központ
Távoli tartalomkezelés (white-label)
- Kódmódosítás és app-frissítés nélkül vezérelhető az admin felületről
- Onboarding képernyők, arculati színek (világos/sötét mód), GYIK
- Hirdetések (helyszínre célzott, dátumtartománnyal, CTA-val)
- Verziózott, Markdown jogi dokumentumok (ÁSZF, adatvédelem); minden tartalom háromnyelvű (HU/EN/DE)
Adatmodell és belső API
A rendszer mintegy 24 összekapcsolt adattáblát kezel, integritás-védett (cascade delete) kapcsolatokkal, verziózott sémával (Alembic). A töltőhardver felé egy belső, IP-korlátozással és API-kulccsal védett gép-gép API áll: töltési jogosultság ellenőrzése indítás előtt (van-e mentett kártya, tartozás, felfüggesztés), munkamenet elszámolása, RFID-tulajdonos azonosítása.
Üzemeltetői és partneri admin
A TOLTO.app egy többszereplős (multi-tenant) admin platform, amely egyszerre szolgálja ki a hálózatüzemeltetőt és a hozzá csatlakozó partnereket (viszonteladók, helyszíntulajdonosok), miközben minden szereplő csak a saját adatait látja. Ez teszi skálázhatóvá a partneri (channel) üzletet az automatikus jutalék- és számlázómotorral.
Kétszintű adatmodell és szerepkörök
A platform a saját üzleti logikáját (jutalékok, partneri jogosultságok, számlázás) elkülöníti a fizikai hálózat technikai adataitól: a saját MySQL adatbázist a partnerekhez/jutalékokhoz használja, a valós idejű hálózati adatokat pedig a HMAC-aláírt REST API-n (GRID Backend) keresztül kapja.
| Szerepkör | Hozzáférés |
|---|---|
| Admin (üzemeltető) | Teljes hozzáférés: minden partner, ügyfél, töltő, tranzakció; árszabás, riportok, rendszerbeállítások |
| Partner (töltőpont tulajdonos) | Csak a hozzárendelt töltőit, ügyfeleit és bevételeit látja; saját havi elszámolásait lekérheti |
| Alfiók (sub-account) | A fő partneri fiók alá rendelt felhasználók, öröklött jogosultságokkal, egy partner akár 10 alfiókot is meghívhat |
A partneri adatszűrés mindig szerver oldalon történik (sosem kliensen). A partnerek az ügyfeleket csak pontos e-mail-egyezéssel vagy a telefonszám utolsó 7 számjegyével kereshetik, adatvédelmi okból.
Jutalékmotor (a bevételi logika)
Minden befejezett töltésnél automatikusan: jutalék = elfogyasztott kWh × partner jutalékkulcs (Ft/kWh); nettó bevétel = teljes díj − jutalék; majd havi aggregálás a partneri számlázáshoz. A jutalék akár hierarchikusan, több partner között is megosztható, és minden lezárt tranzakció auditálhatóan naplózódik.
Funkcionális modulok
Valós idejű vezérlés
control.php, élő töltőflotta-vezérlés böngészőből (AJAX): indítás, leállítás, csatlakozó-reset, kábelkioldás; csatlakozónkénti élő telemetria; 20 mp-es frissítés.
Élő irányítópult
index.php,10 mp-enként frissülő KPI-k: csatlakozó-statisztikák, aktív munkamenetek, napi nettó bevétel, nyitott support-jegyek; másodperc alatti betöltés kötegelt API-hívásokkal.
Interaktív térkép
map.php, Mapbox-alapú megjelenítés; helyszínenként élő popup a töltőkkel és színkódolt státusszal; egy kattintással a vezérlőfelületre.
ESS-monitor
ess.php, napelem (PV) és akku (BESS) valós idejű telemetria, partneri jogosultság-szűréssel (partner_batteries, can_view/can_control). Részletek a 8. fejezetben.
Ügyfél- és partnerkezelés
users.php / partners.php, ügyféladatok, párosítás bevétel-attribúcióhoz; partner-életciklus, jutalékkulcs, csatlakozó- és ESS-hozzárendelés.
Elszámolás és riportok
reports.php / monthly_reports.php, szűrhető tranzakció-elemzés; havi számlázási riportok automatikus sorszámozással (ÉÉÉÉ-NNN), PDF-export.
Analitika
results.php, összesítő KPI-k, időszakválasztók (7/30/90/365 nap), interaktív grafikonok (ApexCharts).
Árszabás-kezelés
pricing.php, tarifaszabályok (Ft/kWh), időalapú aktiválás, csatlakozóhoz rendelés, időzóna-kezelés (Europe/Budapest → UTC).
Ügyféltámogatás
tickets.php, teljes jegy-életciklus, prioritás/kategória, beszélgetésszálak, fájlcsatolmány (max. 10 MB), audit-napló, e-mail értesítés.
control.php valós idejű töltővezérlés (a zászlóshajó-funkció): élő telemetria és távoli vezérlés.
results.php): KPI-k és napi grafikonok.
monthly_reports.php): jutalék/nettó bevétel bontás.
charge_details.php): tranzakciónkénti energia, költség, tarifa.Az egységes platform (vezérlés + elszámolás + energia) egyetlen rendszerrel váltja ki a piacon jellemzően 3–4 különálló eszközt; a beépített partneri modell automatikus jutalékelszámolással minden új partnert új bevételi csatornává tesz, manuális elszámolás és hibakockázat nélkül.
Háromplatformos, fizetésre kész végfelhasználói kliens
A Grid Töltő egy már működő, éles backend-integrációkkal, valós fizetéssel (Stripe) és valós töltőhálózati adatkapcsolattal rendelkező mobilplatform iOS-re, Androidra és webre, nem prototípus, nem mockup. A felhasználó az appban végigviszi a teljes töltési életciklust a regisztrációtól a számláig.
Mit tud ma az app
Töltőkereső + térkép
Natív térkép (Android: Google Maps, iOS: MapKit), valós idejű elérhetőség színkóddal, legközelebbi töltő GPS alapján (Haversine), listanézet, kedvencek, átlátható bruttó (27% ÁFA) árazás.
Töltési folyamat
Indítás az appból, valós idejű követés (kWh, Ft, V/A, SoC, eltelt idő), leállítás egy gombbal, nyugta-szerű összegző és letölthető számla.
Fizetés
Stripe kártyatokenizáció (Setup Intent), több kártya, RFID/NFC tap-to-charge, tartozáskezelés, Apple Pay / Google Pay előkészítve.
Fiók és profil
SMS-hitelesítés, natív Google belépés, biometria (Face ID / Touch ID / ujjlenyomat), magán- és céges fiók, autóprofil, jelszó-visszaállítás deep-linkkel.
Beépített shop
Termékkatalógus, rendelésleadás és -követés GLS-szállításkövetéssel, garancia- és készletkezelés, akciós árazás.
Előzmények + push
Teljes töltési előzmény energia-/költségadatokkal, PDF-számlák, Firebase Cloud Messaging valós idejű értesítések.
Technológiai alap
| Réteg | Technológia |
|---|---|
| Keretrendszer | React Native 0.81 + Expo SDK 54 (legújabb stabil) |
| Nyelv | TypeScript (strict mód) |
| Állapotkezelés | Redux Toolkit 2.x |
| Navigáció | React Navigation 7 |
| Térkép | react-native-maps (Google Maps / MapKit) |
| Fizetés | Stripe React Native SDK |
| Hitelesítés | Google Sign-In natív SDK |
| Biztonságos tárolás | Expo Secure Store |
| Biometria | Face ID / Touch ID / ujjlenyomat |
| NFC / RFID | react-native-nfc-manager |
| Push értesítés | Expo Notifications + Firebase FCM |
| Lokalizáció | i18next (hu/en/de) |
| Build & CI/CD | Expo EAS (felhő-alapú build mindkét platformra) |
A háromplatformos app kész és demonstrálható. Az Apple Developer-fiók megérkezett, így az App Store / Google Play kiadás folyamatban, az app 1–2 héten belül élesíthető. Az élesedés előtti, ismert technikai feladatokat (titokkezelés, perzisztens session, automatizált tesztek, web-paritás, analitika) a 11. fejezet átláthatóan tárgyalja.
Integrált napelem + akku
A zöld-energia képességet, amit korábban már bemutattunk (beleértve a világelsők közötti, 100%-ban zöldenergiás DC-töltőt Aszófőn, evdirect.hu/vilagelso-100-ban-zoldenergias-dc-tolto-indult-aszofon), itt csak röviden, a technológiai stack teljessége miatt szerepel.
A platform megkülönböztető, a piacon ritka képessége, hogy a töltőhelyszínekhez telepített napelem- (PV) és akkumulátoros tárolórendszerek (BESS) valós idejű telemetriáját ugyanazon a felületen kezeli, ahol a töltőket is vezérlik. A monitorozott adatok közé tartozik a pillanatnyi PV-teljesítmény és a napi/heti/havi/éves termelés, az akkumulátor töltöttsége (SoC), egészségi állapota (SoH), feszültsége, árama, hőmérséklete, ciklusszáma és tárolt energiája. A nagy adatmennyiséget a rendszer automatikus mintavételezéssel (downsampling) optimalizálja a gördülékeny grafikonokhoz, a külső hőmérsékletet pedig Open-Meteo API-integráció szolgáltatja.
Többrétegű, due diligence-re felkészített védelem
A platform a B2B SaaS elvárásainak megfelelő, többrétegű (defense-in-depth) biztonsággal készült. A kontrollok a teljes stacken átívelnek, a fizikai hardver felé menő gépi API-tól a végfelhasználói munkamenetekig.
| Terület | Megoldás | Réteg |
|---|---|---|
| Gép-gép hitelesítés | HMAC-SHA256 aláírás kulccsal, időbélyeggel, 30 mp időablakkal (replay-védelem), időzítés-rezisztens összehasonlítással; IP-whitelist | Backend ↔ partner/hardver |
| Kártyaadat-védelem | Nincs helyi kártyatárolás, teljes tokenizáció Stripe-on (PCI-DSS) | Payment |
| Munkamenet-kezelés | Rövid élettartamú JWT access token (30 perc) + visszavonható refresh token (7 nap) | Payment / app |
| Jelszótárolás | Bcrypt egyirányú hashelés, automatikus újrahashelés, erősségi szabályok | Mind |
| Hozzáférés-vezérlés | Szerepkör-alapú (RBAC) minden végponton, szerver oldali adatszűréssel | Mind |
| CSRF / XSS / SQLi | CSRF-token minden állapotmódosító műveleten; minden kimenet escape-elve; kizárólag előkészített lekérdezések (PDO/ORM) | Web / partner |
| Rate limiting | Bejelentkezés (5 hibás → 15 perc zár), regisztráció (IP/e-mail), jelszó-visszaállítás | Auth |
| Munkamenet-sütik | HttpOnly, Secure, SameSite=Strict; login-kori session-regeneráció | Web / partner |
| OAuth | Minden közösségi token szerveroldali, kriptográfiai ellenőrzése | Auth |
| Visszaélés-megelőzés | Kötelező SMS-telefonhitelesítés; automatikus fiókfelfüggesztés chargeback esetén | Auth / Payment |
| Naplózás | Strukturált kérésnaplózás érzékeny adatok automatikus maszkolásával (jelszó, kulcs, aláírás) | Backend |
| E-mail kézbesítés | Microsoft Graph API (OAuth 2.0), verifikáció, jelszó-visszaállítás, meghívók, értesítések | Mind |
| Adatvédelem | Verziózott, többnyelvű jogi dokumentumkezelés (ÁSZF, GDPR-tájékoztató); soft delete adatmegőrzéssel | Mind |
Miért skálázható az architektúra
API-vezérelt szétválasztás
A fizikai hálózat és az üzleti réteg elkülönítve, új töltőhálózat vagy partner hozzáadása nem igényli az alaplogika átírását.
OCPP 1.6 szabvány
Bármilyen szabványos töltőhardverrel kompatibilis, nincs gyártói függőség; a tiszta API-réteg megkönnyíti a roaming (OCPI) irányt.
Multi-tenant + white-label
A többszereplős alap és a kódmentes tartalomarchitektúra kész a partner-/franchise-értékesítésre.
Teljesítmény
Aszinkron FastAPI connection poolinggal; kötegelt API-hívások, munkamenet-szintű cache, gzip, másodperc alatti irányítópult-betöltés.
Verziózott séma
Alembic migrációk, biztonságos, visszafordítható séma-fejlődés; régió- és nyelvfüggetlen adatmodell.
Nyílt, érett stack
Python/Django/FastAPI/PostgreSQL/Redis, széles fejlesztői munkaerőpiac, nincs vendor lock-in, alacsony technikai adósság.
Ismert feladatok és fejlesztési irányok
A due diligence érdekében nyíltan felsoroljuk az élesedés előtti, ismert technikai feladatokat. Ezek jól körülhatárolt, idő- és költségbecsülhető feladatok, nem architekturális kockázatok.
Mobilapp, élesedés előtti feladatok
| Feladat | Jelen állapot | Teendő |
|---|---|---|
| App-kiadás | folyamatban Apple Developer-fiók megérkezett | App Store / Google Play kiadás, 1–2 hét |
| Tartós munkamenet | Token memóriában | Perzisztens bejelentkezés a jobb UX-ért |
| Tesztlefedettség | Manuális QA | Automatizált egységtesztek az üzleti logikára |
| Web-paritás | iOS/Android natív kész, web részleges | NFC/biometria/fizetés finomítása weben |
| Analitika | Nincs beépítve | Termék-telemetria a döntésekhez |
Növekedési és termékfejlesztési irányok
A meglévő architektúra szilárd alapot ad a magasabb hozzáadott értékű bővítésekhez:
- Nyilvános mobilapp-kiadás, a kész app élesítése a következő növekedési ugrás kapuja
- VPP / energia-aggregáció, az ESS-modul
can_controljogosultságára építve (akkumulátor-vezérlés, peak shaving) - Intelligens, PV-vezérelt töltés, a napelemes termeléshez igazított töltési ütemezés (önfogyasztás-optimalizálás)
- Dinamikus, terhelés-alapú árazás, az időalapú/idősávos tarifázás alapja már megvan
- Roaming / hálózatközi integráció (OCPI), a szabványos OCPP-alap és a tiszta API-réteg megkönnyíti
- Fehércímkés (white-label) kiadás további hálózatüzemeltetőknek, a multi-tenant alap kész
- Prediktív karbantartás, a részletes telemetria (akku SoH, hibakódok, offline-érzékelés) megalapozza
- Hálózati bővítés, a jelenleg 14 élő csatlakozó fizikai bővítése
Éles, működő, saját IP, skálázásra kész
A GRID egy érett, éles üzemben működő EV-töltőplatform, amely az üzemeltetés és a kereskedelmi hasznosítás teljes munkafolyamatát saját fejlesztésű, modern technológiai stackbe integrálja: valós idejű OCPP-vezérlés, automatizált fizetés és partneri elszámolás, integrált zöld-energia menedzsment és háromplatformos kliens.
| Erősség | Üzleti jelentőség |
|---|---|
| Éles, működő rendszer 2020 óta | Bizonyított kereslet, alacsonyabb technológiai kockázat, nem koncepció |
| Saját, teljes stack (IP) | Nincs platformfüggőség, nehezen másolható; OCPP backend, API, fizetés, partner-vezérlő házon belül |
| Valós idejű (5 mp) architektúra | Prémium felhasználói élmény, valós idejű üzleti döntések, magasabb rendelkezésre állás |
| Több bevételi forrás egy ügyfélbázison | Töltés + webshop + hirdetés + partneri jutalék |
| Beépített pénzügyi kockázatkezelés | Automatikus tartozás- és chargeback-védelem |
| Skálázható és white-label-re kész | Multi-tenant alap, OCPP-szabvány, tiszta API, a növekedés a termékbe van építve |
| Mobilapp | Kész app, Apple-fiók megvan, élesítés 1–2 hét, közeli növekedési katalizátor |
A jelenleg futó migráció kockázatmentesen modernizálja a 6 éve éles rendszert: a régi adatbázisok read-only integrációja megőrzi a felhasználói bázist és a töltési előzményt, miközben az új, három-komponensű stack skálázható alapot ad a jövőbeli, magas hozzáadott értékű funkcióknak, a PV-vezérelt töltéstől a virtuális erőműig.