-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz SafE84 #49188 üzenetére
Éppenséggel tehetsz tömszelencét is kötődobozra, de mezei okoskonnektorok is jól szokták bírni a hideget és a páratartalmat. A klímám fogyasztását 4 éve egy SHP-2-vel mérem, azóta van kinn a teraszon probléma nélkül, díszfényekre pedig (ahol nem kell mérni csak kapcsolni) egy régi Alfawise PE1004T-t szoktam kirakni, az sem panaszkodott még.
-
Degeczi
nagyúr
válasz dragon1993 #49210 üzenetére
Nagyon nem pontosak, mert hiába kértük már évekkel ezelőtt is feature-ként, a Shelly nem tesz bele finomhangolási lehetőséget, és fixen, bután úgy tekinti, h a felhúzás lineáris időszükségletű, ami pedig érthető módon nem igaz, hiszen egy leengedett redőny esetén az első pár motorfordulat még csak "előfeszíti", széthúzza egymástól a feltorlódott lamellákat, a redőny még nem indul meg fölfelé. Emiatt egy lineáris skálára kiadott 50% parancs simán lehet (redőnyhossztól, motorsebességtől függően), h csak valahol 30% környékére áll, és a tényleges fél-pozícióhoz mondjuk 65%-ot kell kiadni.
Persze jelentősége igazából nincs, de zavaró, mert könnyen leküzdhető téma volna. -
Degeczi
nagyúr
válasz nemethsza #49223 üzenetére
Attól, h fix tápfeszültséget adsz neki elem helyett, még nem fog beindulni, gombot is kellene nyomni rajta, szóval szét kellene szedni és egy dry contactos relével zárni a gombját
@vampire17: igen, ilyen fajtánál ez valóban egyszerű és gyors megoldásDe akkor már valóban jobb olyan típust beszerezni, ami eleve hálózati tápról megy, azok többsége rögtön elindul amikor feszültséget kap, azokat elég egyszerűen egy okoskonnektorra kötni.
[ Szerkesztve ]
-
-
Degeczi
nagyúr
válasz Gabesz87 #49237 üzenetére
Persze, h nincs újdonság, ahogy írja: a yaml használatával történő konfigurálás került eltávolításra. A felületen ez semmi változás, csak a beállítások / integrációk alatt fogod megtalálni, ha vmi állítani kellene rajta, ahelyett, h yaml filet kellene szerkesztened (ahonnan viszont kézzel ki kell szedned áprilisig, ezért az üzenet).
-
Degeczi
nagyúr
válasz gorbep #49388 üzenetére
Tényleg érthetetlen a Youtube videók használata erre, semmi nem indokolja, nagyon nem praktikus. A szöveges leírásokon olyan tempóban haladsz ahogy szeretnél, tudsz keresni szövegre, kimásolni onnan config sorokat, és nem utolsósorban mindig naprakész ha a gyári doksiról van szó. A YT videók mindenben ennek ellentétei.
-
Degeczi
nagyúr
válasz vampire17 #49474 üzenetére
Évente kipróbálom épp hol tart, de pár nap után mindig feladom, katasztrófális. A legalapvetőbb dolgokkal is napokat kell elkínlódni (hogy mást ne mondjak, pl. még olyan trigger sem létezik benne, ami egy bizonyos ideje fönnálló állapotra aktiválódna, ami HA alatt egy egyszerű "for: x seconds" sor, ehelyett egyenként, külön időzítőket kellene létrehoznod mindenhez...), hogy a felhasználói felületet már ne is említsük.
Rejtvényfejtésként jó, de nem alternatíva. -
Degeczi
nagyúr
válasz PistiSan #49509 üzenetére
Ne tükörferdítésre keress, hanem az eredeti "dry contact"-ra, úgy megtalálod. Magyarul potenciálmentes. Semmi köze a nedvességhez, IP védelemhez, árammal nem "szennyezi" maga a kapcsolórelé a kapcsolt áramkört, hanem csak összezárja az általa potenciálmentesen hagyott érintkezőket, így bármit köthetsz rá.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz its_grandpa #49519 üzenetére
Egyrészt miért ne tudnál akár mobilnetről is, az csak a céges VPN kérdése, másrészt a fönnakadás azon az állításodon van, h köteles lenne a szolgáltató NAT nélküli címet adni. Nem az. Nem is lehetne, hiszen eleve azért NAT-olnak, mert nincs elég IPv4 címük.
-
Degeczi
nagyúr
válasz PistiSan #49542 üzenetére
Igen, életvédelmi szempontból mindenképp törpefeszültség (nem az áram, 230V esetén 100 mA is simán halálos lehet) kell olyan helyre, ahol van esély a beázásra (pl. csengőgomb). De ennek nincs köze a kapcsolóreléhez, a dry contact típus sem mehet ki esőtől nem védett helyre, ha nincs időjárásálló kivitele, doboza.
4D4M: az 5V szál fut nagyon közel a 230V-hoz, ezt így semmiképp! Az U4, U5 230-as vezetékei közt is lehetne jóval nagyobb távolság, arra ne alapozz, h mondjuk mindkét csatlakozó 1-es lábára van kötve a nulla, 2-esre a fázis
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz enginev3.0 #49603 üzenetére
Nyáron cserélték nálam is, szintén full buta óra került föl (mert asszem a Démásznak nincs is más raktáron)
-
Degeczi
nagyúr
válasz ViZion #49610 üzenetére
Dehogynem, ír róla a doksi (ahogy azt is, h természetesen nem küldenek ki jelszavakat, csak hash-ek első 5 karakterét ellenőrzik)
@gorbep: maga a HA szépen működik netkapcsolat nélkül (sajnos nem egyszer kellett így használnom a netszolgáltatóm miatt), de ha felhőt használó eszközt integrálsz be, ott nyilván nincs erre garancia, ez már nem a HA hatásköre.
-
Degeczi
nagyúr
válasz gorbep #49632 üzenetére
Ha hülyén van megírva az eszköz firmware-e, azzal nem tud mit kezdeni, ez nem a HA sara... a leírás figyelmeztet is rá, h Miio-k esetén a netelérés blokkolása kapcsolódási hibákat okozhat: "Blocking the network access to the device is known to cause intermittent connection issues due to the device’s internal software hanging and a watchdog restarting the internal software"
A 3EM-et nem ismerem közvetlenül, de asszem lehet MQTT-n keresztül használni.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz gya/352 #49634 üzenetére
Ld. alább, itt gyakran van netkimaradás, de mindig stabilan működnek. Egy próbát megérhet ott, ahol nem. Mivel a Shelly-k az MQTT bekapcsolásához azt a figyelmeztetést írják, h attól kezdve nem fog működni a felhőn keresztüli elérés, nyilván máshogyan működnek ilyenkor, és nagyon könnyen lehet, h ezzel lehet összefüggésben a máshol tapasztalt hiba.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz TucsyAtti22 #49948 üzenetére
HA OS, azaz már oprendszer, nem kell más a gépre (Windows meg eleve nem ideális HA futtatáshoz)
-
Degeczi
nagyúr
Ez sima badge
-
Degeczi
nagyúr
válasz tukko1 #50022 üzenetére
HAOS alatt engedi a Studio Code Server átállítani a munkamappát. Mondjuk pont azért, h ne kelljen így mászkálni, beállíthatod az Appdaemonnak, h továbbra is a HA config alatti appdaemon mappában legyenek a programjaid egy
app_dir: /homeassistant/appdaemon/apps
sorral az appdaemon.yaml-ben (és persze a logokat is érdemes lehet hasonlóan átirányítani)
Ez azzal jár, h nem az appdaemon, hanem a HA mentések fogják tartalmazni ezeket, de ez nem komoly hátrány (és ilyesmihez egyébként is célszerű egy saját github repót fönntartani, abban legyenek az ilyen programok, mert akkor nem sima, fix mentés van róluk, hanem verziókövetett)[ Szerkesztve ]
-
Degeczi
nagyúr
válasz akosmakos334 #50054 üzenetére
Nem lehetetlen kihagyni a felhőt (nagyjából erről szól ez az egész topic...), saját, kisfogyasztású gépre bízva a vezérlést.
-
Degeczi
nagyúr
válasz Fecogame #50057 üzenetére
Elemes wifis hőmérő önmagában sem túl célszerű a nagy energiaigénye miatt, fűtésvezérléshez pedig végképp kizárt (hiszen ott sűrű lekérdezésre van szükség, tehát nem takarékoskodhatsz azzal sem)
Hacsak nem vmi régi kazán, az on-off termosztát bemenete törpefeszültségről dolgozik, és könnyen elvezethető messzebbre is (és a PoE említése miatt nyilván megoldható a kábelezés), tehát akár egy sima, dry contactos relé is lehet ott, ahol már van stabil wifi térerő -
Degeczi
nagyúr
válasz Rodzser Mór #50061 üzenetére
Az első beállítást leszámítva többet egyáltalán nem kell azonos hálón lennie - hiszen különben nem tudnád távolról vezérelni. Az aljzat netkapcsolatának azonban stabilnak kell lennie, ez a felhős megoldás egyik hátránya, különben a legtöbbnél az időzített kapcsolás sem történik meg, mert az sem lokális vezérlés.
-
Degeczi
nagyúr
válasz Rodzser Mór #50063 üzenetére
Nem. Ott kezdődik a dolog, h RTC nincs egyik ilyen eszközben sem, tehát min. a hálózatodon kell lennie egy lokális time servernek, máskülönben egy tápkimaradás után nincs órája - ami önmagában kizár egy időzítést.
De ez is csak bizonyos márka (pl. Shelly) esetén megoldás, mert a legtöbb eleve nem tárol lokálisan időzítéseket, hanem a gyártó szerverén, tehát szüksége van folyamatos netkapcsolatra a működéséhez.
A mobiltelefon meg más téma, az azon futó alkalmazás szintén a központi szerverhez kapcsolódik, nem az eszközhöz (kivéve a legelső alkalmat, amikor beállítod a hálózatot), ezért lényegtelen milyen hálón van (vagy fizikailag hol, lehet mobilneten is bárhol a világban) -
Degeczi
nagyúr
válasz csubuka #50139 üzenetére
Nálam is kettő kis Elfin üzemel, mert így a garázshoz elég volt egy hálózati kábelt kihúznom az ottani wifi AP-hoz, nem kellett még a modbushoz is.
Házon belül mondjuk inkább kábelt vinnék oda, pláne ha azonos típusú eszközök, bár azt persze csak te tudod, nálad ez mekkora munkával jár. Kész rendszernél érthetően sokkal, de ha csak most szerelik majd a fan-coil-okat, azokhoz úgyis kell kábelezés, ott aligha komoly tétel plusz egy jelkábelre is fölfűzni ezeket. -
Degeczi
nagyúr
válasz Fuser és Tsa #50155 üzenetére
A leírás első helyen említi a template-ek kapcsán, még vastagítással is kiemeli, h az egysoros kifejezéseket zárójelek közt kell használni.
-
Degeczi
nagyúr
Ez így nem jó az eddigire sem, pont fordítva kell: az ajtónyitás a trigger, a lement nap a feltétel. Jelen állapotában kizárólag a naplemente pillanatában fog aktiválódni, ha épp nyitva van közben az ajtó is... nyilván nem ezt akarod.
A lekapcsolás meg célszerűen egy másik miniautomatizálás, amit az ajtó szenzor on-ból off-ba ugrása aktivál (feltétel ott nem is muszáj, mert semmi bajt nem okoz, ha egy már lekapcsolva lévő kapcsolónak küldesz ismét lekapcsolási parancsot)
-
Degeczi
nagyúr
Nem lenne elegánsabb, eltérő dolgokról van szó. Csak lehetséges problémákat vezetsz be, ha egybeerőszakolod, és közben semmit nem nyersz. Érdemes mindent a lehető legegyszerűbbre csinálni, mindig az a legstabilabb.
Petikeje: pont az lenne egy szép recept rejtélyes hibák generálására... State triggerben nagyon ritka kivételektől eltekintve mindig meg kell adni a miből-mibe-t, máskülönben pl. még egy rendszerújraindítás vagy bármilyen kiesés is eseményindítóként fog működni (hiszen az után "unknown" állapotból fog pl. "off"-ba ugrani egy entitás...)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Petikeje #50185 üzenetére
De minek bonyolítani, amikor két hóttegyszerű miniautomatizálás áttekinthetően, üzembiztosan megold mindent? Sokkal bonyolultabb lesz egybemosva, utólag elkülönítve melyik eset áll fönn, melyikre milyen feltétel vonatkozik (hiszen az sem azonos) - miközben ismét, semmit nem nyersz vele.
-
Degeczi
nagyúr
Ezért írtam a sok év alatt szerzett saját tapasztalatból, mi egy gyakori buktató - de jössz az elméleti fejtegetéssel, h olyan nem lehet. Hát majd meglátod egyszer magad is, de...
Könnyen lehet unknown egy érzékelő: már a rendszerindítás során is (ott attól függ, okoz-e gondot, h maga a rendszer hogyan áll éppen: hiszen lehet, h maga a lámpa sem elérhető még), hálózatról leszakadás esetén is, vagy ha frissíted, újraindítod a szenzort biztosító integrációt. Teszem azt egy Zigbee2mqtt-t, vagy magát az mqtt szervert.
Ha nem használsz "from"-ot csak "to"-t, az bizony tartalmazza az ilyen határozatlan állapotból on-ba vagy off-ba ugrásokat is, tehát fölkapcsolod vele a lámpát ha ilyen hiányos a trigger, ezért kell mindig from is. Akkor viszont bonyolult az elkülönítés az action alatt, épp mit is kell csinálni - és nincs is értelme az egésznek. Nincs abból semmi probléma, ha nagyon sok miniautomatizálásod van: jól olvasható a kódjuk, stabilak, ki-be kapcsolhatóak egyenként, könnyen tesztelhetőek. Az összetartozóakat úgyis egy-egy file-ba írod, számodra tökéletesen átláthatóan.
-
Degeczi
nagyúr
válasz Cyberbeni #50223 üzenetére
Azt ugyanúgy - mást azonban nem!
Pl. a kikapcsoláshoz fölösleges megadni az időszak feltételt (hiszen különben annak vége után lezajló becsukás már nem futna le. Nem kell messzire menni: az alábbi példában az "after sunset" azt jelenti, h éjfél után csukott ajtóra már nem fog lekapcsolni...), és akkor mindjárt ott a bonyolított szétválasztás - a semmiért.De teljesen igazad van, mindenki úgy szivatja magát, ahogyan szeretné, nem kell hallgatni mások tapasztalatára. Csak akkor nem értem, minek fórumozni? Hanyagolom is itt ezt, semmi értelme.
-
Degeczi
nagyúr
válasz kis.zsolt #50584 üzenetére
Valszeg onnan ered az "áramtalanítás árt" babonája, h rendre egy ismét feszültség alá helyezés az, ami megadja a kegyelemdöfést leginkább egy elfáradt kondinak - de az már amúgyis az utolsókat rúgta, éppen a hosszú üzemideje miatt... Ha időnként áramtalanítva lett volna, tovább bírja.
Van, ami a jellegéből adódóan nem kapcsolható ki, pl. falba épített wifis relé, ami a környezete miatt betorlódó melegtől van még rosszabb helyzetben. Pont a napokban szállt el az egyik, kb. 5 éve üzemelő Shelly 2.5-em, a szabályzó chip robbant fel (szó szerint: lyuk van rajta) a tápjában, de az ok itt is ugyanez: a mellette lévő 4.7 uF 400V kondik egyikének már csak 200 pF körüli kapacitása maradt. Cserélem is ki mielőbb a többi példányban is megelőzésként... (BTW nem egyszerű ilyen kis átmérőjűt találni ebben a feszültségértékben, ez ilyen, bár picit magasabb, de szépen bemegy a helyére. Ez pedig a kisfeszültségű oldalra megy)
-
Degeczi
nagyúr
válasz belashx #50635 üzenetére
Szinte teljesen biztosan az infra vétel okozza. Pl. a saját TV-met is akkor tudom garantáltan bekapcsolni infrával, ha beállítom az ismétlési opciót is, egyszeri küldés nem mindig elég (lehet, h 4 sem kellene, de bajt nem okoz, és ennyivel mindig működik):
Egyébként egyszerűen le tudod tesztelni: a gombnyomásra végeztetsz vmi mást is az action alatt, pl. lámpa kapcsolgatás toggle paranccsal, naplóba írás, üzenetküldés, stb. Ha azok stabilan megtörténnek, akkor valszeg nálad is többször kellene átküldeni egy-egy parancsot.
-
Degeczi
nagyúr
válasz belashx #50641 üzenetére
Ha nincs ilyen opciója a Z2M-es cuccnak (az enyém egy Broadlink mini), akkor gondolom a küldendő kódban lehetne megismételni a parancshoz tartozó szekvenciát.
Lehet, h a vezérlendő eszközöd megy mélyalvásba bizonyos idő után, annak kellene többször elismételt bekapcsolási parancs, mert az elsőt még nem "fogta föl". Kézi távvezérlésnél nincs ilyen gond, mert tovább nyomod a gombot, ha látod, h nem reagál. És gondolom nem mindhárom készülk ilyen, vagy igen?
-
Degeczi
nagyúr
válasz belashx #50652 üzenetére
Akkor lehet, h egyszerűen az IR eszköz hülye, és már akkor elkezdi a következő parancs feldolgozását, míg az előzővel sem végzett.
Egyébként az MQTT-t pont a kieső kliensekhez tervezték, éppen azzal számolva, h sokszor, sokáig lesz offline valami, de ez nem jelent semmilyen problémát: az MQTT bróker őrzi a neki szánt üzeneteket, és amikor a felébredt cucc benéz a "levelesládájába" (topikjába, amire föliratkozott), akkor szépen megkapja ami rá vár. Önmagában tehát ez nem gond, csak ismét: ha hülyén írták meg, h nem sorban egymás után végzi a feldolgozást. Így még az is elképzelhető, h rossz esetben ne legyen hatása a késleltetésnek sem, hiszen az csak a parancsok MQTT brókerre beküldésére vonatkozik - arra már nincs hatással, h egy hibásan üzemelő eszköz mit és mikor kezd velük.
Új hozzászólás Aktív témák
- Eladó Családi Ház Nőtincsen 70 négyzetméter Lakó rész + 40 négyzetméter beépíthető rész
- Autómatrica és prémium minőségű matricák PH tagoknak 30% kedvezménnyel!
- Raktáron! Új EVSE EV 3 fázisú 11kW-os hálózati töltők elektromos autókhoz, 3 év garanciával!
- AKCIÓ! Okos otthon és biztonság - BOLTI ÁR FELÉÉRT!
- Visszapillantó matricák a legjobb minőségben! PH tagoknak 30% kedvezménnyel!
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen