- Rekordmagasba lökte az EPYC és a Ryzen az AMD-t
- Amlogic S905, S912 processzoros készülékek
- 2025-ben jöhet az Intel Panther Lake processzora
- Azonnali informatikai kérdések órája
- Vezetékes FÜLhallgatók
- A Frontier maradt a leggyorsabb szuperszámítógép
- Milyen TV-t vegyek?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Vezetékes FEJhallgatók
Hirdetés
-
Alig egy nap múlva végre bemutatkozik az Assassin's Creed Shadows
gp A Red kódnéven futó epizód végre a feudális Japánban fog játszódni.
-
Hamarosan bárki hazavihet egy Apple Vision Pro headsetet
it A Bloomberg szerint az Apple arra készül, hogy az USA-n kívül is piacra dobja a drága Vision Pro headsetet.
-
A Galaxy A54 és az A34 is megkapta a One UI 6.1-et
ma Európába is eljutott a legfrissebb Samsung felület a két népszerű telefonra.
-
PROHARDVER!
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Olympia76
tag
@ojb @vkp nagyon köszönöm a válaszokat!
Nekem itt panel biztosan nem férne el, hogy azon összerakjam a kütyüt. Van két fali kötődoboz, mindkettőn vakfedél. Az a tervem, hogy csak simán meztelenül bedobálok a két dobozba mindent. Az egyikbe a tápot, a másikba az esp-t, az nfc olvsó modult pedig felragasztom a vakfedélre belülről. Csak attól félek, hogyha így berakom a tápot, akkor hiába ragasztózom be, így, hogy meztelenül lenne, a mozgatásnál mozoghat annyit, hogy szabaddá válik a vezeték. Akkor azt kéne, hogy a meztelenség helyett mégiscsak keresek valami műanyag dobozt, ami pont csak annyival nagyobb a tápnál, hogy a vezetékek még beférjenek, aztán ki tudjam még önteni, igaz?
-
Olympia76
tag
ESPHome-ban sikerült valakinek/ lehet olyan fogyasztásmérő szenzort konfigurálni ami viszonylag gyakran elmenti az értéket, hogy reboot/ áramszünet esetén ne vesszen el?
Tasmota-ról próbálok átállni ESPHome egy teszt sonoff pow-on, ahol ez ugyanúgy probléma, de itt még több problémába ütközöm:
- a sima total increasing energy sensor teljesen lenullázódik reboot alkalmával
- a total_daily_energy szenzor elmenti úgy tűnik, de az meg naponta nullázódikLehet olyan szenzort írni, ami olyan mint a total_daily_energy, de nem daily, hanem megy a végtelenbe folyamatosan?
-
Olympia76
tag
válasz vampire17 #38479 üzenetére
Hmmm, ezt még sosem próbáltam.
Csináljak egy total_increasing mqtt szenzort adott mqtt topicra és az teljesen mindegy, hogy az mqtt topic milyen abszolút értéket riportol, csak a növekedést fogja nézni és hozzáadni saját magához?Huhh, ha ez működik is elég körülményes. Ez ilyen elrugaszkodott igény lenne, hogy senkinek sem hiáhyzik ilyen default szenzortípus, csak nekem?
-
Olympia76
tag
válasz vampire17 #38484 üzenetére
OK, köszönöm, megnézem ezeket.
Az adattárolásra vonatkozó gyakori írás problémát értem, viszont hely nem kell erre, azt nem értem mire írod, hiszen csak egyetlen szenzor aktuális értékéről van szó, az azért nem foglal helyet
@Degeczi, a utility meter jó ötlet, de akkor ez azt jelenti, hogy minden olyan fogyasztásmérő szenzort, amit Tasmota/ESPHome/Shelly, akármi szolgáltat azt érdemes, illetve szükséges alapból betenni egy utility meter-be, különben áramszünet/ reboot esetén fennál a fogyasztás elvesztése, ami alapján az energy fülön borítékolhatóak a negatív értékek? Azért erre lehetne valamilyen "gyáriasabb" megoldás. Te hogyan csinálod akkor ezt? Így?
Viszont, ha az írás és a tárhely probléma, akkor a total_daily_energy szenzor hogyan tudja mégis megoldani? Ott ugye ez a default:
restore (Optional, boolean): Whether to store the intermediate result on the device so that the value can be restored upon power cycle or reboot. Defaults totrue
.Ha ez így napiban ok, akkor egy naponta nem nullázódó szenzorban miért nem?
[ Szerkesztve ]
-
Olympia76
tag
válasz Degeczi #38489 üzenetére
...de akkor amit írtam az ESPHome-os total_daily_energy szenzor ezek szerint kinyírja a flash-t és nem kéne használni? Végső soron, bár kicsit bénácska így, a napi nullázódás ellenére ezzel is lehetne etetni az energia panel-t, nem?
Ha muszáj megcsinálom, de azért nagyon favágásnak érezném, hogy minden egyes fogyasztásmérőre kézzel külön külön plusz egy utility metert gyártani és mindez utánkövetni/ karbantartani a változásokkal.
A DSC átállítást én is tervezem, de még olyan stabilan működik a jelenlegi verzió (leszámítva azt, hogy az AP kiesése után nemigen talál vissza az AP visszajövetele után), hogy nem mertem még nekiállni... Meg tervezem a vezetékesítést is, csak ott meg sajnálnám a profin összerakott kis wemos mini-s panelemet - talán emlékszel, ebben nagyon sokat segítettél.
-
Olympia76
tag
válasz Degeczi #38502 üzenetére
Ahh, ok, még van egy ilyen opció is. Köszönöm!
Itt azt is írja, hogy:
For ESP8266,restore_from_flash
must also be set totrue
for states to be written to flash.Viszont a total a total_daily_energy szenzor leírásánál is van egy ilyen:
restore (Optional, boolean): Whether to store the intermediate result on the device so that the value can be restored upon power cycle or reboot. Defaults totrue
.Most akkor vajon be kell kapcsolni a restore_from_flash-t is akkor a total_daily_energy mentéséhez vagy a saját restore opciója beállítja ezt? Neked ez világos, vagy csak próbával deríthetjük ki?
(...de akkor nekem továbbra sem világos, hogy miért nincs egy naponta nem nullázódó, végtelenbe menő számláló is - annak is pont ugyanennyi lenne a hatása a flash-ra)
-
Olympia76
tag
válasz zsamiatt #38535 üzenetére
Szerintem leginkább azzal, hogy van hozzá elég jó felület, amennyire én láttam.
Én is "okos" voltam és elmentem Sonoff 4ch pro irányba és most küzdök azzal, hogy hogyan lehet az egész öntözést a fapadosnál jobban/ szebben/ bárki által programozhatóan és átláthatóan működtetni. Nem olyan triviális sajnos. -
Olympia76
tag
válasz vampire17 #38538 üzenetére
Én magamnak is szeretném igényesen megcsinálni, de igazad van, hogy egyébként nem annyira gyakran állítgatott rendszer, de azért nem baj, ha más is tudja a családból használni.
...váltottunk már erről üzenetet néhány hete és szöget ütött a fejembe amit mondtál, hogy jó lenne, ha minden menne a sonoff-ról local-ban esphome-al és HA-ból csak a paramétereket adod neki.
Ez az esphome gyári sprinkler platform-jával ott siklik ki nagyjából azonnal, hogy schedule-t nem tud kezelni (igaz, ez csak kb. a legfontosabb része egy öntözőrendszernek ). Szóval most éppen próbálok valami forumokról, innen-onnan összevadászott kódot beizzítani erre. Ez kb. olyan fiaskó az esphome-al, mint a napokban tárgyalt fogyasztásmérős témám, hogy nincs forever total counter szenzor alapból.
-
Olympia76
tag
válasz zsamiatt #38550 üzenetére
Leegyszerűsíted a dolgot... Igen, olyan UI-t csinálsz HA-ban, amilyet szeretnél, de kérdés, hogy mit csinálsz a GUI-val. Nem mindegy, hogy a HA vezérel, vagy azt szeretnéd, hogy a "vezérlőd" önállóan is képes legyen működni HA nélkül. A két megközelítés között, főleg, hogy megközelítésenként több megoldás is létezik elég nagy különbség van, ami a GUI-ra is kihat.
Próbáltad már a rengeteg GUI-t a mintakódokkal vagy csak a google találatok alapján mondod, hogy siba liba? -
Olympia76
tag
Egyáltalán nem probléma a GUI hiánya, ha nem akarod állítgatni vagy csak Te akarod állítgatni és nem vagy erre igényes. Egy alap funkciókat teljesítő (schedule, zónasorrend, duration, stb. ) fapados HA vezérlést (tehát mindent HA csinál) kb. 15 perc alatt raktam össze, de akkor már sokat mondok (A HA új scheduler funkciója is sokat segít ebben).
Viszont, ha local vezérlést és igényes GUI-t akarsz, arra nincs kész megoldás, bármennyire is úgy tűnik távolról a google távcsövön keresztül.
-
Olympia76
tag
válasz vampire17 #38557 üzenetére
Jaja, láttam, de aztán néztem mikor volt az utolsó commit (2019), miközben az Opensprinkler github-ján bőven van aktivitás az elmúlt évekből is, így még nem próbáltam ki. Nem tudom egyáltalán érdemes-e. Lehet majd ha nem jutok semmire, akkor eljutok ide is végső próbaként
-
Olympia76
tag
válasz vampire17 #38564 üzenetére
Akkor rendeltél mást is, mert csak $10 felett van a 15 napos szállítás
Nézem, hogy a lila kábeles hack-en kívül még a jumper header-eket is be kell forrasztani, hogy működjenek a relék.
Lehet inkább próbálkozom a Sonoff-al. Annak legalább van doboza és DIN sínre is rögzül
GPIO-kat hol kell módosítani a kódban? -
Olympia76
tag
Rendeltem DSC keybus interface-hez PCB-t WT32-ETH01-hez:
https://github.com/Dilbert66/esphome-dsckeybus/tree/master/PCB%20Layouts/WT32-ETH01Szóljon akit érdekel.
-
Olympia76
tag
válasz Fuser és Tsa #38581 üzenetére
Próbáld configuration.yaml-ban:
mqtt:
sensor: !include mqtt/mqtt_sensors.yaml
switch: !include mqtt/mqtt_switch.yaml
-
Olympia76
tag
-
Olympia76
tag
-
Olympia76
tag
@degeczi
Tesztelem a Dilbert66 féle ESPHome-os dsc keybus interface-t.
Működik is, de van egy olyan problémám, hogy amikor bármelyik zóna nyitva van, akkor a Partition 1 Status-t "Unavailable"-nek mutatja. Amint zár a zóna, a Partition 1 Status visszatér "disarmed"-ba. Ez Nálad nem jelentkezett?
-
Olympia76
tag
válasz Degeczi #38934 üzenetére
Igen, azt használom. Az az érdekes, hogy éppen értekezem Dilbert66-aki, aki azt mondja, hogy normális, hogy unavailable-be megy:
https://community.home-assistant.io/t/esp8266-into-existing-alarm-dsc-system/225224/251?u=olympiaMost akkor nem tudom mi van...
-
Olympia76
tag
válasz Degeczi #38938 üzenetére
Itt van egy részletesebb magyarázat:
https://community.home-assistant.io/t/esp8266-into-existing-alarm-dsc-system/225224/256?u=olympiaEz alapján Neked is ezt kellene látnod, hiszen eleve "Unavailable"-re van kódolva.
Te érted, hogy akkor most mi van? -
Olympia76
tag
válasz Degeczi #38946 üzenetére
Igen, akkor valószínűleg ez lesz, de stay típusú zónadefiníció is jó ötlet. Nálam valóban nem stay típusúak a mozgásérzékelő zónák sem a földszinten (csak az emeleten, mert mindenki ott tölti az éjszakát, így a földszinten nem kell, hogy stay legyen).
Nem lehet, hogy Nálad is van mégis unavailable, de olyan kevés és csak pillanatnyi (mivel stay típusúak, így nem blokkolják a beriasztást), hogy nem veszed észre az előzményekben?
Akárhogy is, valószínűleg ezek valamelyike (vagy mindkettő külön-külön, vagy a kettő együtt együtt ) lesz akkor az oka, hogy nem jelentkezik Nálad ez. Köszönöm, hogy utána gondoltál! Nekem viszont akkor át kell írnom az összes DSC-s automatizmust a korábbi taligentx féle MQTT-s interface-hez képest, ahol is a partíció státuszt használtam mindenhol.
-
Olympia76
tag
-
Olympia76
tag
válasz Degeczi #39054 üzenetére
Nálam a nappali TV Kodi-val megy, Vero4K+ van alatta. Bekapcsolásnál CEC kapcsolja a TV-t és az AVR-t is. Egy távirányító van a Vero-hoz, azzal megy minden. TV adást is Kodiból megy tvheadend-en keresztül, így a Kodi felületéről megy minden. Hang az AVR-ről megy, ennek hangerejét a Kodi állítja CEC-en keresztül. Kikapcsolásnál is lekapcsol mindent CEC-en keresztül a Kodi. Projektort mondjuk én is Broadlink minivel vagyok kénytelen kapcsolni. TV-ről projektorra átkapcsolásnál TV-t CEC-el ki, projektort infrán be. Szuper, hogy mindehhez elég a Vero néhány gombos távirányítója. Nem kell se a TV-é, sem az AVR-é, sem a projektoré (najó a projektoré elöl van, mert az elmentett color profile-ok kötött semmi mással nem tudok váltani ).
Másik TV-n XBOX van, az is szépen ki-be kapcsolja a TV-t CEC-el.
-
Olympia76
tag
Van valami megoldás(otok) arra, hogy hogyan lehet elkerülni, hogy trigger-elődjenek az automatizációk a Z2M újraindulásával járó állapotváltozások miatt?
-
Olympia76
tag
válasz Degeczi #39129 üzenetére
Igen, ezek így vannak.
Tegnap este megkeveredtem egy kicsit, hogy mi történik. Kiderült, hogy egy sensor miatt indult el egy automatizmus már jó ideje és ezt nem vettem észre, mindig a többinél kerestem a probléma forrását.Ez az egy szenzor pedig az ikeás illuminance szenzor. Ez indít automatizációt numeric state/ below triggerrel. Ma este majd még tesztelek, de úgy néz ki, hogy a below X akkor is teljesül, ha unavailable-ból vált X alá. Ha így van akkor ez elég bug gyanús, mert ennek a triggernek csak numeric-numeric változás esetén szabadna aktiválódnia, nem?
-
Olympia76
tag
Elnézést az enyhe offtopic-ért, de hátha tud valaki el tudja magyarázni, hogy miért lehet az, hogy a napközben termelt áramomból egy jó csomót nem fogyasztok el, "feleslegesen" visszatáplálom, ahelyett hogy helyben elfogyasztanám.
Min múlik ez? Én azt sem tudom, hogy az inverter milyen arányban táplál rá a 3 fázis között a hálózatomra? Egyenlő arányban? Vagy valamilyen módon a panelek inverterbe való bekötésétől függ, hogy melyik fázisra fog többet rátáplálni? Azt kellene akkor nézegetnem, hogy melyik fázison jön az inverterből a legtöbb áram és azt kötni a hálózatnak arra a fázisára ami a legtöbbet fogyasztja?
Szemléltetés a mai napról:
-
Olympia76
tag
Ezek a standard energy dashboard színek.
Ha nem tudod a színeket akkor szerintem nem találtad ki. A lila a termelt és visszatáplált mennyiség. A kék a fogyasztás, a narancs a saját termelésből fedezett fogyasztás."A végeredményt azonban az éves elszámolás adja."
Nem mondod...
...viszont majd egyszercsak nem lesz szaldó, nem árt lépésről lépésre felkészülni azzal, amivel lehet. -
Olympia76
tag
@noorbertt
Sikerült anno megcsinálnod a Shelly RGBW2 által generált tápegység sípolás megszüntető kütyüt? Eddig is sípolt halkan a konyhában a 12v-os fehér led szalag, de most frissítettem 24v-ra és teljesen elviselhetetlenné vált, dimmeléstől függetlenül sípol a táp. Két különböző Shelly RGBW2-vel és két különböző márkájú táppal próbálva ugyanaz. Bravo Allterco!Esetleg mi jöhet szóba Shelly RGBW2 helyett?
Van még itthon raktáron Athom WLED vezérlő, de ahhoz meg nincs elérhető binary analog ledhez PWM vezérléssel. Elvileg fordítani lehet, de most annyira nincs kedvem ebbe beleásni magam és a környezetem sincs meg hozzá. -
Olympia76
tag
"A példánál maradva, illetve azt megfordítva: van mondjuk 3kW termelésed mindegyik fázison (tehát összesen 9), van egy elektromos autód, ami tölt éppen 6kW-al, de csak 1 fázisú a fedélzeti töltője (nem mindegyiké 3 fázisú). A végeredmény: 6kW visszatáplálás (a két nem terhelt fázison 2x3kW), és 3kW vételezés (a terhelt fázison 6-3kW). Mindeközben ha szummát nézel, akkor ugye termelsz 9kW-al, és fogyasztasz 6-al, mégis vételezni fogsz, viszont a szaldós elszámolás ezt most még "elsimítja"."
Nagyon köszönöm, pontosan erre voltam kíváncsi!
Ezen viszont az automatizáció nem segít. Ennek kisimításában akkor valóban az tud valamennyit segíteni, ha a termelési órákban fogyasztó fogyasztók "szétosztásra" kerülnek a 3 fázis között, amennyire lehetséges. Ez "jó kis játék"... -
Új hozzászólás Aktív témák
- Samsung Galaxy A34 - plus size modell
- Rekordmagasba lökte az EPYC és a Ryzen az AMD-t
- Politika
- Mobil flották
- Sony Xperia 1 V - kizárólag igényeseknek
- Elvörösödik az Xperia 1 VI
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Anyagi katasztrófára figyelmezteti az Apple-t a brit média
- Otthonfelújítási program (2024.)
- Amlogic S905, S912 processzoros készülékek
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen