-
Fototrend
Okos Otthon összefoglaló:
Új hozzászólás Aktív témák
-
-
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz
LouiS22
#39912
üzenetére
De ahogy nézem, azok csak az értelmezéshez egyszerű szövegek, amit amúgyis bárki össze tud hozni saját scriptekben.
Ami ténylegesen fontos lenne, az egy magyar speech-to-text megoldás, ami nem tudom, lokálisan mivel fog menni, milyen lesz a minősége + mekkora hardvert igényel majd elfogadható feldolgozási időkhöz (átlagos, kisfogyasztású otthonvezérlő gépen még a jó minőségű lokális TTS is túl lassú, pedig az sokkal egyszerűbb feladat...)
Valszeg jobban járunk, ha az marad felhős, és pl. a Google szolgáltatása (úgy látom, havi egy óra ingyenes) kapja meg a feldolgozandó hanganyagot. A legjobbabb meg az lenne, ha a Google eszközök lennének képesek közvetlenül erre, a saját rendszernek átadni a hallott magyar szöveget, hiszen különben még az érzékelő hardvert is meg kell oldani valahogyan (kellően érzékeny, jó minőségű mikrofonokkal, nem túl nagy fogyasztással - és még túl ronda se legyen)
-
Degeczi
nagyúr
válasz
FMarci
#39823
üzenetére
Can-bust tudtommal csak régi Junkersek használtak, a Bosch kazánok talán egyetlen kivétellel (az is Openthermes) már EMS bus-t használnak, a 2500W is rajta van az itt sokat említett EMS ESP kompatibilitási listáján. Ahhoz könnyen összerakható illesztő, próba nyákhoz készített tervet is raktam be itt korábban, de az csak a meglévő rendszert kapcsolja okosotthonhoz, fűtésvezérléshez ettől még szükség van vmilyen gyári termosztátra.
-
Degeczi
nagyúr
válasz
q13579
#39749
üzenetére
A Dilbert66 oldalán lévő optós kapcsolást 3 érzékelőbemenettel kiegészítve itt egy terv amit az alapján csináltam úgy, h könnyen össze lehessen huzalozni egy forrszemes próbanyákon.
Amit az ESPHome-ról tudni kell, azt gyorsan föl lehet szedni a projekt oldalán, a DSC riasztóról pedig a privátban említett két topikot (1, 2) célszerű átolvasni és persze az adott típus telepítési leírását, nálad ezt.
Elsőre biztosan nem egyszerű, rejtvényfejtés jellegű a dolog - de mindenképpen érdemes rászánni az időt, nagy sikerélmény.
Szerk: most látom, h az itteni beírásaid alapján valszeg nem foglalkozol Home Assistanttal, így az első eldöntendő kérdésed az, ebbe belefognál-e. Ha ez nem téma a jövőben sem, akkor csak a sima DSCKeybusinterface jöhet szóba, mert abból fordítható olyan változat, ami önmagában, webes interface-el is használható, míg az ESPHome fork kimondottan csak Home Assistanthoz illesztéshez való (de ahhoz nagyon)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
LLKobe
#39740
üzenetére
Pl. Accuweather integráció esetén így nézi ki az előrejelzés:
Ami itt a szenzor "forecast" attribútumában érhető el, tömb formában, adott napnyi távolságra indexelve, azon belüli tömbből pedig a 'templow' lekérdezve, pl. a vasárnapot (ami most 3 napnyira van) így:
{{ state_attr('weather.otthon', 'forecast')[3]['templow'] }}
ami a képen látható -5.4-et adja vissza.De ez minden időjáráselőrejelző integrációnál más és más, mindenesetre teljesen hasonló szokott lenni.
-
Degeczi
nagyúr
válasz
nimfas
#39680
üzenetére
Sokunknak van Blitzwolf/Gosund dugalja - de nézd meg a topik címét... okosotthonba integrálva a kérdés sem merül föl, mert nem használod a gyártói idétlen felületet (jellemzően még a firmware-t is lecserélve), saját vezérlésed van mindenhez. Ezért nincs tapasztalat ezzel.
-
Degeczi
nagyúr
válasz
q13579
#39667
üzenetére
Igen, az a legkisebb (négyzónás) Powerseries panel, a régebbi, MQTT alapú DSC Keybusinterface név szerint említi is kompatibilisként. Ezzel együtt HA alatt érdemesebb rögtön a Dilbert66 féle ESPHome megoldással próbálkozni (átkapcsolva a "new" branchre!), kényelmesebb.
-
#39654
Degeczi
nagyúr
Pizzafutar
#39653
Degeczi
nagyúr
válasz
Pizzafutar
#39653
üzenetére
Nem, és jó eséllyel nem is lesz, hiszen az már titkosított kommunikációt használ. De az alábbi esetben aligha van ilyen típusról szó, ahhoz túl új.
-
-
Degeczi
nagyúr
válasz
joker2020
#39348
üzenetére
Lehet rákötni sima termosztátot, de akkor mitől tartozik ide a téma?
Ha sima, on-off rendszerű termosztát és okosítani szeretnéd, akkor mindenképpen olyan relé kell, ami dry contactos (tehát csak összezár két lábat a sorkapcson, nem pedig feszültséget ad ki) és van kapcsoló bemenete is, ahová a régi termosztátot bekötve megmarad az is, de távolról is felülbírálható, átkapcsolható.
Másrészt ha van a termosztát helyén nulla és fázis, vagy könnyen odavezethető, akkor egyszerűbb lehet eleve vmilyen wifis termosztátot fölrakni.
Illetve ahogy Vampire említi, első körben érdemes on-off helyett buszos termosztátot választani - de mintha régi FÉG kazánt írtál volna, ahhoz ez valszeg kiesik.
-
Degeczi
nagyúr
válasz
Primary92
#39280
üzenetére
A kompromisszumok közé manapság már erősen beletartozik a fogyasztás is, hiszen egy 24/7 folyamatosan üzemelő eszközről van szó, ahol nagyon nem mindegy, h mondjuk tizenpár W a teljesítményfölvétele, vagy annak többszöröse.
Ezért népszerűek pl. a HP T620-hoz hasonló minigépek, kis fogyasztással, nem drágán is megfelelő teljesítmény nyújtanak erre a célra. -
Degeczi
nagyúr
válasz
blackfly
#39256
üzenetére
Ezért is praktikus, ha van ezekhez egy-egy input_select pl. "üres", "mos", "készen" státuszokkal, az üzenetküldés triggere pedig az, ha ez "készen"-be megy át (aminek persze az a feltétele, h "mos" státuszban legyen, ÉS ekkor essen le a fogyasztás adott ideig egy küszöb alá. Ez pedig nem fog megtörténni újraindítás során, hiszen akkor mondjuk "üres" státuszban van)
-
#39254
Degeczi
nagyúr
szatocs1981
#39250
Degeczi
nagyúr
válasz
szatocs1981
#39250
üzenetére
Az is elfogadható, engem inkább zavarna 1 fok eltérés. Pl. a Xiaomi szenzorok jellemzően 1-2 tizeden belül vannak.
Másrészt 1C eltérés saccra simán okoz ekkora relatív páratartalom különbséget. -
Degeczi
nagyúr
válasz
LógaGéza
#39232
üzenetére
Igen, ez régi hiányosság, h nincs egy queue kezelésre képes médiajátékos szolgáltatás, és nyakatekert módon kell kezelni a helyzetet... A státusz eszköztől függően sajnos elég sokat tud késni, egymás után szorosan következő lejátszásokhoz (pl. figyelemfelhívó hangeffekt, majd rögtön utána a szöveg) nem mindig jó, ezért kínomban előre generáltatom le a TTS fileokat, amiknek Appdaemon alatt Pythonban már könnyen meg lehet nézni az időbeli hosszát, és beidőzíteni a közben beérkező lejátszási igényeket az utánra.
De ennél sokkal jobb és egyszerűbb lenne egy beépített queue. -
Degeczi
nagyúr
válasz
amargo
#39204
üzenetére
Nincs napelemem, ezért nem tudom, csak érdekel: ha van mondjuk egy 6 kW háromfázisú rendszered, akkor abban fixen ki van osztva, h fázisonként 2 kW-ot tud (és mondjuk csak az egyik fázist 3 kW-al terhelő fogyasztó esetén 1 kW a hálózatból jön szép időben is) vagy képes dinamikusan kezelni ezt? Vagy az invertertől függ?
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
radio11
#39180
üzenetére
Már a feszültség is bármi lehet kb. 220-250V közt ami már önmagában is elég nagy eltérést okoz, másrészt ha nincs meg a teljesítménytényező, a tisztán ellenállás-jellegű fogyasztókat leszámítva végképp használhatatlan az eredmény, hiszen kapcsolóüzemű tápoknál akár 0.3 is lehet ez.
-
Degeczi
nagyúr
válasz
LLKobe
#39142
üzenetére
De miért thermostatot mondasz? Adj nekik eltérő nevet, pl így expozálva a Gugli Home felé két climate eszközt, és akkor egyértelmű, h az "air conditioning"-ot vagy a "heating" hőfokát, üzemmódját akarod állítani (és még aliast is lehet adni):
google_assistant:climate.gree_hvac:name: air conditioningaliases:- climateexpose: trueroom: Living roomclimate.gas_heating:name: heatingaliases:- heaterexpose: trueroom: Living room[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
Olympia76
#39130
üzenetére
Az valóban bug-szagú, ill. valszeg egyelőre megkerülhetetlen feature. Hasonló gond, h egy eszköz állapotváltozásába is beleszámít az unavaliable, ami miatt min. az utolsó rendszerindítás dátumát veszi föl, korábbi nem lehet.
Így pedig hiába teszed ki a felületre "secondary info"-ként a "last_changed"-et, az nem mindig valós. Pl. ezek közül sem a padláson, sem a fészerben nem jártunk 3 napja, csak akkor volt az utolsó újraindítás:
Van erről régóta ticket, de a rendszer alapvető problémájával magyarázzák a fejlesztők, h mellékhatás nélkül nem tudnának változtatni rajta, ezért inkább nem teszik.
-
-
-
Degeczi
nagyúr
válasz
Olympia76
#39060
üzenetére
Főként a HA-ból időzített bekapcsolásra gondolok, pl. amikor indul egy F1 időmérő vagy futam. Ehhez csak a TV-t kell bekapcsolni, a megfelelő csatornára és hangerőre állítani. Amíg nem volt rezsicsökkentés-csökkentése, végig a TV integrációján keresztül, azóta infrával bekapcsolva, majd huszonpár mp késleltetés után már az integráción át kiadva a hangerőbeállító, TV adásra és csatornára átkapcsoló parancsokat.
-
Degeczi
nagyúr
válasz
Olympia76
#39053
üzenetére
Hmm, ez nem is rossz ötlet, látom van ESPHome-hoz is CEC megoldás... de nálam mindegy: bevált infrával is, és akárhogyan is van indítva offline módból, kell kb. fél perc a TV integrációjának, h meglássa, csak utána lehet azon keresztül parancsokat kiadni (mint konkrét hangerő-érték, elindítandó alkalmazás, stb)
-
-
Degeczi
nagyúr
válasz
ratkaics
#39041
üzenetére
Amíg még teljesen üres DB-be kezded visszatölteni, legelső alkalommal, addig persze nincs jelentősége a DROP TABLE-nek, hiszen nincs törlendő tábla. Mindenesetre az a szokás (és pl. a parancssori mysqldump is úgy generál mentést), mert jellemzően már létező adatbázist vágunk fölül a visszatöltéssel, és ott kell a törlés, szóval jobb, ha ki van pipálva az is.
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz
ratkaics
#39038
üzenetére
Persze: más táblában is várható hasonló nyűg, és igen, az indexeket is létre kellene hoznod.
Ezért inkább arra kellene rájönnöd, miért nem lett jó az adatbázis visszatöltése, és azt helyretenni.
Parancssorból lenne jó visszatölteni, h lásd a hibaüzeneteket - mert vmi csak kellett legyen.
Az alacsonyabb verzióra visszatöltés nem szerencsés, de amire próbálod, az nem túl régi, egy éves verzió, mennie kellene.
Ha belenézel a mentésbe, egyszerű (csak nagy) szövegfile: először drop table paranccsal törli az adott táblát, majd create table-el létrehozza. Már ez tartalmazza az AI és primary key beállítoskat, itt mehet vmi félre. Min. egy ilyen részt ki kellene másolni és kézzel futtatni, mit üzen rá. -
Degeczi
nagyúr
válasz
LouiS22
#39027
üzenetére
Igen, ill. némelyik okostévé is hajlamos a szokásos, bőven 1W alatti helyett akár 15W körüli készenlétre, ha engedélyezve van a wifin/hálózaton keresztül ébresztés. Másrészt OLED TV bizonyos üzemóránként a készenlétbe lekapcsolás után pár perccel fog bele a kijelzőfrissítésbe, ezért azoknak nem is tenne jót egy rendszeres áramtalanítás rögtön a használat után.
-
Degeczi
nagyúr
válasz
ratkaics
#39000
üzenetére
Nem kell máshogyan fölrakni, csak régen tehetted föl, mert még februárban írták, h átköltözik olyan helyre, ami alapban minden új HA installáció része lesz, és a régi ("Community Addons") repóban nem frissítik tovább, csak ott lett deprecated.
Amúgy ez az Addon csak opcionális, csak az eszközökre történő kényelmesebb telepítésre szolgál, a HA integráció enélkül is sima ügy, ha máshogyan, pl. saját gépen programozod föl.
-
Degeczi
nagyúr
válasz
zsamiatt
#38963
üzenetére
Nálam egy mezei szünetmentes téglán van az okosotthonvezérlő HP T620, a net (szolgáltatói router, wifi-AP-k, switch, NAS) ez bír kb. 40 percet. Ha ez leállt, onnantól számomra már mindegy, nem kell kapcsolat a riasztóval. Az elején persze kapok értesítést a táp-problémáról, ill. ha ezen az időn belül visszajön az áram, arról is.
-
Degeczi
nagyúr
válasz
Degeczi
#38955
üzenetére
Ahhhha, kinyitva a fészerajtót valóban ott a naplóban a "Secure system" üzenet, és amíg nyitva van, valóban elérhetetlen a riasztó HA-s kezelőpanelje. Mondjuk annyiból jogos, h ilyenkor úgysem lenne élesíthető. Eddig föl sem tűnt, mert ebben a szutyok időben akár hetekig sincs nyitva a fészer, ESPHome-ra meg nemrég tértem át.
Ha @Olympia76 nálad is főként benti zónák vannak, szerintem állítsd át azokat force armable-ra, és akkor nem lesz unavailable státusz (meg eleve így logikus: attól még tudd beélesíteni, ha még mozgás van odabenn, vagy nyitva pl. a bejárati ajtó, mert vki már ott áll)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
Olympia76
#38958
üzenetére
Szerintem több szempont miatt is jobb az okosotthon szünetmenteséről táplálni a riasztóillesztőt:
- nem terheli a riasztó panelt és főként annak akkuját - márpedig nem kicsi egy ESP energiaigénye, ami nem elhanyagolható módon csökkenti a riasztó akkus üzemidejét
- de miért is tenné? Hiszen az okosotthon áthidalási ideje sokkal kisebb: jellemzően fél-egy óra, és mire az végetért, már nincs is jelentősége a riasztóillesztőnek, mert nincs kivel kommunikáljon tovább! A riasztó pedig önmagában fél-egy napig üzemelne akkuról - és ezt csökkenti jelentősen egy onnan táplált ESP...
- különösen pont a riasztó esetén biztonságosabb is az optocsatolós illesztés, hiszen itt nagy a villámcsapás miatti túlfesz esélye (nekem pár hónapja ki is vitte a riasztóközpontot - és így az egyik optocsatolót is, de a galvanikusan elválasztott ESP persze megúszta)Ezért váltottam idén külső USB táplású optós illesztésre, a Dilbert66 repóban látható kapcsolást megtervezve próbapanelen. Pont nem sokkal a hozzászólásod előtt osztottam meg ugyanabban a topikban, még látni is a képen a villámcsapás miatt kicserélt optót. Persze, nem olyan szép mint egy legyártatott PCB, de ez hol érdekel amikor az egész egy műanyag kötődobozban van benn a kamrában? Cserében bármit kijavítok rajta, pl. a megsült optóval próbálkozáshoz is csak nyolclábú foglalatom volt itthon, de egy próbapanelen ez sem gond.
Nemrégiben aztán ezen tértem át ESP Home-os kódra, főként a rajzon látható 3 extra csatlakozás miatt, amivel ki tudtam váltani nem kritikus nyitásérzékelést (mint a postaláda vagy a spájzajtó) az ESP szabadon maradt lábaihoz, drága DSC bővítőpanel helyett.
-
Degeczi
nagyúr
válasz
Olympia76
#38939
üzenetére
Ill. sejtem, mi lehet!
Nálam a távozási élesítés "goodbye" hangparanccsal indul - ami azonban azzal jár, h még mozgok a nappaliban, majd ezután nyitom a nappali ajtót, a párom már lehet, h nyitja a kaput, tehát van egy rakás nyitott zóna, ezért persze mindet "force armable"-ként vettem föl, hiszen máskülönben blokkolnák az élesítést bypass nélkül.
Mivel minden zónaérzékelés így történik, valszeg ezért nincs nálam az alábbi jelzés, csak sima "zone open" -
Degeczi
nagyúr
válasz
Olympia76
#38939
üzenetére
A Dilbert66 féle kódon pedig mindössze ennyit változtattam saját forkban, h ne írja bele a szövegbe a partíciósorszámot, ill. a Stay zones open helyett magyar Zónaérzékelés szöveg legyen a panelon. Minden más változatlan a new branchez képest.
Esetleg ez alapján még arra gondolok, h nálad esetleg nem "stay"-típusúként vannak definiálva a zónák. Nálam a mozgásérzékelők mind azok, 5-ös kódúak, mert azok mellett lehet éjjelre otthonmaradó módban élesíteni, hiszen azok olyankor érzékelhetnek mozgást, csak a bejárati ajtó vagy kapu nem.
De mondjuk valszeg ezen sem múlik, mert néha persze azokat is nyitom, az előzményekben azonban olyankor sem lesz unavaliable a riasztó. -
Degeczi
nagyúr
válasz
Olympia76
#38939
üzenetére
Nem tudom, miért van ilyen állapotban a riasztód. Nálam csak a zöld ready világít a kezelőn, és sosincs a logban "Secure system before arming", így unavaliable sem...
Pl. egy mozgás esetén is csak annyit jegyez meg, h nyitva egy zóna, de ettől még marad "System is ready, ready to arm":
[19:04:08][D][text_sensor:067]: 'dscalarm line1': Sending state 'System is Ready'[19:04:08][D][text_sensor:067]: 'dscalarm line2': Sending state 'Ready to Arm <>'[19:04:08][D][info:1779]: status 01, last status 01,line2status 00,selection 01,partition=2,skip=0[19:04:08][D][text_sensor:067]: 'dscalarm line1 partition 2': Sending state 'System is Ready'[19:04:08][D][text_sensor:067]: 'dscalarm line2 partition 2': Sending state 'Ready to Arm <>'[19:04:08][D][binary_sensor:036]: 'Motion kitchen': Sending state ON[19:04:08][D][text_sensor:067]: 'dscalarm zone status ': Sending state 'OP:5,OP:11,OP:18,OP:20'[19:04:08][I][Moduledata::976]: 11: FF 01 0F FF 0F FF FF FF FF 03 00 00 00 00 00 00[19:04:08][I][Paneldata: :976]: 11: 11 00 AA AA AA AA AA AA AA 02 00 00 00 00 00 00[19:04:09][I][Paneldata: :976]: C3: C3 00 00 FF C2 00 00 00 00 00 00 00 00 00 00 00[19:04:10][I][Moduledata::976]: 05: FF 01 FF FF DF FF FF FF FF FF 01 00 00 00 00 00[19:04:10][I][Paneldata: :976]: 33: 33 00 FF FF FF FF FF 00 00 00 00 00 00 00 00 00[19:04:10][I][Moduledata::976]: 33: FF 01 51 11 FF FF 8F 00 00 00 00 00 00 00 00 00[19:04:10][I][Paneldata: :976]: 34: 34 00 81 02 81 01 02 3B 00 00 00 00 00 00 00 00[19:04:10][D][info:1779]: status 02, last status 02,line2status 00,selection 01,partition=1,skip=0[19:04:10][D][text_sensor:067]: 'dscalarm line1': Sending state 'System is Ready'[19:04:10][D][text_sensor:067]: 'dscalarm line2': Sending state 'Ready to Arm <>'[19:04:10][D][info:1779]: status 01, last status 01,line2status 00,selection 01,partition=2,skip=0[19:04:10][D][text_sensor:067]: 'dscalarm line1 partition 2': Sending state 'System is Ready'[19:04:10][D][text_sensor:067]: 'dscalarm line2 partition 2': Sending state 'Ready to Arm <>'[19:04:10][D][binary_sensor:036]: 'Motion nappali2': Sending state OFF[19:04:10][D][text_sensor:067]: 'dscalarm zone status ': Sending state 'OP:5,OP:11,OP:18'[19:04:11][I][Moduledata::976]: 05: FF 01 FF FF BF FF FF FF FF FF 01 00 00 00 00 00[19:04:11][I][Paneldata: :976]: 28: 28 00 FF FF FF FF FF 00 00 00 00 00 00 00 00 00[19:04:11][I][Moduledata::976]: 28: FF 01 55 45 FF FF 3F 00 00 00 00 00 00 00 00 00[19:04:11][I][Paneldata: :976]: 2D: 2D 00 81 02 81 01 00 32 00 00 00 00 00 00 00 00[19:04:11][D][info:1779]: status 02, last status 02,line2status 00,selection 01,partition=1,skip=0[19:04:12][D][text_sensor:067]: 'dscalarm line1': Sending state 'System is Ready'[19:04:12][D][text_sensor:067]: 'dscalarm line2': Sending state 'Ready to Arm <>'[19:04:12][D][info:1779]: status 01, last status 01,line2status 00,selection 01,partition=2,skip=0[19:04:12][D][text_sensor:067]: 'dscalarm line1 partition 2': Sending state 'System is Ready'[19:04:12][D][text_sensor:067]: 'dscalarm line2 partition 2': Sending state 'Ready to Arm <>'[19:04:12][D][binary_sensor:036]: 'Motion kitchensink': Sending state OFF[19:04:12][D][text_sensor:067]: 'dscalarm zone status ': Sending state 'OP:5,OP:18'Mondjuk két partícióm van a DSC 1864-en, de nem hiszem, h ezen múlna bármi is.
-
Degeczi
nagyúr
válasz
Olympia76
#38936
üzenetére
Vmi a központoddal furcsa, mert a "Secure system before arming" üzenetnek nincs helye egy normál, nem élesítésre váró állapotban... ilyenkor nekem ebben az ESHome logban sincs unavailable. Próbáld a kezelőn beélesíteni, majd hatástalanítani, hátha attól visszakerül korrekt helyzetbe.
-
Degeczi
nagyúr
Az másfajta, nem kritikus adathoz jó. Itt azonban a fő kulcsról van szó, ami mindenképpen egyedi értéket kell kapjon soronként, de ezt persze nem is kell az insert parancsban megadni, hiszen az adatbázis-kezelő feladata ezt kitölteni: akár mert auto_increment van a mezőn, akár mert a táblába beszúrásra van trigger ami allokál növekvő értéket egy sequence-ből.
MySQL/MariaDB esetén az előbbit használják, tehát a mezőnek auto_increment id-nek kell lennie, és akkor nincs hiba.
-
Degeczi
nagyúr
válasz
ratkaics
#38908
üzenetére
Miért nem azonos verzióra? Újabbra még ok lehet (bár egy fő verzió váltás esetén ott is lehetnek nyűgök), de régebbire visszatöltésnél eleve nagyobb az esélye hibának...
Mindenesetre a recorder_runs tábla stuktúráját nézd meg, és a run_id-t állítsd auto_increment-es id-re, olyan induló értékkel, ami nagyobb a jelenlegi max értékénél, az meg kell oldja - de ha ezzel gond van, máshol is lehet még baj...
-
Degeczi
nagyúr
válasz
ViZion
#38892
üzenetére
Out of milk, online, megosztott lista (alkalmazásban és weboldalon egyaránt kényelmesen szerkeszthető) évek óta elégedetten használjuk. Mindenki hozzáadja amikor eszébe jut, mi van fogytán, mi kellene, és mivel közös lista, bármelyikőnk van vásárolni, egyetlen érintéssel lehúzza róla, amit megvett.
Az az egy kár, h a vonalkód adatbázisa csak központi, hozzáadni nem lehet, márpedig főként csak amerikai termékeket ismer (és kényelmes lenne a fogyóban lévő cucc vonalkódját scannelni névbeírás helyett) - de amit egyszer szövegesen beírtál, az legközelebb már cache-ből jön, nem kell ismét beírni.[ Szerkesztve ]
-
Degeczi
nagyúr
-
-
Degeczi
nagyúr
-
Degeczi
nagyúr
válasz
zambozoli
#38763
üzenetére
Ha egy sorban van a template kifejezés az előtte álló kulccsal, akkor tedd aposztrófok közé (itt dupla macskakörömmel, hiszen szimplát már használsz a kifejezésben)
Vagy ha széttöröd egy következő sorba úgy, h atime:után>-írsz, akkor ez nem kell.És mindenképpen rakd föl a Studio Code addont, azzal az ilyen hibákat rögtön, syntax highlightként látod!
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
radio11
#38755
üzenetére
Föltéve, h nem Égáz-Dégáz... FB csoportban kapta vki ezt a választ tőlük (ami persze vicc, hiszen a nyitásérzékelőben is ugyanolyan reed-érzékelő van mint a gyári megoldásban és természetesen bármiféle szikra elképzelhetetlen és nem zavarhatja meg a mérőórát sem - de ez van, ők diktálnak):
"Az ön által megadott link, egy ajtó/ablak nyitás (biztonsági) érzékelő leírását tartalmazza.
A leírás szerint az érzékelő jelet küld a telefonra ha valaki kinyitja az ajtót, esetleg ablakot.
Az órába épített mágneses (impulzus) jeladó megfigyelésére az ön által megadott eszköz alkalmatlan, robbanásbiztos szempontból (nem gyújtószikramentes kivitelű) akár veszélyes is lehet a gázrendszerek közelében, illetve zavart is okozhat a gázmérő számláló szerkezetének működésében.A „Mi Window and Door Sensor” használata a gázfogyasztás monitorozására alkalmatllan és nem megengedett!
Törvényi előírás alapján jelenleg Társaságunknak a 10 m3/h névleges teljesítménynél nagyobb névleges teljesítményű gázmérők távleolvasására van kötelezettsége.
Távlati terveinkben szerepel az ennél kisebb teljesítményű gázmérők távleolvasása is – például a lakossági felhasználóknál felszerelt gázmérők távleolvasása az „okos otthon” projekt keretében - de jelenleg még nincs döntés, hogy mikortól, milyen technikai megoldást fogunk alkalmazni és milyen forrásból. Amennyiben ez megvalósul, akkor a lakossági felhasználóknak is elérhetővé fogjuk tenni a távleolvasott gázmérési adatokat.
Mindaddig egyedi igény alapján, bizonyos feltételek teljesülése esetében Társaságunk engedélyezheti a gázmérők felhasználó által történő távleolvasását.
Amennyiben saját költségén meg kívánja valósítani a mérési adatok gyűjtését, akkor be kell szereznie a felszerelt gázmérőtípus gyártója által gyártott impulzus jeltovábbító elemet, amit az alábbi feltételekkel lehet csatlakoztatni a felszerelt gázmérőhöz:
- Engedélyünket írásban kell megkérnie társaságunktól.
- Hozzájárulásunkat azzal a feltétellel adjuk, hogy egy esetleges mérőcsere során nem garantáljuk a jelenleg felszerelt gázmérővel azonos gázmérő típus biztosítását, ami esetleg a gázmérő jelenlegi impulzus kimenet csatlakozás kialakításának változásával is járhat. Ebben az esetben az impulzus jelfogadó-továbbító elem cseréje az Ön költsége.
- Hozzájárulásunkat csak addig biztosítjuk, amíg egy esetleges törvényi előírás nem kötelezi Társaságunkat az érintett fogyasztási helyen felszerelt gázmérő Társaságunk által történő távleolvasására. Ebben az esetben is természetesen nyitottak leszünk olyan műszaki megoldás megtalálására, amely az Ön mérésadatgyűjtése felé is biztosítja az impulzus kiadást.
- A jelenleg felszerelt gázmérőhöz csatlakoztatható impulzus jeltovábbító elem beszerzése az Ön költsége.
- A jelfogadó-továbbító elem felszerelését és a gázmérőhöz történő csatlakoztatását – az Ön megrendelése és Társaságunk díjjegyzéke alapján - kizárólag Társaságunk szerelője végezheti.
- A jelfogadó-továbbító elemnek gyújtószikramentes kivitelűnek kell lennie."[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
Gabail
#38708
üzenetére
Az energy panel a napi-, azon belül is az óránkénti fogyasztásra van kihegyezve.
Ha viszont kézzel írogatod és kihagysz pár napot (ami biztosan előfordul) akkor hirtelen jelenik meg a következő följegyzési napon az egész időszak fogyasztása (ahogy addig is, a fölírás órájában az előző napé). Persze a havi nézet ettől még nagyjából jó lehet. -
#38599
Degeczi
nagyúr
Fuser és Tsa
#38590
Degeczi
nagyúr
válasz
Fuser és Tsa
#38590
üzenetére
írja pedig, h a configuration.yaml 14. sorában a bibi, ott húzhat be vmit amiben float a data_type
-
#38587
Degeczi
nagyúr
Fuser és Tsa
#38586
Degeczi
nagyúr
válasz
Fuser és Tsa
#38586
üzenetére
Ne a kötőjel alá húzd ki, hanem szóközt tegyél a - és a name: közé, ahogy a 38584-ben írtam. Ez a listák konvenciója yaml-ben. Így a name:-el azonos oszlopon kezdőhetnek a hozzá tartozó sorok, ami áttekinthetőbb.
-
#38584
Degeczi
nagyúr
Fuser és Tsa
#38583
Degeczi
nagyúr
válasz
Fuser és Tsa
#38583
üzenetére
Talán az indentálásával van baj. De miért nem csinálod egyszerűbben, áttekinthetőbben?
A configuration.yaml-ben elég ennyi:
mqtt: !include_dir_merge_named mqtt/mqtt.yaml nem kell, az mqtt mappában pedig az mqtt_sensors.yaml-ed (bár lehet simán sensor.yaml is, hiszen a mappából már következik, h ez mqtt) pedig így kezdődik:
sensor:- name: update-padlas...hasonlóképp a switch.yaml is
switch:- name: akármi
és ugyanígy lehet light.yaml, cover.yaml, ... anélkül, h ezt külön lépcsőben definiálnod kellene. -
#38580
Degeczi
nagyúr
Fuser és Tsa
#38579
Degeczi
nagyúr
válasz
Fuser és Tsa
#38579
üzenetére
mqtt alatt nem sensors, hanem sensor a következő szint
https://www.home-assistant.io/integrations/sensor.mqtt/
(meg ugye a sensor: előtt nincs kötőjel, csak ide került vmiért?)[ Szerkesztve ]
-
Degeczi
nagyúr
A Dilbert66 féle ESPHome megoldással a virtual keypad nem jelent semmi eltérést, mert az csak egy HA Lovelace alatti javascript megoldás a felületre, az illesztőprogram változatlan marad.
Mondjuk ami igazán fontos, a kijelző két sora szenzorként is elérhető minden partícióhoz külön, de néha hasznosak a nyomógombok is, h ne kelljen odabattyogni egy kezelőhöz pl. hibastátuszt lekérdezni. -
Degeczi
nagyúr
válasz
Olympia76
#38501
üzenetére
Az nem ezen múlik, hanem a flash_write_interval opción. Alapban 1 perc, érdemes lehet nagyobbra állítani.
@TheProb: ezért említettem, h tényleges biztonsági felhasználás esetén kell mellé kiegészítés - egy lépcsőház nem ilyen, oda valóban elég lehet. Egyébként mindegy milyen a rádiófrekvenciás kommunikáció, a probléma a kártyaolvasó és a központ közti vezetékes kapcsolattal van.
-
Degeczi
nagyúr
válasz
icemad
#38495
üzenetére
5W nagyon sok lenne, jó esélllyel inkább pontatlan mérés lehet, mert jellemzően 1W alattiak, esetleg egy picit fölötte ha a relé be van húzva.
Szerk: ráguglizva ennél a típusnál sincs másként
Relay OFF : < 1 W
Relay ON: 1.2W-1.6W[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
Olympia76
#38491
üzenetére
Igen, a napi- (havi-, éves-) nullázódás elvileg nem akadály, hiszen utána ismét valós, aznapi a nulláról növekedés, az nem szabad, h meghülyítse az energia panelt.
Favágós sajnos, de megoldás.A DSC hagyományos, egyedi firmware-es (taligentx féle DSCKeybusinterface) stabilan megy, nekem sem volt gondom vele éveken át (ill. egyszer egy bugot találtam az egynél több partíció élesítésében, rögtön javította a srác), főként azért álltam át, mert
- a Wemos Mini 3 szabadon maradt lábát nyitásérzékelésre akartam használni, h a riasztón fölszabaduljon ezzel egy bővítőmodul. Ha egyedi firmware-t kell ehhez átírni, az nyűgös, pláne ha idővel módosítani is kell rajta (mivel az alap DSCKeybusinterface nem tesz lehetővé OTA frissítést). ESPHome alatt viszont egyszerűbb nem is lehetett volna: a yaml config file-jába beleírtam a 3 saját binary_sensor definíciómat, lefordítás, OTA update, és már meg is jelentek HA alatt az új szenzorok
- ha bármi miatt debugolni kellene, rá tudok kapcsolódni most is egyesphome DscAlarm.yaml logsparanccsal és máris látom az üzeneteit
- a Dilbert66 féle ESPHome-os megoldás "new" branchében még virtual keypad is van, ami ugyanúgy működik, mint egy LCD-s kezelő (ami nekem nincs, csak LED-es), rögtön látható rajta minden
- ugyanez emulálni is képes 5108-as bővítőt, így virtuális zónákat is hozzá lehet majd adni, amiket amúgy a HA kezel, viszont így át tud adni a DSC központnak. Nem kritikus, de jópofa, valszeg kipróbálom
- eleve tetszik, h az ESPHome yaml-ben minden már névvel és osztállyal (pl. nyitás-, füst-, probléma-) van definiálva, rögtön így jelennek meg HA alatt a szenzorok, nem MQTT topikokból kell kihalászni az infót
- rögtön magától kezel mindent jól, a hálózati tápellátás megszűnését is magától átadja egy ac_status szenzorban, míg a taligentx féle cucchoz nekem kellett ezt hozzáadnom, az nem foglalkozott ezzel. Nálam ez azért fontos, mert az áramszünetet is így, a riasztón keresztül érzékelem HA alattés biztosan van még más is, de engem nagyon meggyőzött, játszogatok azóta Tasmotás cucc ESPHome-osításával (persze abszolút nem égetően, jól működnek, csak a kíváncsiság hajt)
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
Olympia76
#38488
üzenetére
A hely azért számít nagyon, mert hiába végzel wear levelinget, sok mentéssel (ami egy fogyasztásmérőhöz kellene) nagyon hamar teleírod a teljeset, majd újra, és újra - míg el nem éri az élettartama végét. Mindegy, h csak pár byte az adat, ha a teljes hely is csak pár kB.
Ugyanezért nem célszerű kis SSD-t használni a rendszerhez sem, hiába lenne elég mondjuk 16 GB-os is, mert a gyakrabb teleírások miatt sokkal rövidebb az élettartama, mint pl. egy 128 GB-osnak.Eddig még nem állítottam át a cuccaimat, nálam is fönnál az, h ha kihúzok egy Tasmotás okoskonnektort, visszadugás után hülyeséget ír hozzá aznapra az energia panel. Mivel én is hajlok az ESPHome-osításra (a DSC riasztó illesztését is nemrég raktam át alá, nagyon bejött) és ott nincs napi-, havi- stb számláló, ezért ígyis-úgyis érdemes utility metereket rápakolni.
Az mondjuk igaz, h ezt illene magától kezelnie a HA-nak, a statisztikában is képes lehetne csökkenő érték figyelmen kívül hagyására, és akkor az energia panel sem mutatna fals adatot. -
Degeczi
nagyúr
válasz
TheProb
#38482
üzenetére
A legtöbb ilyen olvasó a Wiegand protokollt használja, ami annyira egyszerű és mindenféle biztonságot nélkülöző, h készen kapható a feltöréshez (lehallgatáshoz, visszajátszáshoz) összerakott eszköz... ld. demó videó.
Persze hozzá kell férni a vezetékeihez, de mivel az olvasót kívülről kell fölszerelni, az biztosan hozzáférhető, így olyat csak akkor szabad használni tényleges biztonsági célra, ha kap szabotázsvédelmet is, ami érzékeli a leszerelést és riaszt!
-
Degeczi
nagyúr
válasz
Olympia76
#38481
üzenetére
A fogyasztásmérőn sűrűn menteni nincs értelme, nagyon gyorsan tönkretenné a kicsi flash memóriát.
De a utility meter megfelelő: alapban figyelmen kívül hagyja a negatív változást, így kiszűri az áramtalanítás utáni visszakapcsoláskor visszatöltött teljes addigi, halmozott fogyasztás hirtelen (mintha aktuális lenne) megjelenését.
Igaz, leghosszabb az éves periódus benne, de egy ilyen után a nulláról kezdi ismét, vagyis az energia panelt nem zavarja össze, az jól jelzi a növekményt.
-
Degeczi
nagyúr
válasz
Kolondrum
#38293
üzenetére
Az udvar általában nem művelt terület, az érzékelő kábele pedig nem veszélyes, így bőven elég mondjuk 2 ásónyomnyi mélyen gégecsőben lefektetni a kábelt hozzá, egy hétvége alatt megvan.
Nekem a dupláját, 50 méteren felüli hosszban kellett beásni a kapuhoz nyitásérzékelő és csengő kábelét (és mivel maradtak benne szabad erek, később a postaláda is kapott nyitásérzékelőket), de az sem volt vészes, legalább a lezárás idején is volt egy kis testmozgás
Egy megváltás azóta, h teljesen megbízható az érzékelés, sokkal jobb mint korábban a 433 MHz-es megoldás volt.Ha építkeznék, mindenhová behúznék kábeleket, de mivel már adott volt a ház, a rengeteg ablakhoz, beltéri ajtóhoz persze nem véstem be utólag, oda praktikusak a Xiaomi Zigbee nyitásérzékelők, simán 2 évig is elketyegnek két elemcsere közt.
-
Degeczi
nagyúr
Nem ismerem, de a képeden látható szöveg szerint nem a fel és le nyilat kell nyomva tartani, hanem bármelyiket a kettő közül.
Gyakran amúgy egyszerűen csak azzal szokott gond lenni, h ugyanazon az SSID-n van az 5 GHz-es wifi is, mint a 2.4-es, márpedig az ilyen okoseszközök csak az utóbbit támogatják, ezért célszerű külön nevet adni annak. -
Degeczi
nagyúr
válasz
icemad
#38126
üzenetére
Pl. lakótelepen tökéletes, hiszen ott hideg időben folyamatosan kering a víz, így radiátor termosztáttal jól tudod szabályozni az érintett helyiség hőmérsékletét.
De saját gázkazánnal fűtve is így dolgozik sok gyári időjáráskövető megoldás, ott is jórészt folyamatos a víz keringetése, csak az előremenő hőfokán állítgat a rendszer.
Ami meg hagyományos szobatermosztáttal szabályzott, arra az áll, amit ViZion írt, normál esetben ott is dolgozik annyi ideig a fűtés, h a többi szobában lehet értelme fölrakni radiátor termosztátot. Ha meg vmiért nem a leghidegebb helyiségben van a fő termosztát, akkor segíthet az okosotthon, hiszen különösen on-off rendszert könnyedén tudsz indítani, befolyásolni ha fűtési igény lép föl valahol. De ehhez érdemes lehet lecserélni a fő szobatermosztátot integrálható típusra, ha nem olyan.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz
zsamiatt
#38112
üzenetére
Ez hogy lehet kérdés, ha ESPHome-ot használsz?
Ott az egész onnan indul ki, h egy xxx.yaml filera ráengeded a compilerét - és a Dilbert66 féle DSCKeybusinterface projekt (szigorúan a "new" branch, mert a master nagyon régi, elavult) leclone-ozott mappájában ott van ez a file, abban ezek a sorok, már csak át kell írnod a nálad érvényes pinekre. -
Degeczi
nagyúr
válasz
SafE84
#37928
üzenetére
Igen, a koordinátorra nem kényesek, routerre viszont annál inkább, nagyon megválogatják a Xiaomi érzékelők, mire hajlandóak csatlakozni. A legnagyobb gáz a Zigbee-vel részben ez, és főként az, h amikor kiesik egy router (mert pl. kihúzol egy okoskonnektort) akkor a végtelenségig, akár napokig is várnának mire rácsatlakoznak egy másik, elérhető routerre.
alatt van megadva minden
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest