Sajnos igen, azt nem fogod megúszni. De nem 1-2 óra alatt vissza tudsz állni.

Mielőtt kérdezel, nézd meg az 1. számú hozzászólást, vagy használd a keresőt, azért van!

Köszönöm a részletes leírást, bár az előző hozzászólásokban meggyőztek a külön be- és kikapcsolási automatizmus használatáról.
Sajnos így nagyon sok automatizmus lesz, illetve van már most is, ahogy "bonyolítom" a dolgokat.
Szerettem volna az összetartozó automatizmusokat összevonni egybe, de ezt senki nem javasolja, bár nem értem az okát, mert használok már ilyet más megoldással.

Értelemszerűen ha jól van felépítve és nincs probléma, akkor nincs minőségbeli különbség a kétfajta megoldás között. Amíg nem csinálják meg NC-nál a csoportosítást, vagy tagelést vagy mappákat, addig rendszerezésben előnyt nyújt, ha az összetartozó automatizációk egyben vannak.

...mit teszel ma, ami holnap is számít ?

Azért felpiszkáltatok a problémával. Tettem még egy próbát és úgy tűnik működik.

trigger:
- platform: state
  entity_id: binary_sensor.teraszajto
  to:
  - 'on'
  - 'off'
condition:
- condition: sun
   after: sunset
action:
- service: light.turn_{{ trigger.to_state.state }}
   target:
   entity_id: light.terasz_vilagitas

A teraszajtó nyitásakor felkapcsolja a terasz világítást, becsukáskor lekapcsolja. Egy késleltetést kellene beilleszteni a becsukás után, hogy 10-20 sec-al később kapcsolja le a világítást.

Esetleg lát benne valaki problémát ami miatt még sem jó vagy hasznos egy ilyen megoldás?

Ha megy, akkor jó.
Nálam is az autómatizálások egy része NodeRED-ben van, mert ott jobban követhető volt számomra.

Már leírtam tegnap, miért hibás ez a módszer, nem ismétlem. Hajrá, csak a magad kárán fogsz tanulni.

Bocsánat, én nem ilyen kendácsolásra gondoltam (:

Hanem id-vel ellátott triggerek alapján történő végrehajtási szál kiválasztásra. Most hirtelen erre böktem rá az én automatizációimból a példa kedvéért.
Így lehetséges a normális nyomkövetés és hibakeresés.

...mit teszel ma, ami holnap is számít ?

Sziasztok! Nem teljesen okosotthon, de hátha van tippetek: a 433 MHz-en üzemelő távirányítóim az elmúlt pár napban egyik pillanatról a másikra elromlottak (kapunyitók). A triviális dolgok kizárva, elemek tökéletesek, párosítva vannak rendesen, fél percenként kb. működik mindkettő. Arra gyanakszom, hogy valami erős rádiós interferencia lehet a környéken. Hogy tudnám ezt ellenőrizni? Van esetleg bármi megoldási javaslatotok? (okosmegoldásom van B-tervnek, működik mindkettő mobilappról, de a fizikai gombok jobban fekszenek, mint a kínai szerver)

Egyetértek veled, de gondoljuk végig jelen esetben mi történik.

A sensornak két állapota van beállítva, on és off, az unknow nem értelmezett. A meghívott művelet csak akkor hajtódik végre, ha on vagy off az érzékelő állapota. Az érzékelő vagy a rendszer kieséskor ha unknown lenne a sensor állapota, akkor nem történik semmi a vezérlés által. Ha az érzékelő fals állapotú lesz pl. zárva van de az állapot on- ra áll vagy fordítva, akkor a megfelelő művelet végrehajtódik és fel- vagy lekapcsol a világítás. Mikor az érzékelő visszaáll (ez nem tart sokáig), akkor a valós állapotnak megfelelő művelet hajtódik végre és helyreáll az eredeti állapot. Valós probléma, ha a világítás ilyenkor magától felkapcsol majd helyreáll, ha ez egyáltalán bekövetkezhet, hiszen mint írtam az unknow állapothoz nincs művelet rendelve.

Ez az automatizmus nem biztonsági funkció, nem olyan mint a pl. delay alkalmazása sok helyen. Bár lehet, hogy tévedek vagy félreértek valamit... Ezért is kérdeztem rá.

Bizony hogy triggerel az unknowból váltás is ha nincs megadva a from - de mondom, h majd a saját tapasztalatodból megtanulod, ha már másnak nem hiszel.

Szia,
Az a baj (pl) ha nyáron partiztok kint, és valaki kinyitja majd becsukják az ajtót, akkor magatokra kapcsoljatok a villanyt.

Aki okosrelével oldja meg a fűtésének vezérlését, mivel oldja meg azt a szituációt, hogy ha az azt vezérlő eszköz (szerver, pc, akármi) nem működik?

Arra gondolok, hogy ha az okosrelé felkapcsolódik, majd a vezérlő eszköz ekkor valamiért nem működik tovább, akkor az okosrelé felkapcsolva marad. Így a fűtés egészen addig megy, amíg a vezérlő eszköz újra működőképes nem lesz (és lekapcsolja), vagy észre nem veszem, hogy már 27 fok van a házban...

Erre az eshetőségre hogyan készültök fel?

Tudom, kicsi az esélye, de előfordulhat.

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Szia,
Nekem nspanelre kellene lecserélni a mostani termosztatot. Ezt használom az nspanelen custom firmwareként: https://github.com/Blackymas/NSPanel_HA_Blueprint
Ennek a kodjaba lehet backupkent programot rögzíteni, de itt azért nem kell ontanulo algoritmusa gondolni.
A mostani termosztatot (computherm e280) meg saját programjával lehet programozni, de utána már függetlenül a HAtol vagy a computherm szervertől működik.

Ha olyan okos reléd van amin van SW (switch) bemenet (pl Shelly 1) akkor arra köthetsz egy kapcsolót. Nem designos, de működik.

A régi termosztátot sorba kötve meghagyod vészkikapcsolónak. Ha elvárt hőmérséklet plusz 1 fok fűtés lekapcsol.

Ha "űrhajó" biztonságra vágysz, akkor:
Egy olcsó termosztát a kívánt vezérlő érintkezőjével sorban, ami a felső biztonsági hőmérsékleten kapcsol (és kapcsolat)

Egy olcsó termosztát a kívánt vezérlő érintkezőjével (+ az esetleges sorba kötött termosztát) párhuzamosan, ami az alsó biztonsági hőmérsékleten kapcsol (vagy kapcsolat)

A normál kapcsolást végző 'jelfogó' "keep alive" jelekkel történő üzemeltetése a vezérlés irányából.

Ez nem hit kérdése, szeretném tudni, megismerni a dolgok hátterét, hiszen anélkül nem lehet építkezni.
Tudomásod szerint mi és hol lesz unknow állapotú? Az érzékelő (bináris), a Shelly vagy a HA-ban?
A garázs világítással volt problémám és az be volt (és van is) állítva from-to triggerrel, mégis alkalmanként felkapcsolja a világítást mikor lecsukódik a kapu. Havonta egyszer kétszer, de az időzítés leteltével kikapcsolódik. Ezt jó kompromisszumnak tartom a kényelem és biztonság okán, bár jó lenne megoldani...
Ezek ismeretében örülnék ha időt szánnál a problémára és elmagyaráznád pontosan a probléma lényegét, hiszen az általad javasolt megoldás sem tűnik minden esetben működőképesnek.
Nekem sokat segítene, ha érteném a problémát, illetve meg tudnál jelölni hivatkozást ahol ezt megismerhetem és megoldást kereshetek rá.
Köszönettel a türelmedért.

Köszi, hogy felhívod rá a figyelmemet, bár gondoltam rá. Több lámpa van a teraszon, ezek egyikét vezérlem az automatizmussal...

Szerintem arra gondol, hogy ha valamiért az ajtó nyitás értékelő nem küld magáról állapotot (pl. Zigbee hálózat nem elérhető) akkor az érzékelő státusza unknown lesz. amikor újra megjön az érzékelő állapota akkor unknown-ból vált off-ra. Vagy on-ra. Ebben az esetben az automatizmusod kapcsolni fog.

Ezért írtam a sok év alatt szerzett saját tapasztalatból, mi egy gyakori buktató - de jössz az elméleti fejtegetéssel, h olyan nem lehet. Hát majd meglátod egyszer magad is, de...

Könnyen lehet unknown egy érzékelő: már a rendszerindítás során is (ott attól függ, okoz-e gondot, h maga a rendszer hogyan áll éppen: hiszen lehet, h maga a lámpa sem elérhető még), hálózatról leszakadás esetén is, vagy ha frissíted, újraindítod a szenzort biztosító integrációt. Teszem azt egy Zigbee2mqtt-t, vagy magát az mqtt szervert.

Ha nem használsz "from"-ot csak "to"-t, az bizony tartalmazza az ilyen határozatlan állapotból on-ba vagy off-ba ugrásokat is, tehát fölkapcsolod vele a lámpát ha ilyen hiányos a trigger, ezért kell mindig from is. Akkor viszont bonyolult az elkülönítés az action alatt, épp mit is kell csinálni - és nincs is értelme az egésznek. Nincs abból semmi probléma, ha nagyon sok miniautomatizálásod van: jól olvasható a kódjuk, stabilak, ki-be kapcsolhatóak egyenként, könnyen tesztelhetőek. Az összetartozóakat úgyis egy-egy file-ba írod, számodra tökéletesen átláthatóan.

Köszönöm, talán ez rávilágít a lényegre. Ha jól értem a HA eltárolja az érzékelő vagy kapcsoló vagy akármi előző állapotát és időnként lekérdezi. Előfordulhat, hogy a lekérdezésre nem kap választ és ekkor a HA beállítja az állapotát unknow-ra?

Ez előfordulhat HA újraindításkor, hálózati torlódáskor és egyéb esetekben is?

Te is tudod, hogy a tapasztalat egy dolog és ha nem lehet a kiváltó okot megállapítani, akkor a sem a probléma, sem a megoldás nem rendszerezhető, releváns.

Emlékeztetőül a garázs világítás problémámra, nem oldotta meg a tapasztalatod alapján ajánlott from-to beállítás annak idején sem...

Minden esetre köszönöm a válaszaidat és javaslataidat, megfogadom azokat, hiszem nálam tapasztaltabb vagy a témában.

Ha két trigger van, ahol meg van adva a from és to is, akkor az actionben ugyanúgy a trigger.to_state.state értéket kell használni.

Ha külön van bontva valami 2 autómatizálásra és át akarsz írni egy értéket, akkor könnyebb elfelejteni mindkét helyen átírni, mintha egyben lenne. Szerintem mindenki el tudja magának dönteni, hogy neki hogyan átláthatóbb, fölöslegesen kötöd az ebet a karóhoz, hogy csak úgy a jó, ahogy te csinálnád.

Nagios figyeli az összes eszközt (HA servert is beleértve), ha valamiért valamelyik nem elérhető, akkor jön üzenet. Ha valamelyik helyiségben átlépi a hőfok a +25 fokot, vagy +15 alá csökken, akkor jön üzenet. Külső helyen lévő Nagiossal nézem a routert, és a belső Nagiost is, ha megáll valamelyik, jön üzenet. Ha mégis armageddon van, akkor a fűtésnek (kazán/keringtő/radiátorszelepek) váltókapcsolók vannak beépítve az elosztóba, így bármelyiket ki-be-auto tudom kapcsolni.

Nekem ESPEasy vezérli a relét, ami a benti termosztáttól (is) kapja a jelet. Az ESP-ben saját progi fut, ha nincs net, akkor is dolgozik. Akkor is jól fűtött, amikor félreprogramoztam és a web UI-t el sem értem...

Hold on, trying to give a fuck... Nope, not Happening • Powered by Fedora Linux • "Az élet olyan sz@r, szerencsére a felén már túl vagyok" Al Bundy

Mire gondolsz "kendácsolásként"?

A példa nagyon hasznos éppen most akarok ilyesmivel foglalkozni, köszönöm, hogy megosztottad. Tanulmányozni fogom és ha kérdésem lesz, engedelmeddel megkereslek.

Köszönöm.

Azt ugyanúgy - mást azonban nem!
Pl. a kikapcsoláshoz fölösleges megadni az időszak feltételt (hiszen különben annak vége után lezajló becsukás már nem futna le. Nem kell messzire menni: az alábbi példában az "after sunset" azt jelenti, h éjfél után csukott ajtóra már nem fog lekapcsolni...), és akkor mindjárt ott a bonyolított szétválasztás - a semmiért.

De teljesen igazad van, mindenki úgy szivatja magát, ahogyan szeretné, nem kell hallgatni mások tapasztalatára. Csak akkor nem értem, minek fórumozni? Hanyagolom is itt ezt, semmi értelme.

Ugyan Cyberbeninek írtál, de sajnálom, hogy személyeskedésre vetted a problémát. Szerintem mindannyian örülnénk és megértenénk az álláspontodat hiányos ismereteink birtokában, ha kinyilatkoztatásaidat nem tapasztalatok, hanem információk és hivatkozások megosztásával támasztanád alá. Hiszen azért fórumozunk, hogy ismereteket, információkat és megoldásokat keressünk és találjunk magunk és mások okulására.

Köszönöm, hogy elolvastad és próbáltál segíteni, ezért hálás vagyok és nem veszem zokon, ha a továbbiakban nem válaszolsz az általam írt hozzászólásokra.

További szép napot kívánok neked!

Xiaomi C200 smart kamerán ki lehet valahogy kapcsolni a hangos értesítéseket (hálózat keresése, csatlakozva...)?

light.turn_{{ trigger.to_state.state }}
Erre céloztam volt. Ennél a legegyszerűbb automatizációnál nyilván nem tud túl sok komplikáció fellépni, csak hogyha jobban belebonyolódsz, akkor követhetetlen, hogy mikor mi és miért történt, mert nem elkülönültek a lezajlott ciklusok.

Természetesen rendelkezésre állok én is, de nem sokan maradnak magukra a nyűgjükkel ebben a topikban a tapasztalatok alapján (:

...mit teszel ma, ami holnap is számít ?

hardveresen mindig (Szétszeded, lehúzod a kábelt az alaplapról). Komolyra fordítva: szerintem nem, de az is igaz, hogy nem ismerem ezt az eszközt.

Mielőtt kérdezel, nézd meg az 1. számú hozzászólást, vagy használd a keresőt, azért van!

Valaki írta, hogy az Esp32-n futtatott BLE proxy elég nagy erőforrást igényel. Beférhet mellé stabilan egy LD2410 vagy 1125H (jelenlét érzékelő)? Vagy inkább vegyek külön lapot hozzá?

Illetve levegőminőség érzékelőnek mit vagy miket használtok? Találtam egy elég komplex megoldást, igazából csak a CO érzékelés hiányzik belőle (ötlet rá?)?

Köszi

'' Az élet egyszerű. Döntéseket hozol és nem nézel vissza.'' // Tomorrow's just your future yesterday!

Felküzdöttem az NSPanel-ra HA Blueprint-et, jobban tetszik mint a tasmotás verzió, főleg hogy offline is működik a termosztátos része! Viszont a hőmérséklet szenzor tasmota és esphome alatt se mér jól. Bár esp alatt pofonegyszerű eltolni pár fokot, de ha pl összehangolom a 23 fokra őket akkor ha 22 fok van akkor a nspanel 21,4 et mér! Tudja esetleg valaki hogy lehet a szenzort kalibrálni?

Több hőmérőm is kb +/- 0.1 fok különbség van köztük!

Nem vagyok nagy villamossági szaki, de hogy létezik az, hogy 3x16A esetén 22-23A működik egy fázison Legalább is ezt mutatja a Smart Gateway:

[ Szerkesztve ]

19 órakor bekapcsolt nagy fogyasztóid mind 1 fázisra vannak kötve... EVSE?

- Micimackó! Hogyan betűzik azt, hogy szeretet? - Sehogy Malacka, azt érzik .......

EVSE+elektromos főzőlap (bár korábbi emlékeim szerint az 2 fázison mutatott nagy értéket, de lehet, hogy tévedek. Direkt a főzőlap bekapcsolása után csináltam ezt a screenshotot). Ezen kívül pedig megy még 3 klíma és egy Xiaomi elektromos konvektor! Szóval megy ám egyszerre több nagy fogyasztó

Nem lehet.

"Szörnyek léteznek, de túl kevesen vannak ahhoz, hogy igazán veszélyesek legyenek. Sokkal veszélyesebbek az átlagemberek, a funkcionáriusok, akik készek hinni és cselekedni anélkül, hogy kérdéseket tennének fel." (fordította DeepL ) - Primo Levi

HMKE-s... lehet hogy hibrid.... amúgy nálam 10A szolgáltatói KMSZ simán vitt tartósan 17A-t...

Szabvány szerint 113%-ot legalább 1 órán át kell vinnie... ha kint van hidegben, simán hihető...

- Micimackó! Hogyan betűzik azt, hogy szeretet? - Sehogy Malacka, azt érzik .......

Ja, azt nem láttam a post-ban. Azt hittem "sima" betáp.

"Szörnyek léteznek, de túl kevesen vannak ahhoz, hogy igazán veszélyesek legyenek. Sokkal veszélyesebbek az átlagemberek, a funkcionáriusok, akik készek hinni és cselekedni anélkül, hogy kérdéseket tennének fel." (fordította DeepL ) - Primo Levi

Akkor most teljesen megbízhatatlan ez a Smart Gateway, valótlanságokat mutat? Azt sem értem, hogy van egy pillanatnyi teljesítmény vételezés és egy visszatáplálás grafikon, de ezeken nem mutat semmit. Ennek vajon mi lehet az oka? VAgy ehhez már kéne egy mérő a villanyóra és kapcsolószekrény közé (van Fronius Smart Meter, csak beszerelve nincs, mert nem tudtuk lehúzni a kábelt a falban, de majd a jövőben ezt megoldom valahogy).

#50238 gorbep: mármint mi a hibrid? Meg mi van kint hidegben?

[ Szerkesztve ]

Nem feltétlenül tárolja el az előző állapotot, előfordulhat olyan, hogy mindig ránéz például az MQTT-re, hogy ott milyen állapot van az adott entitáshoz. Ha azonban nem éri el valamiért az MQTT-t, akkor mivel se nm ON, sem nem OFF az érzékelő állapota, hanem unknown, ezért ezt is fogja beállítani. Degeczi által említett helyzet is tipikusan ilyen: a HA indul, de még nem kapcsolódott az MQTT-hez. Ebben az esetben még sem nem ON, se nem OFF az állapot, hiszen még nem tudjuk.

Hőkioldás esetén a 1,13-as és a 1,45-ös szorzó a meghatározó tényező. A kismegszakítónak a 13%-os túlterhelést több mint 1 órán át kell engednie, ez a legkisebb vizsgáló áram. Viszont 45%-os túlterhelés esetén 1 órán belül megkell szólalnia.
Ugyanitt a karakterisztikarol is értekeznek. B-t tesz a szolgáltató.

...mit teszel ma, ami holnap is számít ?

Természetesen bizonyos mértékig túlterhelhető a megszakító, ezért van a linkelt hővédelem, illetve a túláramra való megszólalás. Ezek az értékek a megszakító ismeretében katalógusból kikereshetők. Valószínűleg az a helyzet, hogy az adott fázison levő fogyasztók egyidejű bekapcsolásakor fellépő terhelés ugrásra még nem szólal meg, de ez soha nem biztonságos a vezeték keresztmetszetek, az azonos védőcsőbe behúzott vezetők száma, kötések állapota és egyéb jellemzők alapján.
Nem javasolt így használni a hálózatot, egy rossz kötés és a másfeles vezeték túlmelegedhet. A feszültségesésből kiszámolható a veszteség, pl. 1 V feszültségesés 22A esetén 22 W veszteséget jelent, amit pl. a gyenge kötés a kötődobozban akar eldisszipálni. Bele lehet gondolni mi történhet...
Javasolnám a nagyobb fogyasztók átrendezését az egyes fázisok között, illetve ha van (pl. slimmelezer), akkor más eszközzel is ellenőrizni a fázisonkénti terhelés.

Most mi fut az nspanelen? pl. esphome esetén calibrate_linear amit keresel.

Sziasztok!

Megvettem az itt linkelt fekete FC0012 tunert. Az rtl433 Home Assistant alatt úgy fest, hogy működik, az MQTT explorerben azonban nem jelenik meg a topik. Az output kv kapcsoló sem mutat semmit a logban. Mi lehet a gond?

Nagyon köszönöm

[rtl_433] rtl_433 version 22.11 branch  at 202211191645 inputs file rtl_tcp RTL-SDR [rtl_433] Use -h for usage help and see https://triq.org/ for documentation. [rtl_433] Publishing MQTT data to 192.168.1.139 port 1883 [rtl_433] Publishing device info to MQTT topic "rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id]". [rtl_433] Publishing events info to MQTT topic "rtl_433/9b13b3f4-rtl433/events". [rtl_433] Publishing states info to MQTT topic "rtl_433/9b13b3f4-rtl433/states". [rtl_433] Registered 176 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-58 63 67-71 73-81 83-87 91-94 96-100 102-105 108-109 111-116 119 121 124-128 130-139 141-149 151-155 157-161 163-167 170-175 177-179 181-185 187-197 199 202 204-215 217-223 ] [rtl_433] Found Fitipower FC0012 tuner [rtl_433] Exact sample rate is: 250000.000414 Hz [rtl_433] Sample rate set to 250000 S/s. [rtl_433] Tuner gain set to Auto. [rtl_433] Tuned to 433.920MHz. [rtl_433] Allocating 15 zero-copy buffers [rtl_433] MQTT Connected... [rtl_433] baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us [rtl_433] MQTT Connection established.

Tekintsétek tárgytalannak, nem nálam van a szerver és az antenna nem volt bedugva

Jesszus, villanyasszal azert ezt nezesd meg..rossz a fazisterheles elosztasod.

exTiga