-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
ojb
tag
A képpel én nem a hőmérséklet eltérésre, hanem a jelentési gyakoriság különbségére utaltam...
Nekem a kerek hőmérők "nagyon" együtt járnak.
Volt, amikor 4db jött egyszerre, azokat az asztalon egymás mellé téve ellenőriztem néhány napon keresztül "változó" szobahőmérsékleten.
Meglepő volt, hogy az egymáshoz képest mutatott hőmérséklet eltérés 0.3°C -on belüli volt és együtt mozgott ill a páratartalom mérés eltérése is 5 % -on belüli volt.
Nálam a jelzett kerek hőmérők már egy éve mennek az eredeti CR2450-es elemmel és ezekből a szenzorokból 4db median értéke biztosítja a fűtés vezérléséhez a trigger -t is
a "gyorsaságuk" (relatív sűrű jelentésük) miatt. -
ojb
tag
Segítséget kérek...
Nyáron, éjjel nyitott ablakban kellene "betörőt" érzékelni.
Az ablakon belül a lakók, kívül macskák, sünök ogrék stb mozoghatnak, előfordulhatnak az esetleges behatolókon kívül, tehát ezen téves riasztások elleni védelem szükséges.
Csak elemes megoldás jöhet szóba.
Lehet ablakon (szúnyoghálón) belüli, de kívüli megoldás is.
Minden ötletre nyitott vagyok -
ojb
tag
Z2M (szenzor) használatakor van arra lehetőség, hogy az LQi a "másik" irány értékét (is) mutassa?
Alapértelmezésben (End Device) a Coordinátor -> Szezor irány az LQi értéke, de nekem a Szenzor -> Coordinátor irány értékére (is) szükségem lenne.
Vagy hasonlóan akár mindkét irányra, mint Coordinátor < - > Router esetében[ Szerkesztve ]
-
ojb
tag
válasz madoxx #45999 üzenetére
"Szeretném ha lenne hülyebiztos megoldás (kiesett a wifi/HA/akármi, de áram még van), így az RF táviránytós megoldás felé hajlok."
Van elegánsabb megoldás:
A Buta redőnymotor vezérlése:
- Mechanikus kapcsolóval
- RF 433 távirányítóval (egy vagy több csatornás)
- RF 433 Fali nyomógombbal ( A mechanikus helyett pl, ha nincs cső a redőnytok és a kapcsoló között)
- ZigBee HA integrálhatóság vagy közvetlen Bind a ZB scene vagy ZB fali scene kapcsoló és a relé között.
- Google - Amazon hangvezérlés- Elméletileg [ezze] a ZB relével megvalósíthatóak a fentiek.
Dőlt szöveg mutatja azokat a lehetőségeket, amikor csak áram van
-
ojb
tag
válasz enginev3.0 #46029 üzenetére
"tököm ki van ezzel a gyenge zigbee térerővel, pedig vannak a házban routerek is zbminik,"
Célszerű némi odafigyeléssel a ZB és a WiFi hálózatot "összehangolni"
A szolgáltatói és általában a SoHo routerek a háron "nem átfedéses" csatornát (ch1 ; ch6 és ch11) használják előszeretettel auto beállítás mellett is 20MHz sávszélesség esetében.
Szerencsére a WiFi ch12 és ch13 aránylag tiszta, sőt sok szolgáltatói WiFi router default nem használja. Ebből következik, hogy a ch25 és ch26 -os ZB csatorna "talán" a legkevésbé zavart terület.
A Z2M default a ch11-es ZB csatornát használja (ami kökeményen benne van a WiFi ch1 -ben) a ZHA úgy emlékszem a ch15-öt (ami már sokkal jobb helyen van, kivéve, ha valaki a közelben pont az átfedéses ch3 - 4 - 5 wifi csatornát szeretné használni 20 vagy 40 MHZ-en).
A helyi környezet WiFi terhelése alapján már ez is okozhat működésbeli különbségeket a Z2M és ZHA között.
2.4GHz-en a WiFi megközelítőleg tízszeres teljesítménnyel ad, mint az elemes szenzorok ill a ZB routerek többsége.
Ez ellen csak megfelelő "frekvencia tervvel" lehet hatásosan védekezni.
A ch25 ZB csatorna biztosan működik mindenféle kínai vacakkal is, ugyanis én ezt használom.
Sőt pont az a baj hogy az LQi szerint túl jó a hálózat... Túl sok a 255-höz közeli érték -
ojb
tag
válasz fejesi #46072 üzenetére
"Nincs már ötletem, mit tehetnék még."
lsd #46047 hsz
Első körben állítsd át a WiFi routeredet 20/40MHz-ről 20MHz-re.
Sajnos nem tudni, hogy a SonOff mely ZB csatornát használja default (jó eséllyel a 15-öst), ezért a WiFi router-t auto-ról manualra állítva 20MHz-es sávszélesség mellett be kell állítani a ch1-re, majd próbálkozni és ellenőrizni, hogy változott-e valami..
Amennyiben nem, akkor meg kell próbálni a WiFi routeren a ch11-es csatornát használni.
Jó eséllyel az okozza problémát, hogy a router 40MHz-s sávszélességet használ és pont olyan frekvencián( csatornán ) üzemel, ami a ZB bridge-et zavarja. Legfőképpen azért, mert a SonOff bridge-ben egymástól néhány centiméterre van a ZB és a WiFi
Esetleg egy kérdést megér a SonOff irányába, hogy a ZB csatorna állítható-e a bridge-ben. -
ojb
tag
Kettő év használati tapasztalatai alapján megvalósítható. amit szeretnél...
Mindent végigcsináltam előtte én is.
Ami nálam működik (is):
Konyhában "egyszerű" 100mm-es csőbe rakható fürdőszobai HŐCSERÉLŐS ventilátor, aminek a hőcserélője NEM ENTALPIÁS!!!
Éjjel nappal ~20m3/óra üzemmel működik!
HA nincs otthon senki és a rel páratartalom nagyobb, mint 65% VAGY a CO2 szint magasabb, mint 1.100ppm AKKOR a szellőztetést megemeli 50m3/órára egy automatizmus.
A ház alapvetően padlófűtéses radiátoros kiegészítéssel.
Fűtési szezonban a reggeli 21°C -> 22°C -ra váltáskor a radiátorokra szerelt TRV-k kinyitnak és "besegítenek" a levegő gyors felmelegítésébe és ezzel együtt a helyiségekben meg is forgatják - keverik a levegőt. (felfelé szálló meleg levegő)
Az esti hőmérséklet csökkentéskor zárnak a TRV-k.
Mióta ezt a setup-ot használom megszűnt a penész, amit előtte évekig nem sikerült kiküszöbölni!!! -
ojb
tag
válasz Eclips21 #46259 üzenetére
Az LQi értékét a Coordinátor (Router) -> Szenzor irány tulajdonságai határozzák meg szenzor esetében.
A Te esetedben a 0 erre az átviteli irányra jellemző értékekből képződik.
Természetesen a 255-ös LQi érték ugyan úgy használhatatlan érték, mint a 0.
Szerencsére a másik irány (Szenzor -> Coordinátor) a fontosabb pl a hőmérő esetében.
Pont erről írtam az előző hozzászólásomban, hogy ez így önmagában nem sok információt hordoz... és ezért kérdeztem, ismer-e valaki olyan megoldást, hogy end device -ok esetében is a routerekhez hasonlóan mindkét átviteli irányt ki lehessen csikarni a Z2M-ből.
Félek, hogy valami bug lehet a Z2M-ben, ami ezeket a fals értékeket generálja, de az is elképzelhető, hogy az egész ZB hálózatot "megborítja" a SonOff Dongle -E fix +20dBm-es kimenő teljesítménye plusz egy 6dBi -es Omni antenna az eszköz végén.
Pont ezekről az anomáliákról írtam régebben néhány hozzászólásban.
(A 255LQi alapján a szenzor azt hiszi, hogy szuper a hálózat és mindenáron a legmagasabb értékű eszközhöz (jelen esetemben a Coordinátor-hoz) szeretne kapcsolódni, mert azt hiszi, ha ő ilyen jól hallja a Coordinátort, akkor majd az is ugyanilyen jól fogja hallani őt.)
Na ez a valóságban nem biztos, hogy így is van...
Szóval a nagy teljesítményű (+20dBm) Coordinátorok -- és ide tartoznak a Routerek -- is (jellemzően pl a SonOff -P és -E ) jól megkeserítik az átlagos ismeretekkel rendelkező user-ek életét, főként az -E , aminek a kimenő teljesítménye -- ismereteim szerint -- nem szabályozható, ellentétben a - P -vel, aminek viszont beállítható (visszább vehető) a Tx Power-e, aminek hatására homogénebbé tehető a ZB hálózat. -
ojb
tag
válasz kekigyu #46385 üzenetére
Az általánosan elterjedt bojlerek fűtőszála < 2.5kW , ami ~10A-es áramot jelent tartósan.
Ekkora terhelést stabilan elviselnek a 16A-re méretezett eszközök. Általában akkor is , ha kínaiak. (Évek óta üzemeltetek 2.5kW-os hősugárzókat 16A-es kínai okoskonnektorokon keresztül. Hiba nélkül, stabilan.)
Amennyiben a kérdéses bojler teljesítmény felvétele nagyobb, mint a jelzett max 2.5kW nem célszerű ezeken a konnektorokon keresztül üzemeltetni.
Sőt semmilyen konnektoron keresztül, hanem csak fix bekötéssel! -
ojb
tag
Kicsi eséllyel fogsz RTC-vel szerelt gyári eszközt találni,
de lehet csinál(tat)ni...
Egyedül arra kell figyelni, hogy a vezérlő még ESP8266 legyen
A DS3231-es RTC modul [link] nagyon könnyen integrálható pl akár a SonOff Basic-be is.
A Tasmota és az ESPEasy is támogatja.
Pl SonOff Basic R1 programozó tüskéire dugva... -
ojb
tag
válasz koala69 #46490 üzenetére
Szinte tökéletes az elgondolásod.
Talán annyi kiegészítés, hogy optocsatoló esetében tranzisztorra sincs szükség, csak
egy db ~ 3.3kOhm -os collector ellenállásra az ESP oldalon feltéve hogy csak trigger jelnek szeretnéd használni.
A DSC oldali dióda munkaellenállása a sziréna irányába kiadott feszültségtől függ.
Nagy valószínűséggel DC12V lesz. Tehát 10 - 15kOhm-os ellenállásra lesz szükség.
Arra figyelj, hogy az optocsatoló két oldalán található "GND"-k lehetőleg ne legyenek összekötve. Kivéve, ha az ESP is a DSC tápjáról fog üzemelni.Látom közben Degeczi kolléga prezentált rajzot is...
A fent leírtak alapján az optocsatoló a PGM használata esetében is tökéletesen megvalósítja a "szintillesztést"[ Szerkesztve ]
-
ojb
tag
válasz ftamas0201 #46742 üzenetére
Én inkább pl ebbe az irányba mennék...
-
ojb
tag
-
ojb
tag
válasz kekigyu #46823 üzenetére
Mindkét eszköz tökéletes választás lehet.
A Dongle E annyival van talán előbb, hogy a HA is ugyancsak az EFR chipet alkalmazza a SkyConnect USB ill a Yellow eszközeiben is...
Erre a chipre már elkészült a multiprotocol támogatás HA alá, a P -re még -- ismereteim szerint -- nem.
Attól, hogy a Z2M oldalán az E "nem támogatott" még tökéletesem működik.
(Mindkettő eszközből használok és nem tapasztalok alapvető különbséget közöttük működési szempontból) -
ojb
tag
válasz Nerazim #46887 üzenetére
A SonOff annyival több, hogy az antennáját szükség esetén letudod cserélni nagyobb nyereségűre. A ZB-GW04 is tökéletes választás a maga PCB "gömb sugárzó" antennájával.
HA esetében az ezen eszközökben használt chip-ek a preferáltak jelenleg. (SkyConnect ill.
HA Yellow) a multiprotokol lehetősége miatt. -
ojb
tag
Mivel eddig nem találtam az alábbiakról bejegyzést a topikban, ezért kipróbáltam és...
Tegnap ill. ma, kíváncsiságból létrehoztam az első Thread/Matter hálózatomat HA alá az alábbi eszköz segítségével.
Open Thread Border Router firmware-t írtam rá és nem a MultiPan RCP-t.
Így egy olcsó a ZB Coordinátortól független OTBR-t sikerült készíteni.
(Ezért pl nem szükséges lecserélni a "régi" és jól bevált CC2562xxx-es chipre készült ZB Coordinátorokat)
Jelenleg szépen együtt dolgozik a ZB hálózattal.
A ZB a 25-ös az Thread a 11-es csatornát használja.Az OTBR és a Matter Server addon-okkal sikerült életre kelteni HAOS alatt.
és természetesen szükséges ezen addon-ok integrációja is.
Jelenleg az egyetlen Thread érzékelőm teszt üzeme tart. (Aqara P2) /A Tasmota egy virtuális Matter kapcsoló a Nest hub alá/
Amint lefut a teszt és kellő információt nyújt a "hálózat" a megbízhatóságáról kipróbálom a MultiPan RCP-t is.Viszont aki kitalálta, hogy ez az egész Thread/Matter az egyszerűbb és átjárhatóbb "smartHome" integrálhatóság miatt van az finoman szólva nyalja meg a sarkam...
[ Szerkesztve ]
-
ojb
tag
válasz hun005a #47109 üzenetére
Elvileg a Tuya szoftver Setting menüjében lenni kellene egy Relay Status sornak
Ebben kell Memory vagy Remember last status - ra állítani ahhoz, hogy emlékezzen az áramszünet előtti állapotra vagy pedig On-ra kell állítani, hogy boot után állandóan bekapcsolja a relét.
-
ojb
tag
válasz ViZion #47112 üzenetére
Igazad van
Helyesebb lett volna az "Elvileg... " helyett úgy kezdeni a mondatot, hogy
"Szerencsés esetben a Tuya szoftver..."
(Sajnos nem minden esetben lehet ezt az opciót elérni. Nekem is van kettő BW konnektorom -- elvileg a SmartLife app-hoz kapcsolódnának -- amiknek eltűnt az évek alatt ez a relé beállítási lehetősége a Tuya app-ból) -
ojb
tag
...,ha már szóba került.
Vezérelt (szabályozott) fűtés esetében hogyan tudjátok elkerülni a " felfűtési effektus" kialakulását?
Lehet én csinálok valamit rosszul?
Amennyiben 2°C nagyobb az Away - Home hőmérséklet különbsége a vezérelt rendszeren a felhasznált energiában nem látom megtérülni, ha hagyom "nagyon" lehűlni a lakást. -
ojb
tag
válasz brickm #47268 üzenetére
"... ha pl elvesztik a kommunikációt egymással (HA és az eszköz),..."
Ezt az infót honnan szerzi be az ESP?
Mit használsz "handshaking"-nek? / A HA < - > ESP kapcsolat folyamatos ellenőrzésére /
( WiFi loss ; MQTT loss ; KeepAlive delay )
Talán a legegyszerűbb ezt a jelet felhasználni triggernek... -
ojb
tag
A SiliconLabs Zigbee/OpenThread Multiprotocol Add-on használatával sikerült már valakinet a ZigBee mellé Thread/Matter eszközt is integrálni HA alá?
Kérdésem lenne... -
ojb
tag
válasz tsilver #47622 üzenetére
A gyorsaság relatív...
A hőmérséklet változás sebessége erős befolyásolási tényező.
Valóban a ZB eszközök nem jelentenek túl sűrűn, ha nem változik a hőmérséklet, de begyorsulnak abban az esetben, ha pl elindul a fűtés elkezd melegedni a környezeti hőmérséklet.
Valóban fűtés vezérlésére egy ZB eszközt használni nem túl megbízható...,
de pl három olcsó ZB pl. [kép] hőmérő elhelyezve a helyiség különböző pontjain, majd a mért hőmérséklet átlag vagy median értékét felhasználva a kazán kapcsolgatására már nem is olyan rossz dolog, mert három eszköz úgysem egyszerre jelent ill. pihen, hanem különböző időpontokban...
Ez a jelentés gyakoriságát igen - igen betudja sűríteni a HA esetében alkalmazott min/max integráció [link] kimenetén.
Az átlag (median) értéken kívül az esetlegesen "lehaló" szenzorok esetében is biztonságot nyújt ui. egyszerűen kihagyja őket.
A fenti képen látható szenzor vezéreli a fűtéseimet.
A konvektorokat egy - egy a kazánt pedig összesen 4db -- a nagy légtér (összenyitott nappali ; előszoba ; étkező és konyha) miatt különböző helyeken elhelyezett -- szenzorok mediánja kapcsolgatja.[ Szerkesztve ]
-
ojb
tag
Ehez hasonló feldatot kettő automatizmussal oldottam meg.
Lehet nem oly elegáns, de működik...description: "Ventilator On"
mode: single
trigger:
- platform: time_pattern
minutes: /1
condition:
- condition: or
conditions:
- condition: numeric_state
entity_id: paratartalom
above: 60
- condition: numeric_state
entity_id: bogi_homero_paratartalom
above: 60
action:
- service: switch.turn_on
data: {}
target:
entity_id: switch.aljzat_3description: Ventilator Off
mode: single
trigger:
- platform: time_pattern
minutes: /1
condition:
- condition: numeric_state
entity_id: bogi_homero_paratartalom
below: 58
- condition: numeric_state
entity_id: paratartalom
below: 58
action:
- service: switch.turn_off
data: {}
target:
entity_id: switch.aljzat_3Természetesen az entity_id-k nem biztos, hogy helyesek
[ Szerkesztve ]
-
ojb
tag
Ezek automatizmusok...
Percenként lefut mindkettő.
A Ventilator On ellenőrzi, hogy a páratartalom vagy a bogi_homero_paratartalom értéke nagyobb-e mint 60%. Bármelyik igaz esetében bekapcsolja az aljzat_3 -at.A Ventilator Off azt nézi, hogy a páratartalom és a bogi_homerő_paratartalom értéke kisebb-e mint 58%. HA mindkettő igaz kikapcsolja az aljzat_3 -at
Természetesen a percenkénti futtatás helyett használni lehet a páratartalom mérő entitások változását is triggernek.
mode: single
trigger:
- platform: state
entity_id:
- sensor.páratartalom
- sensor.bogi_homero_paratartalom
condition:
- condition: or
conditions:[ Szerkesztve ]
-
ojb
tag
válasz szabifotos #48064 üzenetére
"Mi lehet a megoldás?"
A vevő újratanítása, de előtte a memóriájának a teljes törlése!!!
Az RF vevők általában nyolc egymástól független, különböző kódsort képesek megtanulni és kapcsoló parancsként értelmezni. (Nyolc különböző távirányító vagy kapcsoló)
A tanítási folyamat alatt sajnos előfordulhat, hogy nem a kívánt távirányító jelét tanulja meg a vevő, hanem pl a szomszéd éppen akkor sugárzott adatsorát.
A felhasználó ezt általában észre sem veszi és megismétli a tanítást... ennek hatására...
A vevő máris kettő adatsort ismer, mint kapcsoló jel.
Ue történhet abban az esetben is, ha tévedésből valamiért a vevő "learning" módba kapcsolódik...
A felhasználó nem akar tanítani, hiszen nem nyomkodja bőszen a távirányító (kapcsoló) gombját, de a környékbeli szomszéd ezt nem biztos, hogy tudja.[ Szerkesztve ]
-
ojb
tag
válasz Degeczi #48080 üzenetére
Maximálisan egyetértek veled.
Valóban "nehézkesebb" a használata, mint a korszerű ZB vagy BLE eszközöké.
Bár hozzá tartozik az is, hogy évekkel ezelőtt nálam egy RF433-as (GS-WDS07) door sensor küldte be a gázóra impulzusait SonOff Basic-on keresztöl, amiben egy RX480R vevő fogadta a 433MHZ-es OoK jelsorozatokat.
Kettő vagy három szezonon keresztül dolgozott igen - igen nagy biztonsággal és pontossággal. Évente ~ 8.000 impulzust számolt meg és továbbított a Domoticz irányába.
Semmivel sem volt megbízhatatlanabb, pontatlanabb, mint a jelenleg használt ZB adót használó rendszerem. -
ojb
tag
válasz RobbeV0201 #48071 üzenetére
Beszerelt WiFi modul esetében a Gree SmarHome nem jó ???
Google Home -on keresztül elvileg láthatja a Nest Hub is. -
ojb
tag
"Melyik notificationre gondolsz?"
A Push valóban ilyen...
Napi 500 a korlát.
Csak az engedélyezéshez kell a mobil app.
Később anélkül is fogadni tudja a telefon az üzeneteket, de természetesen a HA-nak ki kell látnia. DE csak ki!!!
Feltételezem a szükséges update-k miatt, amúgy is állandóan hazalát a HA... -
ojb
tag
válasz v.attis #48216 üzenetére
"fel lépne-e a Faraday kalitka jelenség...?"
Igen !
Viszont jó eséllyel talál valami lukat a kazán alján, ahol ki - be tud bújni a 2.4GHz-es jel.
Én a kazán aljára ragasztottam egy pici műanyag szerelődobozt és abban van a jelfogó,
Onnan kábeleztem tömszelencéken keresztül a tápot és a kapcsoló jelet.
Mivel vezérlésről van szó mindenképpen érdemes ellenőrizni a nagyon stabil WiFi kapcsolatot ( > - 65 - 60 dBm) vagy erősen ajánlott a " keepalive" alkalmazása !
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Promenade Publishing House Kft.
Város: Budapest