-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Degeczi
nagyúr
-
Degeczi
nagyúr
-
-
Degeczi
nagyúr
válasz Primary92 #43381 üzenetére
Nem muszáj: a fejlesztői eszközök alatt van kimondottan "manuálisan konfigurált mqtt" újraolvasás...
Az viszont nem világos, h mivel van gondod. A config az indentálást leszámítva jónak tűnik (de ha az ilyen, akkor told a name n betűje alá az utána következő sorokat is)[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Primary92 #43383 üzenetére
Ja, már az elsőre is akartam kérdezni, h ez ugye több üzenet - de ha egyetlen, akkor nem csoda: ez így nem szabályos JSON!
A mostani módosításoddal már az, ezért fogadja el.
A villanyóráknak külön topikja legyen, így mindegy mennyi van, azon belül egyhez már jó a mostani módszered.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Primary92 #43386 üzenetére
Persze, ezért is jó a yaml config, pár copy-paste és search&replace-el pillanatok alatt létre lehet hozni sok hasonló szenzort.
Egy szenzornak egy állapota van. Saját integrálást írva lehet olyat csinálni, h több tulajdonság alatt is megjelenjen több minden, de ilyen célra nincs értelme, ezeket amúgyis (pl. statisztika miatt) jobb külön entitásként kezelni.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Jofi81 #43388 üzenetére
Nekem sincs tapasztalatom vele, de ha van rá mód, szerintem is inkább az optikai, hiszen ott azt írja a linkelt oldal, h pillanatnyi teljesítményértéket is kapsz, és a fogyasztást is nyilván abszolút számértékként egy leállás után is (míg ha az impulzusszámlálásod bármilyen okból éppen kimarad, utána manuálisan kell korrigálnod az elmaradást)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz zsamiatt #43430 üzenetére
Igen, így csak szép játék, de gyakorlati felhasználásra nem jó, mivel a fene se fog ilyen eszközt keresgélni, nyomogatni, közelről belebeszélni parancskiadáshoz, kell vezényszóra állandóan fülelő cucc - azt viszont nem egyszerű összehozni, sok mikrofonnal, háttérzajból amennyire lehet kiszűrve a beszédet, csak a tényleges parancsszóra reagálni.
A legjobb az lenne, ha sikerülne vkinek meghackelni egy gyári megoldást, Google vagy Alexa hangasszisztensre saját firmware-t tenni, hiszen a hardver ott adott.
Másrészt a jó minőségű TTS lokálisan elég erőforrásigényes (de nyilván a STT is), és az okosotthon rendszer futtatására amúgy tökéletesen elegendő, kis fogyasztású rendszeren sokkal lassabb az online szerverekénél. Jó lenne ahhoz is vmi hardveres támogatás, mint képfölismeréshez a Coral.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Pékmester #43456 üzenetére
Nagyon nem jellemző, de igazából szükség sincs rá, jobban jársz a 2.4-el, hiszen okoskonnektornál a sebesség nem számít, a jó lefedettség viszont annál inkább, és az lényegesen jobb azon a frekvencián, más forgalmad pedig ott valszeg nincsen (ahol számít a sebesség, pl. laptop, telefon, tv, stb nyilván 5 GHz-re csatlakozik) így a 2.4 GHz maradhat az okoseszközöknek.
-
Degeczi
nagyúr
válasz Pékmester #43461 üzenetére
Egyrészt ahogy Vizion mondja, ha gyári firmware-t használsz, az okoskonnektorod a gyártói felhőre csatlakozik föl, és azt nemhogy az 5 GHz-en lévő telefonról, de mobilnettel a világon bárhonnan eléred, hiszen teljesen független csatlakozásokról van szó.
Másrészt a 2.4 / 5 GHz csak a wifi csatlakozást érinti, ettől még az egész lehet (és célszerű is, ha az) egyetlen helyi hálózat, amin bármelyik eszköz eléri bármelyik másikat. Persze lehet másképp is beállítani, de nem érdemes, és alapesetben szerintem minden mezei router így van beállítva, megy a helyi elérés is, ha olyan eszközről van szó ami azt engedi (vagy saját firmware-t telepítve)
Amikor beállítod a gyári állapotú okoskonnektorod (és az még semmit nem tud a helyi hálózatodról), addig, az egyszer valóban a 2.4 GHz-re kell csatlakozz a telefonoddal is, de később már nem.
Jellemzően tudsz megadni külön SSID nevet az 5 GHz-nek, így könnyen kiválasztható a telefonon, melyikre akarsz csatlakozni. Ha esetleg nem, akkor arra az időre egyszerűen le is tiltható, mint más is említi.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz Kolondrum #43470 üzenetére
Hülyék ezek a kínaiak: 2 évvel ezelőttig, a három fázisra bővítésig használtam egy névleg ugyanilyen típusú "DDS238-2"-t, Modbus változatot - de az csak mért, nem kapcsolt...
-
Degeczi
nagyúr
válasz v.attis #43483 üzenetére
Rasperry régebben volt ajánlott, amikor olcsón hozzá lehetett jutni. Manapság már kimondottan drága, pláne úgy, h neked kell jó minőségű tápot, házat, hűtést és vmi SSD megoldást találnod hozzá. Praktikusabb vmilyen mini-PC, levetett passzív thin-client gép, mint pl. az itt sokszor említett HP T620.
Rendszernek pedig ma már adja magát, h elsőként a Home Assistantot próbáld ki, nagyon egyeduralkodó lett (parancssorban sosincs dolgod), kellően kezdő-barát is és az eszköz támogatása messze a legjobb.De ha van a környékeden olcsón vagy kallódva valahol régebbi RPi azon kipróbálhatod a Domoticzot is ha támogatja minden cuccod, ahhoz valóban elég az is.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz enginev3.0 #43520 üzenetére
Elvileg jó ideje Gree az is, így persze.
-
Degeczi
nagyúr
válasz vampire17 #43524 üzenetére
Igen: "A Fisher egy nagyon jó és megbízható márka- volt régen. Egy jó ideje OM gyártmányként csak a márkanév maradt meg, a klímát magát egy ideig a Midea, majd jelenleg a Gree vette át gyártásban. A minősége emiatt rendkívül hullámzó, az alapmodelleket nem is szoktuk ajánlani. Több darabot cseréltünk már csörgő- zörgő kültérik miatt és a hazai képviselettel igazi közelharcot kellett vívni minden egyes garanciális ügyintézésnél"
-
Degeczi
nagyúr
válasz Primary92 #43529 üzenetére
Mert rossz névre hivakozol: a szenzornak
sensor.autotolto_uzemmod
nevet adtál, nemsensor.tolto_uzemmod
-ot... (a unique_id nem entitásnév)Ezt rögtön látod, ha a fejlesztői eszközök / állapot alatt végignézed milyen szenzorjaid vannak, ill. minden hasonlót mindig a fejlesztői eszközök / sablon alatt érdemes kipróbálni, az erre van!
Ott is látod, h ha beírsz egy{{ is_state('sensor.tolto_uzemmod','65') }}
-ot, az False eredményt ad majd, hiszen nincs ilyen szenzorod.Amúgy ettől eltekintve jó.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz v.attis #43579 üzenetére
Persze, az after-before feltételek itt fölöslegesek, semmi szerepük. Hasonlóképp a mode-nak sem, hiszen a fix időpont miatt garantáltan csak egyszer tud elindulni az automatizálás (mode-ra pedig csak ott van szükség, ami egymásra futhat többször is, mert vmi előre megjósolhatatlan pillanatban bekövetkező esemény okozza)
Ja, és az ilyen generált entitásokat mindig érdemes vmi beszédes nevűre átnevezni
[ Szerkesztve ]
-
Degeczi
nagyúr
YAML nem igazán, mert áttekinthetetlen. Pl. Appdaemon alatt Pythonban tökéletes, de ha a Node-red feszik jobban, persze abban.
Célszerű a szenzor friendly nevét lekérdezni, és azt TTS-el be is lehet jelenteni mondjuk hazaérkezéskor, másrészt bizonyos típusok elemszint visszajelzése megbízhatatlan, ezért célravezetőbb azzal is kiegészíteni, h ahol ez megoldható (mérőeszköznél simán, nyitásérzékelőnél vagy nyomógombnál persze nem) azt is figyelni, mikor változott utoljára az értéke (last_changed attribútum). Sajnos régi HA nyűg, h ez újraindításoknál resetelődik, de itt úgyis csak arról van szó, h mondjuk 2 órája teljesen, tizedre változatlan hőmérséklet elképzelhetetlen, az pedig szépen detektálható.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz v.attis #43634 üzenetére
A Miio csak az elérési tokenek kinyerése miatt (évekkel ezelőtt ezt neked kellett manuálisan megszerezned pl. telefonos alkalmazás bizonyos verziójából, nem volt praktikus) igényli a felhőt, egyébként lokálisan kezeli az eszközöket. Természetesen ettől még léteznie kell az adott eszköznek Mi Home alatt, hiszen ott van beállítva a wifihez kapcsolódás is, ott kapta meg ezt az elérési kulcsot is, de attól kezdve többet el sem kell indítanod a Mi Home-ot.
A Yeelight integrációnak még erre sincs szüksége, ott nincs ilyen token, csak a lokális elérést kell egyszer engedélyezni (még fw frissítés előtt, mert az kiütheti ezt az opciót!) -
Degeczi
nagyúr
válasz v.attis #43637 üzenetére
Természetesen tudod saját dongle-vel kezelni a Zigbee eszközöket, azokhoz sem kell a Xiaomi Gateway, a jövőben vásárolt Xiaomi Zigbee cuccokhoz sem (wifishez meg persze eleve nem), párosíthatóak saját koordinátorhoz is. BT-t nem használok, de arról ketten is írtak neked, ahhoz sem kell.
-
Degeczi
nagyúr
válasz v.attis #43701 üzenetére
Késleltetést csak rövidet célszerű használni, ennyire hosszút nem, mert idővel biztosan elő fog fordulni abban a 3 órában újraindítás és akkor sosem fut le a kikapcsolás. Második automatizálás ami üzembiztos módszer.
Másrészt ha munkanap lefutó folyamat a cél, akkor arra jobb "munkanap" szenzort használni, hiszen lesznek hétköznapra eső ünnepek, amikor nem kell fusson.
-
Degeczi
nagyúr
válasz v.attis #43703 üzenetére
Manuális kapcsolás persze működik mindig, az időzítés ami elvész újraindítás során.
A gyári munkanap szenzor. Hozzáadod az integrációknál (esetleg a felületén hozzáadod az ismert szabadságolási napjaidat), és már van is egy
binary_sensor.workday_sensor
, ami "on" értékű munkanapokon, ezt célszerű ilyen automatizálás feltételeként használni. -
Degeczi
nagyúr
válasz vampire17 #43714 üzenetére
Vmi HA felületi nyűg lehet, mert az utóbbi hetekben többször észrevettem, h a böngészőablak néha nem scrollozható az oda visszakapcsolás után, pedig nálam kb. 3 képernyő magas a fő oldal. Ráfrissítek, már megjelenik a scroll. Ilyen korábban nem volt.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz v.attis #43736 üzenetére
Ezzel sajnos nem tudsz mit kezdeni, sütikben tárolja a beállításaidat (max. valóban a cookievédelmet), és nem a szerveren. Asszem van is ilyen feature request, h szerveren legyenek userfüggő beállítások, és a kliensen az legyen az alapértelmezett, de nincs hír, h lenne változás ebben.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz enginev3.0 #43744 üzenetére
Bizonyos kameráikra lehet tenni egyedi firmware-t, azok jól integrálhatóak.
-
-
Degeczi
nagyúr
válasz vampire17 #43813 üzenetére
Miért nem automatizáció? A blueprint is az, egy fölparaméterezett, fool-proof automatizáció.
Egyébként ezt Appdaemonnal lehet áttekinthetően kezelni, közös kóddal minden gombhoz, megadva melyik gomb melyik redőnyhöz (vagy csoporthoz) tartozzon, hogy ha mozgásban van egy redőny akkor megállítást jelent egy újabb gombnyomás, egyébként indítást, és ebben még az sem probléma, h relétől függően eltérő a mozgás visszajelzése (a Shelly-k közvetlenül az entitásuk állapotában adják vissza, Zigbee-s kínai típus egy "moving" attribútum alatt, és az sem egységes, hogyan: egyik pl. "UP"-ot és "DOWN"-t, másik meg "closing" és "opening"-et. Nem baj, Pythonban szépen kezelhető)
-
Degeczi
nagyúr
válasz vampire17 #43868 üzenetére
A riasztó vezetékes mozgásérzékelőit használom minden szobában, ott nincsen cooldown, csak rövid impulzusokat adnak.
@4D4M: ha csukott ajtó mellett érzékelsz mozgást a WC-ben, akkor az foglaltságot jelent, ilyenkor egyrészt ezt jelezni lehet az ajtó fölé rakott tábla bekapcsolásával, másrészt a lámpát az ajtónyitásig nem szabad lekapcsolni, és máris megoldva a mozdulatlansági probléma. Persze valóban csak akkor működik, ha csukod az ajtót (de a tábla miatt zárni nem kell, vendégek esetén sem)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz csubuka #43882 üzenetére
Nem a végállást kell tudnia, hanem a fölhúzás időszükségletét kell bekalibrálni, amiből tudni fogja, kb. mennyi ideig kell ráadnia a feszültséget egy bizonyos pozíció eléréséhez. Nincs szó tehát semmilyen érzékelésről, csak sacc (és "optimistic") alapon megy.
Ebben a kalibrálásban az tud segíteni, ha a relé végez teljesítménymérést, mert akkor automatikusan is el tudja ezt a kalibrációt végezni (hiszen a végállásban leesik nullára a redőny teljesítményfölvétele - de az megintcsak tökmindegy, milyen módon kapcsolt ki a motor), mint pl. a Shelly 2.5 - bár az is hiába végzi el ezt magától, a fejlesztők magasról tesznek a felhasználók évek óta hangoztatott kéréséről, h ezt lehessen korrigálni, mivel érthető módon ez nem lineáris folyamat (hiszen fölhúzásnál az első pár motorfordulat még csak az összetorlódott lamellákat kezdi széthúzni, még nem indul meg a redőny) amitől teljesen fals a pozíció, redőnyhosszúságtól függően pl. valahol 65% környékén van a tényleges fél-pozíció.
Teljesítményt nem mérő relénél ezt kézzel kell elvégezni, de az sem vészes és csak egyszer kell megtenni.@vampire17: teljesítményfölvételt mér a Shelly 2.5, fesz esés (valójában amúgyis emelkedés lenne végállásban) erre nem volna megbízható.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz HUNited #43938 üzenetére
Egyedi firmware-rel (főként Tasmota, ESPHome, ESPEasy) bármit meg lehet oldani - de egyrészt a mai típusok már gyakran olyan chipet használnak ami ezzel nem kompatibilis, másrészt ez igazán akkor futja ki magát, ha komolyan gondolod az okosotthont, és van saját szervered.
Mivel itt szinte mindenki ezt teszi, a gyári alkalmazással csak nagyon keveseknek van tapasztalata.
Új hozzászólás Aktív témák
- AKCIÓ! Okos otthon és biztonság - BOLTI ÁR FELÉÉRT!
- Gyönyörű autómatricák azonnal gyors országos kiszállítással! PH-soknak 30% kedvezmény!
- Autómatrica és prémium minőségű matricák PH tagoknak 30% kedvezménnyel!
- Visszapillantó matricák a legjobb minőségben! PH tagoknak 30% kedvezménnyel!
- Eladó-Kiadó ingatlan táblák , hogy sikeres legyen az eladás! PH tagoknak 30% kedvezménnyel!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs