Normálně si nech vyměnit vodoměr za model s přímo pulzním výstupem a pak budeš číst pulzy (kde 1 pulz je třeba 1 litr nebo tak něco).
A nebo pokud má tvůj vodoměr magnet, tak jsou senzory, které detekují otáčení té magnetické vrtulky. To bývá asi nejčastější.
Celkem standardní řešení.

Jsou vodoměry a plynoměry s KNX sběrnicí, asi se to dá použít jako podružný měřák, ale bude to stát majlant.

NIXIMOR: imho moc moznosti nemas, protoze kdyz se nad tim zamyslim:
odmyslime si hotove reseni "na klic", ktere jsi psal, ze it nevyhovuji kvuli granularite odectu nebo cloudu => jsme u diy/bastleni
chces se vyhnout tomu, aby byl IoT bazmek v trubce. psal jsi, ze tam mas pitnou vodu + imho je to zbytecny failure point a problem, kdyz budes chtit tu IoT cast predelat
tzn. nejsnadnejsi je vzit dedikovany meridlo (vodomer), ktere budes nasledne odecitat. bud se ti povede sehnat nejaky s digitalnim vystupem nebo jsi u odecitani z analogu
a s analgovoym odectem ti nezbyva nic jineho nez a) dekodovat ciselnik (tzn. to reseni s kamerou) nebo b) pocitat pulzy


pokud jste se nekdo setkal jeste s jinou moznosti, tak me prosim opravte :)

TOOMIX: Zrovna jsem nedavno koukal na tohle - https://www.pieterbrinkman.com/2022/02/02/build-a-cheap-water-usage-sensor-using-esphome-home-assistant-and-a-proximity-sensor/

QWWERTY: ok, asi jsem shanel nejake min redneck reseni, ale kdyz nic jineho nezbyde, tak to asi zkusim takhle :)

NIXIMOR: vodomer + neco jako tohle?
chiptron.cz - Novinky: Měření spotřeby vody a plynu u klasických analogových měřidel díky ESP32, kameře a strojovému učení/umělé inteligenci - Tensorflow. Stačí koupit desku za cca 350 Kč....
https://chiptron.cz/news.php?readmore=1483

Nerealizoval jste nekdo mereni spotreby vody? Uz v tom lezim druhy den a prijde mi, ze vsechno co je na trhu je prakticky pro offline mereni, kdy se pocita s odectem jednou za cas.

Shanim neco, co dam na potrubi / do potrubi (ale pak to musi mit certifikaci pro pitnou vodu), a budto pres wifi nebo pres cokoliv co jsem schopny odecitat lokalne, mi to bude posilat v dostatecne kratkych intervalech (max. minuta) aktualni odecet. Napajeni na miste neni problem. Problem je rozmer potrubi, jde o DN32.

Nabizi se tam dat bezny vodomer, a na nej nejake odecitaci cidlo, ale tady jsem prave narazil na to, ze vsechno to posila budto do nejakeho cloudu, kde mi vygeneruji tak maximalne excel, nebo to posila jednou za x minut, coz je pro moje potreby malo. Use case je, ze potrebuju v grafu videt v case kolik vody se odcerpalo s narazovymi spickami typu ted se sli vsichni sprchovat, ted se napousti mycka, ... Mame totiz studnu, kde v soucasnem suchu doteka voda prilis pomalu a stava se ze prave ve spickach jsme schopni ji uplne vycerpat do sucha, jenze ty spicky potrebuju byt schopny zdetekovat, abych na to mohl nejak reagovat. Vysku hladiny v te studni uz monitoruju, ale potrebuju tam videt tu korelaci s odberem, abych dokazal zdetekovat, kdyby ta voda unikala jinudy, coz je aktualni podezreni.

Takze budu rad za tipy. Na miste mam napajeni, mam tam wifi, pripadne umim cist 4-20mA proudovou smycku. Nejake veci jako mbus nebo LoRa by se daly zaridit, stejne tak jako integraci do grafany si zvladnu postavit, pokud mi to zarizeni ty data bude schopne davat. Nekdo nejaky tip?

PISTA1: nežere ta gps baterku? Plus teda mě to neustále ukazuje, že jsem v zóně doma, ale to je asi o nastavení, nejspíš nemám povolené sdílení polohy právě ze strachu o tu baterku.

PISTA1: No pokud po odkódování dáš dostatečný delay aby další spuštění začalo až po těch 5 minutách třeba, tak už budeš znovu spouštět se správným stavem.

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

MR_DAN: Ano dá, dokonce některé zigbee rele moduly mají myslím i dva vstupy. Ale dokumentace těch cluster commandů, kterýma to konfiguruješ je většinou žádná nebo špatná a asi často vendor specific, takže na to není nějaké jednotné rozhraní nabízí to třeba jen jejich appka přes jejich hub.
Asi jednodušší je v tomhle nějaké WiFi řešení, kde je uvnitř esp a dá se to přepsat vlastním firmwarem. Je to stále napájené, tak nebude problém se spotřebou.