-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Degeczi
nagyúr
Hát előre nem tudtam, h ilyen az a Lidis csengő, utólag pedig már mindegy volt, megjegyezte, törölni meg nem lehetett...
Később aztán raktam föl korrekt riasztót vezetékes mozgásérzékelőkkel, az első nagy lezárás alatt meg vezetéket is beástam a kapuig a csengőhöz, így már mindegy. -
Degeczi
nagyúr
válasz Vodike #34295 üzenetére
#33470-ben ugyanerről volt szó (másoltátok valahonnan?): a hvac_modes attribútum egy tömb, a neve is ezért van többesszámban (az összes lehetséges módot tartalmazza, amint azt a Fejlesztői eszközök alatt meg is nézheted) amit nincs értelme egyetlen stringgel összehasonlítani.
Egyszerűen maga a climate.haloszoba_ac state-je, amire szükséged van, tehát nem kell az attribute sorAz ablak szenzorát pedig nevezd át beszédesre, ne szívasd magad ilyen id-vel
-
Degeczi
nagyúr
válasz repvez #34307 üzenetére
Magát a rendszert kezdeti kísérletezéshez dedikát célgép helyett a normál gépeden virtualizált környezetben is fölrakhatod, de az okoseszközöket be kell szerezned, szimuláció nincs (tökéletes úgysem lehetne, így túl sok értelme sem lenne) ismerkedéshez demó van HA-ból és OpenHAB-ból is.
-
Degeczi
nagyúr
válasz repvez #34320 üzenetére
Bármelyik rendszer alatt tudsz létrehozni MQTT szenzort (beleértve a nyitásérzékelőket, hőmérőket, feszültségérzékelőket, riasztóközpontot - lényegében bármit), és akkor magad szimulálhatod a megfelelő topikba küldéssel, h történt vmi.
(mondjuk az értelmét akkor sem látom, miért nem akkor mész át a hídon amikor már odaértél, mit fogsz megtudni egy ilyen előzetes erőfeszítésből - de kétségtelenül egyszerűen megcsinálhatod) -
Degeczi
nagyúr
válasz tradeelek11 #34385 üzenetére
Neten olvasott (nekem csak 13-as van) felhasználói tapasztalatok szerint a 15-ös helyből nagyjából korrekt adatokat szolgáltat, míg a 13-as vmivel (15-20% közt) nagyobb teljesítményt (és így fogyasztást) mér a ténylegesnél.
Eszköz-állapot tesztelésre persze ettől még ugyanúgy megfelel, csak ha költségszámoláshoz használta volna vki, ahhoz kellett némi korrekció - de idén bekerült a Z2M-be is ez a lehetőség. -
Degeczi
nagyúr
válasz vampire17 #34451 üzenetére
Azt tudod, h rögtön visiítani kezd amint megszűnik az a betáp? (hiszen szabotázst feltételez)
Riasztóval ez azért nem gond, mert ha nem hanyagolták el a karbantartást (pár évente akkucserét), annak saját akkuja jópár órát, akár fél napnál is többet bír, azaz bőven áthidal egy szolgáltatói áramszünetet.
Ha azonban AC-DC tápot adsz neki, rögtön beindul a sziréna áramszünet idején, vagy ha szünetmentesre is kötöd, egy átlagos típus azt sem bírja sokáig. -
Degeczi
nagyúr
válasz vampire17 #34454 üzenetére
Akkor jó, ez többnyire nem állítható így (saját akkuja persze kell legyen, szirénázás közben nagy az áramfölvétel, ami a riasztónak is sok lenne, és vezetékből is vastag kellene, így meg csak a töltés 250 mA-re kell méretezni - és elméletben a falról letépve is szirénázik tovább. Gyakorlatban mondjuk nem, mert egyszerűen vízzel teli vödörbe teszik bele)
[ Szerkesztve ]
-
Degeczi
nagyúr
Pushbullethez is van gyári integráció.
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz LLKobe #34498 üzenetére
Ez tényleg kicsi - de te nemrég kezdted, valszeg nincs még nagy DB-d semmiben (nem csak HA, hanem az addon-ok is, pl. nálam a Unifi controller mentése is szép nagy, annak adatbázisa miatt)
Töltsd le: sima tar.gz file-ok, még a Total Commander is bele tud lépni. A full backup úgy értendő, h az addonokhoz is minden config és egyéb saját file benne van - de nem maga az addon, az fölösleges lenne, elég csak a szükséges verziót tárolni, amit majd letölt a Docker az újraépítés során[ Szerkesztve ]
-
Degeczi
nagyúr
válasz daninet #34554 üzenetére
A YAML configoláshoz nagyon jó, logikus szintaktikájú.
Alapvető ("ha ez, akkor az") automatizálásokhoz is hasonlóan kényelmesen, jól használható, csak ott érdemes kerülni , ahol bonyolultabbak a feltételek (AND-OR egymással vegyesen), elágazások, ahhoz már valóban nem barátságos. -
Degeczi
nagyúr
válasz szricsi_0917 #34585 üzenetére
Komplex dolgokat nem érdemes sima HA automatizálásként készíteni, mert hamar áttekinthetetlen lesz. Én mondjuk lábrázást kapok a Nodered-től, de tény, h abban is jóval egyszerűbb megoldani ilyesmit, csak célszerű föltenii hozzá a HA illesztést, amivel közvetlenül hozzáférsz abban lévő entitásokhoz.
A felületed marad HA, csak a programozást, az események kezelését végzed Nodereddel. -
Degeczi
nagyúr
válasz Fuser és Tsa #34598 üzenetére
Tavaly október óta nyomta a warningokat, h már nem támogatott adattípust használsz... ezt vették ki fél év után, mint az írják is az áprilisi breaking changes-ben.
Tessék már odafigyelni ezekre a napló-üzenetekre, fontosak! -
Degeczi
nagyúr
válasz ratkaics #34658 üzenetére
Kiesik időnként a szenzorod, elérhetetlen lesz - és az float-ra alakítva (ami így egy jó ideje már nem is helyes így, kell default értéket is megadni) 0 lesz, ezért.
Meg kellene találnod a kiesések okát, szőnyeg alá söprésként meg feltételbe tenni a kifejezést, h csak akkor dolgozzon, amikor nem elérhetetlen, egyébként a számolt szenzor aktuális értéket adja vissza.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Saughassy #34667 üzenetére
Igen, még decemberben vették ki a fogaskerék alól (a legelső említett módosítás volt a breaking changes alatt)
A fejlesztői eszközök alatt átírhatod, nem readonly. Ha MQTT alapú szenzor, akkor valszeg MQTT auto discoveryként kapod a paramétereit, azok írják vissza amikor ismét érkezik üzenet tőle.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Saughassy #34671 üzenetére
Nemrégi szívtam én is vele, h megváltozott az RTL433-al befogott szenzor id-ja, így a felületen beragadt a korábbi néven használt szenzor állapota... pár hónappal ezelőttig sosem csinált ilyet, elemcsere sem volt, talán az RTL433 addon frissítése okozta nálam, nemtom, majd figyelem csinál-e még ilyet
-
Degeczi
nagyúr
Na ha valami, ez aztán baromira nem igaz! Szenzor definiáláshoz miben kellene jobb doksi a gyárinál, ami áttekinthető és mindent bemutat, jól használható példákkal? A haladóknak közvetlen linkkel a forráskódjára.
És hozz már egy konkrét példát újoncnak látványos nem segítésre! -
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz Warter #34758 üzenetére
Azért nem gondolom mert kezdőről van szó, akinek a template condition nem lenne barátságos, pláne mivel nem is azt írja, h "x időn belül ne fusson" hanem aznap csak egyszer, vagyis az automatizálás utolsó futásának dátumrészét kellene összehasonlítani az aktuális dátummal.
Egy alábbi helper viszont egyszerű, érthető, áttekinthető kódot igényel. -
Degeczi
nagyúr
válasz ratkaics #34766 üzenetére
- above után ne string szerepeljen, mert úgy pl. a '10' is kisebb, mint a '4.5' (ez is GUI hülyeség, h így írja)
- condition: and, conditions: szinte mindig fölösleges (csak akkor kell, ha or is van), mert a feltételek egymással eleve "és" kapcsolatban vannak, itt meg amúgyis csak egy feltétel szerepel
- a device típusú műveletekről nincs doksi, ezért ha csak lehet, nem ajánlott azokat használni (a GUI viszont nagyon szereti, innen is rögtön látszik, h azzal készült) Hagyományos módon ugyanez így nézne ki:- service: switch.turn_on
data:
entity_id:
- switch.regi_bojler
- az action alatt már nem condition-t írsz hiszen ott ez nem feltétel (ha így írod, azt jelenti, h álljon meg az automatizálás azon a ponton, ha nem teljesül a feltétel...), hanem szintén service hívással billented on-ra:- service: input_boolean.turn_on
data:
entity_id: input_boolean.regi_bojler_bekapcsolt
- a konvenció "on" és "off", célszerűbb erre tesztelni az input_boolean-t, még ha esetleg működik is 0-val -
Degeczi
nagyúr
válasz ratkaics #34777 üzenetére
- az entity_id nevébe nem kell kötőjel, így nem fog működni (és az idézőjel is fölösleges. Hogy problémát okoz-e, arról nem tudom, sosem próbáltam, de szükség nincs rá, vedd ki azt is, ahogy a többi entity_id-nál is írod)
- a state: '0' lehet, h működik (ezt sem próbáltam így), de a konvenció a state: 'off'-ra tesztelésÍgy jó lesz (ill. már csak egy éjfélre időzített automatizálás kell, amiben input_boolean.turn_off-ot hívsz erre a helper változóra a napi törléshez)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz ratkaics #34782 üzenetére
A "| float" eleve nem helyes már régóta így, kell egy alapértelmezett érték. Az legyen pl. -1, mert azzal egyszerűen beazonosítod az elérhetetlen állapotot, tehát vmi ilyesmi működhet:
{% set Temp1 = states('sensor.energy_consumed') | float(-1) %}
{% if Temp1 != -1 %}
{{ (Temp1 - 1358) | round(0, default=0) }}
{% else %}
{{ states('sensor.energy_consumed') }}
{% endif %}
-
Degeczi
nagyúr
válasz tsilver #34794 üzenetére
Ha a Gree alkalmazásában kell ismét fölvenni a klímát, akkor ez nem az integráción múlik (amiből a HA-ban alapban lévő amúgy teljesen jó)
-
Degeczi
nagyúr
válasz tradeelek11 #34825 üzenetére
Bizony, nagyon nem ajánlott az általános ttyUSBx használata, hiszen az változhat.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen