Hirdetés
-
Ellopták a Tesla akkumulátor-titkait
it Beperelte egy korábbi beszállítóját a Tesla, és azzal vádolja, hogy üzleti titkokat lopott a Tesla akkumulátorgyártási technológiájával kapcsolatban.
-
Olcsó USB WiFi AC adapter
lo Egy olcsó WiFi AC USB adapter jó szolgálatot jelenthet, ha az új router csak elvileg támogatja a 2,4 GHz-es átvitelt.
-
Kivételesen olcsó Moto érkezik Európába
ma Az Android 14 Go rendszerű Moto E14 az Egyesült Királyságban mutatkozott be, ott 32 ezer forintnyi fontot kell fizetni érte.
-
PROHARDVER!
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
LouiS22
veterán
Azért ezt nem lehetetlen beszerezni.
Másik: Alzánál reklamálsz. Ha nem volt feltüntetve, hogy US csatlakozós, akkor meg pláne. Szerintem cserélni fogják szó nélkül.
B opció: ha van német ismerősöd, akkor nagyjából most rendelj egy hivatalos google store-ból egy mini-t, ma náluk BF van.
Mielőtt kérdezel, nézd meg az 1. számú hozzászólást, vagy használd a keresőt, azért van!
-
Degeczi
nagyúr
-
fo_di
őstag
# Example configuration.yaml entry cover: - platform: template covers: garage_door: friendly_name: "Garage Door" value_template: "{{ states('sensor.garage_door')|float > 0 }}" open_cover: service: script.open_garage_door close_cover: service: script.close_garage_door stop_cover: service: script.stop_garage_door
én valami ilyesmit próbálnék meg, ahol a shell commandok nevét jól kell írni[ Szerkesztve ]
-
Degeczi
nagyúr
Hát! Részben pont ezért teszel rá Tasmotát, h be tudd integrálni.
Létrehozol egy mqtt platformú switch-et, ahol a command topic-hoz beállítod a Bridge parancstopikját (cmnd/xxxxx/yyyy), payload_on-ként pedig megadod a kiküldendő kódot (amit a Tasmota console-ján kilestél, amikor az eredeti távvezérlőt használtad - bár ha scriptet írtál rá, akkor nyilván ott is ugyanezt a kódot használod)Végül egyszerűen switch.turn_on service hívással lehet kiküldeni, nem kell scripthívással vacakolni.
[ Szerkesztve ]
-
DougButabi
tag
Én sokat szívtam azzal, hogy script-be téve nem ment a redőnyvezérlés, valami idézőjeles probléma volt az rf kód körül, és csak összevissza próbálkozással jöttem rá, mert a neten lévő példák-tól eltérően működött csak.
Mondjuk én broadlink service-t hívok meg, nem tudom számít e nálad is.Este megnézem, mi volt a megoldás.
-
fo_di
őstag
https://www.home-assistant.io/integrations/switch.mqtt/
az alján van egy teljes template
a name lesz a neve (switch.name), a topic a tasmota által várt topik, a payload_on lesz az IR kód -
Degeczi
nagyúr
Ha egyszer ráérzel, valójában emberközelibb, mert számszerű id-vel sehol nem kell foglalkoznod, hanem végig beszédes nevekkel (amikben akár magyar karaktereket is használhatsz, h a felületen jobban mutasson, a kódban pedig egyszerűen ékezet nélkül hivatkozhatsz rá, mert olyan id-t kapnak, ha külön nem definiálod)
Tehát ha pl. ha a switchednek
name: "Redőny fel"
nevet adsz, arra a service hívás így néz ki egy automation-ben:action:
- service: switch.turn_on
data:
entity_id: switch.redony_fel
Az MQTT üzenetküldést külön nem kell megadnod (bár persze lehet olyat is), mert ha a switch - platform: mqtt -ként van létrehozva, akkor automatikusan MQTT üzenetküldéssel jár a "turn_on" hívása, ahol a kapcsolónál megadott
payload_on
:-t fogja beküldeni command_topic-baSzerk: a config változatása sajnos csak újraindítás után lép életbe, az automatizálásokhoz nem kell, azokat újra lehet tölteni.
Szerk2: switch.turn_on, nem simán on.
Ja, és valóban, mivel redőnyt vezérelsz, még egyszerűbb a helyzet, mert eleve van cover-ből is mqtt platform, ahogy használod is.[ Szerkesztve ]
-
Degeczi
nagyúr
Ott van a leírásban: "If a state topic and position topic are not defined, the cover will work in optimistic mode. In this mode, the cover will immediately change state (
open
orclosed
) after every command sent by Home Assistant. If a state topic/position topic is defined, the cover will wait for a message onstate_topic
orposition_topic
."
Tehát ha nincs visszajelzésed (márpedig rádiós vezérlésnek ez a legnagyobb hátránya, h nincs), akkor hagyd el a state topikot a configból (és persze azoptimistic: false
-ot is, vagy tedd true-ra), és a HA rögtön átállítja az állapotot az utolsó parancsnak megfelelően, nem fog várni a visszaigazolásra.Persze, érdemes is!
Pl. aswitch:
szekciót átrakod egy switches.yaml-be (ahol az első sort kimegjegyzéseled#switch:
formában, hiszen az már szerepel a configuration-ben, de érdemes meghagyni itt is a file elején, h rögtön látható legyen honnan származik), és helyette ezt hagyod benne a configuration.yaml-ben:switch: !include switches.yaml
És hasonló módon az összes többit is, így jól áttekinthető marad a config.[ Szerkesztve ]
-
Chal
addikt
A szétpakolásra az include helyett nekem jobbam bejött a "package" funkció. Teljesen átálltam már rá, sokat tisztított a dolgokon. A lényege abból áll, hogy a packages szekció alatt definiált könyvtárak teljesen függetlenek a config egyéb részeitől (ez csak parser szinten értendő, tehát nyilván ezekben a configokban ettől még hivatkozható egy másik configban levő objektum (entity, service, akármi). Így egyáltalán nem kell arra figyelni, hogy a szülő config melyik szekciójához tartozik az adott file amit éppen szerkesztünk.
Nagyjából így néz ki ami a fő config file-ba kell:
packages: !include_dir_named PACKAGES
Ezután lehet csinálni bármilyen logika alapján szeparációt, úgy, hogy létrehozunk a PACKAGES könyvtára alatt további könyvtárakat, melyeken belül nulláról írhatunk configot (tehát használható lesz a "automation:", "sensor:", "cover:"... akármi szekció, függetlenül attól hogy más package-ben vagy a fő config file-okban van e már ilyen).
Pl. én most projekt/helyszín alapján gondolkodok, de nyilván ízlés kérdése, keverni is lehet, ahogy jól esik. Valami hasonló most a szerkezet:
PACKAGES/futes
PACKAGES/riaszto
PACKAGES/vilagitas
stb..Ezeken a könyvtárakon belül minden projektnek van saját automation/sensors/scripts/stb... yaml file-ja (illetve amelyiknek ami kell).
Azt vettem észre, hogy sokkal könnyebben találom meg a dolgokat ha valami hiba van, vagy módosítani szeretnék.
[ Szerkesztve ]
-
Degeczi
nagyúr
Gondold át, h mit szeretnél, milyen feltételekkel, és már írhatod is az automatizálást.
Pl. hétfőn és kedden 7-kor fölhúzni a hálószobai redőnyöket (ami egy group) ha van otthon vki és nincs ünnepnap és még nincs kézzel fölhúzva a redőny hogy kézi pozíciót ne rontson el (ez nálad nyilván kiesik, meg persze az otthonlét vagy ünnepnap figyelése is, ha azt nem kezeled még - de amúgy érdemes):- alias: Bedroom shutters up mon-tue
trigger:
- platform: time
at: '07:00:00'
condition:
- condition: time
weekday:
- mon
- tue
- condition: state
entity_id: input_boolean.someone_at_home
state: 'on'
- condition: state
entity_id: input_boolean.holiday_mode
state: 'off'
- condition: template
value_template: >-
{{ state_attr('cover.bedroom_ne_cover', 'current_position') < 35 }}
action:
- service: cover.open_cover
data:
entity_id: cover.haloszoba_redonyok
Másrészt ha odakint besötétedik, akkor lehúzatom (nem fullra, hanem hogy maradjon szellőzés nyáron a redőnylécek között. Rádiós vezérléssel ez jobb híján cover.close_cover lenne):
- alias: Bedroom shutters down on darkness
trigger:
- platform: state
entity_id: input_boolean.darkness_outside
to: 'on'
action:
- service: cover.set_cover_position
data:
entity_id: cover.haloszoba_redonyok
position: 10
ahol a darkness_outside input_boolean-t egy külső világosságszenzor vezérli (azért így külön, mert több automatizálás is fölhasználja, és ne legyen mindenhol küszöbérték definiálva, csak egy helyen, és mint input_booleant, felületről kézzel is könnyen lehessen kapcsolni/tesztelni). Van, aki ugyanerre a Nap állását használja.
- alias: Switch on darkness outside
trigger:
- platform: numeric_state
entity_id:
- sensor.brightness_outside
below: 10
action:
- service: input_boolean.turn_on
data:
entity_id: input_boolean.darkness_outside
Hőmérséklet alapján nem tudom, lenne-e értelme, de ugyanígy lehet numeric_state aszerint is.
[ Szerkesztve ]
-
Degeczi
nagyúr
Értem, de nem hiszem, h ezt érdemes automatizálni, csak nyűg lenne vele, ha kellene a fény - de épp 24 fok fölé ment és az automatizálásod lehúzza...
A nappaliba most rakok föl majd redőnyöket, ott pl. lesz még olyan, h ha a TV be van kapcsolva és a Nap alacsonyan jár, akkor csak annyira lehúzni, h épp a képernyő le legyen majd árnyékolva. De ezt is csak akkor, ha megy a TV, különben jobb a fény.
-
Chal
addikt
Nem kell külön, ami benne van, azt automatán include-olja. Szerencsére az userek is kezdenek rákapni, egyre több olyan nagyobb volumenű (értsd: akár 100+ soros config) példánál látok olyat, hogy package alapon osztja meg az illető githubon vagy a HA coummunity fórumon. Roppant kényelmes is beemelni/személyre szabni.
[ Szerkesztve ]
-
szat8
tag
Egy lehetséges megoldás az, ha a Nap járáshoz igazítod a redőny állásokat.
Először kell hozzá két sensor, amik a nap magasságát és irányát figyelik.- platform: template
sensors:
sun_elevation:
friendly_name: "Sun Elevation"
unit_of_measurement: '°'
value_template: "{{ state_attr('sun.sun', 'elevation') }}"
- platform: template
sensors:
sun_azimuth:
friendly_name: "Sun Azimuth"
unit_of_measurement: '°'
value_template: "{{ state_attr('sun.sun', 'azimuth') }}"Aztán megfigyeled, melyik azimuth szögnél hol süt be a Nap, és csinálsz hozzá thresholdokat. Pl.:
# napsütés délnyugati homlokzaton
- platform: threshold
name: "sun azimuth dny"
upper: 120
lower: 90
entity_id: sensor.sun_azimuthAztán csinálsz 2 automatizmust.
Az egyik, hogy húzza le a redőnyt, ha a threshold on-ba kapcsol (ez a trigger), és condition-nak megadod, hogy a Nap magassága legyen valami fix érték felett, tehát már feljött a Nap (mondjuk above: 20), és hogy a hőmérséklet 24°C felett van.
A másik, hogy húzza fel a redőnyt, ha le van húzva, a threshold az adott homlokzaton off-ba kapcsolt, és még fent van a Nap.Nekem is a listámon van ennek a kipróbálása, de a tavaszig/nyárig kivárok.
Szerk.: Bocs, a szóközöket telefonon mindig elszúrja, de legalább kicsit gyakorolhatod a szintaktikáját.
[ Szerkesztve ]
-
fo_di
őstag
https://community.home-assistant.io/t/automation-help-sunrise-and-sunset/95072/7
ez talán azt mutatja, amit te is akarsz[ Szerkesztve ]
-
fo_di
őstag
https://www.home-assistant.io/docs/automation/
erre gondolsz? a jobb oldali menüben vannak további pontok -
Chal
addikt
Ilyet nem fogsz találni, mert az egyes szekciók ezerféleképpen kombinálhatóak. IF/ELSE és AND/OR kapcsolatok bárhol lehetnek, no meg egyéb más is. Ebből adódóan lehetetlen lenne olyan doksit írni amilyet szeretnél. A HA előnye egyben a hátránya is e miatt, azaz a learning curve eleje roppant lapos, viszont cserébe meg lehet benne csinálni natívan bármit (így nincs szükség külső scriptekre, Node Redre, és egyéb előtét megoldásokra). Valamint a HA doksija feltételezi azt is, hogy nem nulláról kell magyarázni magát a leírónyelvet (a yaml-t).
-
Degeczi
nagyúr
A trigger a kiváltó esemény. Mivel ott csak a napfelkeltét említed, feltételként pedig hogy 7 után legyen, így ha már 7 előtt följön a Nap, nem fog történni semmi, hiszen nem teljesült a feltételed.
Ha azt szeretnéd, h 7-kor mindenképpen húzza föl a redőnyt, akkor a trigger: részbe egyszerűen beírod azt is, h
- platform: time
at: '07:00:01'
és akkor máris van olyan triggered, ami biztosan teljesül akkor, ha följött a Nap addigra, ha nem.szat8: úgy rémlik, te kombinálni szerettél volna bizonyos feltételeket bizonyos triggerekkel, azt szerintem nem érdemes annyira bonyolítani. Alább viszont ugyanaz a feltétel érvényesülhet mindkét triggerre, ez egyszerű.
[ Szerkesztve ]
-
fo_di
őstag
elvileg ebben a kódban benne van, hogy mit talál meg a workday szenzor (a python kódot importálja a rendszer)
aclass Hungary
részben benne van, vagyis nem kell külön megnevezni (235-349 sorok):
- január 1
- március 15
- nagypéntek (2017 utáni dátumokra)
- húsvét vasárnap
- húsvét hétfő
- pünkösd vasárnap
- pünkösd hétfő
- május 1
- augusztus 20
- október 23
- november 1
- december 24
- december 25-26
elviekben a kódban szerepelnek 2010 utáni dátumokra a keddi ünnepek előtti és a csütörtöki ünnepek utáni pihenőnapok, de a dolgozós szombatok nincsenek benneezen kívül szerepel még benne 1950 és 1989 közötti időszakra március 21 (tanácsköztársaság kikiáltása), november 7 (nagy október szocialista forradalom)
szabadságokra lehet egyszerűbb egy dedikált naptár a gugli naptáradban, amit megosztasz a home assistanttal
[ Szerkesztve ]
-
Degeczi
nagyúr
-
Degeczi
nagyúr
Itt a napfelkelte triggert rögtön ki is lövöd azzal a feltétellel, h az időpont egyezik-e a beállított értékkel - hiszen az gyakorlatilag sosem lesz pontosan azonos... Ha azt szeretnéd, h a beállított időpont előtt ne menjen föl, akkor ">="-t írj feltételként.
(másrészt kísérletezd ki a fejlesztői eszköztár sablonszerkesztőjével a kifejezést, mert nekem határozottan úgy rémlik, h atimestamp_custom()
csak false paraméterrel adott vissza korrekt helyi időt - bár ez elképzelhető, h a rendszer beállításaitól is függ) -
kenand
veterán
Vannak látványosabb frontendek Home Assistanthoz, de csak akkor mennek ha https-en éred el.
Más:
Egy Gigabite BRIX-en fut a Xpenology, VM-ben (Ubuntu) azon, Hass.io (Home ASssistant) sajnos a bluetoooth szenzorokat elégé roblémásan kezeli
sudo hcitool lescan
Parancsot kiadva keresi a BT eszközöket,m majd input errorral kilép
Így nem igazán tud ja a szenzorokat sem biztonsággal ismételten lekérdezni.
Legújabb 5.50 Bluez-t fordítottam hozzá. -
kenand
veterán
Én is google-vel kerestem
Pl dashboardDe 1 éve találtam másokat is, de nem tudtam synology alatt megoldani a https-t.. idén meg még nem álltam neki
[ Szerkesztve ]
-
szat8
tag
Pár nagyon egyszerű dologgal felturbózott sima HA felület van a képen.
A grafikonokat pl ezzel csinálta, nagyon pofás egy egyszerű:
mini graph card -
kenand
veterán
Pálma fűtésről írok, pü-ben nem akarom szétoffolni a fórumot
De ha valakit érdekel itt vannak képek, megoldások, takarásról és fűtésről.[ Szerkesztve ]
-
Rolly
veterán
Így sikerült úgy néz ki megoldani a delayt:
action:
- service: cover.open_cover
entity_id: cover.kitchen_shutter
- delay: 00:00:02
- service: cover.open_cover
entity_id: cover.kids_room_shutter
- delay: 00:00:02
- service: cover.open_cover
entity_id: cover.livingroom_court_window_shutter
- delay: 00:00:02
- service: cover.open_cover
entity_id: cover.livingroom_court_door_shutter
- delay: 00:00:02
- service: cover.open_cover
entity_id: cover.working_room_street_shutter
- delay: 00:00:02
- service: cover.open_cover
entity_id: cover.working_room_court_shutter -
Degeczi
nagyúr
Ha a logban jelzi a Sonoff a parancsot, akkor valóban egyértelmű, h nem az automatizálásodban a hiba, hanem a rádiós redőnyök egy újabb komoly hátrányáról van szó.
Pont a lényeget, a delayt viszont ide nem írtad be..
Így csak találgatni lehet, h ha azt az id-k fölsorolása közé szúrtad be, akkor persze, h nem jó úgy, hiszen ahhoz külön service hivásokat kell létrehozni mindegyikhez, és egy-egy service: sor elé kell tegyél egy rövid delayt.Szerk: akkor jól sejtettem
[ Szerkesztve ]
-
Degeczi
nagyúr
Ezért is jó az Appdaemon, mert az folyton figyeli a script mappáját, és amint rámentesz ott bármelyik file-ra, azonnal újraolvassa a tartalmát, és máris életbelép a változtatás. De persze ilyen egyszerű automatizáláshoz bőven elég a yaml.
Amúgy látatlanban ez a Sonoff Bridge (mert gondolom azzal adod ki a parancsot), ill. annak firmware-ének a hibájának is tűnik, hiszen ha az szünet nélkül is kap egymás után több parancsot, félre kell tennie azokat egy pufferbe, és szép sorban egymás után lejátszania, nem szabad akadnia, vagy félbehagynia egy korábbit. Bár mivel ezt valszeg így is teszi, talán a redőnyök hülyesége, h egy érvénytelen (másnak szóló) parancs érzékelése után kell nekik kis idő ahhoz is, h a sajátjukat érzékeljék? Fene tudja.
A 433-as eszközökkel épp az a gond, h egyirányú a kommunikáció, és ütközéskezelés sincs az egyetlen, közös frekvencián, így sosem biztos a parancsok megérkezése. Az is megeshet bármikor, h pont akkor kezd adni egy mozgásérzékelő vagy hőmérő (akár a szomszédban...) amikor a redőnyöknek menne a parancs, és majd azzal akad össze.
Egy hőmérőnél vagy mozgásérzékelőnél ez nem nagy gond, majd átjut a következő adása ha egy el is veszett, de ilyen vezérlésnél komoly hátrány. -
KevinMulder
tag
Az átlagfelhasználók nagy része hőmérséklelet akar mérni, kazánt vezérelni, lámpákat kapcsolgatni. Egy akármilyen okosotthon rendszernek ezeket illik tudnia. A HB ezt tudni fogja, a pluginokra lesz lehetőség. Nem szégyen tanulni a nagyoktól vagy az egyes drivereket átemelni onnan.
-
KevinMulder
tag
A miért választaná a HB-t bárki kérdésre ebben a pillanatban nehéz jól válaszolni. Mert ilyen rendszerek esetében nem az egyes modulok az érdekesek, hanem az egész összessége, a feelingje. A rendszer és a körülötte lévő ökoszisztéma az, ami tetszik vagy nem tetszik az embernek.
Én ebben a pillanatban azt tudom csak mondani, hogy a HB ökoszisztémája és működési modellje eltér a 3 nagytól. Alapvetően decentralizált lesz, azaz pl. tetszőleges számú RPi-t szétdobálhatsz a házban, a rendszer bizonyos korlátok között túléli ha pár kiesik a rendszerből. azaz a központi gép letérdelése esetén a ház még - valamilyen szinten, de kontrollálható marad.
A másik nagy eltérés, hogy a HB-ben nincsenek PHP részek és weboldal generálás, ami szerintem egy borzasztóan insecure dolog. A HB webassembly platformot használ, így a böngészőkben sokkal kompaktabban foglal helyet. Az interakció is közvetlenül socketeken keresztül megy, ami ugyancsak segít a megbízhatóság fenntartásában.
Az elképzelt modell szerint ugyanaz az alkalmazás indul el mind a nem grafikus (embedded), mind pedig a grafikus rendszereken. Így pl ha van egy Rpi+TFT kombód, akkor ennek az egyetlen alkalmazásnak kell futnia, nem kell alá semmilyen böngésző vagy egyéb közbülső réteg.
A pluginokra visszatérve, az okosház rendszereknél nagy csodák nincsenek. Nagyon kevés kivételtől eltekintve általában valami protokollillesztés a feladat, Nem olyan komplikált, mint egy képelemzés (Tesla autopilot és hasonlók). Az tény, hogy sok plugin van, de egyik sem atomfizika, csak sok gályamunka azokat átírni.
Egyébként meg naponta 2x vagyok egy órát vonaton, s untakozom, szóval valamivel el kell töltenem az időt
Tőletek csak annyit kérek, hogy azért ne zárkózzatok el a kipróbálása előtt Legalább itt lehettek a születésénél ... -
fo_di
őstag
a command line a rendszer saját parancssorán fut, tehát dockerben lévő rendszer esetén dockerben, ha ott nem fut le a parancs, akkor nem fog automatizálásból sem
esetleg meghívhatsz egy olyan scriptet, ami a hostra ssh-zik és ott futtatja le az eredményt? vagy esetleg a hoston írsz egy python scriptet, ami pubsubbal figyel egy megfelelő mqtt topikot és azzal hívod meg a command line scriptet? akár az eredményt is vissza tudod nyomni mqttbe -
ojb
tag
"...szerintetek merre induljak el? ..."
Én először is ellenőrizném, hogy a tervezett telepítési helyekről (talajszint!!!) belát-e stabilan a Wemos D1 a routerig. A fűben sok-sok helyen leellenőrizném és beállítanám "hitelesíteném" az érzékelőt, természetesen több nedvességi állapotot figyelembe véve. (Az érzékelő a talaj vezető képességét méri, ami nagyban függ az oldott ásványi anyagok, ionok, karbonátok stb -- tápoldatok, műtrágyák-- mennyiségétől és természetesen a víztől is. Viszont figyelembe kell venni és ki kell tapasztalni , mert hasonló "mérési eredmény" keletkezhet egy kevésbé, de mélyen átázott talajban és egy sekélyen belocsolt de sok nedvességet tartalmazó vagy jobb vezetőképességű talajrészben.) Én lehet bepróbálnék olyan érzékelő szondát, ami inkább a gyökérzónában mér. [kép][ Szerkesztve ]
-
Degeczi
nagyúr
Egyszerűen egy template kifejezésben beszorzod amennyivel kell, és kerekíted. A Fejlesztői eszközok/Sablon fülén így kikísérletezett kifejezésből pedig pl. csinálsz egy template sensort, amit már bárhol fölhasználhatsz.
Új hozzászólás Aktív témák
- Betelik a pohár: nagy igény lenne a gyorshajtás-ellenes technológiára
- Okos Otthon / Smart Home
- Szeged és környéke adok-veszek-beszélgetek
- Épített vízhűtés (nem kompakt) topic
- Robot fűnyírók
- Revolut
- Motoros topic
- Honor Magic5 Pro - kamerák bűvöletében
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Politika
- További aktív témák...
- Prémium autómatricák kedvező áron! PH tagoknak 30% kedvezmény!
- Riwall PRO RALM 4640 SPi,40V AKKUS ÖNJÁRÓ 46CM FŰNYÍRÓ, TÖLTŐVEL 4DB 4Ah AKKUVAL ELADÓ 2ÉV GARANCIA
- Robot porszívó Mi Robot Vacuum Mop 2 Pro eladó
- DAH Solar 405W full black napelemek verhetetlen áron
- Steelcase acélvázas íróasztal/számítógépasztal 120x80x70cm kábelrendezővel 40kg