-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Degeczi
nagyúr
Ha még nincs letiltva a tápciklussal kiresetelés ("SetOption65 1"-el, amúgy érdemes, mert áramszünet tud okozni csúnya meglepetést), akkor egymás utáni sok (7-8?) áramtalanítás elvégzi ezt.
Másrészt ha hozzáférsz a parancssorához, ott is van reset parancs ami mindent töröl. -
Degeczi
nagyúr
DSC esetén kerüld a mostani "Neo" szériát, maradj a jól bevált korábbi "Power"-nél (ami a 1616-al kezdődik, de annak ilyen célra hamar elérheted a határait, érdemesebb 1832 vagy 1864 központot választani, ott marad tér bővítésre), mert az újak olyan titkosított kommunikációt használnak, amihez nincs házilagos illesztés, míg a korábbiakhoz ott a DSCKeybusinterface, célszerűen egy egyszerű optocsatolós illesztéssel (bár lehet egyetlen tranzisztorral is, de jobb leválasztani)
Elvileg Paradox esetén is van egyszerű házi illesztés soros csatoláson vagy gyári interface-en keresztül, de azzal nincs tapasztalatom.
-
Degeczi
nagyúr
válasz Jofi81 #36744 üzenetére
Ezt a fórumot célszerű végigolvasni, ill. DSC specifikusan ezt, különös tekintettel a profik (mint pl. Syn7h37ic) hozzászólásaira
Rengeteg olyan hasznos tapasztalat akad, amit megosztanak.fo_di: igen, főként a max bővítési zónák száma. De pl. a pici 1616 esetén az alaplapra is csak 6-ot lehet kötni (míg a 1832 vagy 1864 esetén 8-at: ezt jelzi a második számjegy a típusban) így ott a 16 zónás max kiépítés is csak úgy lehetséges, ha van két olyan kezelő is, ami tud zónát fogadni
[ Szerkesztve ]
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz Tarokk79 #36774 üzenetére
Zigbee a praktikusabb, mert módosítani sem kell rajta, helyből menni fog Z2M-vel, és a hálózatodat is kiterjeszti. Pl. az SHP15 is ilyen.
Vagy a Shelly Plug S, mert a Shelly cuccok helyből támogatják az MQTT-t, így ott sem kell módosítani rajta.
De a gyári specifikációt mindig érdemes fenntartással kezelni, és jóval alatta maradni. -
Degeczi
nagyúr
Ja, azt már 3 hónapja bejelentették, a 2022.6 első változási pontjaként, valóban hozzátéve, h a 2022.9-től lesz kötelező. Ilyenkor mindig az első 1-2 héten át szoktam állítani az ilyesmit, így mire odakerül a sor, már el is felejtettem - ahogy most is. Néhány copy-paste és search&replace kérdése volt az egész, az indentálást a Visual Studio Code magától megoldotta.
[ Szerkesztve ]
-
Degeczi
nagyúr
Egyetértek, szerintem is jobban átlátható volt külön file-okba szervezve a configot. Az átállás után a lights.yaml, a covers.yaml és a switches.yaml nálam is kiürült (de a sensors.yaml-ben is csak pár template és scrape maradt) hiszen minden világítás, redőny vagy kapcsolóm vagy mqtt-ben van, vagy a saját integrációja kezeli.
A logikája érthető ennek is (más integráció is így kezeli, bár nem sok van, de pl. a különböző modbus eszközök is modbus domain alatt vannak, nem pedig a sensors, binary_sensors, covers, stb. alatti modbus-ban), viszont sokkal áttekinthetetlenebb lett így egy nagy config, az tény.
[ Szerkesztve ]
-
Degeczi
nagyúr
Ez valóban jó ötlet!
(ráadásul az automatizálásaimat magam is így kezelem, csak azokat include_dir_merge_list-el behúzva a különböző file-okból, hiszen azok egy listába kell kerüljenek)Nincs is ezzel nagy gond, viszont egy átlagos felhasználónak teljesen jól átlátható volt a korábbi egyszerű helyzet, miszerint mindegy, honnan származik egy entitás, a hozzá tartozó domain config file-jában lesz kezelhető.
Most mindenképpen szétválik, és tudnod kell, h ezt a szenzort pl. az mqtt alatti configban keresd mert onnan származik, a másikat meg a modbus alatt: ez így nem felhasználóbarát, ennyi.
(programozói szempontból viszont érthető, hiszen miért kellene mondjuk egy cover domainben minden elképzelhető forrást külön kezelni? Ott célszerűbb, ha az mqtt vagy modbus, vagy bármilyen más integráció configja maga sorolja föl az általa kezelt eszközöket) -
Degeczi
nagyúr
válasz amargo #36846 üzenetére
Persze, szétbonthatod az MQTT-t, de ez továbbra sem lesz ugyanaz mint a korábbi, mert így már mindenképpen külön helyre kerül pl. az MQTT-s, a modbus-os vagy a template szenzoraid, redőnyeid, kapcsolóid stb definíciója, míg azelőtt egy helyen voltak, ami mindenképp barátságosabb volt - részben pont azért, amit írsz: a nagyobb egységnek a cover, a light, stb domaint tekintve, hiszen egy felhasználó számára a funkciójuk a lényeg, és nem a technikai megvalósítása, kevésbé praktikus az utóbbi szerint csoportosítani.
-
Degeczi
nagyúr
válasz amargo #36851 üzenetére
Igen, ebben nem értünk egyet, felhasználói szempontból szerintem a funkció az elsődleges, az az alá csoportosítás a helyes és nem a műszaki megoldás alá - ami egyébként is bármikor változhat, mondjuk átszerelhetek egy MQTT alatt configolt Shelly redőnyvezérlőt Modbusos típusra. Számomra az a lényeges, h ez egy redőny és ezért a covers alatt találjam - ne kelljen hónapok, évek múltán is rögtön tudnom, h "ja, annál az ablaknál egy Modbusos vezérlő van, ezért másik config alatt, a Modbusból indulva kell keresni"... Programozói szempontból érthető döntés, felhasználóiból nem.
Szenzornál sem logikus az így induló csoportosítás, a szenzorfunkció a lényeges, és nem az, milyen integrációból érkezik. Az csak a másodlagos felhasználói szempont.
Automatizálással nincs gond, miért lenne? Egy szintről indul mind.Szerk: korábban volt egyetlen sensors.yaml (és covers.yaml, stb.) ezekben szerepelt az összes szenzor a forrásuktól függetlenül, mert a szenzor definíció első sora tartalmazta azt, honnan származik, pl. - platform: mqtt, - platform: template stb. formában.
Júniustól ez változott meg úgy, h az MQTT kikerült, és már az mqtt: domain alatt kell definiálni őket egy sensor: alatt fölsorolva.
Ebből adódóan ezeket mindenképpen máshol, más config file-ban kell keresni, mint amik pl. modbus-ból vagy template-ből jönnek.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz amargo #36857 üzenetére
Nem, a könyvtárakba szeparálás ellen semmi kifogásom.
Pl. egy covers alatt logikus, h külön legyen mondjuk bedroom, livingroom, stb.De az, h ne innen induljunk, hanem már az elejétől legyenek szétcsoportosítva az eszközök attól függően mi hozza létre azokat, és így külön útvonalon kelljen keresni az MQTT és a Modbus eszközöket, az egyáltalán nem logikus és nem felhasználóbarát. Mindegy, mennyire haladó az a felhasználó (de a kattintgatók itt nem számítanak, hiszen ők sosem találkoznak ezzel a config struktúrával).
Pont ugyanúgy, mintha az entitás neve sem pl. cover.bedroom_north, cover.bedroom_west lenne, hanem mondjuk mqtt.cover.bedroom_north és modbus.cover.bedroom_west ami agyrém volna.
Config file szervezésben sem jobb ötlet ez a módszer. -
Degeczi
nagyúr
válasz jagofett #36879 üzenetére
Nagyon ritka (talán régi Immergas típusnál fordul elő) az a kondenzációs kazán, ami csak on-off-ot tudna. A linkeden ott a telepítői kézikönyv, az alapján a tiéd is tud buszrendszerű termosztátot fogadni (a gyári Sensys nyilván mocsok drága, azt kellene megtudni, milyen rendszert használ az Ariston, pl. Tado tudja-e kompatibilisen kezelni)
-
Degeczi
nagyúr
válasz jagofett #36881 üzenetére
Uhh, az szépen fölment... korábban a Hardveraprón is gyakran volt nem vészes áron, most csak légkondihoz valót látni
De rákeresve a Sensys sem brutális, 45-ért is hirdetik - kérdés lehet az is, illeszhető-e csak maga a busz is HA-hoz valahogyan (pl. magam is gyári Bosch termosztátot használok és házilag készített EMS ESP buszillesztést, azzal állítom át a termosztát számára parancsolt hőfokot napszaktól és otthonléttől függően)[ Szerkesztve ]
-
Degeczi
nagyúr
válasz jagofett #36890 üzenetére
A fogyasztás sem olyan jó, hiszen on-off vezérlés mellett a kazán mindenképpen max teljesítménnyel kezd rá, és csak a visszatérő hőfoka alapján modulál vissza. Egy buszrendszerű termosztát helyből tudja közölni, mekkora hőigény van (+létezhet időjárásfüggő folyamatos vezérlés is, nagyon alacsony előremenővel)
-
Degeczi
nagyúr
válasz BlackJack21 #36908 üzenetére
Igen, ahhoz is jó, támogatott.
Hú, jó rég, még tavaly tavasszal írtam a saját példányról (bár azóta megint ott vannak a kapcsolások az oldalukon, akkoriban átszerkesztés miatt pont nem, ezért volt egy cache-elt változata linkelve)
Azóta már végképp csak ESP32-es panelt érdemes használni hozzá, azt használja a fő repó. -
Degeczi
nagyúr
Az integration-nek lehet vmi nyűgje.
Nálam a gázkazán %-ban adja vissza az aktuális teljesítményét, ezt módtól (fűtés, HMV) függően számolom át wattra egy template szenzorral, majd azt integrálom fogyasztásként:sensor:
- platform: integration
source: sensor.boiler_power_in_watts
name: boiler_energy2
round: 0
method: left
végül ebből m3-t számolok:
template:
sensor:
- name: "Kazán saccolt összfogyasztása"
unit_of_measurement: "m³"
state: >
{{ ((states('sensor.boiler_energy2')|float(0)) / 9444) | round(3) }}
state_class: total_increasing
device_class: gas
és valóban, hiába adom hozzá a state_class és device_class-t a sensor.boiler_energy2-höz, az nem jelenik meg az Energy panel gáz forrásaként - de akkor sem, ha aláhúzás nélküli nevet adok neki... (mondjuk nálam mindegy, úgyis a template szenzort használom) -
Degeczi
nagyúr
válasz kingmechanik #36941 üzenetére
A mai kazánokra igaz, már a begyújtás is max gázteljesítménnyel történik, ezért is célszerű minimalizálni a bekapcsolások számát.
-
Degeczi
nagyúr
válasz Jofi81 #36946 üzenetére
Nem az EMS ESP méri, az csak visszaad egy aktuális égőteljesítményt %-ban, abból tudod visszaszámolni a fogyasztást ha más nincs. Ez így csak közelítés, bár elég jóra is be lehet lőni.
Garantáltan pontos akkor lehet, ha maga a kazán közöl fogyasztási adatokat, de ilyet ezek a kisebbek biztosan nem tesznek (meg persze a főzés gázigénye sincs benne, és azért az sem elhanyagolható pláne nagy teljesítményű égőfejet használva, vagy különösen a sütőt, ha az is gázos. Ha engedi a szolgáltató, mindenképpen érdemes egy reed vevőt tenni az órához, akár vezeték nélkülit is. Van itt a fórumon, aki 433 MHz-est használ: ha nem nagyon szennyezett az a sáv a környékeden, az is jó, egyszerű megoldás lehet) -
Degeczi
nagyúr
válasz Jofi81 #36950 üzenetére
Ha impulzusadós vízóra, akkor persze (csak az aknából kell fölvezetni, a föld alól nem jönne át a rádiójel), de úgy tudom, a legtöbb szolgáltató nem olyat rak föl, hiszen alapban nincs rá szükség. Viszont ha igaz, el szoktak fogadni mástól származó hitelesített mérőórát is, így nem lehetetlen a csere (bár valszeg egyszerűbb a szolgáltató bevonása nélkül sorbakötni vele a saját mérőt)
-
Degeczi
nagyúr
válasz LLKobe #37026 üzenetére
Ilyesmire elvileg jó lehet a
homeassistant.reload_config_entry
service hívás -
Degeczi
nagyúr
válasz Olympia76 #37102 üzenetére
Igen, a Xiaomik nagyon háklisak arra, kivel párosodnak, és igen, sajnos a kiesést sem kezelik jól.
Pl. amikor a közelben villámlik, többek közt ki szoktam húzni a hűtőgép Zigbee-s okoskonnektorát is - és ezzel ilyenkor leesik egy rakás Xiaomi nyitásérzékelő a hálózatról, mert eszükben sincs átlépni az amúgy jó térerejű fő koordinátorra...Nemrég egy Woox okosizzót üzemeltem be, arra is csak egy Ikea Tradfri távvezérlő csatlakozott, a közelében lévő Xiaomi nyitásérzékelők, hőmérők nem (mondjuk jobb is, ennél sem kizárható néha áramtalanítás)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Krilehor #37152 üzenetére
Ott van a gyártója oldalán, h 868 MHz-es, így az infrás Harmony-val nem lehet kezelni. A visszajelzés nem jelent okvetlenül kétirányú működést, pl. a klímák távvezérlője is jelez üzemmódot, hőfokot, ventilátorfordulatot, stb-t a kijelzőn, pedig csak egyirányú infra kapcsolattal adja át az összes beállított jellemzőt.
-
Degeczi
nagyúr
válasz Krilehor #37154 üzenetére
Nem feltétlenül ténylegesen aktuális, hanem ami szerinte aktuális. Ezt könnyen ki tudod próbálni, h eltávolodsz biztosan hatótávolságon kívülre, ott nyomogatod, akkor is változik-e: ha igen, akkor nincs kétirányú kapcsolat, csak saját magának tartja nyilván a szerinte fönnálló állapotot. Mint egy klíma távvezérlő is. Jó eséllyel ilyen, mert nem sok értelme lenne kétirányú megoldással bonyolítania a gyártónak, bőven elég ez a saját nyilvántartású módszer is.
Először az RF protokollt kellene teljesen földerítened, aztán az alapján saját olyan IR-RF gatewayt készíteni, ami szintén nyilvántartja ezeket az állapotokat (mert ezek szerint jó eséllyel nem pl. "hangerő +", "hangerő -" parancsok mennek ki, hanem konkrét értékek beállításai, tehát ugyanígy nyilván kell tartanod az aktuális utolsó helyzetet)
Nem mondom, h lehetetlen, de veszett sok, nehéz munka valós haszon nélkül, így nem hiszem, h érdemes vele foglalkozni. -
Degeczi
nagyúr
válasz koala69 #37182 üzenetére
Azt nem, mert az Energy dashboard minden megjelenítés során ad-hoc lekérdezést végez a statisztikai adatbázisból, nincsenek külön entitásként az értékek.
Mivel az ottani megjelenítés alapja egy általad megadott, folyamatosan növekvő fogyasztás szenzor, egyszerűen arra ráteszel egy utility metert daily ciklussal, és az alapján már mehet is a numeric_state above: 7.0 trigger, h már túllépted a napi keretet. -
Degeczi
nagyúr
Igen, a "cuco" panelon a fém borítás alatt ott az a W701 chip, amit a Tasmota flash leírása is említ, h mostanában már azzal szerelik, és azzal nem kompatibilis.
Ha visszanézed az utóbbi pár hónap hozzászólásaiban, sajnos már ez a tipikus, nagyon kicsi az esélye még ESP chipes változatot kifogni vmi visszamaradt raktárkészletről. -
Degeczi
nagyúr
válasz LLKobe #37223 üzenetére
Ez a template trigger
Persze van annyira okos, h nem elemezgeti folyamatosan, hanem csak akkor vág bele a kiértékelésbe, ha a kifejezésben szereplő bármelyik entitás értéke változott (ha pedig esetleg nincs egyáltalán, akkor percenként)
Adattípustól függően célszerű vmilyen (float vagy int) filtert tenni rá, nehogy szöveges legyen az összehasonlítás, és alapértéket megadva, hogy ne jelentsen hibát az, ha vmelyik entitás épp elérhetetlen vmiért (akár csak mert még indul a rendszer)
Tehát vmi ilyesmi kifejezéssel (amit a Fejlesztői eszközök / Sablon alatt kényelmesen kikísérletezhetsz){{ states("sensor.egyik")|float(0) > states("sensor.masik")|float(0) }}
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz vampire17 #37229 üzenetére
Lehet, picit bonyolítva, de a felületen is jól követhetően: van egy input_select-em a szárítógép állapotáról, ami lehet "Üres", "Szárít", "Pihen" és "Készen"
- "Szárít"-ba akkor megy, ha csukva az ajtaja és "üres" vagy "pihen" módban 20W fölé ugrott a teljesítménye
- "Pihen"-be akkor megy, ha "Szárít"-ban volt, és 10W alá esett
- "Készen" akkor van, ha már 2 perce "Pihen"
- "Üres"-be meg persze ajtónyitásra
Így egyszerűen lekezelve az utóforgatás (hiszen "Készen"-ből már nem fog visszaugrani) és az egyéb automatizálások is látják mi a helyzet, pl. lehet hangbejelentést tenni arra, h átment "Készen"-be, majd arra, h már 5 perce "Készen"-ben van, 15 perce, stb.
(Készen-ben ajtónyitásra meg bemondani, h "most ugye nem felejted el a szűrőt kitisztítani", "szárít"-ban ajtónyitásra meg megkérdezni, mit felejtettél ki? )
Persze igazából a "pihen" fölösleges is, lehetne akkor "készen", ha már 2 perce 10W alatt van - de enni nem kér ez a plusz státusz, és így jól látható távolról is, mi történik.További haszon, h ez az input_select állapot nem vész el újraindításkor sem.
-
Degeczi
nagyúr
válasz LLKobe #37247 üzenetére
Ill. miért ne lehetne bonyolultabban, de utána karbantartást nem igénylően automatizálni vmilyen scrape megoldással a Google Map API-tól lekérdezni
Tényleg egyszerű egyébként használni, egyszer a cégnek gyűjtöttem ki partnercégek nyilvános nyitvatartásait vele, és könnyen kezelhető JSON-ben adja vissza az egyes napokat, efféle módon:
"periods" : [
{
"close" : {
"day" : 1,
"time" : "1700"
},
"open" : {
"day" : 1,
"time" : "0900"
}
},
{
"close" : {
"day" : 2,
"time" : "1700"
},
"open" : {
"day" : 2,
"time" : "0900"
}
},
...
"weekday_text" : [
"hétfő: 9:00–17:00",
"kedd: 9:00–17:00",
"szerda: 9:00–17:00",
"csütörtök: 9:00–17:00",
"péntek: 9:00–17:00",
"szombat: Zárva",
"vasárnap: Zárva"
]
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz simico #37267 üzenetére
Az is jó lehet, de be is rakhatsz a végére egy 30 perces delayt, utána egy conditiont numeric_state above: 10 (és nem "10"! Még ha a numeric_state miatt valszeg nem is rontja el, akkor is érdemes helyesen írni, hiszen különben a "2" is nagyobb mint "10"), majd ismét egy értesítés
Vagy még inkább az action rész repeat until-ba rakva (szintén delay-el a végén, until után meg az eddigi feltétel fordítottja, vagyis below: 10), mert akkor csak egyszer szerepel ez az értesítési rész, és fél óránként szépen ismétli majd.
-
Degeczi
nagyúr
válasz zsamiatt #37262 üzenetére
Egyébként biztosan utility meteren keresztül megy?
Mert pont az szokott ilyen problémát okozni, h nem, és közvetlenül az eszközt pakolod ki az Energy panelra, amivel nincs is gond - amíg megy folyamatosan... amint áramtalanítod azonban bármiért, elérhetetlen lesz, 0 értékkel jelenik meg - majd amikor visszadugod, hirtelen ismét megjelenik a korábbi halmozott értéke, látszólag tehát 0-ról fölugrásként, vagyis megduplázva az addigi fogyasztási értéket...
A utility meter azért szűri ezt ki, mert az figyelmen kívül hagyja a negatív változást, tehát a 0-ra esést nem veszi figyelembe. Egyszer remélhetőleg az energy panelt is fölokosítják ilyesmire, és akkor nem lesz muszáj utility meteren keresztül átküldeni az ilyen entitásokat a kiküszöböléshez. -
Degeczi
nagyúr
válasz vampire17 #37273 üzenetére
Berakod egy tömbbe a limiteket, és a hónap-1 index-el fölhasználod
{% set havi_limitek = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 ] %}
{% set havi_limit = havi_limitek[now().month-1] %}
Most {{ havi_limit }}
(amúgy ezek nagyon régiek, azóta már nem m3, hanem energia szerinti meghatározás van, ami mindenhol ennél vmivel magasabb havi m3-re fordítható át)[ Szerkesztve ]
-
Degeczi
nagyúr
válasz vampire17 #37280 üzenetére
Eredetileg 59 132 MJ éves limitből számolták ki, h egy átlagos, 34.2 MJ/m3 fűtőérték mellett 1729 m3 jön ki, azért adták meg azt - ügyesen kifelejtve, h akad az országban pár terület ennél jóval alacsonyabb fűtőértékű gázzal ellátva, akár még a 30 MJ/m3-t sem elérve, tehát ők sokkal rosszabb helyzetben lennének ha m3 alapú lenne a limit, hiszen m3-ben kifejezve 10-15%-al többet fogyasztanak...
Ezért úgy módosították a rendeletet, h már 63 645 MJ legyen az éves limit, és ez számít, ebbe kell beleférni, nem a m3 keretbe.
De ez így egy átlagos, 34 MJ/m3 körüli gáz esetén is nagyobb limiteket ad m3-ra számolva, éves szinten 1871 m3 környékét.
A %-ok számítanak az alábbi táblázatodból, a m3-t még itt is a régi érték alapján számolták (pedig az első, energiaoszlop már az új, az jó...)
Még 35 MJ-al számolva is (amit pl. nálam sosem ér el: néha max 34,7, de 33,7 is némelyik számlán) januárra 336 m3 jön ki, februárra 284, stb.Szóval szerintem nézd vissza a számláidon, mi volt a környékeden valaha is a max fűtőérték, aztán az alapján kalkulálj havi limiteket, annál jó eséllyel csak kedvezőbb lehet a tényleges helyzet
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Raktáron! Új EVSE EV 3 fázisú 11kW-os hálózati töltők elektromos autókhoz, 3 év garanciával!
- Eladó Családi Ház Nőtincsen 70 négyzetméter Lakó rész + 40 négyzetméter beépíthető rész
- Üzleted van? Akkor ilyen nyitvatartás matricával dobd fel! PH tagoknak 30% kedvezmény!
- Visszapillantó matricák a legjobb minőségben! PH tagoknak 30% kedvezménnyel!
- Xiaomi Smart Cooking Robot. Teljesen új bontatlan 2 év garanciával!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs