-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
Degeczi
nagyúr
válasz Spuri2000 #16214 üzenetére
Lassan 2 éve használok összesen 9 példányt, abból kettőt kültérben (esőtől persze védve, de hideg-meleg akadálytalanul éri), 10A-t bőven meghaladó terhelésekkel is (mint klíma, mosógép, szárítógép, mosogatógép, sütő, egy éven át villanybojler is) és Tasmotával kifogástalanul teszi mind a dolgát!
A pici SHP6-al nekem is volt rossz tapasztalatom, de ezek nagyon beváltak.
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz LógaGéza #16219 üzenetére
Ha HA (bocs ) alatt kezeled, akkor semmi különöset nem kell tenned, csak az mqtt configban megcserélned a kettőt, azaz a "mosógép" nevű szenzor alatt azt az mqtt topikot figyeld, ami korábban a klímáé volt. Így a history is szépen megmarad.
Előtte célszerűen a Tasmota "EnergyReset" parancsával át tudod vinni az addigi halmozott értékeket az eszközökön belül is.
[ Szerkesztve ]
-
-
Degeczi
nagyúr
válasz szabifotos #16223 üzenetére
Mint ahogy az első üzenet írja: nincs olyan, h "binary sensors", ott szóköz helyett aláhúzás kell és egyes szám:
binary_sensor:
(és már az itteni kódformázó is jelzi, h csak az első szót pirosítja ki)[ Szerkesztve ]
-
Degeczi
nagyúr
Ez persze igaz, viszont nálam pl. annyi minden leállna broker nélkül, h azzal nem is tervezek. Tartalékgép van, percek kérdése beüzemelni ha az éles megdöglene. Teljesen atombiztos úgysem lehet, mert a router is tönkremehet.
A vezérlő központi szoftver már könnyebben leállhat (akár hiba, akár csak karbantartás miatt), ott hasznos áthidalni amivel lehet. -
Degeczi
nagyúr
válasz Vodike #16245 üzenetére
A Tasmota menüjében a loggolás pontja alatt van egy "telemetry period", ami alapban 5 perc. Nagyon kicsire (10s vagy annál is kevesebb) nem érdemes állítani, de már 20-30 mp-el is jól reagál.
3W-ot amúgy simán meghaladhatja tényleg, szerintem 10W vagy még magasabb küszöb célszerű. -
-
Degeczi
nagyúr
válasz LógaGéza #16249 üzenetére
Ezért használok több állapotot. ami jól kezeli a különböző helyzeteket:
- "üres"
- "mos". Ide "üres" helyzetből az indulási küszöböt (nálam 25W) meghaladva kerülhet, vagy '"pihen" állapotból 10W fölé ugorva. Mindkét esethez "és" feltétel az ajtó csukott állapota. A nagyobb indulási küszöb miatt nem zavarja meg az időzítés beállítása után pillanatra picit (10-15W) megugró fogyasztás.
- "pihen": ha "mos" helyzetben volt, és 10W alá esett a teljesítményfölvétel. Előfordul mosás közben fél perc-percre.
- "készen": ha már 2 perce "pihen" állapotban van. Ekkor jön az értesítés is.
- ha 5 (majd 15, 30) perce senki nem reagált erre, ajtó csukva maradt, akkor ismételt értesítés.
- ha itt ("készen" állapotban) nyílik az ajtó, akkor az állapot visszaáll "üres"-re[ Szerkesztve ]
-
Degeczi
nagyúr
Furcsa, mert a 106.6 teljesen minimális pár változást jelent (így föl sem raktam, maradt a 106.5), a felülettel kapcsolatban pedig semmit, és az issue-k között sem látni a tiédhez hasonló problémát.
-
Degeczi
nagyúr
válasz goldister #16261 üzenetére
Az esetek többségében ezt retain módú parancs okozza: amikor ismét fölcsatlakozik az eszköz bármilyen okból (ez lehet wifiről leszakadás vagy újraindítás akár az eszköz, akár az mqtt szerver oldalán) akkor megkapja a retain módban a topikjában lévő parancsot.
Ezért vagy minden parancs legyen retain módban (föltéve, h kézzel nem kapcsolgatod!) vagy egyik sem, a korábbit pedig úgy töröld, h egy üres (szóköz) parancsot küldesz a topikba retain módban. -
Degeczi
nagyúr
válasz goldister #16263 üzenetére
Nem. Opcionálisan lehet retain flaggel ellátott üzenetet is küldeni, amikor az "ottragad" a topikban végleg, így az MQTT szerverre fölcsatlakozó kliens azonnal megkapja (mindig az utolsót, topikonként egyetlen ilyen lehet. Ezért lehet törölni is egy üres retain módú üzenettel helyette)
Ez egyszerű opció, pl. a HA MQTT Switch alattretain: true
-val kapcsolható be, a mosquitto_pub parancsnál pedig a -r opcióval.Gondolj pl. érzékelőkre, ott nagyon hasznos: ha egy nyitásérzékelő csak akkor küld adatot, amikor változás van akkor újraindítás után addig nem lenne infód az aktuális állapotáról, amíg nem nyitják vagy csukják az ajtót... Retain módban beküldött állapot-üzenetekkel viszont mindig ottmarad az utolsó.
De alapvetően bárminél jól jön, ha azt csak automatizálásból kapcsolod, mert így áramszünet, wifileszakadás vagy bármilyen újraindítás után is az utoljára parancsolt állapotba kerül az eszköz (ha azonban kézzel is, pl. egy mennyezeti lámpát fali kapcsolóval is, ott már kellemetlen, ha a kézzel leoltott lámpa az éjjel fölkapcsol)
-
Degeczi
nagyúr
válasz LógaGéza #16318 üzenetére
De, technikailag nyilvánvalóan fogta, a problémát az okozta, h más protokollt használ a szenzor, amit a szoftvered nem támogat... Az Rflink a legrosszabb ebből a szempontból, gyakorlatilag halott (pár havonta ugyan kiteszik az oldalukra, h "élünk még", de valójában 2017-es az utolsó kiadása, azóta pedig rengeteg szenzor létezik amit nem ismer, a forrása pedig zárt), az RTL 433-al viszont jó eséllyel működhet, az sűrűn frissül. Pont nemrégi lepődtem meg kellemesen, h frissítés után meglátta a tavalyelőtt vett Lidis időjárásállomást, amit korábban még nem.
-
Degeczi
nagyúr
válasz vampire17 #16327 üzenetére
Egyszerű automatizálásokhoz (és ha Blocky-val megoldható volt, valszeg ilyen) már elég a felületelen kattintgatni. Amihez nem, ott is könnyen megtanulható a yaml, a kimondottan bonyolultakhoz pedig az Appdaemon tökéletes, kényelmes megoldás (Pythonban).
A leírások nagyon jók, sok példával, és fórumokon is rengeteg tapasztalat gyűjthető.Persze, mehet párhuzamos több rendszer is, amíg nincs vezérlés ugyanarra az eszközre több helyen. Sőt, ugyanazt is lehet több helyen próbálgatni, ehhez is kényelmes megoldás a Docker (asztali gépen szépen kikísérletezhető minden, aztán a végső helyére már a kész, beállított config fileokat lehet fölmásolni)
A Docker egyik célja pont az, h könnyítse a dolgod... Semmilyen függőséggel nem kell törődnöd, hiszen mindent tartalmaz ami kell a rendszer futásához, az elkülönítés miatt pedig összeakadás sem fordulhat elő (ha pl. másik szoftvernek más verzióra lenne szüksége vmiből). Egy frissítés is annyiból áll, h leállítod és törlöd a docker kontéred meg az image-t amiből épült, majd újra kiadod azt az egyetlen parancsot, amivel annak idején létrehoztad, és pár perc múlva már ott az új rendszer.
A config file-ok, adatok a host géped egy megosztott mappájában lesznek, azokat természetesen nem érinti a konténer törlése. Sőt, a HA egyik komoly előnye, h ha változtatsz vmi rendszer komponensen (egy eszköz illesztőprogramján), akkor egyszerűen lemásolod az eredeti forrást egy custom_components mappa alá, módosítasz rajta amit kell - és újraindítás után már a saját változatodat fogja használni. Ez is a host gépeden van, szintén változatlan marad verzióváltás során, így egy újabb HA verziót telepítve is megmarad a saját, módosított programod. -
Degeczi
nagyúr
válasz vampire17 #16329 üzenetére
Ez már a Hassio. Az is tökéletes, kényelmes - bár picit kiveszi a kezedből az irányítást azzal, h maga felügyeli a HA futtatását. Én ezért maradtam a sima Home Assistant docker telepítésénél, ahol nincs ilyesmi.
A többség amúgy Hassio-t használ, pont azért, mert elintéz sokmindent a háttérben, további docker image-ekben szereplő kiegészítők telepítését is, amiket így nem kell külön fölraknod.
Szóval tökéletes választás. -
Degeczi
nagyúr
válasz vampire17 #16331 üzenetére
Hát rögtön a /config alatt.
Egyébként szerkesztgetéshez mindenképpen rakd föl a Visual Studio Code-ot, veszettül jó! A böngészőben egy teljes értékű editor: pont olyan, mintha grafikus felületen futna közvetlenül a gépen (és sokkal kényelmesebb, mint be-ssh-zva, konzolos editorral)Na igen, ezek szeirnt a Hassio magától használ egy alapkönyvtárat, és az alatti homeassistant mappát használja /config-ként.
Nálam, a sima Home Assitant telepítésnél a docker run parancs egyik -v paramétere az, h melyik mappámat jelölöm ki erre.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz vampire17 #16335 üzenetére
Attól függ, mi változott.
Ha új entitást hoztál létre, akkor a HA-t (nem okvetlenül a konténert: a Konfiguráció / Szervervezérlés / újraindítás alatt is újraindítható) igen, ha csak automatizálás változott, akkor az az előbbi menüpontban enélkül is újratölthető.Ha esetleg nem látsz minden menüpontot, a bal oldali sáv alján a nevedre kattintva először be kell kapcsolni a Haladó üzemmódot.
A Hassio kiegészítőket nem ismerem, azok nálam az alap HA-n nincsenek, külön dockerekben van minden.
-
Degeczi
nagyúr
válasz vampire17 #16340 üzenetére
Ha Gree klímához kell, ahhoz van jól bevált komponens (egyszerűen egy custom_components mappa alá bemásolva)
-
Degeczi
nagyúr
válasz kbela365 #16365 üzenetére
A numeric_state "below" és "above"-ja amit most használsz, pontosan így is működik: csak a küszöb átlépésekor aktiválódnak.
A problémád az okozhatja, ha indításkor nincs állapota a szenzornak (unkown), majd beáll az aktuális értékre, ami már persze érthető, ha "átlépi" ezt a küszöböt.
Ezért elvileg az a legegyszerűbb megoldás, ha retain módúvá teszed a szenzort (föltéve, ha az MQTT-n keresztül jön, mint pl. Zigbee2mqtt-n egy Xiaomi szenzor, vagy vmilyen időjárásállomás egy 433 MHz-es vevő->MQTT-n) -
Degeczi
nagyúr
válasz huliganboy #16370 üzenetére
"Device" platformú automatizálásról azt írja a leírás, h az a felületen kattogtatásra való, ezért nem is részletezi az opciókat.
Mindenesetre az látatlanban is valószínű, h egy notify service hívás nem maradhat adatok nélkül (data: {}) hiszen hogyan értesítsen, milyen szöveggel? Kell neki message is.
-
Degeczi
nagyúr
válasz m4csk4fogo #16373 üzenetére
Nyomógombnál a vevőtől távolság a döntő, mert a Xiaomi kényelmes, de kb. csak 10 m a hatótáv, ezért praktikusabb egy 433 MHz-es vezeték nélküli csengő, aminek tudod fogni a jelét HA alá integrált vevővel is (és ettől még megmaradhat a saját beltérije is, de akár a Xiaomi GW-en lévő hang lejátszását is elindíthatod csengőhangként - vagy bármilyen hálózati hangszóró, pl. Google Home eszköz, Sonos kompatibilis hangszóró mint pl. Ikea, stb is megszólalhat)
-
Degeczi
nagyúr
válasz LógaGéza #16377 üzenetére
Külön is vehetsz ilyen antennát, csak az általában a szokásos koax csatlakozóval lesz, de ilyen MCX-átalakítót is fillérekért vehetsz - és igazából más nem is nagyon kell, mert antennát már dróthuzalból simán tekersz magadnak
-
Degeczi
nagyúr
válasz vampire17 #16390 üzenetére
Elvileg igen.
Egyébként van annyira okos, h kigyűjtni a template-ben található entitásokat, és azok változása esetén értékeli ki a kifejezést.
Így végeredményben ugyanaz, mintha egy sima "platform: state" triggerben adnád meg a climate.nappali-t (ami annak bármelyik attribútumának megváltozására aktiválódik) és ott condition-ben írnál hasonló template-t kifejezést. -
Degeczi
nagyúr
válasz vampire17 #16393 üzenetére
Gondolj bele: nem értékelheti ki folyamatosan, megállás nélkül a template kifejezést (hogy mikor teljesül végre), hiszen az hatalmas terhelés lenne.
Ezért optimalizál úgy, hogy az abban található entitásokat figyeli, és csak akkor értékeli ki, ha megváltozott azok közül valamelyik állapota (bármilyen attribútuma, nem csak a "state" nevű).
Esetedben csak a climate.nappali szerepel a kifejezésben, így azt fogja figyelni. Akár a "temperature", akár a "current_temperature" attribútuma (akár persze bármilyen másik, ha van még neki) változik, akkor fogja megnézni, teljesül-e amit előírtál.Tehát ugyanez másképp írva:
trigger:
- platform: state
entity_id: climate.nappali
condition: template
value_template: >-
{{ state_attr('climate.nappali', 'temperature') }} >
{{ state_attr('climate.nappali', 'current_temperature') }}[ Szerkesztve ]
-
Degeczi
nagyúr
Így van, a kézi futtatás egyszerűen végrehajtja az action: alatti részt, feltételek vizsgálata nélkül. Teszteléshez mondjuk tényleg jobb lenne, ha nem így tenné.
vampire17:
A group akkor "on", ha bármelyik tagja "on".
Amúgy mielőtt automatizálásokat írsz, az későbbi olvashatóság miatt célszerű az entitások kezelése alatt beszédes nevűre átnevezni a Xiaomi id-t.[ Szerkesztve ]
-
Degeczi
nagyúr
Logikusan nézve igazad lenne, azonban annyira gyakori az ilyen éjfélen átívelő feltétel, h ezt korrekt módon lekezeli (külön kezeli a before < after esetet), így nincs vele hiba.
Azt is szeretem a HA-ban, h pillanatok alatt megvan az áttekinthető forrásában az érintett kódrész, ahol ez látható: vagyis csak akkor érvénytelen a feltétel, ha az aktuális időpont a before (beleértve) és az after (nem beleértve) között van, ez esetben 09:00-al kezdve 17:59-ig nem teljesül, 18:00-tól 08:59-ig igen
[ Szerkesztve ]
-
Degeczi
nagyúr
válasz vampire17 #16418 üzenetére
Nem kell beállítanod, ezt a default viselkedés. Azt tudod átállítani az all paraméterrel, h csak akkor legyen on, ha minden tagja az.
Természetesen vissza is áll off-ra, különben nem lenne értelme.
Ezt akár a fejlesztő eszközök alatt az entitásoknál is tudod nézni, de a desktopra is kirakhatod vmelyik kártyára. -
Degeczi
nagyúr
válasz vampire17 #16422 üzenetére
A fejlesztői eszközök / sablon alatt be tudod írni ezeket a template kifejezéseket, így ott lehet tesztelni, milyen eredményt ad.
Nem kritikus, elfogadja így is, de ha már numeric_state, akkor számmal hasonlítsd, ne stringgel, az after után viszont hiányzik az aposztrófok közé írás (a feltételek meg alapban "and" kapcsolatban állnak egymással, de persze ez sem baj, csak az a 2 sor el is hagyható)
Mindesetre ha a trigger a sablonszerkesztőben jónak tűnik, először meg lehet próbálni egyenként hozzáadogatva a feltételeket, akkor majd csak kiderül, melyikkel van gond.
-
Degeczi
nagyúr
válasz vampire17 #16424 üzenetére
Az nem HA specialitás, hanem YAML szabvány (pl. a Symfony PHP keretrendszer doksija is kitér rá)
Amikor egy string túl hosszú lenne a kényelmes szerkesztéshez, nyugodtan szét lehet törni több sorba, csak az előtte álló sor végére kell egy>
Ez összefűzi a következő (indentált) sorokat egyetlen hosszú stringbe, aminek alapban megtartja a legvégén a soremelés (\n) karaktert. Ezt veszi le opcionálisan, ha egy-
jel is ott van, ezért a>-
Ha eleve egyetlen sorba írod, ahogy a (#16422)-ban, akkor persze nem kell, és amúgy általában a végső soremelés sem okoz bajt, így többnyire elhagyható a -[ Szerkesztve ]
-
Degeczi
nagyúr
válasz kbela365 #16425 üzenetére
Én is így, külön telepítve használom.
A Zigbee2mqtt alapban nem retain flaggel küldi be az adatokat, de ez bekapcsolható a configjában! Érdemes is, különben a következő jelentésig (ami közel egy óra is lehet) "unknown"-ban maradnak ezek újraindítás után.Ha esetleg ez se lenne elég vmiért, akkor azzal is megkerülheted, h azt az értesítő automatizálásodat
initial_state: ‘off’
-ra állítod, és a HA indulásáratrigger:
platform: homeassistant
event: start
azaction:
részbe teszel egy kellően hosszúdelay:
-t, majd egyservice: automation.turn_on
hívással aktiválod az addig inaktív automatizálást.[ Szerkesztve ]
-
Degeczi
nagyúr
válasz kdavid86 #16428 üzenetére
Inkább fordítva: így helyes, hiszen a HA működéséhez szükséges az MQTT megléte, ahhoz próbál kapcsolódni... (ahogy az adatbázis szerverhez is) Pont ezért célszerű önállóan indított dockerek helyett docker-compose-t használni, mert ott létezik depends-on opció, amivel megadható ez a függő viszony.
Ha retain módra vannak állítva a Zigbee2Mqtt szenzorok, akkor ez nem probléma, hiszen a topikjaira föliratkozva azonnal megkapja az utolsó értékeket a HA, így nincs kiesés.
-
Degeczi
nagyúr
válasz LouiS22 #16450 üzenetére
Ez nem igaz, kimondottan ritka, amikor valóban hozzá kell nyúlni, egyáltalán nem jelent "sok szopást". Lassan 2 éve használom a HA-t, ez idő alatt bőven egy kézen meg tudom számolni, hányszor kellett vmilyen configon verzióváltás miatt változtatnom.
vampire17: egyszerűen
entity_id: group.all_heating
-re hívod meg.[ Szerkesztve ]
-
Degeczi
nagyúr
Mert a kód alapján úgy írták meg, h hatékony legyen, lényegében nulla erőforráshasználattal, mivel indításkor csak beállítja a lejárati dátumot és hogy mit kell visszahívnia a rendszernek amikor az elérkezik. Így addig az időpontig nincs vele dolga - de persze nem is frissül semmi, szóval arra valóban nem jó, h visszaszámlálót tegyél ki a képernyőre.
-
Degeczi
nagyúr
válasz huliganboy #16476 üzenetére
A normál szenzor szabadon fölvehet bármilyen értéket, a payload_on, payload_off ott ezért értelmezhetetlen, nem létező opció. Csak binary_sensor: alatt használható, hiszen annak van kizárólag on/off állapota.
-
Degeczi
nagyúr
válasz vampire17 #16482 üzenetére
"attributummal nem lehet triggerelni"
Dehogynem lehet!
Ahogy korábban is írtam már, a "state" trigger ezt csinálja, minden attribútumot figyeli. Pl. egy házimozi erősítőnek is sokféle attribútuma van (ki-be kapcsolt állapot, kiválasztott bemenet, hangerő) és egy ilyen automatizálás ezek bármelyikének változására lefut:- alias: test_amp
trigger:
- platform: state
entity_id: media_player.en_kicsi_erositom
Alább (#16480) azonban nem state triggert használtál, hanem template-t, ami kiértékeli a template-be írt logikai kifejezést. Ha annak eredménye logikailag igaz, aktiválódik, egyébként nem, ennyi.
Persze, h
data_template:
kell az alábbi service hívásra, hiszen csak az értékeli ki a megadott kifejezést. A simadata:
egyszerűen átadja, ahogy van. Tehát ott a'{{ state_attr(''climate.nappali'', ''temperature'')}}'
szöveges értékre próbáltad beállítani szegény numerikus változódat...[ Szerkesztve ]
-
Degeczi
nagyúr
válasz huliganboy #16494 üzenetére
Ha dockerben futtatod, annak egy --device=/dev/ttyUSB0 (vagy amelyik kell, persze) opcióval lehet jogot adni
Új hozzászólás Aktív témák
- The Last of Us: Part II - Kész lenne már a PC-s kiadás?
- TCL LCD és LED TV-k
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Milyen videókártyát?
- Milyen autót vegyek?
- Politika
- Linux kezdőknek
- Macska topik
- A személyes adatainkkal, képeinkkel tréningezi az AI-t a Meta
- Autodesk - Revit
- További aktív témák...
- Üzleted van? Akkor ilyen nyitvatartás matricával dobd fel! PH tagoknak 30% kedvezmény!
- Raktáron! Új EVSE EV 3 fázisú 11kW-os hálózati töltők elektromos autókhoz, 3 év garanciával!
- Traktor és kamion matricák széles választékban! PH tagoknak 30% kedvezmény!
- Erős asztalláb (Steelcase)
- Arlo Smarthub VMB4540 Féláron!
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen