PISTA1: Muzes si udelat template switch na EZS. Ten bude jako jedna zapouzdrena entita resit vsechny tyhle stavy. A pak pokracovat viz nize, volat jen turn_on. Ale taky bych to videl na single automatizaci s conditions, ze zapinani EZS probehne pouze v pripade, kdy jiz neni zapnuta.

DRIZDIK: quened to neřeší, tam další spuštění čeká na ukončení prvního.

MEDWYN: Jo když by HA komunikoval s EZS napřímo a moh bych mu poslat přikaz zakoduj nebo odkoduj. Bylo by to jednoduchý.
Ale já musím EZS zapínat/vypínat impulsem na zoně.

Mám automatizaci bez trigru. jenom akci která pošle zapni, čekej 1s, vypni. Tím automatizace skončí. Jenže EZS trvá několik sekund než provede zamykací procedury a sepne výstup co signalizuje zastřeženo.
Takže jsem večer udělal input boolean a do podmínek jsem hodil že input musí být off a akci: input om, zapni, čekej 1s, vypni, čekej 15s, input off.

Nicméně teď jsem koukal jak fugují quened a jaký jsou vůbec možný typy. (jeden furt zjišťuje co všechno to umí :-)
A vlastně je to jednoduchý, nechat single, input můžu vyhodit a na konci jen čekej 15s.
Díky tomu bude automatizace v běhu po celou dobu, než se EZS překlopí a pokusy o spuštění bude ignorovat.

PISTA1: A co takhle to rozdelit, aby prijezd nikdy nevyvolal zakodovani? (pouzit ruzne triggery s nastavenym trigger_id a nedelat na entite alarmu toggle)

PISTA1: Od toho jsou queued automatizace, které počkají až předchozí, klidně i s nějakým cooldownem doběhne

PISTA1: Tak jsem to myslel .)

ABE: Zakážu na 15s opětovný spuštění akce která provádí odemčení/zamčení. Takže když přijdou dva příkazy za sebou druhej to bude ignorovat.

PISTA1: Po odkodovani zakazat na X sekund, zmenu stavu?

CERMI_FOX: GPS poloha mobilů a 200m zona okolo pozemku Wifi je na tohle nespolehlivý, to by šlo třeba v bytě.
Stejně tak obráceně pokud jeden z nás odjíždí a nikdo není doma vyskočí push notifikace jesli se má zamknout. Děti zatím kodujou postaru na klávesnici při odchodu. kdyby zapoměli tak mě vyskočí push.

CERMI_FOX: *prijde na wifi (uz toho mam dnes dost :) )

PISTA1: jak detekujes, ze prijela manzelka? Mobil zmizi z wifi?

CERMI_FOX: No to máš pravdu. Stejně jako když praskne žárovka.... vezmu ve skříni náhradní a vyměním. :D

btw teď řešim jeden malej špečík s EZS. Mám nastavený že když přijedu já nebo manželka domů tak se automaticky odkoduje, bohužel je tam asi 5s prodleva od spuštění procedury než EZS signalizuje odemčení, takže když přijedem spolu a mobily se trefí do toho okna, tak jeden odkoduje a druhý hned zas zakoduje :D

PISTA1: jo, ale pokud ti vypadne relatko, tak si nezapnes

DRIZDIK: Vypínačem ale žádnej fyzikej stav nezanecháváš. ani proti ničemu nebojuješ. Jen jím změníš výstup on - off. S automatizací to normálně spolupracuje + pokud ti z nějakýho důvodu vypadne HA ovládáš po staru.

DRIZDIK: jsem dost smolnej člověk, takže snad všechno, krom rozbitých upgradů, co se kdy podělalo, se podělalo v době, kdy jsem nebyl fyzicky doma, abych to nahodil :)

Aktiv-standby instance mi dává větši smysl, ale z praxe vim, jak moc je těžký tohle odladit (zvlášť když na to není čas si s hrát do hloubky), aby to fungovalo dobře, nebo aspoň lépe než kdyby tam ten systém byl jen jeden :) A snažil bych se vyhnout tomu automatickému failoveru do druhé instance, spíš si to nechat na manuální request třeba přes SMS ... ale to je zas až na nějaké dlouhé zimní večery. Tak za 5-10let, dřív se k tomu určitě nedostanu :)
A není to jen o HA, ale třeba i o vzdáleným nahození jističe/fíčka a záložním zdroji :)

git clone ...
cd ...
docker compose up -d
:⁠-⁠)

MR_DAN:
PISTA1:
Za mě je takový krok který ti spíš znepříjemní život si zanechat ten fyzický stav, který ti bojuje proti vzdálenému ovládání.
Pokud máš pod vypínačem aktivní prvek, tak i po vypadnutí HA ti ten vypínač může zachovat funkci. Na druhou stranu, pokud se naučíš dělat upgrade s nějakou zálohou a rychlým recovery procesem, tak už se mi hodně dlouho nestalo, že bych něco rozbil nebo to bylo rozbitý dlouho.

to by nemuselo bejt tak silene tezky... dve nezavisly instance HA, ktery maj stejnej set automatizaci s nejakym globalnim flagem true/false jestli jsou aktivni
a pak nejaky jednoduchy pingatko ze standby instance na active s timeoutem, kterej pripadne nastavi ten globalni flag na true

samozrejme vsechny automatizace by v takovym pripade mely bejt idempotentni, tj vyhejbat se napr togglum na ukor explicitniho on/off, aby se vlastne nic nestalo, kdyz nejakej event prijde dvakrat

PISTA1: podle me spravny uvazovaní je, že ma clovek 2 HA nezavisly instance a ty jsou active-standby - ale nikdy sem zatim neměl čas řešit zda je vubec mozny takovy konfigurace dosáhnout a popravdě o tom pochybuju, možná v budoucnu

ale myslim si že ty, s tim kolik tam toho už máš, bys takovej research měl udělat!!! a dát nám vědět! :)

MR_DAN: Správný uvažování.
Já jsem překlopil na ovládání HA komplet osvětlení, ale všude mám zachovaný původní vypínač. Je sice super že na něj nemusíš vůbech šáhnout. Ale ve chvíli kdy ti HA vypadne (nepovede se update, nebo cokoliv jinýho) jsi takříkajíc v pr... ;)

Stejně tak třeba topení... Topím v kotli dřevem, trochu sem si s tím pohrál, abych to měl co nejvíc zjednodušený a pod kontrolou. Nicméně i když vypadne elektrika na pár dní,stačí otevřít pár ventilů aby fungovala samotíž a v baráku budu mít pořád teplo i když to bude trochu náročnější na obsuhu.

DRIZDIK: myslis nejaky ty Shelly, vid? neco takovyho taky googlim... kdyz ja ty wi-fi uplne nechci, uz takhle tady mam tu 2.4 sit dost zarusenou
kdybych vedel jestli to jde udelat s relema od sonoffu, asi budu muset koupit jedno testovaci a zkouset

ono pak je otazka, jestli je vubec dobrej napad to delat, pripravit se o fyzicky prepinani, ze by teoreticky to zigbee mohlo treba nejet... ikdyz mam server s HA, zigbee2mqtt a vlastnima mqtt sragorkama nad tim (dalsi duvod pro zigbee) zalohovany a funguje plne offline