CERMI_FOX: Tak to opravdu nehrozí ;)

PISTA1: no právě, teď vydrží a rád bych, aby to tak zůstalo a telefon se v tašce občas neproměnil ve žhnoucí cihlu a nevyžral všechnu baterku :)

2024.8: Beautiful badges! - Home Assistant
https://www.home-assistant.io/blog/2024/08/07/release-20248/#knx-can-now-be-managed-via-the-ui

Pěkný

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