-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Degeczi
nagyúr
Három fázisnál valóban nagyon veszélyes, ha megszakad a nullavezető, mert akkor a leginkább terhelt fázison leesik a feszültség, a másik kettőn viszont akár 380V-ra is fölmehet! És ilyen történhet rajtad kívülálló okból is, pl. póznán történt kábelszakadásból is, szóval engem is érdekelne erre jól használható védelem, mert simán lehet milliós nagyságrendű kár belőle.
Pont egy hónapja kötötték be nálam végre a három fázist a korábbi 1x16A helyett, és majdnem helyből így jártam: olyan óraszekrényt hoztak ki, amiben két mérőhely volt, bár nálam csak egyre van szükség, nem gond - de a szekrény gyártója hibásan kötegelte a két órahely kábeleit, és a szolgáltató nulla nélkül kötött be!
Ez a terheletlen mérésnél ki sem derült, hiszen az ott még összekötött nulla és földelés miatt szép egyforma és normális volt a feszültség minden fázison.
Benn a házban először csak egy fázis volt bekötve, így rögtön föltűnt, mennyire durván esik a feszültség azon minimális terhelésre is - és közben hogyan kezd megszaladni a másik kettő (amikre akkor még szerencsére nem volt rákötve semmi, máskülönben a kazán, mosógép rögtön bánta volna...) -
Degeczi
nagyúr
Amikor kiesik a nulla, a fogyasztók sorba kerülnek egymással két fázis közt (ami 400V)
Ha pont egyforma lenne a terhelésük, ez semmi gondot nem okozna (teljesen szimmetrikus rendszerben a nullán nem is folyik áram) - de olyan persze otthon nincsen, ott mindig aszimmetrikus a fázisok terhelése. Így pedig az a cucc szívja meg, amelyiknek nagyobb az ellenállása, mert annak kapcsain lesz nagyobb feszültség. Mivel az otthoni berendezések többségének ma már kapcsolóüzemű tápja van, ott ez tényleg lutri, épp hogyan jön ki. -
Degeczi
nagyúr
válasz RobexX10 #27645 üzenetére
Hogyne kellene, hiszen a pozícióra állás azon alapul, h ismert (miután egyszer bekalibráltad) a fel- ill. a leengedés időtartama, így a kívánt helyzetnek megfelelő ideig adja rá a feszültséget. Ha ezt nem teszed meg, a gyári alapérték valóban kevés is lehet a saját redőnyödhöz, és akkor simán előfordulhat, h végig sem viszi.
Én Zigbee2Mqtt-vel használom, ott adja magát akár a Z2M saját felületén, akár az általa létrehozott eszközén ott a kalibrálási kapcsoló, ami után elindítva egyik végállásból a másikba, beállítható (asszem a stop megnyomásával amikor odaért) ez az időigény.
-
Degeczi
nagyúr
válasz zsamiatt #27679 üzenetére
Persze. Ha csak helyi mentést készítesz, az tönkremehet (annyira meg azért nem fontos, h több lokális tárolón lévő példánya legyen)
A felhőmentesség az eszközök beintegrálásánál hasznos a gyors válaszidők és a netkapcsolattól meg távoli szervertől független működés miatt. Kevésbé kritikus szolgáltatásnál (mint pl. hangvezérlés) már nem gond, ilyen, éjjelente magától elkészülő másod-backupnál meg végképp.
Érdemes csak erre regisztrálni egy Google fiókot, azon a 15 GB-on elfér sok, a kiegészítő pedig magától intéz mindent. -
Degeczi
nagyúr
válasz cpt rodgi #27696 üzenetére
Persze, már a gyártó is rögtön írja, h dry contacts
Esetleg még az is szempont lehet, h megy DC-ről is (bár az általad írt 19V pont a két lehetséges tartománya között van...) -
Degeczi
nagyúr
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz magyarl #27767 üzenetére
Németországból jön, most már gyorsan (1-2 hét)
-
Degeczi
nagyúr
válasz falco5 #27806 üzenetére
A Moes egy kereskedőcég, forgalmaz sokféle termosztátot. Ha gázkazánhoz valót vettél, akkor természetesen nincs belőle gond, mert "dry contact"-os, azaz ugyanúgy csak összezárja a vezérelt két szálat, mint egy elemmel működő típus.
Léteznek azonban villanyfűtéshez és szivattyúvezérléshez való típusok is, azok kiadnak hálózati feszültséget a vezérelt kapcsokra, azok tönkretehetnek egy gázkazánt.
-
Degeczi
nagyúr
válasz Sygnus83 #27857 üzenetére
Mert az ilyen dimmerek működése abból áll, h megszaggatják a tápot, ami induktív terhelésnél (mint pl. egy motor) hatalmas "visszarúgásokkal" jár.
Pont nemrég volt a Shelly-s csoportban egy fazon, aki a leírás kimondott, határozott tiltása (konkrétan említi a tűzveszélyt!) ellenére ventilátort vezérelt egy Shelly Dimmerrel, és nahát, leégett...
Szerk: ehun-e[ Szerkesztve ]
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz vampire17 #28092 üzenetére
Ja, h végleg leesik a wifiről?
Úgy értettem, h áramszünet idején persze nekem is leesik minden Yeelight Ceiling a wifiről (míg a házvezérlés persze szünetmentesen van), de maguktól visszacsatlakoznak a wifire (és így a HA integrációba) amikor újra van áram.Nem vmi olyan szerencsétlen áramszünet volt, ami resetelte a lámpát?
Kicsi rá az esély, mert 2 mp-es szünetekkel kell 5x elvenni/visszaadni a tápot, de éppen előfordulhatott. -
Degeczi
nagyúr
Redőnyt húzogatni, klímát vezérelni éppen távolról is van értelme, és redőnynél különösen elcseszett dolog az RF-es vezérlés, mert jellemzően pozícióra állni, pozíciót visszajelezni sem tud (ami pedig nagyon hasznos automatizálásokban is), nomeg egyszerre több eszköznek parancsot kiadni sem lehet hiszen ugyanazt a frekvenciát használják, így késleltetésekkel kell vacakolni.
Persze ha már adottak a rádiós motorok, akkor nyilván egyszerűbb kompromisszum, mint azokat kicserélni, de amúgy tényleg kerülendő, ha lehet.Csak egyszer jelentő érzékelőknél (mint pl. nyitásérzékelők) meg végképp felejtős, mert nem lehetsz teljesen biztos az információban, akkor meg minek. Annak idején megváltás volt a 433-as nyitásérzékelőket Zigbee-sre cserélni.
Időjárás szenzorokhoz viszont teljesen jó, ott semmi probléma, ha esetleg elveszett egy jelentés, pár perc múlva majd jön másik.
[ Szerkesztve ]
-
Degeczi
nagyúr
Ha vki játszana a HA-ban nemrég megjelent Energy füllel, de nem elérhetőek ott ehhez a szenzorok, mert azoknak rendelkezniük kell pár jellemzővel (és pl. Modbus szenzorhoz ez közvetlenül be sem állítható egyelőre), akkor a legegyszerűbb megoldás globálisan pótolni egy összes ilyenhez egy ilyen customize bejegyzéssel (persze átírva a megfelelő wildcardra, nálam pl. xxxx_osszfogyasztas némelyik ilyen szenzor):
homeassistant:
customize_glob:
sensor.*_energy:
last_reset: '1970-01-01T00:00:00+00:00'
device_class: energy
state_class: measurement
-
Degeczi
nagyúr
válasz LouiS22 #28115 üzenetére
Abszolút...
Itt talán kicsit korán került ki élesbe a fejlesztés (ami persze nem baj, mert valós visszajelzések alapján változtatják) és a doksi is szó szerint naponta változik, nem teljesen egyértelmű, mi kell hozzá (pl. a last_reset sem), a hiánypótlás módja sem feltétlenül (mivel eddig nem kellett, én sem tudtam, h van egyáltaláncustomize_glob
), ezért írtam az alábbit -
Degeczi
nagyúr
válasz LouiS22 #28124 üzenetére
Azt nem tudom megérteni, a GUI-n végzett beállításokat miért JSON-ban mentik a rejtett mappában lévő registry-be...
Ez uis, mivel nem emberi fogyasztásra való formátum, kizárja azt, h kézzel átránts egy tesztkonfigon kikísérletezett beállításkészletet az éles rendszerre míg ha YAML lenne, egyszerűen átmásolhatnál bármit. Azért érthetetlen, mert a JSON és YAML amúgy rokon formátumok, és semmiből nem állt volna előbbi helyett utóbbiban készíteni a mentést.
Hasonlóképp a GUI-n végzett device automation-ök sem hordozhatóak, mert csak az adott konfigon érvenyes device_id-kra hivatkoznak, és nem entity_id-kra, amik lehetnek azonosak, beszédes nevűek több rendszeren is.Amúgy a GUI-val nincs baj, és pl. az energy panelhez szükséges beállításokat abban is lehet pótolni, csak persze sokkal egyszerűbb a customize_glob.
-
Degeczi
nagyúr
válasz vampire17 #28180 üzenetére
Én a Pythont is csak a HA miatt ismertem és kedveltem meg.
És megéri, mert veszett jó, h ha valamelyik integráció működésében bármi nem tetszik, akkor elég a forrását a custom_components mappa alá másolni, ott módosítani rajta - és újraindítás után már a saját kód lesz hatályban (ráadásul rendszerfrissítések után is)Meg úgy általában nagyon könnyű saját integrációt is összerakni, és automatizálásoknál is, ahol a YAML már nem áttekinthető (pl. mert összetett feltételekre vagy kivételkezelésre van szükség) ott kényelmesen Pythonban is meg lehet írni Appdaemon alatt (amit ráadásul újra sem kell indítani egy-egy módosítás után)
-
Degeczi
nagyúr
Még nagyon régi sem muszáj legyen, pl. én is használok telefonos alkalmazást, amivel reggeli induláskor leolvasom a villany- és a gázórát, ez feltölti a saját felhőjébe, ahonnan egy primitív saját HA integrációval leszedem.
Ha tudnám állítani az adat timestamp-jét, akkor elég lenne naponta egyszer is lekérdezni, mert a felhőben persze ott van, h mikor pontosan történt a leolvasás.
Mivel én sem találtam rá szebb megoldást, inkább óránként kérdezem le a felhőből, az már nem nagy eltérés (mondjuk meg főként mert a saját mérés teljesen jól követi a ház fogyasztását, messze 1% alatti hibával, így a szolgáltatói villanyóra csak ellenőrzésként kell - a gáz napi fogyasztást meg nem akarom monitorozni) -
Degeczi
nagyúr
Igen, onnan pl. ez a hozzászólás érvényes most is, én is ugyanígy, pymysql.cursors-al kezelek DB-t Appdaemon alatt (csak nem a rendszerét, hanem sajátot, pl. naptárhoz, viccekhez , eseménynaplóhoz)
-
Degeczi
nagyúr
Kíváncsiságból elhoztam egyet, eljátszok majd vele. Van már ESPHome illesztése is, ami HA-hoz még praktikusabb.
-
Degeczi
nagyúr
Riktán járok Pesten, de az M5 miatt nekem meg csak a soroksári játszik. Mivel a "Vindriktning" (most nem halandzsa név: "szélirány", németül is "Wind richtung") USB-C-s, gondoltam hozok el kábelt is (az nem jár hozzá), ebből még úgysem sok van itthon, az Ikeás meg jó és nem is drága - de kiderült, h ebben az áruházban meg az nincs nekik, csak micro ill. lightning USB kábel áll hegyekben...
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz cpt rodgi #28251 üzenetére
Amennyire tudom, pont ez egy hátránya a Google hangszórókkal szemben, h nem használható lokális file lejátszására, csak az Amazon által ismert nyilvános szolgáltatásban szereplő lehet (tehát pl. Amazon alá beintegrált Spotify fiókodban indítható el vmi)
Így a szöveg fölolvasása is csak a saját rendszerével (Amazon Polly) megy, a jó minőségű (és magyarul is használható) Microsoft TTS-el nem[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Saughassy #28258 üzenetére
Ez így valóban önszívatás.
RPi-t célgépként érdemes használni, HassOS-el, és akkor semmi nyűgöd nincs vele.
Nagyobb gépen meg Dockeren keresztül, úgy Debian-nal akár Supervised telepítés is lehet.
Közvetlenül csak mazochistáknak, hiszen akkor rajtad áll a jövőben is a környezet karbantartása, frissítése, ütközések elkerülése. -
Degeczi
nagyúr
válasz Saughassy #28268 üzenetére
Ha Supervised verziót telepítettél, egyszerűbb nem is lehetne: a Supervisor menü alatt ott a Pillanatkép opció, ahol magad pipálod ki, mit szeretnél menteni
Verziófrissítéskor amúgy magától föl is kínálja ezt.
Célszerű a Google Drive Backup kiegészítőt is fölrakni, és akkor nem csak lokális mentésed lesz.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Saughassy #28272 üzenetére
A #28258-ban még pont nem azt próbáltál fölrakni, hanem a legnehezebb módozatot, a nyers Core-t...
Nem, a rendszer verzióhoz semmi köze, hanem egy kiegészítés, h pofonegyszerűen, pár kattintással lehessen kiegészítőket telepíteni, beállítani - és persze ilyen mentéseket megoldani is. Ezek a kiegészítők a háttérben önálló docker image-ekként jönnek le, azokat lehet vele parancs-sor helyett kényelmesen, GUI-n kezelni.
Vagy a Supervised telepítés tartalmazza, vagy maga a HassOS is, a sima Core, vagy a dockeres Core nem, ott magadnak kell mindent kézzel megoldani.
RPi-n próbálgatáshoz többek között ezért is a legcélszerűbb a HassOS.
-
Degeczi
nagyúr
Univerzálisan tényleg ez a legjobb.
Az RFlink halott projekt, évek óta nem volt frissítve (nálam vmi Aldis hőmérőt nem ismert, és akadt eszköz, amire meg rengeteg szemetet gyártott, mert egyszer így, másszor úgy "ismerte föl"), a Sonoff Bridge nyitásérzékelőkhöz jó volt, de időjárásállomásból az sem mindent látott nálam, az RTL-el viszont minden ment rögtön.
Csak asszem jó minőségű RTL 433 sticket nehéz már szerezni -
Degeczi
nagyúr
válasz Galahed #28362 üzenetére
Mi sem egyszerűbb: csinálsz egy automatizálást a
homeassistant
platformstart
eseményére.Célszerű egy akkora delay-el kezdeni, ami után a rendszer elemei már mind üzemelnek.
Pl. hogy a Tasmotás és Shelly MQTT konnektorok, redőnyvezérlők azonnal helyes állapottal jelenjenek meg, ilyen MQTT parancsokat küldök nekik indításkor:- alias: "Resfresh MQTT switch power states on HA start-up"
trigger:
platform: homeassistant
event: start
action:
- delay:
seconds: 60
- service: mqtt.publish
data:
topic: sonoffs/cmnd/state
payload: ""
- service: mqtt.publish
data:
topic: cmnd/sonoffs/POWER
- service: mqtt.publish
data:
topic: shellies/command
payload: "announce"
De amúgy egy korrekt okosizzót, lámpát valóban nem kell külön abajgatni, magától tudnia kell olyat, h az utolsó állapotába álljon vissza.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Galahed #28366 üzenetére
Mondjuk ez persze csak a HA indulásakor fut le - ami egy normál áramszünet után jó esetben nem történik meg, hiszen a szünetmentesed (ugye van? Rengeteg idő előtti kártya sérülés, config elszállás oka, ha nincs!) remélhetőleg áthidalja, és akkor nem a HA indulásra, hanem a "visszajött az áram"-ra kell időzíteni
Nemrég amúgy pont a szünetmentes szivatott meg: USB-n keresztül túl hamar leállította a rendszert, noha bőven bírta volna az áramszünet végéig. Így aztán hiába volt a gép setup-jában beállítva, h visszajött áramra kapcsoljon be - ha az valójában el sem ment, így persze nem történt meg a visszakapcsolás sem...
Természetesen távollét idején (szerencsére nem hosszún, így csak két napra nem volt időzített locsolás)
Azóta annyit változtattam, h a setupban állítottam be minden nap hajnalra bekapcsolást (többnyire úgyis éjjeli vihar idején megy el), ill. nem hallgatok az USB-n jött UPS pánikra, időzítve kapcsolom le ha már fél órája nincs áram.[ Szerkesztve ]