Bitek mindenhol, avagy okos tárgyak

ESP32-S3 7" RGB kijelzős adatgyűjtő

eNeS — Mon, 12 Oct 2026 11:00:28 +0200

Egy elektronikus tájékoztató tábla kapcsán vásároltam tesztre egy ilyen kijelzőbe épített ESP32-S3 eszközt.
A projekt aztán tárgytalanná vált, így kerestem neki alternatív felhasználási lehetőséget.

Térjünk is rá a felhasználásra: némi töprengés után beugrott, mire tudnék egy touch nélküli kijelzőt használni, amiben van wifi és bluetooth is. Gondolom mindenki látott már egyszerű időjárás állomást, egy beltéri kijelző, 1-2 db vezetékes vagy vezeték nélküli hőmérővel. Egy ilyen beltéri, BLE hőmérők adatainak gyűjtésére szolgáló megoldást aránylag könnyen meg lehet oldani ezzel a kütyüvel. (Gondoltam én...)

A hardver:

"ESP32-S3-Touch-LCD-7" és "ESP32-S3-LCD-7" találhatóak meg, a touch-os értelemszerűen drágább, és az elejére ragasztott érintőkijelző miatt láthatólag fizikailag nagyobb is, mint a sima. Én touch nélkülit vásároltam, mert eredetileg nem volt célom bevitel kezelése. (bár utólag belegondolva a touch vezérlés bármikor jó lehet, de mostmár mindegy)
Megszoktam már, hogy az engem érdeklő speciális tételeket nem lehet kapni Magyarországon, ezért még én is meglepődtem, hogy itthon is ESP32-S3-Touch-LCD-7-est kapni, bár olyan áron, hogy még a +3 EUR büntetővámmal is megéri Kínából rendelni.

A ketyere lelke egy ESP32-S3N16R8 Wi-Fi Bluetooth SoC 240 MHz sebességgel, főbb paraméterei: 512KB SRAM + 8MB PSRAM, 16 MB Flash tárhely.
A korábban általam használt I2C és SPI illesztésű kijelzőkhöz képest ezen párhuzamos RGB LCD illesztő van, ami 16 biten kommunikál, (ezzel 16 GPIO-t elhasználva + a szinkronizációs és vezérlőjelek számára szükségesek) nagyobb sávszélességgel 800x480 felbontással 65K színmélységgel, és elég jól látható 7" mérettel.

Ha valakiben ilyen ötlet motoszkálna, azt már az elején érdemes tisztázni, hogy az ESP32-S3 hardveres videodekóder nélkül nem ideális általános videolejátszásra. Egyszerűbb kodekkel, kis felbontással és alacsony képkockasebességgel elképzelhető szoftveres lejátszás, de ezt külön tesztelni kellene.

A teljes leírása:
https://docs.waveshare.com/ESP32-S3-Touch-LCD-7

Az eszközre úgy tudunk firmware-t tölteni, ha a 15-ös kapcsolót átbillentjük UART1 állásba és az UART1 feliratú USB-vel összekötjük gépünket USB-C USB-A kábellel, a 16-os BOOT gombot nyomva tartva megnyomjuk a 17-es RESET gombot.

A 4-es SD kártya foglalat hasznos lehet, ha például képeket szeretnénk megjeleníteni rajta váltakozva, esetleg még webes felületen a képcserére is lehet biztosítani felületet, ez volt az egyik első tervem, de az időjárásállomásba végül nem került bele.

A készülék oldalán sorakozó csatlakozók nagyon ígéretesnek tűnnek elsőre, de átnézésük után már árnyaltabb a kép:

1. van egy PH2.0 csatlakozó külső 3.7V akku bekötésére, ami néhány órányi működésre elegendő tartalékot adhat a kijelzőnek, mondjuk áramszünet esetére. Egy CS8501 töltőáramkör kezeli az akkut és adja a VBUS-ra direktben az 5V-ot, valamint a töltésjelző LED-ek is erre vannak kötve. Szoftveresen nem tudjuk meg az akku feszültségét, állapotát, de abból sem nyerünk sok információt, hogy az USB csatlakozón van-e áram, mert a CS8501 akkor is ráadja az 5V-ot a VBUS-ra, ha nincs áram. Összességében az akku feszültségét egy feszültségosztó létrával tudhatjuk csak meg, egy szabad ESP32 GPIO-ra kötve. Ha találunk ilyet. Említettem ugye, hogy 16 db-ot elhasznál a kijelző?

2. a 13 és 14 tüskék csak a CAN és RS485 lezáró ellenállások a vonal végére, ha szükségesek, praktikus.

3. a 9 és 11 a CAN és RS485 csatlakozók nem az ESP32-re, hanem egy SP3485EN és TJA1051T/3/1J átvivőre vannak kötve, tehát ezeket nem tudjuk szabad GPIO-ként használni

4. itt van még a 10-es I2C header, amire külső I2C eszközt csatlakoztathatunk, mondjuk egy I2C IO portbővítőt, ha szeretnénk még GPIO-kat használni. Egyébként már egy portbővítő van ezen az I2C buszon, tehát szabad GPIO-ként önállóan nem tudjuk használni, a beépített CH422G portbővítőhöz szükséges libraryt mindenképpen szükséges befordítani, inicializálni és használni, mert példának okáért ez kapcsolja be a kijelző háttérfényét. Ha pedig van touch, akkor szintén ezen az I2C vonalon van, ami nevesen a GPIO8/GPIO9-et használja.

5. és akkor végül de nem utolsósorban marad a 8-as Sensor AD csatlakozó, ami a GPIO6-ra van kötve, digitális vagy analóg bemenet is lehet, gyakorlatilag ez az egyetlen szabadon hozzáférhető és használható GPIO a lapon az ESP32-ről. Ezt ízlés szerint használhatjuk az akku feszültség figyelésére, ha bekötjük, vagy nyomógombnak, vagy mozgásérzékelőnek. De ha egynél több dolgot szeretnénk, marad a kiegészítő IO bővítő az I2C-re.

6. Jut eszembe, aki a kijelző tetején (én úgy vélem ez a teteje, mert ott az antenna, de nézőpont kérdése) levő BOOT gombot szeretné felhasználni, lebeszélném róla, mert a GPIO0-ra van kötve, ami egyúttal az RGB kijelző zöld 3-as bit adatát hordozza, így nyomkodása működés közben fura kijelzőhibákat fog eredményezni.

A szoftver:

Támogatja az ESPHome is, a fórumot olvasgatva láttam, hogy 2025 december környékén sok wifi és OTA frissítési hibát tapasztaltak - bár szerintem a lefagyások oka a kijelző kezelésében keresendő, sőt konkrétan az SRAM heap memóriát gyanítom a háttérben.

Megvan a legendás mondat, hogy 640 kilobájt RAM mindenkinek elég lesz? Na 512KB se lesz elég...

Érdekesség: A mondat egyébként nem így hangzott el, hanem valószínűleg valahogy úgy, hogy 640kb elég lesz a következő 10 évben mindenkinek. Erről vallott is később Gates:
„Meg kell mondanom, hogy 1981-ben, amikor azokat a döntéseket hoztuk, úgy éreztem, hogy 10 évre elegendő szabadságot biztosítok. Vagyis a 64k-ról 640k-ra való lépés olyasminek tűnt, ami nagyon hosszú ideig ki fog tartani. Nos, nem így lett – alig 6 évbe telt, és az emberek elkezdték ezt valós problémaként látni."

Az ESP32-S3 erőforrásai nem alkalmasak egy modern, teljes értékű böngésző és a teljes Home Assistant dashboard natív futtatására. Ezért a teljes webes felületet nem lehet egyszerűen úgy megjeleníteni rajta, mint egy tableten.

Persze létezik olyan projekt is (Remote WebView), ami a Home Assistanton egy virtuális gépben futtat egy desktop Chrome böngészőt, és annak a képét küldi át direktben egy ESP32-es kijelzős dashboardra (nem az ESP32 rendereli az oldalakat), ezzel azt az illúziót keltve, mintha futna egy böngésző rajta. Kreatív megoldás? Igen. Erőforráshatékony? Nem.

Úgy döntöttem végül, próbát teszek és készítek egy egyedi firmwaret, no nem azért, mert okosabbnak gondolom magam az ESPHome fejlesztőinél, inkább a kíváncsiság hajtott. Hiszen manapság mi sem egyszerűbb, csak elmondja az ember egy MI-nek, hogy milyen programot szeretne, és az elkészíti. Mondjuk az ember utána napokon át keresheti benne a hibákat. :D

Az ESPHome is támogatja az eszközt, én azonban a natív ESP-IDF és FreeRTOS alapú fejlesztés mellett döntöttem, PlatformIO környezetben. A gyártói példaprogramból indultam ki, és közvetlenül az ESP-IDF API-jait használtam.

Akit nem érdekelnek a részletek, lapozzon rögtön a Firmware részre.

A gyártó ad némi támpontot a kiinduláshoz a fejlesztőknek:

https://github.com/waveshareteam/ESP32-S3-Touch-LCD-7

Az első tesztprogram egész jól sikerült, nagyon boldog voltam, amikor sikerült lefordítanom a gyártói LVGL demot és el is indult, és még képet is láttam. Aztán elkezdtem mindenféle objektumokat és betűméreteket használni egy üres projektben a demo alapjain. Amikor nekikezdtem nyáron, még csak LVGL8 támogatás volt a példaprogramjaikban, átírtam hát LVGL9-re, mert először azt hittem a régi LVGL8 és az új ESPIDF inkompatibilitás a fagyások oka. Aztán egy hónappal később feltették a hivatalos LVGL9 támogatást is a Waveshare githubra... 2024-ben jelent meg az LVGL9 architektúra, nem siették el a srácok. Tudom, ne elégedetlenkedjek folyton, de a kínai eszközök gyártói szoftveres támogatása néha komolyan kétségbeejt.
De önmagában az LVGL9 nem oldotta meg sajnos a hibát. Az ESPIDF magát a kijelző Frame Buffer-t (ami a képernyő méretétől függ, pl 800x480x2= 768 000 byte), a PSRAM-ban tárolja, ez nem is nagyon férne a kis méretű SRAM-ba. Viszont van még egy kis méretű Draw Buffer is, na ha ez átkerül a PSRAM-ba, akkor jönnek a problémák, méghozzá látványosan: a WiFi és Flash hozzáférések közben terhelés alatt elkezd szétcsúszni a kép.
Úgyhogy a projekt első és legfontosabb szabálya: DrawBuffer csak SRAM-ba tehető. A PSRAM használatával olyan képhibák jelentkeztek, amelyek a memória-sávszélesség és a DMA-adatátvitel korlátaival magyarázhatók.
Ugye ez így leírva milyen egyszerű? Aham, csak egy napig kerestem a hibát elsőre.

Sajnos egyébként ez sem 100%-os megoldás, az OTA-frissítés további problémát okozott, mert a flashműveletek és a kijelző folyamatos adatellátása nehezen összeegyeztethető. Hirtelen fapados megoldásom erre az volt, hogy OTA előtt kikapcsoltam a kijelzőt, utána be. Aztán továbbgondoltam a dolgot, és átálltam a Tasmota által használt safeboot partíciós egy slotos firmware frissítésre, így a probléma megszűnt probléma lenni, mert az egyszerű safeboot úgysem kezeli a kijelzőt.

Az ESP-IDF RGB LCD meghajtójának dokumentációja konkrétan leírja, hogy a PSRAM sávszélességének hiánya képhibát okozhat.
Egy ismerősöm erre azt mondaná "bottleneck", én inkább csak simán azt mondom szűk keresztmetszet. Egyből beugrott régi professzorom kedvenc mondata is "A cache-ek feloldják a szűk keresztmetszeteket".. az Espressif Systems mérnökei azonban nem ugyanoda jártak, ahova én, így ráhagyják a megoldást a fejlesztőkre, hogy szoftveresen kerüljék meg a problémát.

Ennyit az első LVGL hibáról. Utána különböző méretű szövegekkel kísérleteztem és a Raspberry Pi-n végzett hasonló projekt alapján Truetype betűtípust használtam, ehhez szükséges TTF libraryval. Na ezek után jöttek az újabb random fagyások Végül sikerült leszűkítenem, hogy akkor fogy el az SRAM (ismét), amikor egy nagyobb betűtípust írok ki, és a font glyph gyorsítótárának csökkentésével megoldódni látszott a hiba. Egy darabig. Mert amikor ismét előjött egy nappal később, akkor felhúztam magam egy cseppet, és a szükséges méretű fontokat legeneráltam fix méretben, beágyaztam a forrásba, és akkor szűntek meg végleg az ilyen jellegű hibák.

A Bluetooth-stack bekapcsolása után újraindításkor a rendelkezésre álló belső memória annyira lecsökkent, hogy a Wi-Fi inicializálása vagy működése már nem volt megbízható. A tapasztalatok alapján a belső RAM korlátozott kapacitása volt a szűk keresztmetszet.

És hogy miért rugózom ennyit ezen az SRAM/PSRAM kérdésen? Az SPI illesztett PSRAM 10x lassabb elérésű (általánosítás a nagyságrend érzékeltetésére, sok tényezőtől függ), mint a beépített SRAM, tehát érezhető lassulást okoz, ha sok adatot használ onnan az ESP32. Másrészt nem mindent lehet áttenni oda az SRAM-ból, a DMA-IRQ megszakításokat kezelő folyamatokat egyáltalán nem, és van amit maga az ESPIDF nem enged áthelyezni. És van, amit az RGB kijelző miatt nem érdemes áthelyezni, jusson eszünkbe, hogy a PSRAM sávszélesség túlhasználata kijelzőhibákat fog okozni.
Némi küzdelem után a NimBLE használatával sikerült annyira minimalizálnom a memóriahasználatot, hogy max 1 Bluetooth kapcsolatra korlátozással elindult a Wifi és a Bluetooth is egyidőben. A NimBLE kisebb memóriaigényű alternatívának bizonyult a projektben használt Bluetooth-stackhez képest. A firmware-ben passzív szkennelést használok, mert a cél kizárólag a BLE-hirdetési csomagok (advertisement) fogadása és dekódolása, nem pedig a hőmérőkkel való aktív kapcsolatfelvétel.

Ezt követően kialakítottam a grafikai dizájnt, az ikonokat, a kártyák elrendezését, és 12 db-ban határoztam meg a maximumot, 1x1 - 3x4 választható felosztásban, amihez dinamikusan választ megfelelő betűméretet és ikonokat a program. Webes felületen a Display-ben lehet felosztást állítani, a Dashboard-on pedig a kártyához kiválasztani a megfelelő szenzort, és olvasmányosabb nevet adni neki.

Miután mindez működött, felismerte a Xiaomi/ATC/BTHome protokollal működő hőmérőket a házban és jöttek az adatok, újabb ötleteim támadtak, korábbi tapasztalataim alapján a Home Assistant WebSocket-en keresztüli lekéréseket és a Shelly MQTT adatgyűjtést is beépítettem, csak úgy mellesleg. A Data Source menüben lehet beállítani, hogy melyik adatforrásból dolgozzon. És igen, egyszerre csak egy adatforrás lehet aktív. Hogy miért? Természetesen az összesen 512KB SRAM az oka.

A HA eszköz registry-jét websocketen megszerezni könnyű, de feldolgozása nem annyira, egy ESP32 szemszögéből. Nálam nincs olyan sok szenzor, de 0.5MB méretű JSON volt, első körben PSRAM-ba tettem az egészet, aztán kitaláltam, hogy darabokban átnézettem letöltés közben és csak a hőmérséklet-páratartalom-akku-rssi eszközöket mentettem el. Ha még nem említettem volna időjárásállomás volt a kitűzött célom, így ezekre fókuszáltam. :)
A Shelly MQTT támogatást is beépítettem, mert miért ne? Induláskor küld announce felhívást MQTT-n, és ha van online Shelly, akkor válaszol és a hőmérőket felsorolja a felület. Ha alvó állapotban van a Shelly, akkor előtte célszerű kézzel felébreszteni, a kezdeti ismerkedéshez.

Az Integration fülön lehet Home Assistant MQTT kapcsolatot beállítani rajta, amin AutoDiscovery segítségével beregisztrálja a kapcsolóját, hogy távolról lehessen be-kikapcsolni a kijelző háttérvilágítását - fényerőállítást nem tud a hardver. Persze HA nélkül is létezik élet, ezért http post-al is be lehet:

curl -u admin:admin -X POST "http://IPCIM/api/display?on=1"

vagy ki lehet kapcsolni:

curl -u admin:admin -X POST "http://IPCIM/api/display?on=0"

Hogy miért MQTT AD és miért nem WebSocket? Ha valaki megírja nekem hogyan lehet kizárólag websocketen, külön program nélkül állandó szenzort létrehozni HA-ban, akkor legközelebb úgy csinálom, de én magam nem találtam erre megoldást, az AutoDiscovery viszont egyszerű és működik.

A biztonság kedvéért tettem bele egy Watchdogot is, hogy lefagyás helyett induljon újra, de első tesztjeim alapján a memóriaelfogyás típusú hibákat sikerült kiiktatnom. Nem mondom, hogy nem lehetne okosabb még a program, nem kezelhetne több mindent, de Proof-Of-Concept programnak szerintem megfelel, nem tervezek bele egyelőre több funkciót. A projekt neve L7 Display, alcíme: "Na ugye hogy lehet stabilan futó programot írni erre az istencsapására?" :D

És hogy mi látszik a kijelzőn?

A projekt eredeti célja: beltéri időjárásállomás készítése Bluetooth hőmérők adatainak gyűjtésére, önállóan, külön szerver nélkül, amire teljes mértékben alkalmas is. Aztán járulékosan jött a többi lehetőség.

Firmware

A projekt forráskódja elérhető itt:

https://github.com/enesbcs/e32l7wdisplay

A bináris pedig a release-ek között:

https://github.com/enesbcs/e32l7wdisplay/releases

ESPTool segítségével a factory image fájlt kell kiírni rá első alkalommal, a későbbiekben OTA módon is frissíthető lesz majd:

esptool.py --chip esp32s3 --port /dev/ttyACM0 --baud 460800 \
  write_flash 0x0 factory-8mb.img

Első indításkor hotspot AP módban indul esp32-xxxxxx néven, jelszó nélkül, a sok X az eszköz MAC címének a vége lesz. Alapértelmezetten a jelszó admin / admin . Gondolom aki látott már régi TP-Linket, értékeli az iróniát. :)

Ítélet:

HA dashboardnak én nem ezt használnám, inkább egy Androidos tabletet.
De amennyiben tisztában vagyunk a korlátaival és elfogadjuk azt, bizonyos célfeladatokra jó lehet.
Hogy mondjak valami pozitívumot is róla? Szépek a színei.

DIY ESP32 termosztát saját firmware-rel

eNeS — Sun, 20 Sep 2026 12:23:53 +0200

Néhány éve már készítettem egy saját WiFi-s termosztátot, ami ESP32-re épült, és Tasmotával működött. Akkor még egy 128×128-as színes TFT kijelzőt is raktam rá, a termosztát működését pedig egy saját Berry szkript intézte a motorháztető alatt. Amiről viszont akkor nem írtam, hogy nem volt előzmény nélküli a dolog, volt egy prototípusa még előtte, ami most pakolás során kezem ügyébe akadt, így nézett ki:

A projektet úgy tudnám leírni, hogy "a kéznél levő, olcsó vagy könnyen beszerezhető modulokból hogyan rittyentsünk egy termosztátot gyorsan". :) Ezen még MicroPython alapú firmware volt, (nem volt túl gyors) tehettem volna rá Tasmotát is, de most ahogy kezembe akadt, felmerült, hogy lehetne erre saját firmwaret is írni. Elővettem hát a Berry szkriptet (ami a működés javát végzi) és írtam köré egy működő vázat.

A külseje nem lett túl látványos, de nem is volt célom. Egy fekete műanyag doboz, középen egy apró OLED kijelzővel, jobb felül a forgóenkóderrel, alatta pedig a mozgásérzékelővel. A kijelzőn alapállapotban az aktuális és a beállított hőmérséklet látható. A forgóenkóderrel lehet a kívánt hőmérsékletet állítani, a nyomógombjával pedig a fűtést ki- és bekapcsolni. A mozgásérzékelőt pedig egyszerűen csak arra használom, hogy ha valaki a termosztát közelében jár, akkor felébressze a kijelzőt, ha nincs aktivitás, akkor pedig kikapcsolja. (a kép beégése elleni védelem)

Hardver

ESP32 D1 Mini v1.0
128×64-es SSD1306 OLED I2C kijelző
AM312 PIR mozgásérzékelő
3 V-os relémodul
forgóenkóder modul nyomógombbal
AM2320 I2C hőmérő/páratartalom-érzékelő
12 V → 5 V DC-DC step-down modul
egy kész műanyag projektdoboz
némi vezeték, sorkapocs és természetesen a szokásos mennyiségű melegragasztó. :)

A színes 128×128-as SPI TFT helyett egy teljesen egyszerű, 128×64 pixeles I2C OLED van benne. Ez nemcsak olcsóbb és kisebb, hanem programozni is sokkal egyszerűbb, kevesebb memóriát igényel, és a kijelző frissítése is gyorsabb, mivel lényegesen kevesebb adatot kell átküldeni.

Belül kicsit érdekes a helyzet. A D1 Mini, a relé, a DC-DC átalakító, az AM2320 és a különféle csatlakozások próbáltak elférni valahogy. A képeken jól látszik, hogy ez már az a kategória, ahol a „majd csak belefér” tervezési módszer érvényesült. A végeredmény ugyan nem egy ipari vezérlőszekrény belseje, de működik, és a doboz teteje is rámegy. Nem állítom, hogy ez a konstrukció büszkeségem tárgya, de ami működik, az működik. :)

A bekötés

A kapcsolás sem lett különösebben bonyolult. A 12 V-os bemenet először a step-down konverterre kerül, ebből készül az ESP32 számára szükséges 5 V. Az I2C-s eszközök és a többi periféria az ESP32 megfelelő tápfeszültségéről működik.

Az új firmware jelenlegi GPIO-kiosztása:

ESP32 GPIO	Funkció
GPIO21	I2C SDA – OLED + AM2320
GPIO22	I2C SCL – OLED + AM2320
GPIO17	Fűtésvezérlő relé
GPIO18	PIR mozgásérzékelő
GPIO19	Enkóder nyomógomb
GPIO5	Enkóder CLK
GPIO23	Enkóder DT

Az I2C buszon két eszköz van:

0x3C – SSD1306 OLED
0x5C – AM2320

Az ESP32 pedig egy hagyományos, ESP32-D0WD-V3, 4 MB flash, PSRAM nélküli példány.

Firmware

A PlatformIO projekt forrása itt található:

e32-thermostat – GitHub

A program jelenleg többek között az alábbiakat tudja:

5–30 °C között állítható célhőmérséklet,
0,25 °C-os lépésköz,
0,3 °C hiszterézis,
minimális 30 másodperces fűtési idő,
legfeljebb 30 perces folyamatos fűtés,
5 perces hűtési idő,
belső és külső hőmérséklet használata,
OLED kijelző automatikus kikapcsolása,
mozgásra/gombra/enkóderre történő kijelző-ébresztés,
MQTT,
Home Assistant autodiscovery,
webes kezelőfelület,
OTA frissítés.

Vagyis a Tasmota helyett most már maga a termosztát programja intézi az egészet.

A termosztát működése

A hőmérsékletet az AM2320 méri, a firmware pedig 5 másodpercenként olvassa ki az érzékelőt. A program több próbálkozással és CRC-ellenőrzéssel dolgozik, illetve szükség esetén az I2C buszt is helyre tudja állítani.

A vezérlés alapja továbbra is a jól bevált hiszterézis. Ha például 22 °C-ra van állítva a termosztát, akkor a relé nem kapcsolgat minden apró hőmérsékletváltozásra. A vezérlés 0,3 °C-os hiszterézist használ, emellett minimális és maximális fűtési idő, illetve egy 5 perces cooldown idő is van. Ezzel elkerülhető, hogy a relé túl gyakran kapcsolgasson, illetve egy esetleges folyamatos fűtési helyzetben is van egy felső időkorlát. A konkrét értékek természetesen szabadon módosíthatók, hiszen más egy lakás és más egy iroda, illetve másként viselkedik egy gyorsan reagáló és egy nagy hőtehetetlenségű fűtési rendszer.

A kijelzőn az aktuális hőmérséklet mellett a célhőmérséklet jelenik meg, illetve egy kis jelzés mutatja, ha éppen aktív a fűtés. A belső hőmérőt #1 jelzi, a külső, MQTT-n vagy HTTP-n érkező hőmérséklet pedig #2-ként jelenik meg. Ha a külső érték két percig nem frissül, a termosztát automatikusan visszatér a saját AM2320 érzékelőjéhez.

A célhőmérséklet beállítására egy egyszerű KY-040 jellegű forgóenkódert használok. Jobbra tekerve nő, balra tekerve csökken a beállított érték. A nyomógomb pedig külön funkciót kapott: ezzel a fűtést lehet ki- és bekapcsolni. Ez szerintem sokkal természetesebb kezelés, mint amikor egy termosztáton három-négy külön gombbal kell megtalálni, hogy melyik mit csinál.

Home Assistant

Mivel ez mégiscsak egy WiFi-s termosztát, természetesen nem maradhatott ki a Home Assistant támogatás sem.

A firmware MQTT-n keresztül kommunikál, és Home Assistant autodiscovery-t is használ. Így az eszköz megfelelő MQTT kapcsolat esetén automatikusan fel tudja kínálni többek között a termosztátot, a fűtés állapotát, a kijelzőt, a mozgásérzékelőt és a tiltási állapotot.

Zárszó

Zárásként hozzá kell tennem, hogy személy szerint már két éve Zigbee termosztátot használok, így inkább csak a nosztalgia hívta életre ezt a cikket. De most, hogy kapott egy gyors, optimalizált programot, elteszem a szekrénybe, még bármire jó lehet. :)

Kültéri BLE hőmérő házilag

eNeS — Sun, 13 Sep 2026 10:50:52 +0200

A lakásomban nincs hiány hőmérőkben, de egy ideje szeretnék kültéri hőmérőt is. Találtam is egy ígéretes kültéri Bluetooth-os hőmérőt az Inkbird gyártótól, de miután kipróbáltam, rá kellett jönnöm, hogy csak aktív módon lekérdezhető, nem küldi passzívan az adatokat. Hogy mi a különbség a kettő között? A fogyasztás elsősorban, de ezt a későbbiekben még kifejtem. Egy szó mint száz, némi keresgélés után rátaláltam az nRF52840 chipre, ami 64 MHz-es Cortex-M4F, 256 KB memóriával és 1 MB tárhellyel, papíron képes lehet Bluetooth/Zigbee/Thread kommunikációra is, ebből az alábbi képen látható hőmérőt eszkábáltam össze:

A hardver

Szenzornak az időjárásállomásokban népszerű, I2C csatlakozású BME280-at választottam, egészen egyszerűen azért, mert a hőmérsékleten és páratartalmon kívül a nyomást is méri. Na persze az is előny, hogy 1,8–3,6 V tápfeszültségről üzemeltethető, a mérési módtól függően néhány mikroamperes fogyasztással. De én még ezt is sokalltam, ezért nem az elemre van kötve, hanem az nRF chip egyik GPIO-jára (P1.00). A GPIO-k standard meghajtás mellett is 4 milliamperig terhelhetők, így ez problémát nem okoz, cserébe a hőmérő csak akkor fogyaszt, ha az nRF chip is ébren van és bekapcsolja a program az adott lábat.

Maga az nRF52840 az adatlapja szerint takarékos SYSTEM ON módban nagyjából 3 mikroampert fogyaszt, de még a kevésbé optimista külső leírások is kevesebb, mint 5 mikroamper fogyasztással számolnak. No persze amikor beindul a rádióforgalmazás, akkor pillanatokra akár 15 milliamper körüli áramot is felvehet a chip, de úgy számoltam, nekem elegendő, ha csak 3 percenként ébred fel, egy rövid adatküldés erejéig. Talán ebből már látható, hogy miért nem szeretném, ha folyamatosan menne a vezérlő aktív módban, és várná, hogy hozzá kapcsolódjanak, hanem e helyett időnként rövid BLE hirdetésben küldené szét az adatokat.

A képen látható Supermini lapon a P0.13 GPIO kikapcsolásával az arra integrált LDO is kikapcsol, valamint a P0.15-re kötött piros LED-et is kikapcsolom induláskor, így a lapon található extra fogyasztókat úgy gondolom sikeresen kiiktattam.

Egy átlagos CR123A elem névleges kapacitása nagyjából 1500 mAh, így, amennyiben mindent jól csináltam, évekig nem kell elemet cserélnem benne.

Érdekesség még, hogyha USB-ről van táplálva a lap és nincs 3,7 V-os akku rákötve, akkor egy kék LED folyamatosan és kikapcsolhatatlan módon villog. Szerencsére ez közvetlen VDD táplálás esetén nem jelentkezik. És ha már akku, ezt a lapot úgy tervezték, hogy kifejezetten 3,7 V-os akkuról üzemeltessük, ám úgy döntöttem a feszültségátalakításból eredő veszteségek (ami másrészt melegedést is okoz) kiküszöbölésére direkt 3 V-os tápforrást fogok választani, és hogy ne kelljen sűrűn cserélgetnem, nem a szokásos CR2032-t, hanem a képen is látható izmosabb CR123A elemet választottam. Viszont a Supermini lapon nincs olyan láb, amire ezt rá lehetne kötni... legalábbis nem az oldalán. Ám ha megfordítjuk, az alján van egy kis padon kivezetve a VDD, amire vígan köthetünk (stabil) 3 V-os tápforrást. Arra azért figyeljünk, hogy ez közvetlenül a chipre van vezetve mindenféle védelem nélkül!
Érdemes arra is figyelni, hogy van egy hibás széria a Supermini lapoknál, ahol a P0.13 kikapcsolásakor egy 5,6 kΩ-os felhúzó ellenállás miatt jelentős szivárgóáram alakul ki, ami a VDDH-n keresztüli 3,7 V-os tápellátáskor az akkut akár 700 mikroamperrel is terhelheti. Ezt ilyenkor érdemes levenni vagy 10 MΩ-os ellenállásra cserélni. Ám mivel én direktben VDD-n keresztül táplálom a chipet, ez a hiba nem érinti a jelen kapcsolásomat.

nRF GPIO	Bekötés
VDD	CR123A+
GND	CR123A-, BME GND
P0.17	BME SDA
P0.20	BME SCL
P1.00	BME VIN

A szoftver

A norvégok által gyártott nRF52 család nem a WiFi, hanem a BLE és az alacsony fogyasztású 2,4 GHz-es rádiós kommunikáció felé van kihegyezve, valamint nagyon kis fogyasztása miatt az elemes működésre jobb alternatíva a kínai ESP32 megoldásoknál.
Szoftvertámogatása az ESPHome-ba is bekerült - a ZephyrOS segítségével - de én úgy látom egyelőre csak Zigbee stack támogatással és csak néhány egyszerű szenzortípussal.

Ám ez nem lehet akadály, készítettem egy egyszerű saját programot a fent vázolt működés megvalósítására, PlatformIO-val lefordítható, FreeRTOS alapú projektként:

https://github.com/enesbcs/iotdiysensor/tree/main/n52btemp

A program feltöltéséhez nem kell semmilyen speciális programozó, a RESET láb és GND közé kötött nyomógombot kétszer gyorsan megnyomjuk, amikor USB-n a számítógépre van kötve, és ekkor megjelenik egy NICENANO nevű meghajtó, ahová fel kell másolni a firmware.uf2 állományt. (Hasonlít a megoldás a Raspberry Pi Pico-nál megszokottra)

A program nagyon egyszerű, OTA támogatást nem tettem bele, mert amin lehetett, azon spóroltam az elemes üzemidő maximalizálása érdekében. Ezért nincsenek rajta elérhető vagy szkennelhető Bluetooth szolgáltatások, hiszen a lap az idő nagy részében alvó állapotban van, ahogy a rádiója is. Amikor felébred 3 percenként, rövid, legfeljebb 31 bájtos BLE hirdetési csomagokat szór a világba, majd visszaalszik. Ennek a csomagnak a szerkezetét BTHome v2 szabvány szerint építettem fel (Shelly eszközök is használják), amit a Home Assistant is támogat, akár a saját BTHome integrációján, vagy akár a Passive BLE Monitor komponensen keresztül.

A dobozolás

Most, hogy a hardverről és a szoftverről is írtam, ideje beismernem, hogy először a megfelelő kültéri házat szereztem be, és annak megfelelően alakítottam ki a hardverem méretét. Némi tájékozódást követően Stevenson-kalitka mellett döntöttem, például az allegro.hu-n "Stevenson külső hőmérséklet érzékelő ház" néven található meg, és UV-álló ASA műanyagból nyomtatják. Akinek van otthon 3D nyomtatója és ASA alapanyaga, saját magának is nyomtathat hasonlót, én megvásároltam 3600 Ft-ért, méghozzá a legkisebb négyszintes változatot:

A megoldás lényege, hogy a lamellák közt a levegő szabadon jár, alulról egyébként szinte teljesen nyitott, és a fehér szín a napsugárzás nagy részét visszaveri. Fontos az elhelyezés is: árnyékos, jól szellőző, napsugárzástól védett helyre célszerű tenni, lehetőleg nem közvetlenül fal mellé.

Ennek a hasznos belmagassága csak 5 cm, így az eszközök elhelyezésére szolgáló 5x7 cm prototípuslapot 5x5 cm-re vágtam, így gond nélkül befért. A hőmérőt úgy helyeztem el, hogy ez legyen legalul, mivel a meleg levegő felfelé száll, így a chip vagy elem esetleges hőleadása nem lesz rá jelentős hatással.

Látható, hogy a 67 mm magas 18650 akku nem férne bele, részben ez is volt az oka annak, hogy más tápellátási megoldást keressek. Aki ilyet szeretne használni, annak javaslom ennek a kalitkának a nagyobb, hétszintes változatát, az már 9 cm magas.

A négyszintes változatot egyébként arra szánták és arra méretezték, hogy kész, beltéri hőmérőket védjen meg kültéren, például ezeket: Aqara LYWSD03MMC, WSDCGQ11LM, Sonoff SNZB-02, SNZB-02WD, SNZB-02P

Felmerülhet a kérdés, hogy bár a kalitka az esőtől és az UV-sugárzástól megvédi az én egyszerű prototípuslapomat, vajon ez elég lesz?
Az nRF52840 és a BME280 működési tartománya egyaránt -40 és +85 °C, egy átlagos CR123A lítium elemé -40 és +60 °C. A forrasztási pontokat -40 és +60 °C közt korrózióálló védőlakkal vontam be, többet nem tudok tenni az érdekében. Persze ez azért még nem egy IP67-es ipari hőmérő, hanem egy kültérre optimalizált barkácsmegoldás, úgyhogy a hosszú távú megbízhatóságát majd az idő dönti el.

Továbbfejlesztési lehetőség: nagyobb Stevenson házba 18650 akku, a hőmérő mellé UV- és luxmérő szenzorok, valamint 12 V-os napelem 5 V-os step-down átalakítóval az USB bemenetre kötve.

A valós fogyasztásról

Kihelyezése után az első napon az elem feszültsége 3,22 V-ról 3,05 V-ra csökkent, majd a harmadik napon beállt 3 V körüli értékekre, eddig úgy tűnik ott stabilizálódott, de az idő majd megmondja. Azt is figyelembe kell venni, hogy a napokban beütött az ősz, hidegek az éjszakák, a lítium elemek feszültsége pedig a hőmérséklettel is változik.

WiFi DIY rezgésérzékelő

eNeS — Tue, 25 Aug 2026 20:51:45 +0200

Egy rezgésérzékelőt elég sokoldalúan lehet használni, teszem azt mozgó részt tartalmazó gépek működésének figyelésére, de van, aki a mosógépére tesz ilyet, vagy alkalmas lehet falépcső alá szerelésre, ezzel mozgásérzékelő nélkül megmondható, járkál-e éppen valaki a lépcsőn.

Biztosan van, aki már látott közelről készen kapható "rezgésérzékelő" modult, amikben egy golyó vagy rugó van, én is próbálgattam őket, és azt kell mondanom, nem túl érzékenyek. Ha konkrétan nem kocogtatom a modult, akkor nem igazán láttam róluk jelzést.

Ám aztán olvastam róla, hogy gyorsulásmérő segítségével is megoldható a feladat, beszereztem hát egy MPU6050-et és egy ESP32-re kötöttem. Hogy ne legyenek WiFi térerőproblémáim, rögtön külső antennás modellt választottam, de ez persze nem kötelező. A belseje ilyen lett:

Alkatrészlista:

ESP32-DEVKIT-32U-4M - 3144 Ft
Antenna 2,4 Ghz WiFi SMA to IPEX 450 Ft
DC-DC step down átalakító (6-55v - 5v) 939 Ft
MPU6050 1583 Ft
Z34B-ABS 1505 Ft
DC aljzat 192 Ft

Tehát projekt költségvetése nagyjából 7800 Ft, még apróságokkal is benne van 8000 Ft-ban. Persze ha körülnézünk, akkor wifis rezgésérzékelőt találunk készen feleárban is, így nem feltétlen éri meg nekifogni, ha a gyári megoldás is megfelel nekünk.

Működtető rendszernek a Tasmotát választottam. Rögtön belefutottam azonban abba az aprócska problémába, hogy bár támogatja az MPU6050 szenzort, ez egyik készen letölthető firmware-ben sincs benne, tehát nekünk magunknak kell fordítanunk.

A fordításhoz az alábbi helyre feltöltöttem a user_config_override.h állományt, de egy kész tasmota32.bin -t is, amit OTA módon tudunk feltenni az ESP32-re, miután USB kábelen feltöltöttünk egy kezdeti tasmota alap buildet.

https://github.com/enesbcs/tasmota-custom-scripts/tree/main/vibrsens

Miután feltettük a megfelelő firmwaret, be kell állítani az I2C vonalat a Tasmotán belül (SDA: GPIO21, SCL: GPIO22) és ekkor a főoldalon megjelennek a gyorsulásmérő által mért értékek.
Ebből közvetlenül a gyorsulást, illetve nyugalmi helyzetben a dőlés irányát tudjuk meg, a rezgésért még egy kicsit dolgozni kell. De ezt Tasmota Berry-ben meg tudjuk oldani.

A Berry program feladata:

az MPU6050 inicializálása,
a gyorsulási adatok kiolvasása,
az alapállapot meghatározása,
a rezgés mértékének kiszámítása,
a zaj kiszűrése,
az érzékelés megerősítése,
a rezgésállapot megtartása egy rövid ideig,
valamint az eredmény MQTT-n keresztüli továbbítása. (MQTT Autodiscovery-vel)

A program megtalálható itt:

vibration.be

Ennek tartalmát a Tasmotában a Tools->Manage File System->Create and edit new file segítségével vágólapon tudjuk legkönnyebben beilleszteni, és ha azt szeretnénk, hogy automatikusan elinduljon, 'autoexec.be' néven mentsük el.

A Configuration->MQTT alatt állítsuk be, milyen MQTT szerverre küldje az adatokat a Home Assistantnak, és a legközelebbi újrainduláskor új MQTT-eszközként jelenik meg a tasmota_xxxxxx, amelyben három szenzort találunk. Egy bináris szenzor mutatja van-e rezgés, majd nyugalmi állapotban visszaáll OFF-ra, illetve a rezgés szintjét és csúcsértékét másodpercenként közli pontosabb kiértékelésre.

A program jelenlegi változata az MPU6050-et 0x68-as I2C címen keresi, 100 Hz-es mintavételezést használ, és a gyorsulásmérő DLPF szűrőjét is beállítja. A program alapértelmezett küszöbértéket használ, de induláskor kalibrációt is végez. A nyugalmi állapotból összegyűjtött minták alapján meghatározza a zajszintet, majd ennek megfelelő küszöböt választ.

A jelen működési mód teljesen szoftver alapú, folyamatosan olvassa a gyorsulásmérő állapotát Az elemes változatok viszont olyan, ultraalacsony fogyasztású gyorsulásmérőt használnak, mint például az ADXL362 vagy a LIS2DW12, amelyek képesek interrupttal jelezni a vezérlőnek, ha mozgást vagy rezgést érzékel. Ilyenkor az ESP32 a mérés nagy részében alvó állapotban maradhat.

Ezzel a projekttel mindössze meg akartam vizsgálni, mennyire érzékeny rezgésérzékelőt lehet fabrikálni egy gyorsulásmérővel, az eredményt az alábbi videó mutatja:

Mindent összevetve a megoldás valóban működőképes, bár nem feltétlen ebben a proof-of-concept formában, ahogyan én teszteltem, hanem inkább interruptos mélyalvással kombinálva.

A mostani megoldás:

MPU6050 → folyamatos mintavétel → ESP32 → Berry → kiértékelés

Míg az elemes változat így működhetne:

ultra-low-power accelerometer → motion/wake interrupt → ESP32 felébred → részletes mérés → visszaalvás

Érdekes felhasználási lehetőségek még:

motorok, szivattyúk és ventilátorok működésének figyelése;
csapágyak vagy forgó alkatrészek rendellenes rezgésének felismerése továbbfejlesztett FFT alapú kiértékeléssel;
mosógép és szárítógép működésének és programvégének érzékelése;
robotporszívó működésének vagy elakadásának felismerése;
hűtőszekrény és klíma kompresszorának, illetve ventilátorának figyelése;
fa- vagy fémlépcső rezgése alapján annak megállapítása, hogy jár-e rajta valaki;
ajtó, ablak vagy kapu nyitásának érzékelése nyitásérzékelő nélkül;
gépek, berendezések vagy tárgyak elmozdításának, megütésének érzékelése;
szivattyúknál annak ellenőrzése, hogy a bekapcsolás után valóban elindult-e a gép;
ventilátoroknál, szivattyúknál vagy motoroknál a normális működéstől eltérő rezgési mintázat jelzése.

TinyControl Lan Controller

eNeS — Tue, 28 Jul 2026 19:44:52 +0200

Üdítő színfolt a kínai felhős cuccok végeláthatatlan áradatában egy lokális hálózaton, MQTT kapcsolatra képes lengyel gyártmányú IOT eszköz.

A TinyControl által gyártott Lan Controller nem a szokásos ESP, hanem STM mikrovezérlők mellett tette le a voksát, és nem a Wi-Fi-re, hanem a stabil vezetékes Ethernet kapcsolatra épít. Mindkettő olyan dolog, amivel tudok azonosulni.

Egy HW3.8-as kiadás került a birtokomba, ami a 3.5-ös család legutolsó tagja, de már ezt sem forgalmazzák, helyette a 3.9 kapható most, ami nagyjából ugyanígy néz ki, a szoftvere is ugyanaz, csak újabb STM chipet kapott, ami erősebb. A HW3.8 nagy újítása, amit természetesen már a következő generációk is tudnak, az aktív 802.3af POE tápellátás támogatása, így egy kábelen megoldhatjuk könnyen az adatátvitelt és tápellátást is.
Kreatív ötlet, hogy a benne levő órát (RTC) az eszköz kikapcsolt állapotában nem elemről, hanem egy egyszerű szuperkondenzátorról látják el árammal, ami 24 órás áthidalást biztosít.

Az én modellemben STM32F107 helyett egy kínai klón GD32F107VGT6 ketyeg 108MHz sebességgel, 96kB SRAM és 1MB flash tárhely társaságában. Látható, hogy az ESP32-höz képest azért nem egy erőgépről van szó, a memóriája és a tárhelye is szerényebb, ennek köszönhetően a webes felülete is ezekhez az erőforrásokhoz mérten szerény kinézetű - de nem csúnya. A nagyjából 0.5W fogyasztáshoz képest nem rossz. A GD32F107 tartalmaz saját Ethernet MAC vezérlőt, amelyhez egy IP101GR RMII PHY kapcsolódik.
A rá integrált relé egy kínai Hongfa HF3FF 005-1ZST típus, amely 277 VAC mellett 10 A kapcsolására képes. A Hongfa ma már kifejezetten ismert szereplő az ipari relék piacán, így ettől a választástól nem kell megijedni. Remélhetőleg Európában rakják azért össze ezeket.

Az adatlapját böngészve szerintem minden IoT iránt érdeklődőnek ugyanaz jut eszébe, mint nekem első olvasatra: „Kell nekem egy ilyen!”

Beágyazott webszerver, analóg és digitális bemenetek, 1-Wire (DS18B20 és DHT22) és I2C hőmérők (BME280,AM2320,HTS221,BME680,AM2301B/AHT20) csatlakoztatása RJ12 porton keresztül. Ha szétnézünk a wireless-bolt oldalán sok szenzort és RJ osztót/splittert is találni fogunk.
Ezen kívül UART portja is van, amin ezeket támogatja: GSM SIM800L, Duralux, PM SDS011, CO2 MH-Z16/19, PM SPS30, Bar/Qr Code SCanner, Ultrasonic distance sensor, RHEWA 82comfirt, GMQ125.
Továbbá MODBUS-on SDM120, SDM72D-M, RDO-PRO-X, Epever Tracer, Sofarsolar, GTIL, Danfos EKC 202C, SDM630/72D-v2, CHINT-DTSU666.

A firmware email küldésen kívül egyedi HTTP oldalt is meg tud hívni, illetve MQTT-n is tudja küldeni a bemenetek/szenzorok állapotait. Van egy gyári mqtt.ats.pl oldal, amire ingyenesen 5 db eszközt tudunk felvenni, ha távolról szeretnénk monitorozni az eszközöket, de az MQTT helyi IOT rendszerhez illesztésre a legkiválóbb. Az Events eseménykezelővel a bemenetek egy bizonyos állapotához tudunk akciókat társítani, mint pl az email küldés vagy http oldal meghívás. (Persze ez nem egy Tasmota-szintű szkriptmotor. A 96 kB RAM korlátai mellett inkább egyszerű automatizálásokra tervezték.)

És akkor nézzük a csatlakozásait:

Amint látható, tápellátásra van egy DC csatlakozója, amin 8-55V DC tápfeszültségről működtethető, illetve az aktív POE, ami szabvány szerint 37-57V között mozoghat. Az RJ12 mind a hat ere használatban van, és úgy van kialakítva, hogy a 1wire és I2C párhuzamosan tudjon működni rajta egy külső splitteren keresztül több hőmérővel is. Azt nem árt észben tartani, hogy az I2C nem igazán hosszú kábelekre való, 1 méternél többre ne vigyük, viszont a 1wire gond nélkül működik 10 méteren is, kábelminőségtől függően akár jóval messzebb is.

Az IDC10-1 és IDC10-2 szalagkábelekkel vezethető ki, ezeken vannak példának okáért a PWM kimenetek, valamint négy kimenet.

A hátulján levő, kivehető sorkapcsokon vannak az analóg és digitális bemenetek. A digitális bemenetek 1,5–20 V közötti feszültséget logikai magas szintként érzékelnek, ezért 3,3 V-os, 5 V-os és 12 V-os rendszerekkel is közvetlenül használhatók. Az analóg bemenetek közül az 1 és 2: 0-5V vagy 0-55V, a 3 és 4: 0-3.3V vagy 0.33V között tud mérni, ez szoftveresen állítható.
Akad itt még 1 db max 1A tranzisztoros kimenet (OUT5), aminek a feszültsége a bejövő tápfeszültséggel egyezik meg és 1 db NO/NC relékimenet (OUT0).

Mindez 67 x 57 x 48 mm méretbe és 50g súlyba sűrítve.

És akkor megragadnám az alkalmat, hogy mutatok egy mintaképet a menüjéből, egyúttal megismerkedésem történetét is beleszőve, hogy hogyan is találkoztam ezzel évekkel ezelőtt: (már 2011 óta léteznek különböző változatai) Úgy történt az eset, hogy egy sorompóhoz kellett volna a portáról egy nyomógombot kötni, de semmilyen közvetlen kábelezés nem volt azon a nyomvonalon, viszont LAN végpont volt mindkét helyen. Néhány perc keresés után a Google kidobta a megoldást: a Lan Controller rendelkezik egy Remote Control menüvel, amelynek segítségével két Lan Controller UDP-n keresztül közvetlenül tud együttműködni. Mindössze látniuk kell egymást és fix IP-re van szükség. Megadható például, hogy az 1-es számú LAN Controller IND1 bemenetének állapotváltozását kövesse a 2-es egység OUT0 reléje. De akár valamelyik előre definiált EVENT is elindítható, amibe több parancsot is tehetünk. Ehhez az 1-es eszközön kell beállítani a vezérlési mátrixot, a vezérelt 2-es eszközön engedélyezni kell csak a Remote Control funkciót, egyező jelszót felvinni, de azon nem kell állítani a mátrixban semmit, az csak fogadó lesz ebben az esetben.

Ma, amikor minden gyártó valamilyen felhőszolgáltatáson keresztül akar két eszközt összekötni, különösen lelkesítő, hogy a Lan Controller ezt teljesen helyben, UDP üzenetekkel oldja meg. Nincs szükség internetkapcsolatra, szerverre vagy MQTT brokerre: a két eszköz közvetlenül kommunikál egymással.

Beüzemelés

Roppant egyszerű használatba venni, ha van POE switchünk vagy 802.3af POE feladónk, de ha nincs kéznél, egy egyszerű 12V-os DC dugós táppal is vígan elindul. Ha kap egy LAN kábelt, akkor az új verziók már DHCP-n kérnek címet, a routerünkön megtaláljuk milyen címet kapott, vagy letöltjük a gyártó LKTools nevű programját. Ez Linux is Windows alatt is kiválóan működik, érdemes egyúttal egy automatikus firmware frissítést is ráküldeni, amit egyébként egy TFTP klienssel kellene elvégeznünk.

Az IP címét böngészőben megnyitva gyári felhasználónév admin/admin, mint a régi szép időkben, amikor minden TP-Link routernek ez volt a jelszava... érdemes ezt módosítani, amint tudjuk.

Home Assistant integráció

Ehhez a gyártó által készített komponenst kell letöltenünk, nincs benne alapból a HA-ban.

Letöltjük a TinyControl integration aktuális verzióját
Home Assistant Samba Share addon segítségével megosztjuk a HA konfigurációs mappáit
A letöltött zip állományból a tinycontrol mappát bemásoljuk a HA-n a /config/custom_components
mappába
újraindítást követően az Integrációk hozzáadása gomb alatt immár elérhető a tinycontrol nevű integráció
a TinyControl eszközök hozzáadásához IP címet fog kérni, így fix IP-t kell majd beállítani neki

A gyártói megközelítés HTTP pollingot használ, és minden lehetséges eszközt felvesz, de letiltott állapotban, kézzel kell engedélyeznünk azt, amit szeretnénk a HA eszközök között.
Ha esetleg e helyett szeretnénk MQTT-t használni, kézzel azt is beállíthatjuk, de HA oldalon a YAML konfigurációt nekünk kell megírnunk.

Saját Home Assistant Add-on

Mivel a gyári integráció HTTP pollingot használ, készítettem egy Home Assistant Add-ont, amely MQTT Auto Discovery segítségével automatikusan létrehozza a TinyControl által publikált szenzorokat és kapcsolókat. Az Add-on csak a megfelelő MQTT prefix(ek) megadását igényli, a Home Assistant entitások létrehozását automatikusan elvégzi. Apró hiányosság, hogy a kimenetek HA-ból történő kapcsolása esetén visszafelé csak a beállított periodikusan érkező státusz érkezése után lesz szinkronban a kimenet állapota a HA-val, de állíthatjuk sűrűbbre is a periodikus küldést az eszköz oldalán, ha ez zavaró.

https://github.com/enesbcs/ha-addons

Ajánlanám?

Természetesen!
Aki a rack szekrényébe szeretne egy megbízható, vezetékes hőmérőt (mert pl a rack szekrény árnyékolja a wifit), ami akár a relével képes bekapcsolni a hűtőventillátorokat, annak jó szívvel tudom ajánlani az eszközt. De kiemelten ajánlják napelemes rendszerekhez is.

Összegzés

Ha létezik IOT svájcibicska, akkor ez az eszköz az. Korábban is dolgoztam már STM32 eszközökkel és nem kellett csalódnom ebben sem. Minden részén a hozzáértő tervezés és hosszú évek tapasztalatának nyomait viseli, praktikus és kompakt eszköz. Ami egy kicsit árnyalja a képet, az a nagyjából 30e Ft-os árcimkéje, és lássuk be, ebből az árból több ESP32-t össze tudunk rakni Tasmotával.

Mozgásérzékelés a Wi-Fi hálózattal

eNeS — Sat, 25 Jul 2026 12:14:46 +0200

Készítettem korábban PIR és radaros mozgásérzékelőt ESP8266-ra kötve WiFi-s érzékelőt, ám ezúttal nem erről lesz szó.
Hanem az ESPEctre szoftverről, amelyet egy ESP32-re feltöltve a Wi-Fi CSI (Channel State Information) adatok elemzése alapján képes megállapítani, hogy történt-e mozgás az ESP32 és a router közötti térben.

A rádióhullámok a falakról, bútorokról és egyéb tárgyakról visszaverődve egy adott környezetre jellemző mintázatot hoznak létre. (Megvan a jelenet, amikor Daredevil a hallásával "látja" a környezetét?) Az ESPEctre ezt a mintázatot figyeli, és ha valaki megváltoztatja azt a mozgásával, azt képes érzékelni. És igen, falon keresztül is működik, igazából problémának én csak azt látom, hogyha valakinek több AP-ja vagy egyenesen Mesh WiFi hálózata van otthon, akkor fixálnia kell, hogy melyikhez csatlakozzon az ESPEctre érzékelő, mert ha néha átvált másik AP-ra, az nyilván fals riasztásokat fog eredményezni, hiszen ilyenkor teljesen más rádiós útvonalat kezd figyelni.
Azt is figyelembe kell venni, hogy a legtöbb ESP32 még mindig csak 2.4GHz-es hálózaton kommunikál, ami egy nagyobb emeletes házban azt jelenti, hogy mind a 13 lehetséges csatorna tele van, némelyik többszörösen is. A rádiós zajt az algoritmus elméletben kiszűri ugyan, de ha nagyon sok csomag érkezik, az ESP32-nek azért véges a feldolgozási képessége, vagyis minél nagyobb a zaj, annál többet is fog eldobni, ezzel romlik a felismerés hatékonysága.

Többféle ESP32-t is támogat: ESP32-S3, ESP32-C6, ESP32-C5, ESP32-C3, ESP32-S2 valamint a hagyományos ESP32 is támogatott. (egyébként a C6/C3/S3 az ajánlott típusok) Azokon a modelleken is 2.4GHz-es wifit használ, amik tudnák az 5GHz-et.

A projekt nyílt forrású, ESPHome natív HA integrációval működik:

https://github.com/francescopace/espectre

Hogyan tudjuk használni?

Többféle megközelítés is lehetséges, a legegyszerűbb, ha van Home Assistant-unk, akkor abba telepítünk egy ESPHome Builder-t (ha még nincs) és abban a New Device-ra kattintva megírjuk a szükséges YAML állományt ahhoz a laphoz, amivel tesztelni szeretnénk. Nekem egy ESP32-CAM akadt a kezembe, amiben egyébként sima ESP32 van.

 esphome:
  name: spectretest
  friendly_name: spectretest

esp32:
  board: esp32cam
  framework:
    type: esp-idf

logger:
  baud_rate: 0
  level: WARN

# Enable Home Assistant API
api:

ota:
  - platform: esphome
    password: "mypasswordispassword"

web_server:
  port: 80
  version: 3
  
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none
  ap:
    ssid: "Spectretest Fallback Hotspot"
    password: "12345678"
  fast_connect: true
  output_power: 20dB

captive_portal:
    
external_components:
  - source: github://francescopace/espectre
    components: [espectre]

espectre:
  traffic_generator_rate: 100   # Packets/sec for CSI generation (0-1000)
  traffic_generator_mode: ping   # ping (default) or dns
  gain_lock: auto               # auto (default), enabled, disabled
  # Detection Algorithm
  detection_algorithm: ml      # mvs (default) or ml (neural network)
  segmentation_window_size: 100  # Analysis window size in packets (10-200)
  segmentation_threshold: auto  # auto/min (mvs/ml: 0.0-10.0)
  hampel_enabled: true          # Outlier removal (default: true)
  hampel_window: 7              # Filter window size (3-11, odd numbers)
  hampel_threshold: 5.0         # Outlier detection threshold (1.0-10.0)
  lowpass_enabled: false        # Noise reduction (default: false)
  lowpass_cutoff: 11.0          # Cutoff frequency in Hz (5.0-20.0)
  ble_channel_enabled: false     # auto (default), true, false

  movement_sensor:
    name: Movement
    filters:
      - multiply: 100           # Scale 0-1 to 0-100
      - clamp:
          min_value: 0
          max_value: 100        # Cap at 100%
      - round: 1                # Round to 1 decimal    
    icon: "mdi:sine-wave"

  motion_sensor:
    name: Motion
    icon: "mdi:motion-sensor"    

  threshold_number:
    name: Threshold

  calibrate_switch:
    name: Calibrate

Extraként engedélyeztem a web szervert, mert szeretem, ha a wifis eszközeim elérhetőek, és tudom őket kézzel is frissíteni, függetlenül attól megy-e az esphome, vagy a HA, vagy éppen újratelepítettem és lövésem sincs mi volt az eszköz API kulcsa... A PSRAM-ot nem kapcsoltam be, mert az ESPEctre nem használ sok memóriát, cserébe a PSRAM elérése lassabb, mint az integrált SRAM-é.

De itt található mindenféle ESP32 típushoz minta YAML fájl is:

https://github.com/francescopace/espectre/tree/main/examples

Miután a YAML fájl elkészült, az ESP32-t BOOT gomb nyomva tartása mellett (vagy a megfelelő GPIO0 GND-re húzásával) USB-n csatlakoztatjuk a számítógéphez. Ezután az ESPHome-ban az INSTALL → Plug into the computer USB menüpontot választjuk.

Az ESPHome letölti a szükséges függőségeket, fordít egy firmwaret és feltölti a csatlakoztatott eszközre, ez egy ideig eltart. Ha minden jól ment, a feltöltés sikeres, az eszköz Online állapotú lett ESPHome alatt.

Továbbá a Beállítások->Eszközök alatt megjelent új eszközként a spectretest nevű, amit felvéve két új érzékelővel leszünk gazdagabbak "Motion" és "Movement" néven. Előbbi bináris van mozgás/nincs mozgás, utóbbi egy százalékos valószínűséget ad vissza.

Az alapértelmezett üzemmódja az MVS, a CSI adatok statisztikai változását elemzi, ez induláskor kb 12-15 másodpercig tart a kalibráció, e közben lehetőleg ne mozogjunk. Ekkor tanulja meg, hogyan "néz ki" egy üres szoba. Ez egy bejáratott megoldás, valóban mindig jelzett, amikor mozogtam, bár volt néhány olyan eset is, amikor én magam nem mozogtam, de nem tudom biztosan, hogy fals riasztás volt-e, mert a szomszédban lakó mozoghatott és ugye falon keresztül is érzékeli a zavart az erőben.. a térerőben. :)

Az eszköz elhelyezését a WiFi adótól 15 méter távolságon belül javasolják, de az sem jó, ha 1 méternél közelebb van, a túl erős jelek is megzavarhatják az érzékelést. A rádióhullámok számos felületről visszaverődnek, így tesztjeim szerint nem csak az ESPEctre és a Wifi közti mozgást érzékeli, hanem akár egy szobával arrébb is, viszont kisebb érzékenységgel. Például, ha a wifi router környékén akár csak a fejemet is mozdítom, az ESPEctre máris mozgást jelez, ha viszont 10 méterrel arrébb mozgok, akkor hiába bólogatok vagy mozgatom a kezeimet, arra nem jelez, csak ha egész testtel arrébb lépek.

Az eszköz állandó wifi forgalmat generál a router és az ESPEctre között, pingeléssel, az oda-vissza irányú állandó kommunikáció biztosítja, hogy folyamatosan rendelkezésre álljon valós idejű CSI. (traffic_generator_rate beállítással hangolható) Az alapértelmezett 100 pps nagyjából 9KB/s sávszélességet visz el eszközönként a wifi sávszélességünkből.

A másik üzemmódja a kísérleti ML, ez 3 másodperc alatt indul, nem végez kalibrációt és nem is lehet kalibrálni, a neurális hálózat rengeteg CSI mintán lett betanítva, ebből próbál általánosítani. A pontossága nem garantált minden környezetben, de én azért kipróbáltam. Meglepően jól teljesített ez a megoldás is, a visszaadott Movement valószínűségi százalékban még az is látszik, amikor megvakartam az orromat a wifi router mellett, bár a korlátot nem érte el, így a bináris mozgás szenzor a HA-ban nem billent át.

Összességében ez egy nagyon érdekes technikai megoldás. Bár a gyakorlati felhasználása némileg korlátozott, jól használható általános jelenlétérzékelésre, illetve akár betörésjelzésre is. A mozgás helyét azonban nem tudja meghatározni, mivel a rádióhullámok a legtöbb beltéri falon is áthatolnak, így a fal mögötti mozgás is megváltoztatja a CSI mintázatát. Emiatt egy adott helyiséghez nehéz automatizmusokat rendelni. Kamerát nem igénylő jelenlétérzékelésre viszont ígéretes megoldás – feltéve, hogy nincs macska a lakásban, mert arra is lelkesen jelez. Érdekes tulajdonsága még, hogy a wifi routerhez közelebbi mozgásoknál a legkisebb mozgásra is érzékeny, bár nem tudom hogyan lehetne ezt felhasználni.

Olimex ESP32-POE

eNeS — Tue, 21 Jul 2026 20:53:48 +0200

Bár a WiFi-s eszközöknek tagadhatatlanul vannak előnyei is, egy jó vezetékes kapcsolat stabilitásának akkor sincs párja. Korábban kipróbáltam az egyszerű, olcsó WT32-ETH01 lapot, aminek vonzereje az olcsósága, de gyakorlatban van néhány hiányossága, ezért érdeklődve nézegettem az alternatíváit és szereztem is tesztre egy OLIMEX gyártmányú ESP32-POE-ISO-IND eszközt.

Ebben egy ESP32-WROOM-32E-N4 ketyeg 240Mhz sebesen, 520 KB SRAM-al szerelve.
Az IND vagyis Industry modellek -40...85°C üzemi hőmérsékletben képesek működni. Az Ethernet csatlakozásért egy SMSC 8710AIEZK chip felel, ez végzi a POE leválasztást is.

A tápellátás többfokozatú DC/DC átalakítással történik, külön leválasztott PoE tápegységgel, ezért USB-ről és PoE-ról is stabilan működik. Akad egy TX4138 a lapon, ami 4.5-60V bejövő feszültséget tud 800mV-40V köztire alakítani, valamint egy F0505S-2WR2, ami bejövő 4.5-5.5Vot stabilizál 5V feszültségre, max 2W fogyasztásig. És ezzel kell gazdálkodni a chip és a rá kötött szenzorok meghajtásakor.

A lap szabványos IEEE 802.3af (aktív) Power-over-Ethernet táplálást támogat, minimum 35VDC feszültséggel. Extraként van egy LiPo akku csatlakozója (JST 2.0), ADC-n keresztül az akku feszültségét is mérni tudja. Az akkut automatikusan tölti, ha van külső tápellátás csatlakoztatva, ha pedig megszűnik a külső tápellátás, automatikusan átáll akkumulátoros üzemmódra.

GPIO39-en ellenőrizhető a külső tápellátás, GPIO35-ön pedig az akku feszültsége.
Példaprogramok ezek használatára:

https://github.com/OLIMEX/ESP32-POE/blob/master/SOFTWARE/ARDUINO/ESP32_PoE_PowerReading/ESP32_PoE_PowerReading.ino

Az alján pedig akad egy Micro SD foglalata is, egyes projektekhez jól jöhet. Van 4 db LED is a lapon, amik egyébként elképesztően fényesek, de takarékossági megfontolásból nem világítanak, ha akkuról megy a lap.

Ja, ha netán a beépíthetőségén tépelődik valaki, fizikai mérete 100x28mm.

Szoftver

Az én első választásam működtető programra a Tasmota. Jó hír, hogy ma már nincs szükség külön Ethernetes Tasmota firmware-re, mert az Ethernet támogatás bekerült a normál ESP32 verzióba, úgyhogy BOOT gomb nyomva tartása mellett USB kábellel rákötve a gépünkre, egy Chrome alapú böngészővel felkeressük a Tasmota Webinstallert:

https://tasmota.github.io/install/

Majd kiválasztjuk az alap Tasmota verziót és a Connect-re kattintva feltöltjük az eszközre.

A sikeres feltöltést követően a "Change Wifi"-re kattintva beállítjuk, hogy csatlakozzon a Wifinkre, majd a "Visit Device"-ra kattintva eljutunk az eszköz menüjébe.

Itt egyszerűen a Configuration->Other alá az "ESP32 Template" mezőbe beszúrjuk az ESP32-POE template-et az alábbi oldalról:

https://templates.blakadder.com/olimex_ESP32-POE.html

Ne felejtsük az Active elé a pipát betenni, majd Save.

Az eszközön elég sok szabad GPIO van kivezetve, akár a középső UEXT csatlakozóján, akár a két szélén, ez utóbbiakat persze forrasztani kell.

A GPIO kiosztása az alábbi:

Természetesen az ESPHome is támogatja hivatalosan ezt a lapot, az alábbi oldalon találhatunk minta YAML konfigurációkat, a vezetékes működéshez az ethernet: résznél a kommentelést szolgáló # jeleket ki kell venni, és ezután a wifi: részt viszont ki kell kommentelni, mert az ESPHome egyidőben csak egyféle hálózatot tud kezelni:

https://github.com/OLIMEX/ESP32-POE/tree/master/SOFTWARE/ESPHOME

És hogy mik a fő különbségek az Olimex gyártó eszköze és a WT32-ETH01 között?
Első körben az Olimex eszköze ipari stabilitású, míg a WT32 esetén néha szobahőmérsékleten is megesik, hogy az eszköz nem képes elindulni, amit egy kis kondenzátorral lehet házilag megpatkolni. Megfigyeléseim szerint a WT32 5V-ról járatva nagyon tud melegedni (a rá integrált AMS1117 DCDC átalakító hatásfoka nem a legjobb), ezzel szemben az Olimex langyos marad 5V-os USB-ről tápolva. Az igazsághoz tartozik az is, hogy amennyiben POE tápellátásról járatjuk, a 37V->3V DC átalakítás miatt némileg több hőt termelhet az Olimex is, de erről a fizika tehet. Mivel a WT32 nem POE képes, ilyen téren nem lehet őket összehasonlítani. Az Olimexre integrált akkucsatlakozó és töltő is rejt magában érdekes lehetőségeket, no nem önálló ellátásként, hanem áramkimaradás alatti szünetmentesítésre kiváló. (~6óra)
Az már csak apró könnyítés, hogy az ESP32-POE lapon van integrált UART chip, ezért közvetlenül USB-ra kötve programozható.
Ennyi pozitívum után mi szólhat mégis a WT32-ESP01 mellett? Nagyjából csak az ára, és a kis mérete, ami a puritán tervezéséből adódik.

	WT32-ETH01	Olimex ESP32-POE-ISO-IND
Ethernet	✔	✔
PoE	✘	✔
USB programozás	✘	✔
LiPo töltés	✘	✔
Akkus szünetmentesítés	✘	✔
SD kártya	✘	✔
Stabilitás	közepes	kiváló
Ár	kb. 5 ezer Ft	kb. 15 ezer Ft

Összefoglaló

Miért gondolom úgy, hogy van létjogosultsága ennek az eszköznek egy okosotthonban? Először is, aki már kipróbált néhány wifis eszközt, észre kellett vegye, hogy nem egészen akkumulátor-barát, ha van is akkus wifis eszköz, azokra a gyártó tesz USB csatlakozót fix tápellátás céljából, ami nem véletlen. Ha pedig tápkábelt úgyis vinni kell a szenzorig, az akár egy UTP is lehet, a PoE képes eszköz pedig egyetlen kábelen tud adatot továbbítani és tápellátást nyerni is.

ESP32 Cheap Yellow Display

eNeS — Thu, 16 Jul 2026 21:18:16 +0200

Röviden "CYD" néven hivatkoznak az olcsó sárga kijelzőre, ami egy ESP32-t is tartalmaz beépítve, ezért egyszerű dolgokat forrasztás nélkül is el tud belőle készíteni egy hozzám hasonló hobbista.

Az igazsághoz tartozik, hogy nem egy, hanem több különféle méretben is kapható ilyen, én a leggyakrabban használt, hangzatos nevű ESP32-2432S028 modellt szereztem be, ami 2.8" kijelzőjű, de létezik 2.4, 3.2 és 3.5 méretben is.

A hardverről

A motorja egy ESP-WROOM-32 vezérlő, 240MHz, 520 KB SRAM, 4MB flash tárhellyel.

Az ESP32-WROOM változat nem tartalmaz PSRAM-ot. Ez elsősorban akkor jelent korlátot, ha nagyobb grafikus felületeket vagy sok képet szeretnénk használni. Aki sok animációt szeretne vele megoldani.. 520KB memóriával nem nagyon fog menni, ebből a képernyőbuffer így is elviszi a memória harmadát.

Teljes mérete 86x50mm, a 2.8" méretű és 320x240 felbontású kijelzőre rajzolásért egy ILI9341 SPI chip felel, ami mellett egy szintén SPI-re kötött XPT2046 érintésérzékelő szenzor kapott helyet. Az érzékelő rezisztív, vagyis nyomni kell, nem multitouch és kevésbé érzékeny mint pl egy modern telefon kijelzője.
A csomagban általában egy műanyag érintőtoll is található.

GPIO kiosztás:

GPIO02	SPI DC
GPIO04	RGB LED PWM_i 1
GPIO05	SDCARD SPI CS
GPIO12	SPI MISO
GPIO13	SPI MOSI
GPIO14	SPI CLK
GPIO15	SPI CS
GPIO16	RGB LED PWM_i 2
GPIO17	RGB LED PWM_i 3
GPIO18	SDCARD SPI CLK
GPIO19	SDCARD SPI MOSI
GPIO21	P3 TFT BackLight
GPIO22	CN1-P3 - szabadon használható
GPIO23	SDCARD SPI MISO
GPIO25	Touch SPI CLK 2
GPIO26	Speaker DAC out
GPIO27	CN1 - szabadon használható
GPIO32	Touch SPI MOSI 2
GPIO33	Touch SPI CS
GPIO34	ADC Light
GPIO35	P3 - szabadon használható, de csak Input
GPIO36	Touch IRQ
GPIO39	Touch SPI MISO 2

A hátulján a képen jobb alul látható a CN1 és P3 csatlakozó, amin a szabadon használható GPIO-k elérhetőek. A CN1-et praktikus módon lehet I2C csatlakozóként használni, a P3-on nagyjából csak a GPIO35 marad, a GPIO21-et ne nagyon akarjuk másra használni, mert fixen az vezérli a kijelző háttérfényét.

Említést érdemel még a GPIO26, ami egy SC8002B erősítőn keresztül van kiengedve a SPEAK csatlakozójára, az RGB led a hátulján szerintem csak mérsékelten hasznos, de erre is elmegy 3 db GPIO, van egy SD kártya foglalata a 2-es számú VSPI buszon, és egy integrált előlapi LDR fényérzékelő a GPIO34-re kötve.

A vásárlásnál érdemes figyelni arra, hogy legalább háromféle hardverváltozat létezik ebből a 2,8"-os modellből is. A GPIO-kiosztás, a kijelzővezérlő, az USB-csatlakozó, sőt még az SD-kártya bekötése is eltérhet. Emiatt az interneten található példaprogramok nem feltétlenül működnek módosítás nélkül minden változaton.

És akkor összefoglalom mire nem jó:

képnézegetésre ez a felbontás enyhén szólva nem alkalmas
videolejátszásra a vezérlő sebessége nem alkalmas
3D grafikákra vagy gyors, folyékony mozgásokra se számítsunk a kijelzőn a gyorsítás hiánya és gyenge CPU miatt
az SC8002 gyárilag túl van erősítve így a hang recseg, tehát zenehallgatásra sem a legjobb választás - kivéve ha mégis forrasztópákát ragadunk

Mire lehet mégis jó?

Érintőkijelzője miatt különböző vezérlőket, gombokat, csúszkákat tehetünk ki rá, amivel okosotthonunkat kezelhetjük, dashboard-szerű egyszerű kijelzőként, pl hőmérséklet-fogyasztás megjelenítésére is nagyon jó.
Egyszerű asztali hőmérőt is fabrikálhatunk belőle, de mivel wifis eszközről van szó, órákban mérhető az akkuról elérhető üzemideje, így vezetékes tápellátásút természetesen.
A 3 db szabad GPIO miatt komolyabb projektnél, például termosztát, ahol kellene már relét is vezérelni, I2C hőmérőt, esetleg mozgásérzékelőt, ott már egy I2C portbővítőre is szükség lesz, de megoldható persze.

Írhatunk rá egyedi szoftvert is, de a Tasmota támogatja az alapfunkcióit: (SD kártya támogatást nem láttam benne)

https://templates.blakadder.com/sunton_ESP32-2432S028.html

A normál ESP32-höz való tasmota32-lvgl binárist kell rátölteni akár a Tasmota Web Installer, akár esptool segítségével.

Feltöltés után a Tools->Manage File Systems alatt kell létrehozni a fenti leírás szerinti display.ini állományt, nekem az elejét le kellett lecserélnem erre, mert egyébként összecsúsztak a sorok:

:H,ILI9341,320,240,16,SPI,1,*,*,*,*,*,*,*,40
:S,2,1,1,0,40,20
:r,2

Természetesen az ESPHome is támogatja, az alábbi online varázslóval még YAML konfigurációt is lehet készíteni az eszközhöz:

https://cheapyellowdisplay.co.uk/config-generator

Ítélet:

Összességében szerintem ez nem egy "mindenre jó" ESP32 fejlesztőpanel, hanem egy olcsó, kijelzővel szerelt HMI-panel. Bizonyos célokra jó lehet. De valamiért az alábbi vicc jutott eszembe róla:

Jól, gyorsan és olcsón dolgozunk, de ebből a háromból egyszerre csak kettő választható.

LuckFox Pico Pro SBC

eNeS — Tue, 14 Jul 2026 16:34:57 +0200

Mindig érdekeltek a Raspberry Pi-hez hasonló Single Board Computer-ek, korábban írtam az egyedi Milk-V DUO típusról is, ami annyira nem győzött meg végül.
Ám szereztem közben a Luckfox gyártótól egy Pico Pro nevű versenyzőt, ami beépítve tartalmazta a LAN csatlakozót és kicsit jobban el volt eresztve memóriával.

Az RV1106G2 Cortex A7 1.2Ghz sebességű vezérlője csak úgy száguld a 128MB DDR3 memóriával, még az apt is gördülékenyen megy, ami, ahogy írtam a 64MB-os Milk-V esetén komoly akadálynak bizonyult. Aki ennél is többre vágyik, a Max változatában már 256MB DDR3 van.

Említésre méltó, hogy hardveres képfeldolgozást javító egysége is van (ISP) a max 5MP felbontású kameraképek gyors feldolgozásához, H264/H265 kódoláshoz. A kamerát a LAN mögött levő MIPI CSI csatlakozóra lehet kötni. Ezen felül van benne egy NPU, ami kifejezetten AI gyorsításra szolgál - no nem a több millió paraméterű AI modellekre kell gondolni, hanem a képanalitikákra, mint a személy- és objektfelismerés, osztályozás, mozgásdetektálás gyorsítása.
Látható, hogy elsősorban kamerának szánták a lapot, de ez nem jelenti azt, hogy ne lehetne más okoseszközt faragni belőle, mert van még 26 használható GPIO vonala is. E mellett beépítve van 256MB NAND flash tárhelye, amin gyárilag van telepítve egy buildroot Linux, valamint csatlakoztatható külső akku az RTC óra idejének megtartásához, illetve SD kártya foglalata is van.

A telepítés azért már nem ilyen egyszerű, leginkább Windows felhasználókra van kihegyezve, a gyártó SocToolKit nevű programjával lehet a NAND flashre felmásolni a saját magunk által fordított, vagy a gyártó által 2025-ben kiadott Ubuntu 22.04-et... hát ezt én most kihagytam. De szerencsére az Armbian oldalon látom ám, hogy van rá támogatás, igaz csak Community, tehát nem hivatalos.

Letöltöttem hát az Armbian Imager programot (kísértetiesen hasonlít a Raspberry Pi Imager-re) és rákeresve valóban ott vigyorog a Pico Pro a Boardok között. Első körben a jobb oldalon levő fogaskerék alias beállításoknál létrehoztam egy profilt, ami engedélyezi a vezetékes LAN-t és beállítja a root jelszavát, valamint egy usert - ez mind kell ahhoz, hogy SSH-n elérjük majd később.

Miután ezzel megvoltam, a varázslón végigzongoráztam a Board típust, a minimális Debian Trixie 13 CLI verziót választottam, a behelyezett SD kártyát kiválasztottam és már csinálta is. (a korábban létrehozott profilt ne felejtsük el kiválasztani másolás előtt az utolsó lap alján)

Itt jött aztán az érdekes rész, mert beraktam az SD kártyát a Pico Proba, de nem az Armbian indult el róla, hanem az előtelepített buildroot linux... aránylag gyorsan rámtört a felismerés, mert a 22-es SSH port nem volt nyitva, ellenben az 5555 ADB port igen. Nézegettem ADB-n keresztül a syslogot, felismerte az SD kártyát, viszont úgy volt beállítva a cmdline, hogy csak flashről induljon. Remek, elmondtam pár hálaimát a tervezőkért, hogy jó egészségben érjék meg az öregkort, majd kicsit olvasgattam, és a fórumon ott a tipp, hogy ilyen esetben törölni kell a flasht és akkor majd az SD kártyáról fog bootolni az eszköz.

Szóval mégis letöltöttem a gyártói segédprogramot: a SocToolKit, na az biztosan remekül fut windows alatt, de Linux Mint-el elindult, viszont nem csinált semmit néhány kövér hibaüzeneten kívül, úgyhogy a parancssoros Linux Upgrade Tool-t töltöttem le és végül ezzel sikerült megoldanom:

sudo cp 88-rockusb.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo service udev restart
chmod a+x rkdownload.sh
./rkdownload.sh -e download.bin

Az rkdownload érdekes módon nem akart futni sudo -val, ezért nincs előtte ez, viszont az udev szabályok felvitele után már nem is kellett emelt jog neki. Az rkdownload indítása előtt a BOOT gombot nyomva tartva USB adatkábellel a géphez kell csatlakoztatni a Pico Pro egységet. Ha látja, eléri és joga is van törölni, akkor ezt írja:

[rkdownload.sh:info] Erase All Flash...
Download boot ok.
Start to erase lba begin(0) count(7fc00)...
Erase LBA (100%)
Erase LBA ok.
[rkdownload.sh:info] Start to reset device...
Reset Device OK.

Betettem az Armbiannal megírt SD kártyát, kapott LAN kábelt és áramot, bebootolt, ahogy illik és máris be tudtam lépni SSH-n a vadiúj 26.8-as Armbianba. A GPIO használathoz gpiod van előtelepítve az Armbianon, gpiodetect & gpioinfo. A CLI rendszer 113MB RAM-ot lát, amiből 36MB-t használt, de azért még 255MB swap memóriát is csinált az SD-re. :) Nem túl sok, de használható. Érdekesség, hogy minden I2C és SPI vonal be van kapcsolva rajta, tehát az I2C/SPI jelölésű lábakat nem lehet szabad GPIO-ként használni, ezeket más lapokon külön overlay-ekkel lehet engedélyezni, itt erre nincs mód - a jelenlegi Armbian verzióban, de ettől még később lehet majd. Extra rajta a Raspberrykhez képest, hogy 2 db 10 bites felbontású ADC is van rajta, igaz csak 1.8V-ig bírják, ezért feszültségosztó is kellhet eléjük. Több ponton hasonlít a Radxa Rock Pi S lapra.

Mérete 72x21mm, kicsit hosszabb, de hasonló alapterületű, mint a Raspberry Zero W lap, viszont a LuckFox esetében az RJ45 csatlakozó foglal elég sok helyet. A Rock Pi S 38x38mm mérete mondjuk alapterületet tekintve még mindig a legkisebb, igaz teljesen négyszög alakú.

Fogyasztását tekintve 5V 0.15A-ig ugrik fel induláskor, aztán normál üzemben 0.02-0.07A között ingadozik, viszont 58 fokra simán felmelegedett, így a Rock Pi S-en tapasztalt 40 fokhoz képest bátran mondhatom, hogy egy kissé melegszik.

Az áráról:

Aliexpressen most nagyjából 12e HUF + szállítás egyenesen Kínából, a lengyel (EU) Allegro oldalon viszont 9400 HUF + szállítási költségen beszerezhető.

Nagyjából ilyen áron lehet Raspberry Pi Zero W vagy Zero 2W-ket is rendelni, már amennyiben kapható, mert körülnéztem a magyar webshopokban és mindenhol elfogyott. Bár az Armbian (részleges) támogatás már jó jel, azért a Raspberryk dokumentációja és szoftveres támogatottsága még mindig vezet. Ennek ellenére ez a Luckfox lapka egészen jónak tűnik, már-már arra vetemedem, hogy ajánlani is tudom.

Avatto ZWT198 zigbee termosztát

eNeS — Mon, 13 Jul 2026 22:01:56 +0200

Ahogy már írtam, a wifis eszközparkomat leépítettem, ezért keresgéltem zigbee alapú termosztátot is. Költözésem miatt olyan megoldás érdekelt, ami 230V nélkül is működik. Végül az Avatto ZWT198 típusból vettem, ez kb 10e HUF áron volt akkoriban is, és úgy látom egészen jól tartja az árát. Meglepő módon akkor sem került sokkal többe Magyarországról véve, mintha Kínából rendeltem volna.

Kicsit zavart ugyan, hogy ugyanazzal a típusnévvel hivatkoznak a WiFi és Zigbee variánsra is, de szerencsére Zigbee-s érkezett hozzám. Bele is néztem, és betettem a működéséhez szükséges 3 AA elemet is, mert USB-ről nem tudom táplálni, nincs áram a termosztát helyén.

Azt látom, hogy egy ZT3L chip biztosítja a zigbee kommunikációt, ez a Tuya sajátja, egy 32 bites ARM Cortex-M33 CPU-val, 48MHz-es, 64KB RAM, 1MB Flash tárhely, 3.09dBi erősítésű integrált PCB antennával. A fogyasztása 8-40mA közötti adatlap szerint, úgyhogy gyanítom ezért tettek bele egy második chipet, ami alatta látható, de annak jelöléseit akkurátusan eltávolították. Mivel az adatlap szerint átlagosan nem mili, hanem mikroampereket fogyaszt a készülék, ez csak úgy jöhet ki, ha ez a második chip kevesebbet fogyaszt, és ő intéz mindent: a kijelzőt, a hőmérsékletet is gyűjti, illetve a ZT3L-t felébreszti, ha kommunikálni kell, egyébként az feltehetően alvó módban van.
Az alján az RT1 jelölésű hőmérő egy NTC +/- 1 fok mérési pontossággal. A bal felső sarokban látható japán relé egy Nexem EC2-3TNU 250VAC/2A - őszintén meglepett, hogy nem kínai relét használtak.
A képen látható NYÁK másik oldalán van a kijelző, ez az egész eleje levehető arról a talpról, ami a falra szerelendő.
Alapvetően nem lenne rossz ötlet, kivéve, ha a sorkapcsokra bekötött kábelek rövidek, mert akkor az elemcsere így izgalmas vállalkozás. Mint nálam, Jobban örültem volna, ha a sorkapocs a fix oldalon van, mint a Computherm termosztátoknál.

A Zigbee2Mqtt támogatja az eszközt Tuya ZWT198/ZWT100-BH néven.

A párosításhoz a felfelé nyilat kellett nyomni a kijelző elején 5 másodpercig, ekkor a wifi-szerű ikon elkezd villogni - ez a zigbee modellnél azt jelzi, hogy zigbee párosítás módban van. :)

Nagy szívfájdalmam, hogy a Zigbeen nem továbbítja az elem állapotát, bár a kijelzőjén van elemtöltöttség jelzés. Ez egy feketepont. Ám mivel percenként fixen bejelentkezik, tudtam olyan automatizmust írni, ami riaszt, ha nem jelentkezett be x ideig - mert akkor lemerült az eleme.

Az első fűtési szezonban kb 4 hónapot bírt ki egy elemmel, de akkoriban bevallom sokat nézegettem a kijelzőjét. A második szezonban már bíztam a HA megjelenítésében, ezért nem nyomkodtam az eszköz gombjait, vagyis nem kapcsolt be a kijelzője (elemes működésnél automatán kikapcsol a kijelző egy idő után, ha nem nyomnak meg rajta semmit) és már több mint 8 hónapja megy ugyanazzal az elemszettel. Szóval a legnagyobb fogyasztója a kijelző.

Az OTA frissítés Tuya eszköz lévén csak Tuya appból és gatewayen keresztük működik, mivel nem adják ki külsősöknek, így Zigbee2Mqtt-vel nem lehet frissíteni a firmwaret rajta.

Egyébiránt elégedett vagyok vele, a hőmérője az ígért +/-1 fokon belül mér (a többi hőmérőmhöz viszonyítva) , a Local temperature calibration-al hozzá tudom igazítani egy másik szoba hőmérőjéhez is, az ütemezője nagyon mezei, azt nem használom semmire, a HA vezérli direktben.

A beállításai között lehet Internal/External szenzor között váltani, de erre nézve semmi leírást nem találtam, viszont az I2C ki van vezetve a NYÁK-on, elképzelhető, hogy lehetne ráforrasztani egy csatlakozót és arra dobozon kívüli I2C hőmérőt is. :)

Otthonokosítás újratöltve

eNeS — Sun, 19 Oct 2025 16:50:19 +0200

2025 a változások éve volt számomra, új munkahely, új város, új lakhely.
Nem nagyon értem rá okosításokkal foglalkozni, sem a blogra írni, de azért persze eszközöltem változásokat.
Első körben nyugdíjba küldtem minden WiFis eszközömet, ESP-ket, Raspberry Pi-ket, Shellyket egyaránt. Feleslegesen sok erőforrást használnak el, az elemes zigbee eszközök gazdaságosabbak, és ahogy költözéskor rá kellett jönnöm, könnyebb őket tetszőleges helyre áthelyezni.
A második nagy változást az jelentette, hogy a Domoticz megszüntette a Raspberry PI Zero W bináris támogatását, így minden frissítéskor forrásból kellett volna fordítanom. Hosszas megfontolás után így lemondtam a Domoticzról, és áttértem Home Assistant rendszerre. A Domoticz egyetlen nagy előnye az volt, hogy minimális erőforrásigénye miatt bármin elfutott szinte, a legkisebb RPI így tökéletes szerver volt, 5W-os fogyasztása 24/7 használatban verhetetlen volt.

Ám semmi nem tart örökké, így nyomozásba kezdtem és redditen találtam egy ígéretes megoldást, a Home Assistantot sokan használják kis teljesítményű vékonykliensen, virtualizálás nélkül. A HP T520 egy RPI3-hoz hasonló teljesítményű, ám már nem ARM, hanem x86 eszköz, M.2 SSD-vel. Alapból 6W-ot fogyaszt, csúcsra járatva a CPU-ját max 10W-ot. Ez még számomra elfogadható.

Ezt a típust már egy ideje nem gyártják, de használthoz nagyon jó áron lehet hozzájutni, Allegro.PL oldalon 17 EUR körül beszerezhető szállítással együtt.

A telepítésre a hivatalos x86-64 live megoldást használtam, készítettem egy másik gépen egy USB bootolható Ubuntu pendrive-ot, elindítottam vele a T520 minigépet, letöltöttem a szükséges 340MB-os image fájlt és a Restore disk image-el kiírtam a minigépben levő M.2 SSD-re. Következő indításkor már a HA indult a gépen.

Egy apró problémám volt vele: A boot mód Legacy támogatását bekapcsolva kell hagyni a BIOS-ban, mert különben nem fog monitor nélkül újraindulni. De miután erre rájöttem, már stabilan elmegy a TV asztalom alatt, csöndesen, mert passzív hűtéses.

Újragondoltam, a céljaimat, mi az amire szükségem van, mi az amit érdemes továbbvinni a régi rendszerből. A BLE hőmérők (LYWSD03, LYWSD02) a legtakarékosabbak elemhasználat szempontjából, ehhez egy kéznél levő noname bluetooth USB sticket csatlakoztattam az új HA szerveremhez, és gond nélkül gyűjti is az adatokat. Az ajtónyitás érzékelők, mozgásérzékelők, a lakás legtávolabb részében levő hőmérő és vezérelt konnektorok pedig mind zigbee-sek lettek, a konnektorok egyúttal zigbee jeltovábbítók is. Az adatok vételét a meglévő Sonoff ZBDONGLE-P zigbee USB adapterrel és a sok eszközt támogató Zigbee2MQTT-vel oldottam meg.
Amin sokat gondolkoztam az a termosztátom, mert nem igazán áll rendelkezésre áram azon a falon, ahol a lakással járól Computherm van, és bizonyos okokból nem szeretnék vezetékelni, így egy elemes zigbees termosztátot üzemeltem be, amiről a későbbiek során szándékozom megírni a tapasztalataimat.
A HA szkriptelésével nem barátkoztam még meg, elég körülményes eddig.

NEO Coolcam hőmérős beltéri sziréna NAS-AB02W (WiFi)

eNeS — Thu, 18 Jan 2024 10:46:40 +0100

Íme egy újabb okoseszköz, ezúttal egy wifis sziréna, ami e mellett hőmérsékletet és páratartalmat is mér. Hasonló DIY eszközt már készítettem korábban, ám ezúttal megnéztem egy gyári kütyüt is közelebbről.

A készüléket elsődlegesen 5V-os fix tápellátásra tervezték, a rajta látható microUSB csatlakozón keresztül, ám a hátulját levéve behelyezhető 2 db 3V-os CR123 elem is, ami áramkimaradás esetén szünetmentesíti a használatát. A CR123 ugyebár nem tölthető, tartalék áramellátásnak szánták ide, kapacitásától függően (~1500mAh) akár 6-8 órán keresztül is képes lehet működésben tartani ezt az eszközt. Fő funkciója a hangjelzés, de egy hőmérő szenzor is helyet kapott benne.

A NEO gyártó nevével fémjelzett eszközök Tuya felhővel működnek, ám a blog olvasói nyilván sejtik, hogy nem gyári firmware-el kívántam használni. Nosza, szerencsére csak három kis csavar fogta, ami az alján levő konzol eltávolítása után könnyen hozzáférhető.

Viszont annak ellenére, hogy a Tasmota Blakadder adatbázisban szerepel, sajna az én NAS-AB02W6 v4 altípusom nem fog Tasmotával működni, mivel a Tasmota csak ESP chipeken fut, a v4 pedig egy Beken chipet kapott, méghozzá egy BK7231N-t.

De azért fel a fejjel, erre is van megoldás! Már egy éve létezik az OpenBeken nevű projekt, ami a Beken chipekre készült, némileg Tasmotához hasonló nyílt forrású firmwaret takar, megismerkedtem hát vele.

https://github.com/openshwprojects/OpenBK7231T_App

Ezen az oldalon a "Releases" alatt letölthetőek a kész firmware image fájlok a BK7231T, BK7231N, T34, BL2028N, XR809, BL602, LF686, W800, W801, W600, W601, LN882H chipekhez.

Node hogyan tegyük fel a készülékre?

Volt lehetőség régebben a CloudCutter használatával OTA módon, vezeték nélkül is feltenni az új firmwaret, de a 2022 februárnál újabb kiadású firmwarekben a gyártó javította a hibát, ami ezt lehetővé tette. Nem kizárt persze, hogy véletlenül most is a kezünkbe kerülhet régebbi firmware-el szerelt eszköz, ami a raktár sarkában állt eddig, de ne fűzzünk ehhez nagy reményeket.

Ami biztosan működik, az a kábeles feltöltés, amihez létezik egy GUI flashelő alkalmazás, aminek Windows-t használók nagyon fognak örülni, mert Windows .NET alá készült.. elvileg le lehet fordítani Linux mono-ra is, de nem kísérleteztem vele.

https://github.com/openshwprojects/BK7231GUIFlashTool

Szerencsére a programozáshoz szükséges lábak szépen feliratozva vannak:

A CP2102 TX lábát a BK chip RXD, az RX lábat a TXD, a 3V3 lábat a WIFI_3V3-ra és a GND-t persze a GND1-re kell kötni. Amire még szükségünk lehet az a CEN láb, ezt egyelőre ne kössük sehová, de készüljünk fel rá.

Miután ilyenformán összekötöttük a chipet egy CP2102 segítségével, és azt a Windows fel is ismerte virtuális soros portként, akkor azt ki tudjuk választani a "Select UART port" mezőben, majd kiválasztjuk a chip típusát, esetemben ez a BK7231N volt. Utána érdemes a "Download latest from Web" gombra nyomni, ezzel letölti a legújabb megfelelő firmwaret. A letöltés ablakban jól jegyezzük meg a letöltött állomány nevét, mert a "Select firmware"-nél nekünk kell azt kiválasztani.
Mindezek után rányomunk a "Do backup and flash new" gombra, kicsit gondolkozik a program, majd kéri, hogy reseteljük a chipet, hogy elkezdhesse a műveletet... ezt vagy úgy végezzük, hogy a 3V3 kábelt lehúzzuk majd visszakötjük (nekem ez nem jött be) vagy a CEN lábat GND-re húzzuk, pontosan 0.25 másodpercre... Nem mondom hogy könnyű, azt se, hogy elsőre sikerült. :D Mondjuk azt, hogy harmadjára ráharapott, és az alább látható biztató "Writing sector" üzeneteket kezdte írni, majd a megnyugtató "Write success" üzenet jelezte, hogy kész.

Itt említeném meg, hogy a lapon a lyukak meglehetősen kicsik, de mit ad isten, az UTP erek lecsupaszított réz része éppen belemegy, így forrasztanom se kellett! :D

Bár a BK chip adatlapja szerint 200mA feletti fogyasztást produkál (szemben a régi ESP chipek 80-160mA-ével!) és ugyan a CP2102 3.3V-os lába max 100mA-t tud papírforma szerint leadni, ám amíg nem akarok wifi kapcsolatot felépíteni, csak egy gyors programozásra kötöttem be, ellátta a feladatát. (bár egy külső 3.3V tápot szoktak javasolni erre a célra az OpenBeken-nel foglalkozó fórumokon)

A GUIFlashTool a sikeres írást követően elmentette egy backup almappába a régi gyári firmwaret, és megpróbálta kiolvasni a GPIO beállításait az abban levő konfigurációs partícióból. Ez általában működhet, ám sajnos ennél a típusnál nincsenek a WiFi chipre GPIO-k kötve, hanem soros vonalon van egy másodlagos feldolgozóval összekötve, egy számomra azonosíthatatlan FMD G3A4GEH -val. Gyakorlatilag ez az FMD végzi a LED villogtatást, a hangjelzést, illetve a hőmérő és páramérő szenzor leolvasását, a Beken chip csak a netet biztosítja, a kettő között az úgynevezett "TuyaMCU" protokollon folyik a kommunikáció. Amit a Tasmotához hasonlóan az Openbeken is támogat.
Van benne egy 8 ohm 2W hangszóró, ami elméletileg 100dB hangerővel tud riasztani, de gyakorlatban egy 8002D erősítő hajtja meg, aminek az adatlapján max 60dB szerepel.. de én nem vagyok kimondottan hangosítási szakember, így ettől még igaz lehet, amit írt a gyártó.

Szépen összerakjuk és áram alá helyezve immár egy "OpenBK7231N_xxxxx" SSID fog megjelenni, amire rákapcsolódva a 192.168.4.1 címen tudjuk megadni neki a saját wifi hálózatunk adatait.

Azt tudni kell, hogy ez nem egy az egyben Tasmota, csak hasonlít rá a kezdőlapja, a témája, és néhány főbb képességet átvett tőle, de ahogy a WebApplication felületére átmegyünk, rögtön látjuk, hogy máshová kerültünk. (Launch Web Application) - Megjegyzés: a webapp betöltéséhez az eszköznek ki kell látnia az internetre! Persze ez a későbbi működéshez nem szükséges, csak a beállításhoz.

Itt a Config menüben láthatóak az alapadatok, a GPIO lábak beállításai, és esetünkben a Channel típusok, mert abba fogjuk beügyeskedni a TuyaMCU adatait. Normál esetben az Import menüben illesztenénk be azt a JSON-t, amit a GUIFlashTool exportált ki korábban, de mivel az üres, ezért másképp közelítjük meg a dolgot. Bemegyünk a Filesystem menübe, ahol a "List filesystem" listázná ki a rajta levő fájloket, de ez még üres... úgyhogy a "Create File" segítségével létrehozunk egy autoexec.bat nevű fájlt, ami minden induláskor végre fog hajtódni az eszközön.

Ide pedig a következő parancsokat illesztjük be, majd a Save gombra kattintva el is mentjük:

//Drivers
startDriver TuyaMCU
//
//Channels
setChannelType 1 toggle
setChannelType 2 Temperature_Div10
setChannelType 3 Humidity
//ch4 = chime sound
setChannelType 4 TextField
//ch5 = volume 0->high 1->middle 2->low
setChannelType 5 TextField
//ch6 = alarm duration in sec
setChannelType 6 TextField
//ch7 = power type 1->battery high 2->medium 3->low 4->usb port
setChannelType 7 TextField
//
//Links & Vars
linkTuyaMCUOutputToChannel 104 bool 1
linkTuyaMCUOutputToChannel 105 val 2
linkTuyaMCUOutputToChannel 106 val 3
linkTuyaMCUOutputToChannel 102 enum 4
linkTuyaMCUOutputToChannel 116 enum 5
linkTuyaMCUOutputToChannel 103 val 6
linkTuyaMCUOutputToChannel 101 enum 7
//Stop blinking
tuyaMcu_defWiFiState 3
//Ask for status at startup
tuyaMcu_sendQueryState
scheduleHADiscovery 1

//Events
//Ask for temperature data at every 2 minutes
addRepeatingEvent 120 -1 backlog tuyaMcu_sendQueryState;

Majd a főoldalán nyomunk egy Restart-ot és újraindítás után már mutatja is az eszközöket:

Amennyiben szeretnénk az adatokat helyi szerverünkbe küldeni, a Config -> Configure MQTT alatt tudjuk ezt megtenni, ha pedig Domoticz vagy HA rendszerünk van,a Config -> Home Assistant Configuration alatt tudjuk az Autodiscovery topicot módosítani, illetve kézzel indítani egy Discoveryt a "Start Home Assistant Discovery" -re kattintva. Ugyanitt lehetőség van kézzel is módosítani a küldendő konfiguráción (bár a yaml szerkesztést sose szerettem), ám szerencsére automatán átment a hőmérséklet, páratartalom és a kapcsoló eszköz is szépen.

Ami fontos: Domoticz esetén az OpenBeken Config -> Configure General/Flags alatt a Flag33 legyen bepipálva, különben a hőmérsékletadatokat nem alakítja át a Beken küldés előtt, és a 24.1 fokból 241 fok lesz. :)

A hőmérő részétől amúgy nem vagyok elájulva. 0.3C-onként lépnek a visszaadott értékei, de ez nem a pontossága, hanem a léptéke lesz. Csak mihez tartás végett egy 21 fokos szobában 24 fokot mutatott... Nem tudom hol helyezkedik el a szenzora, de olyan mintha a doboza belső hőmérsékletét mérné inkább, a szellőzése pedig enyhén szólva is karcsú. (látszik is, ahogy bekapcsolás után majdnem jó, aztán szép lassan melegszik, de a szoba hőmérséklete az valójában nem növekszik) Nem igazán reagált arra sem, ha a leheletemmel próbáltam melegíteni, viszont a páratartalom változását azt azonnal észlelte legalább. Ha hőmérőt keresnék, biztosan nem ez lenne az első választásom.

Egyéb készségei:

Be lehet állítani, hogy megadott hőmérséklet vagy páratartalom esetén riasszon, a riasztás hangerejét három fokozatban lehet állítani 0 a hangos, 1 a közepes, és 2 a halk. A riasztásra 18 féle (0-17) hangminta közül lehet választani, a fent hivatkozott Blakadder adatbázisban szerepelnek, és a riasztás mellett kéken villogó LED-ek (miért pont kék, ha sziréna?) is jelzik, hogy esemény van.

Van egy fórumtéma is az elektroda.com -on, ahol ezt a típust vesézgetik: https://www.elektroda.com/rtvforum/topic3947937.html

Ítélet?

OpenBeken-nel jól hekkelhető, ez pozitívum. Ajtócsengőnek vagy ébresztőnek el tudom képzelni, konkrétan szirénának nem túl combos, az igazi sziréna olyan, amitől a szomszédok azonnal elkezdenek dörömbölni, hogy mi a fene van... ez nem olyan. A hőmérő része pedig nevetséges.

Blitzwolf BW-SHP13 zigbee konnektor

eNeS — Mon, 01 Jan 2024 10:52:18 +0100

A Zigbee eszközeim sorában a következő az SHP13, ami egy fogyasztásmérős okoskonnektor. Zigbee 3.0 kompatibilis és maximum 16A-es fogyasztót tud vezérelni, egyébiránt a Tuya ökoszisztémához tartozik.

Roncsolás nélkül sajnos nagyon nehezen szedhető szét, ez is a ragasztott eszközök sorához tartozik, így nem nézek bele. Van rajta egy pont megfelelő méretű gomb is, mérete pedig egészen szolíd, nem takarja el a szomszéd konnektorokat. (46x46x82mm)

Természetesen mint minden zigbee eszközhöz, ehhez is kell egy gateway, amin keresztül hozzá tudunk férni, ami esetemben a zigbee2mqtt lett, mert ugye ez lokálisan, Felhő nélkül megy. Maga a konnektor router eszköz, így más zigbee eszközök számára jelerősítő szerepet is betölt.

Ahogy látható, az én modellem TS0121_plug néven azonosítja magát, nincs is vele semmi problémám, elégedett vagyok vele. Szépen küldi a fogyasztási adatokat is.

Azonban azt jó tudni, hogy az újabb szériák (az SHP15), amik pont így néznek ki, viszont TS011F_plug_1 és TS011F_plug_3 néven azonosítja őket a zigbee2mqtt, több hibával is bírnak, az egyik az, hogy véletlenszerűen kikapcsolnak, a másik pedig az, hogy időnként hibás mérési eredményeket küldenek.

Domoticz-al az MQTT Autodiscovery hardverrel a zigbee2mqtt szépen együttműködik, kapcsolásra a konnektor azonnal reagál.

Ítélet:

Az SHP13 mindazt tudja, amit egy okoskonnektortól elvárhat az ember, nekem bevált, csak ajánlani tudom.

IKEA Tradfri E1603 zigbee konnektor

eNeS — Fri, 22 Dec 2023 19:53:40 +0100

Mára már leginkább költséghatékony zigbee eszközöket használok itthon, valamint persze DIY wifi eszközöket, amik nem mennek a felhőbe.

Ebbe a sorba illik a következő egyed, ezúttal egy IKEA-s konnektort vásároltam tesztre.

Általában szeretek belenézni az új eszközökbe, ám sajnos a nyilvánvaló csavaron kívül még ragasztották is, így ezt max úgy tehetném meg, ha felmelegíteném, és némileg eldeformálnám, de megtette szerencsére más:

https://diystuff.nl/tradfri/ikea-tradfri-wall-outlet-switch/

Az IKEA eszközökben egy EFR32 vezérlő van ZLL (Zigbee Light Link) támogatással, ami Zigbee 3.0 vezérlőkkel nagyon szépen tud együttműködni. (régi 1.2-vel nem) Formatervezése.. hát mondjuk azt, hogy egyedi. Szépnek azért nem nevezném.

Viszont van egy elég érdekes hiányossága, nincs rajta gomb, amivel a relét lehetne ki-be kapcsolni, így az csak távolról lehetséges. (Ezt sajnos előre nem szúrtam ki a képeken, különben nem is rendeltem volna meg.) Az alján mindössze a tűhegynyi nyíláson elérhető párosító gomb található.

A zigbee2mqtt felismeri, persze csak ha Zigbee 3.0 kompatibilis az USB coordinator firmware-e! Bekapcsolás után egy hegyes eszközzel nyomva kell tartani a kis nyílás mögé rejtett párosító gombját, amíg nem kezd halványodni a LED-je. Ami egyébként vakító fehér fénnyel jelzi, ha a relé aktív.

Mint látható Router típusú, így más Zigbee eszközök tudják jelerősítőként is használni, egyébiránt csak ki-be kapcsolási funkciója van, nincs benne példának okáért fogyasztásmérő.

Ítélet:

Értékelhető gomb hiányában helyi használata elég korlátolt, mióta felemelték az árát, igazából már költséghatékony zigbee-repeaterként sem tudom ajánlani. Helyette a hasonló árú Neo NAS-WR07B okoskonnektort tudnám javasolni, vagy egy picit drágábban egy Blitzwolf-ot, melyekben fogyasztásmérés funkció is van.

Gyártó oldala

Milk-V Duo Linux SBC

eNeS — Sun, 17 Dec 2023 10:12:29 +0100

Az SBC vagyis Single Board Computer egy olyan integrált számítógép, ami egy lapon elfér, méghozzá igen kis helyen. Ennek a családnak talán a legismertebb tagja a Raspberry PI, amit aztán sok egyéb hasonló követett: az Orange Pi, Rock Pi, Nano PI, Banana Pi, LattePanda, Cubieboard és még sok egyéb...

Amikor tehát felfigyeltem az extra kis méretű Milk-V Duo lapkára, hát persze, hogy szereznem kellett egyet próbára! Nagyjából 9 dollárért jutottam hozzá, szállítási költséggel együtt.

A paraméterei a következőek:

CVITEK CV1800B (C906@1Ghz + C906@700MHz)
64MB RAM
10/100 Ethernet (PHY, kell hozzá egy kiegészítő)
microSD foglalat / opcionális NAND tárhely
USB Type-C adat és tápcsatlakozó egyben
26 GPIO csatlakozó 2.54mm kiosztású tüskékkel

És hogy a fogyasztásáról is essen pár szó: úgy hogy rá volt kötve LAN-ra, üresjáratban 5V 0.6A-et, ha pedig apt-vel megdolgoztattam, hogy az SD kártyát és a hálózatot is használja 5V 0.125A-t fogyasztott csúcsjáraton. Ami egészen jó egy Linuxot futtató géphez képest.

A GPIO csatlakozókiosztása az alábbi:

Videokimenete nincs, így monitort nem fogunk tudni rá kötni. Ellenben UART-USB átalakítóval rá tudunk nézni a konzoljára:

Pin 16/GP12/UART0 TX ezt kell az UART-USB RX lábára kötni
Pin 17/GP13/UART0 RX ezt kell az UART-USB TX lábára kötni
Pin 18/GND: GND ezt kell közösíteni az UART-USB GND-vel
mindeközben sem a 3V sem az 5V lábat ne kössük össze az UART-USB-vel, hacsak nem szeretnénk szikrákat látni, mert a MilkV az USBC-n keresztül kap tápot

A versenyzők balról jobbra: Raspberry Pi Zero W, Milk-V Duo, Raspberry Pi Pico

Érdekes módon a Milk-V Duo mérete pontosan megegyezik a Raspberry Pi Pico mikrovezérlőével, bár attól eltérően ez már Linux futtatására alkalmas. Csak emlékeztetőként: a Pi Pico 133Mhz-es, 264KB RAM-al és 2MB tárhellyel szerelt, és beágyazott programozásra használható, operációs rendszer nélkül.

A Duo-nak van egy apró tervezési hibája véleményem szerint: ha az ember beforrasztja a LAN csatlakozót, a microSD kártya többé nem igazán vehető ki, hacsak tövig vissza nem csípi az ember csípőfogóval a kiálló részeket.

Többek figyelmét is felkeltette a dolog, egyebek között Ubuntu és Arch Linux lemezkép is fellelhető ehhez a lapkához itt:

https://xyzdims.com/3d-printers/misc-hardware-notes/iot-milk-v-duo-risc-v-esbc-running-linux/

A készítő lelkesedésében viszont elhanyagolta az integrált LAN támogatást, ami nem is működik egyik általa készített rendszerben sem sajnos, mivel az USB-s RNDIS nevű megoldásra fókuszált, ami annyit tesz, hogyha valaki ráköti USB-n a Milk-V lapot a számítógépére, akkor egy USB-LAN-ként jelenik meg a 192.168.42.1 címen, ahová SSH-n be lehet lépni. És ha feldriverezzük a gépünket és be is állítjuk, akkor rajtunk keresztül képes lehet kijutni az Internetre is. Akár. Bár bevallom, engem ez a lehetőség a legteljesebb mértékben hidegen hagy.

Ugyanis van rendes LAN csatlakozása, amihez ha vásárolunk egy ilyen kiegészítőt, akkor normál LAN hálózatra köthető:

https://www.aliexpress.com/

Ahogy a fenti képen látható, nem túl bonyolult eszköz, élelmesebbek egy ilyen megoldással is kiválthatják:

Vagyis egyszerűen rákötik a 100 mbites csatlakozáshoz szükséges négy eret az UTP kábelből a Milk-V lapkára. Merész megoldás, de 10cm-nél rövidebb kábellel működik a visszajelzések szerint.

Sajnos a fenti OS image-ekkel ez nem fog menni, ellenben van egy másik Debian Linux image, amivel a LAN tökéletesen működik:

https://community.milkv.io/t/milkv-duo-duo-debian-full-7z-519m-download/862

Letöltése után Balena Etcher vagy USB Imager segítségével tudjuk az .img fájlt egy üres 8GB-s SD kártyára kiírni. Behelyezése után az eszköz működésre kész, a LAN csatlakozóján DHCP-vel IP címet fog kérni.

Az SSH-n történő belépéshez a root felhasználó alap jelszava riscv.
A 64MB mellé egy 256MB méretű swap memóriát is aktivál az SD kártyán, hogy valamennyire azért működőképes maradjon a rendszer akkor is, ha a 64MB betelik. (és hamar betelik!) Ebből pedig az következik, hogy az amúgy sem túl hosszú életű SD kártyát még hamarabb tönkreteszi az állandó swappeléssel.

Maga a készítő is felhívja rá a figyelmet, hogy ez a kiadás nem stabil, csak kísérleti kiadás, és valóban.. az APT sources.list nem létező helyre mutat, szerencsére a Debian már támogatja a RISCV64 platformot, így át tudtam írni azt a hivatalos deb.debian.org -ra, így tudtam apt-vel telepíteni is.. Ellenben a "Building dependency tree" minden telepítés és frissítés előtt nagyjából 5-10 percig tart, ami a kevés memória miatt van, hiába swappelget, mint állat a háttérben, bele nem fagy ugyan, de gyors az nem lesz. Néha dob egy hibát a /run partíció miatt, ami 11MB méretű, de a Debian szerint ennek a legkisebb biztonságos mérete 16MB, ez szintén memóriában van, így ha átállítom az megint csak fogy...
Végül csak ráküldtem egy teljes apt upgrade -et, de annyi függőségi hibával állt le, hogy igazából ezt nem javaslom senkinek. :) Viszont jó hír, hogy nem nyírta ki teljesen a rendszert, mert újraindítás után is működött a fél-frissítés után.
Ellenben a duo-pinmux programot sem sikerült működésre bírnom, ami az egyes GPIO lábak funkcióit állítaná, ami azért jelentős hiányosság. E nélkül csak teljes kernelfordítással lehet változtatni ezeket, így a terveimet, hogy majd RPIEasy-be integrálom ezt a hardvert, fel kellett adnom egyelőre. Ez így nagyon kevés.

Állítólag van olyan, aki tudott már OpenWRT-t fordítani rá, de kész image-et nem láttam még rá, hogy kipróbáljam. Az OpenWRT kisebb memóriaigényű eszközökön is képes működni, így elméletben ez akár még jó is lehet. Egyszer majd.

Ítélet:

Ez a modell még nagyon messze áll attól, hogy általánosan használható Linuxot stabilan tudjon futtatni. A 64MB memória annyira vérszegény, hogy vásárlását nem tudom ajánlani jó szívvel. Ellenben a gyártó bejelentette a 256MB-os variánsa érkezését, amire kíváncsi lennék, mert az már jóval használhatóbbnak tűnik.

Shelly Plug S wifi konnektor

eNeS — Thu, 14 Dec 2023 10:44:55 +0100

A Shelly Plug utódja a Plug S, ami némivel kisebb méretű, és ESP8266 alapú eszköz. (Gen1 Shelly)

Papíron 2500W-os fogyasztót bír el, és képes mérni is a fogyasztást.
Van egy gomb az eszközön, amivel a relé állapotát lehet változtatni, de annyira picike, hogy nem állíthatnám, hogy kényelmes lenne a használata, ez egy fekete pont. A LED-je kéken világít állandóan, ha a hálózat elérhető, kiegészítve egy pirossal, amikor a relé aktív. Szerencsére ez a funkció kikapcsolható a menüjében (LED light control/WiFi Status light) ha nem szeretnénk, hogy állandó irányfényként működjön. :)

A korábbiakhoz hasonlóan első indulást követően egy saját WiFi AP-t indít shellyplug-s-xxxx néven, amire jelszó nélkül csatlakozhatunk, majd böngészővel a http://192.168.33.1 IP címet megnyitva beállítható az eszköz.
Az Internet & Security részben tudjuk megadni saját wifi hálózatunk nevét és jelszavát:

Ha sikeresen megadtuk ezeket és a Connect-re nyomtunk, elvileg máris elérhető saját hálózatunkból is.

Az MQTT beállítása ugyanúgy a Internet&Security->Advanced developer settings alatt található, mint minden más, korábban bemutatott Shelly-k esetében.
A Domoticz Autodiscovery hardverhez való hozzáadásában a ShellyTeacher nevű alkalmazás tud segíteni. Ennek a konzolos változatát akár direktben a szerveren is futtathatjuk python3 segítségével, a README-ben leírtak szerint, vagy letölthetjük a kész binárist 64 bites Windows/Linux rendszerre. Ez utóbbihoz az alábbi videós útmutatást tudom ajánlani:

Domoticz alatt az Autodiscovery létrehoz egy kapcsolható relé eszközt, egy belső hőmérséklelet mutató eszközt, és az aktuális fogyasztást (W) mutató eszközt. (a Watt-minute mértékegységben jelentő energia eszköz teljes értékű használatához viszont Domoticz 2023.2 verzió szükséges legalább)

A hardverről

Az ESP8266 mellett 2MB flash van benne, és érdekes módon egy az egyben ugyanaz a GPIO kiosztása, mint a Blitzwolf SHP szériás okoskonnektoroknak. (mik vannak?) Sőt, még a fogyasztásmérő is ugyanaz a BL0937, ami benne van.

A be-kimenetek a következőek:

GPIO-0: vörös LED
GPIO-2: kék LED
GPIO-13: Nyomógomb
GPIO-15: Relé
GPIO-5: BL0937 CF
GPIO-12: BL0937 Sel
GPIO-14: BL0937 CF1

Bár a gyári firmware szerintem tökéletes rajta, van lehetőség Tasmotára is alakítani. Itt leírják a vezetékes frissítés menetét:

https://faulty.cloud/blog/shelly-plug-s-pinout

de gondoltak azokra is, akik nem szeretnék szétszedni, OTA módon, vezeték nélküli is megoldható:

https://github.com/yaourdt/mgos-to-tasmota

A Tasmotához készítettek saját template-et is, bár mint írtam, ugyanaz, mint a Blitzwolf SHP:

https://templates.blakadder.com/shelly_plug_S.html

Ítélet:

Mivel ez még első generációs eszköz, helyette a Gen2 megfelelője a Shelly Plus Plug S ajánlott, ami már ESP32 alapú, van benne Bluetooth és helyi szkriptelési támogatás valamint Wifi jelismétlő funkciót is tud.
Jelenleg még ez a sima Gen1 változat is kapható a boltokban, nagyjából kétezer forint a különbség a kettő között, de a Shelly EU boltban már kifutott termék.

Gyártói adatlap

Shelly GAS

eNeS — Sat, 02 Dec 2023 15:56:09 +0100

A Shelly GAS egy vezeték nélküli, gázszivárgást érzékelő és jelző eszköz. Ezt a teszteszközt ismét bkil jóvoltából szereztem.

Ez egy Gen1 eszköz, vagyis ESP8266 van benne. Létezik vezetékes CNG és palackos LPG gázt érzékelő változata is. A képen nem látható, de a hátulján egy dugvilla van, mivel ez nem elemes, hanem hálózati áramról működik. Az alsó részén van egy jack csatlakozóra hasonlító nyílás, erre lehet kötni a külső gázelzáró manipulátort. (külön vásárolható)
A jobb oldalán pedig egy pici nyílást találhatunk, ezt a dobozban mellékelt tűvel megnyomva RESET-elhető a készülék szükség esetén. A tetején pedig egy tesztgomb látható, amivel tudjuk tesztelni, mi történik riasztás esetén..

Bekapcsolás után (fülbántó módon) két rövidet csippant az eszköz, és elkezd "körbeszaglászni", ez a művelet 2-3 percig eltarthat, egy hosszabb sípolással jelzi, ha végzett, ekkor ki is zöldül a kör alakú zöld LED-je... Amit mellesleg nem is lehet kikapcsolni, éjszakai irányfénynek így remekül használható. :) El tudom képzelni, hogy éjszaka ha áramingadozás van, ez a sípolgatás mekkora élmény lehet.

Amikor gázszivárgást érzékel, fantasztikusan irritáló módon sípol, papíron 70dB (egy méteren belül) hangerővel, a hangerő 1-11es skálán állítható a felületén egyébiránt. Mild leaknál másodpercenként egyet, Heavy leaknél már 5 másodperc folyamatos sípolást kombinál kis szünetekkel.

A gázrészecskék jelenlétét ppm -ben megadja számszerűen, valamint az állapotát is: "OK" nagyjából 2 ezerig, "Mild Leak"-et (2-3 ezer környéke) vagy "Heavy Leak"-et (4 ezer felett). A pontos értékeket nem láttam, mert meglepően gyorsan reagált, amikor a gázrózsa mellé helyezve teszteltem.

Használható a Shelly felhőben az alkalmazásával, vagy lokális hálózatban is felhő nélkül, ahogy minden Shelly.

A korábbiakhoz hasonlóan első indulást követően egy saját WiFi AP-t indít shellygas-xxxx néven, amire jelszó nélkül csatlakozhatunk, majd böngészővel a http://192.168.33.1 IP címet megnyitva beállítható az eszköz.
Az Internet & Security részben tudjuk megadni saját wifi hálózatunk nevét és jelszavát:

Ha sikeresen megadtuk ezeket és a Connect-re nyomtunk, elvileg máris elérhető saját hálózatunkból is.

Lokális hálózatban a Gen1-eknél szokásos Actions menüben tudunk az események (riasztás) bekövetkeztéhez maximum 2 db HTTP hívást kapcsolni.

Ha integrálni szeretnénk saját rendszerünkbe, az MQTT beállítása ugyanúgy a Internet&Security->Advanced developer settings alatt található, mint minden más, korábban bemutatott Shelly-k esetében.
A Domoticz Autodiscovery hardverhez való hozzáadásában a ShellyTeacher nevű alkalmazás tud segíteni. Ennek a konzolos változatát akár direktben a szerveren is futtathatjuk python3 segítségével, a README-ben leírtak szerint, vagy letölthetjük a kész binárist 64 bites Windows/Linux rendszerre. Ez utóbbihoz az alábbi videós útmutatást tudom ajánlani:

Domoticz alatt az Autodiscovery létrehoz két választókapcsolót, az egyikben az aktuális működési módot jelzi, a másikban a riasztás típusát, illetve a PPM értékét is regisztrálja egy külön szenzorban. (igaz ez utóbbit CO2-nek írja, de a lényegen ez nem változtat)

Shelly 1 PM

eNeS — Mon, 27 Nov 2023 20:56:36 +0100

A Shelly 1 megspékelve fogyasztásmérő funkcióval. Érdekes módon még a fizikai méretei is megegyeznek, 36x41x17 mm, a színe viszont sokkal rikítóbb, mint a kék színű sima Shelly1 volt. Mivel méretei megegyeznek, kompatibilis a Shelly1 Addonnal, valamint a hozzá nyomtatott tartókkal is természetesen.
Ezt a teszteszközt ismét bkil jóvoltából szereztem.

Gen1-es eszköz, ugyanúgy ESP8266 van benne, mint a korábbi modellekben 2MB flash tárhellyel. Maximum 16A-es fogyasztót képes kapcsolni, és mérni is max ennyi fogyasztást tud.

AC és DC áramra is beköthető, az alábbi bekötési rajzok szerint:

A korábbiakhoz hasonlóan első indulást követően egy saját WiFi AP-t indít shelly1pm-xxxx néven, amire jelszó nélkül csatlakozhatunk, majd böngészővel a http://192.168.33.1 IP címet megnyitva beállítható az eszköz.
Az Internet & Security részben tudjuk megadni saját wifi hálózatunk nevét és jelszavát:

Ha sikeresen megadtuk ezeket és a Connect-re nyomtunk, elvileg máris elérhető saját hálózatunkból is.

Domoticz alatt az Autodiscovery létrehoz egy kapcsolható relé eszközt, egy bemenet állapotát mutató input eszközt, az online állapot jelzését, valamint egy választó kapcsolót, ami mutatja, hogy rövid vagy hosszú gombnyomás történt. És persze nem utolsó sorban a fogyasztási adatokat.

Őszintén szólva ez már kifutó széria, helyette a Plus 1PM-et ajánlja a gyártó vásárlásra. (Az új Gen2 Plus szériáról ugyebár azt kell tudni, hogy ESP32 van benne, így több memória, flash tárhely áll rendelkezésre, ezért képes egyidőben felhő és MQTT kapcsolatot is fenntartani, valamint szkripteket is lehet rá feltölteni)

Shelly Button 1

eNeS — Thu, 23 Nov 2023 20:43:10 +0100

Valamikor 2018-ban készítettem egy DIY WiFi-s nyomógombot, és már akkor rá kellett jönnöm, hogy a WiFi és az elemes használat nem barátok. Így amikor a Shelly piacra dobta a Button nevű termékét, nagyjából sejtettem hogyan működik, és nem gondoltam, hogy ilyet kellene szereznem. Ismételten bkil jóvoltából azonban hozzájutottam egy ilyenhez, hát tesztelem.

Fehér és fekete színben gyártják, fizikai mérete 45mm x 45mm x 16mm
Nem túl nagy, bár a beépített akkumulátora miatt aránylag nehéz. Egy microUSB port van az oldalán egy gumidugóval rejtve, azon keresztül lehet tölteni. Egy kezelői gombja van a tetején, az alját óvatosan lepattintva pedig az akkumulátor alatt találjuk a Reset gombot.

Mivel ez még egy Gen1 eszköz, így egy ESP8266EX chip rejtőzik benne, 2MB flash tárhellyel megsépekelve. A tápellátását egy 3.7V-os 400mAh akku biztosítja, a gyártó szerint 3000 gombnyomásra elegendő szuflával egy töltésre.

Működését tekintve általában alvó módban van, 10-12 óránként egyszer ébred fel, akkor küldi az akku adatokat, meg jelzi, hogy él, ha kell. Egyébként csak gombnyomásra éled fel, 10-60 másodpercre, majd megint alszik. Ebből következik, hogyha el akarjuk érni a webes felületét, vadul nyomkodnunk kell a gombot, sőt ha mentünk valami beállítást, mentés előtt is, mert könnyen lehet hogy elaludt az eszköz, míg mi nézegettük a beállításokat. :D Elméletben, ha komolyan vesszük a 3000 gombnyomást és naponta max 6-szor nyomjuk meg, a 2 extra ébredését is beleszámolva akár egy évig is bírhatná az akku.. ám én még nem láttam olyan feszültségszabályzót, ami veszteségmentes, az pedig állandó fogyasztás, ha 3.7V-ról 3.3V-ra kell alakítani a feszültséget, így inkább max 2 hónapot saccolnék optimális esetben egy töltéssel az akku élettartamára, főleg ha használjuk is.

A korábbiakhoz hasonlóan első indulást követően egy saját WiFi AP-t indít shellybutton1-xxxx néven, amire jelszó nélkül csatlakozhatunk, majd böngészővel a http://192.168.33.1 IP címet megnyitva beállítható az eszköz.
Az Internet & Security részben tudjuk megadni saját wifi hálózatunk nevét és jelszavát:

Ha sikeresen megadtuk ezeket és a Connect-re nyomtunk, elvileg máris elérhető saját hálózatunkból is.

Bár támogatja az MQTT-t, ám mivel elemes eszköz és fel is kell ébrednie, ezért én a sebesség miatt ezt nem feltétlen ajánlanám. Az egyik dolog, amit elemes eszköznél szoktak ajánlani, az a fix IP cím beállítása, ezt ugyanitt tehetjük meg az Internet&Security alatt a "Set static IP address" pontot kiválaszva.

Az eszköz megkülönböztet egyszeres, dupla és tripla gombnyomást, valamint hosszú nyomvatartás eseményt is. Hátránya ennek a dolognak, hogyha egy rövid gombnyomásra lenne is szükség, akkor is vár még némi időt, hátha még megnyomunk egy gombot.. ennek a minimális hossza 200ms. (Multipush beállítás)

Célszerű az Action-ök alatt HTTP URL hívás formájában küldeni róla az adatot, ez a leggyorsabb és takarékosabb megoldás:

Ám akárhogy optimalizálgattam, 5 másodperc alatt érkezik meg a gombnyomás esemény a Domoticz szerverre ezen a módon. Mondjuk elég sok idő elmegy arra, hogy várja a további gombnyomásokat, közben villog az eszköz. Ez nagyon gyenge. Bár emlékezvén a Shelly nyitásérzékelő lomhaságára, igazából nem számítottam nagyon gyorsabbra.

Ha valaki mégis az MQTT mellett döntene, az is megoldható természetesen. Az MQTT beállítása ugyanúgy a Internet&Security->Advanced developer settings alatt található, mint minden más, korábban bemutatott Shelly-k esetében.
A Domoticz Autodiscovery hardverhez való hozzáadásában a ShellyTeacher nevű alkalmazás tud segíteni. Ennek a konzolos változatát akár direktben a szerveren is futtathatjuk python3 segítségével, a README-ben leírtak szerint, vagy letölthetjük a kész binárist 64 bites Windows/Linux rendszerre. Ez utóbbihoz az alábbi videós útmutatást tudom ajánlani:

Domoticz alatt az Autodiscovery létrehoz egy választókapcsolót, amiben mindig a legutóbb megnyomott típusú esemény lesz látható. 1x rövid, 2x, 3x és hosszú gombnyomás.
MQTT-vel már 8 másodperces reakciósebességet sikerült elérnie az eszköznek.

Ítélet:

Én inkább maradok a Zigbee nyomógomboknál, amik egy gombelemmel elmennek kb örökké és villámgyorsan reagálnak.

Bluetooth hőmérők Shelly Gen2 átjáróval

eNeS — Tue, 21 Nov 2023 14:56:21 +0100

Korábban írtam már az ESP32 és a BLE hőmérőkről, ott egy saját micropythonos megoldásomon keresztül mutattam be a dolgot.

De miért is jó a BLE?

A Bluetooth Low Energy kifejezetten az alacsony fogyasztásra fókuszál, így egyáltalán nem meglepő, hogy ezekben az eszközökben ritkábban kell elemet cserélni. Feltéve, hogy megfelelően használjuk őket. Amikor ugyanis aktív módban keresünk, vagy kapcsolódunk direktben az eszközhöz, átmenetileg megnő a fogyasztása, illetve nem is tud más kapcsolódni hozzá, amíg le nem kapcsolódunk, mert a Bluetooth 1:1 kapcsolat. (ez okozza például, hogyha valaki rákapcsolódik a telefonjával a hőmérőre bluetooth-on keresztül, attól a hőmérőtől nem fog adat érkezni a gateway-re, amíg le nem kapcsolódik, szóval ha valamiért olyanokkal kell egy fedél alatt élnünk, akiknek passziója, hogy bluetooth hőmérőkre kapcsolódnak a telefonjukkal, akkor vagy zigbee hőmérőket vegyünk inkább, vagy távolítsuk el az illetőt)
A sokkal praktikusabb passzív módban 6 hónap - 1 év elem élettartamot írnak például a legolcsóbb LYWSD03 típusra - megfelelő firmware-el. További érdekesség, hogy az aktív módú csatlakozásnak kisebb a hatótávolsága, nekem egy falon keresztül még éppen megy, de nem mindig - ellenben passzív módban a mérési adatok egy födémen és két falon keresztül is átjutnak, amin nagyokat csodálkoztam, mert a WiFi se nagyon megy el addig.

A megfelelő firmware alatt természetesen nem a gyárit értem... Először az ATC kiadás érkezett meg több típushoz, de ez már 2022 óta nemigen van támogatva:

https://github.com/atc1441/ATC_MiThermometer

Ami jelenleg is aktív fejlesztés alatt áll, az a pvvx változat:

https://github.com/pvvx/ATC_MiThermometer

Mielőtt nekiesnénk, csak szólok (bár számomra magától értetődik), hogy amelyik Xiaomi eszköznek lecseréljük a firmware-ét, az többet nem fog megjelenni a gyári gateway-eken és a telefonos applikációban sem. Mondjuk én nem is használok ilyeneket. :D

A firmware feltöltése nem túl bonyolult, On-The-Air történhet, egyszerűen böngészőből. A régi flasher is működik még:

https://atc1441.github.io/TelinkFlasher.html

Ám ajánlom az új használatát, amennyiben üzemel a böngészőnkben, és felismeri a BLE eszközöket a közelben:

https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html

Rákattintunk a Connect-re, kiválasztjuk az eszközt, érdemes közel menni ahhoz amit szeretnénk frissíteni, vagy kivenni az elemet a többiből, jöhet a Do Activation gomb (gyári firmware esetén), kitallózzuk a firmware fájlt, amit már letöltöttünk előre (a pvvx-nél nem kell letölteni, felajánlja a megfelelő típusokat, csatlakozáskor), rányomunk a Start flashing-re és várunk egy fél percet türelmesen. Újraindulás után immár ATC_xxx néven fog látszani eszközünk, a beállításait szintén a TelinkMiFlasher-ben tudjuk elérni és finomhangolni.

Működik egyébként PC-n is, én Chrome-al próbáltam, de nem mindig sikerül elsőre csatlakozni az eszközhöz, javaslom e helyett telefonon keresztül meglátogatni a fenti oldalt, ez már csak azért is praktikus, mert azon mindig kéznél van a Bluetooth és könnyebb közelebb menni a hőmérőhöz is vele, mint egy PC-vel. Mert a firmware cseréhez direkt kapcsolat kell (nem árt egy 40% feletti elem is!) és bizony az egy falon keresztül már macerás tud lenni.

Éles szeműek láthatták, hogy immár Zigbee firmware is elérhető három BLE típushoz is, ezeket akkor tudjuk feltenni, ha már a gyárit lecseréltük pvvx firmware-re. Azt viszont érdemes átgondolni, hogy a zigbee firmware-től csak 5 percenként kapunk jelentést, és jobban fogyasztják az elemet... De persze ilyen olcsó kijelzős zigbee hőmérőt nem lehet kapni a piacon, így biztosan van, aki rászánja magát, nekem a BLE teljesen megfelel. (itt szúrnám közbe, hogy az eredetileg is zigbee SNZB-02D tizedik hónapja megy nálam és 60% az eredeti eleme)

Node ennyit magukról a hőmérőkről, beszéljünk kicsit arról, hogyan kapunk adatokat tőlük. Gyárilag ugye van hozzá saját gateway, nagyon remek, felhős. Hagyjuk is.
DIY megoldásként általában vagy ESP32-vel szoktak egy úgynevezett BLE Gateway eszközt készíteni, vagy egy USB Bluetooth dongle segítségével egy PC-t/szervert használni átjárónak, amikről a bejövő adatokat aztán egy központi rendszer rögzíti, illetve akciókat végez a beérkező adatok alapján. Ez lehet akár a Homeassistant, vagy esetemben a Domoticz.

Például az alábbi szoftverekkel tudjuk a Bluetooth adatokat gyűjteni és továbbítani:

mPyEasy: ESP32-re készült, aránylag kevés eszközt támogat, egyszerű MQTT kapcsolatot tud.
RPIEasy: Raspberry-re készült, de normál PC-n, miniPC-n is futó program, BLE USB stickel működik, hátránya, hogy aránylag kevés eszközt implementáltam bele, a telepítése pedig a Python alapok miatt kezdők számára nem túl egyszerű. MQTT Autodiscoveryt ez is támogat immár, és van webes felülete.
Tasmota: ESP32-re. A webes felületén elérhető minden, ha más nem, hát konzolban, egészen jól dokumentált, tud MQTT Autodiscoveryt is (bár 12-es verziótól ehhez saját binárist kell fordítani), Domoticz-al is remekül együttműködik, jó az eszköztámogatása, és alapvetően passzívan várja az adatokat. Nem kell kézzel beírni a hőmérők címeit, de szűrhetjük azokat, ha akarjuk.
ESPHome: ESP32. nemigen van webes felülete, központilag jól menedzselhető, kár hogy az MQTT autodiscovery integrációban ugyanazzal az egyedi azonosítóval küldi ki az ÖSSZES megtalált BLE hőmérő adatait a ble_tracker, így a Domoticz csak egy hőmérő eszközt vesz fel.. így ez nem túl használható. Számomra legalábbis. Nyilván HA-val, ha nem MQTT-vel, hanem a dedikált integrációjával használja valaki, annak megy.
OpenMQTTGateway: ESP32. Nemigen van bármi hasznos beállítási lehetőséggel rendelkező webes felülete, MQTT-n keresztül menedzselhető, MQTT Autodiscoveryt támogat, egyébként Domoticz-al is egész jól megy... ellenben az alapértelmezett "Adaptív keresés" funkciója beiktat aktív keresést is, szerintem túl sűrűn, bár elvileg lejjebb lehet venni, nekem nem sikerült, így pedig ez nem túl elembarát. Pozitívum, hogy rengeteg eszközt támogat, és automatikusan megtalál mindent, nem kell yaml fájlba irogatni kézzel a MAC címeket, mint az ESPHome esetén. Ha le lehetne beszélni az aktív keresésről, még tetszene is. Sokkal inkább, mint az ESPHome.

Sok egyéb megoldás létezik még, én személy szerint az RPIEasy és a Tasmota opciókat szoktam választani, ám nem akarok senkit meggyőzni arról, hogy ezek a jók, ellenben elértem a cikk tulajdonképpeni témájához: ajánlok egy új megoldást!

Ugyanis a Shelly Gen2 eszközei immár ESP32 alapúak és van bennük Bluetooth támogatás, illetve egészen jól szkriptelhetőek. Mondjuk a Javascript nem nagy kedvencem, akkor már inkább a Berry, de ez nem lehetett akadály, el is készítettem hát a Shelly szkriptet, ami passzív módon hallgatja a BLE forgalmát, és ha támogatott csomagokat észlel, azt továbbítja MQTT-n, illetve be is regisztrálja az eszközt Autodiscovery-vel. Ha pedig úgyis van egy Shelly-nk, miért is ne használjuk akár erre is?

Ha van Gen2 Shelly eszközünk, ami nem elemes, akkor nyissuk meg a konfigurációs oldalát böngészővel:

A Scripts/Add script gombra kattintva tudunk új szkriptet hozzáadni.

Elnevezzük, beillesztjük az alábbi oldalon található szkriptet a törzsbe, és elmentjük (Save) majd elindítjuk.(Start)

https://github.com/enesbcs/shelly-script-examples/blob/main/ble-pasv-mqtt-gw.js

Az előző képen látható 'ble_pasv_gw_mqtt' a szkript neve, ahogy én mentettem el, és e mellett jobbra látható egy kapcsoló, ha arra kattintunk, a szkript automatikusan el fog indulni a Shelly újraindulásakor. Azt ugye mondanom sem kell, hogy a Settings/Bluetooth settings alatt a Bluetooth legyen engedélyezve?

A szkriptben két beállítás van, az 'mqtt_topic' -ba beírhatjuk a blegateway/ helyére, hogy hová szeretnénk, ha küldené a kinyert adatokat a szkript, a 'discovery_topic' pedig az a hely, ahová a konfigurációs objektumokat beküldi, Retain flag-el.
Olyan beállítási lehetőség nincs benne, hogy csak bizonyos MAC címekről továbbítson adatot, mindent küld, amit lát. De van az a pénz... :D

Sőt, aki netán lokálisan szeretne a hőmérő adatai alapján valami akciót végezni a Shelly-ben, a fenti szkript módosításával megteheti, ha megtalálja ezt a sort a kódban:

mqttreport(res.addr, res.rssi, hdr)

A res.addr tartalmazza a hőmérő címét, a hdr pedig egy szótár, amiben pl a hdr.temperature és hdr.humidity tartalmazza az adatokat. Az Allterco github-ján pedig sok példa található a relék aktiválásától a telegram integrációig.

Az ismert protokollok az ATC, PVVX, Xiaomi-Mijia és a BTHome v2, mind titkosítás nélkül, természetesen.

Na most erre lehet, hogy felszaladt a szemöldöke néhány embernek, mi az, hogy titkosítás nélkül, ezt bárki láthatja? Bizony-bizony, ez a passzív adatszórás lényege, hogy amíg a hatótáv és a falak engedik, ezt bárki látja. Van Encrypt opció az egyedi firmware-ben, illetve a gyári megoldások is már titkosítják az adatot, de tényleg az a legnagyobb problémánk, hogy a szomszéd láthatja, hány fok van a nappalinkban? Én ettől nyugodtan alszom.
Az már lehet probléma, ha a szomszéd olyan vicces gyerek, aki unalmában MAC klónozással olyan kütyüt készít, ami más hőmérséklet-adatokat szór a mi hőmérőnk MAC címével BLE-n (valószínűtlen, de nem elképzelhetetlen), és mi erre alapoztuk a fűtési rendszerünket.
Nekem mondjuk a termosztátomnak saját hőmérője van, és azt használja, ha nem vagyok otthon, így ezzel nem tudnak megfogni. Ha pedig otthon vagyok, akkor jelenlét alapján az aktuális szoba BLE hőmérőjét használja, de mivel ilyenkor otthon vagyok, látni fogom, ha valami gond van. :)

Az igazi biztonsági probléma az, amiről senki sem beszél, és semmilyen titkosítás nem véd ellene, ugyanis a TELinkFlasher -rel bárki átprogramozhatja a mi hőmérőnket, ha megfelelő fizikai közelségbe kerül. Családi háznál, ahol vastagak a falak, esetleg kert is van a ház körül, ez nyilván nem probléma, hiszen illetéktelen nem jut 5 méternél közelebb a hőmérőhöz, ám ha tartunk ilyen jellegű támadástól, inkább maradjunk a gyári firmware-nél vagy zigbee megoldásnál. Lakótelepi lakásban könnyen a szomszéd hőmérőjét programozhatjuk véletlenül a fal másik oldalán. :D

A Domoticz-ban engedélyezve az MQTT Autodiscovery hardvert, 1-2 perc után máris előkerült automatikusan minden BLE hőmérőm, bármilyen egyéb manőver nélkül, annyit kell csak tennem, hogy elnevezem őket, mivel a passzív módban nem küldik a nevüket, így ott nyilván csak a MAC cím szerepel automatikusan.