-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
ojb
tag
Látom szóba kerültek a CC2652 -es coordinátorok.
A CC2652P vel vagy a CC2652P2-vel van már valakinek tapasztalata? -
ojb
tag
@szat8 #2583
"de a wifis hamarabb lemerülne"
Ebben az esetben nem jöhet szóba az ESP -k deepsleep lehetősége?
Nem vagyok biztos benne, hogy percenkénti sűrűséggel szükséges jelenteni a talajnedvesség állapotát Egy 3.000mAh akkuról azért elég sokáig képes üzemelni egy ESP (deepsleep használatával), főleg, ha van a tetején egy kicsi napelem
@zsamiatt #25082
"Tapanyag figyelest is meg lehet oldani valahogy?"
Igen, de ehhez a nedvességen kívül már többek között a talaj PH értékét ; elektromos vezetőképességét stb szükséges mérni.
Itt már minden mindennel összefügg...
Egyszóval ezeket az adatokat mérni is "drága", nemhogy monitorozni. (Egészen más eszközök, mérési elvek szükségesek az "egyszeri" méréshez ill. a folyamatos monitorozáshoz.) -
ojb
tag
válasz llacee #25307 üzenetére
Sikerült beleválasztanod
A GPIO15 le van húzva GND-re.
Valószínűleg a jelfogó meghúzatásához nem, de a "tartásához" elég áram tud átfolyni a lehúzó ellenálláson és az opto-n keresztül.
Próbálj másik GPIO-t használni
Wemos-on D1 - D7 -ig bármelyik jó lehet out-ra.[ Szerkesztve ]
-
ojb
tag
-
ojb
tag
válasz Wheremypony #25456 üzenetére
Feltételezem a redőnytokban van ~230V
Buta redőny motort használnék, amit a redőnytokba (belső ablakkeretre vagy a belső ablaköbölbe a redőny magasságába) épített Shelly 2.5-el vezérelném WiFi-n (HA-n) keresztül.
A Shelly kapcsoló bemenetét a mellé rakott két csatornás RF 433MHz-es vevő [link] ,
az RF vevőt pedig pl az ablak mellé a falra ragasztott dupla RF 433MHz nyomógomb [link] működtetné.
Így megoldható a lokális független működtetés (RF) és az integrálhatóság is aránylag kis (~9$) többlet költséggel. -
ojb
tag
Érdemes áttanulmányoznia [ ezt ] a leírást, segédletet. Nem csak a Chameleon-ra érvényesek a benne leírt dolgok, hanem minden vezetékes rendszer esetében érdemes átnézni és átgondolni -- a villanyszerelővel egyeztetni -- még a beruházás legelején, hogy mit is szeretne megvalósítani a felhasználó.
Az említett Chameleon mellett esetleg el lehet gondolkodni az RS485-ön ( lehetőleg 12V-os) , mint vezetékes és megfizethető gyártó független vezetékes alternatíva. -
ojb
tag
válasz mr.perfect #25444 üzenetére
-
ojb
tag
válasz tboy72 #25673 üzenetére
A linkelt modult nem lehet sorosan flash-elni, mert van rajta valami Elvileg [ezt] lehet
Ha ráforrasztod a modulra a JTag égetéshez szükséges drótokat is a soros + táp mellé és beleteszed egy borítékba, majd elküldöd a címemre szívesen ráteszem a JetHome coordinátort vagy routert, ami már SBL (Engedi a későbbi soros flash-elést is!!!).
Természetesen utána visszaküldöm Neked..
Keress meg privátban, ha érdekel...
-
ojb
tag
válasz tboy72 #25669 üzenetére
" (Pedig azt írják, hogy ez űberfrankó)"
Szereztem némi tapasztalatot a kérdéses modullal (CC2538 + CC2592 PA)
Mielőtt valakiknek túlzott elvárásaik lennének megosztanék néhány tényt:
Nagy előny, hogy olcsó. Viszont, ahhoz hogy használható legyen kell még rá költeni.
(PCB; kiegészítő alkatrészek a soros vagy USB-s panelhez ; doboz stb) ami még néhány ezer Ft költséget jelent. Ez alól kivétel, ha router-ként van használva, mert ebben az esetben csak egy 3.3V-os tápegység kell hozzá.
Előny: "Lórugásnyi" kimenő teljesítmény +20 - 22dBm (Ez min 10 szerese az általánosan elterjedt modulok adó teljesítményének)
Sok leírás szerint ez 800m áthidalható távolságot jelent szabad téren, ami valljuk meg valóban tekintélyes távolság ZigBee esetében. Azt viszont elfelejtik megemlíteni, hogy ez csak, akkor eredményez használható kapcsolatot, ha a "másik" oldalon is hasonló teljesítménnyel adó eszközzel tud kommunikálni. Lefordítva... Hiába építek a CC2538-ból coordinátort az áthidalható távolságot a szenzorok (adóteljesítménye) fogja meghatározni és nem a coordinátoré. Az általánosan elterjedt ZigBee szenzorok kimenő teljesítménye töredéke a CC2538-énak. Tehát a CC2538 hiába kiabál el 800m-re, ha csak a 20m-re levő szenzorokat hallja meg, mert sajnos süket, mint az ágyú. (Jelentősen érzékenyebb eszközök is vannak a piacon)
Akkor mire is jó??? P2P (peer to peer) kapcsolatok kialakítására.
Egyet pl Routernek flash-elve összegyűjteni az emeleten, udvarban, pincében stb az eszközök jeleit és nagy teljesítménnyel biztonságosan messziről elküldeni a coordinátor-nak ill. a coordinátor nagy teljesítménnyel adott jelét képes stabilan venni és továbbítani a szenzorok irányába.
Tehát a ZigBee hálózatot nagy területre ki lehet terjeszteni, úgy hogy elkerülhető a többszörös routolás.
Bocs kicsit hosszú lett...[ Szerkesztve ]
-
ojb
tag
válasz smallmer #25718 üzenetére
Az eláztatás ellen csak akkor tudsz biztosan védekezni, ha pontosan ismered a kiszivárgó víz leendő útvonalát és oda helyezed a leak sensort. Én úgy oldottam meg a kérdést, hogy a külső szűrőt beletettem egy műanyag edénybe és abban ellenőrzöm az esetlegesen felgyülemlő szivárgó vizet. Magában az akváriumban pedig lehet figyelni a víz pontos magasságát akár mechanikus, akár elektronikus szenzorral, amik képesek (természetesen az akvárium felületétől függően) akár néhány dl víz elfolyása esetében jelzést adni. Én [ilyet] használok, de [ez] a WiFi-s is tökéletes lehet ( [ez] még talán vernyákol is víz hatására )
A vízszint érzékelésére az akváriumban, pedig [ilyeneket] ill. [ilyen] non contact kivitelt. A reed-es szenzor és az RF433 vagy Wifi-s szenzor érzékelői nyugodtan párhuzamosan köthetőek és ebben az esetben egy riasztást generál az esetleges szűrő vagy akvárium szivárgás.[ Szerkesztve ]
-
ojb
tag
válasz zsamiatt #25757 üzenetére
Csukott ablak mellett az 1500 ppm elfogadható érték.
Az U valami belső viszonyítási érték, ha nagyon érdekel a téma [itt] bővebben kifejtik.
Amíg nem mutat 400 ppm-nél kevesebbet nem kell idegeskedni
Szabad levegőn elég ellenőrizni, hogy valóban 400 körüli értéket mutat-e.
Nem ahhoz kalibrálja magát!!!
Napszaktól és a környező növényzettől függően kb helyes értéket fog mutatni szabadban is!
Három éve használok ilyet és jó. -
ojb
tag
válasz kdavid86 #25764 üzenetére
Egy átlagos hálószoba méreteivel számolva (télen szellőztetés nélkül) csukott ajtó mellett reggelre elég durva értékek képesek kialakulni. Akár 2.500ppm fölötti érték is lehet.
A #25762 hsz-hez csatolt grafikonon jól látszik, hogy reggel nyolc körül nyílik össze a hálószoba és a nappali. (ott van a CO2 érzékelő) És az is kivehető, hogy ma mindenki itthon volt és a szellőztető nem bírt a lakókkal ill. de. nem lehetett az időjárás miatt rendesen szellőztetni, azért van az 1.000ppm körüli érték.
"Hogyan megy ennel a kalibralasi folyamat, ha nincs referencia?"
Valami misztikus belső algoritmus szerint képes kalibrálni önmagát... És valóban.
Amikor elkezdtem használni én is próbáltam megfejteni, de feladtam és elfogadtam, hogy képes arra, hogy pl "belső rossz levegőn" történő bekapcsolás és több órás működés után friss levegőre helyezve pillanatokon belül mutatja a reális értéket. Mondjuk naponta többször is kalibrálja - korrigálja önmagát.
Engem eddig meggyőzött, hogy nem mutatott még 396ppm-nél kevesebb CO2 koncentrációt. -
ojb
tag
válasz zsamiatt #25763 üzenetére
"mennyinél kellene szellőztetni?"
Ez sztem egyén függő ...
Arra azért kíváncsi lennék, hogy jelenleg hol és milyen körülmények között lehet 350ppm-es koncentrációt mérni. (Talán valamely őserdőben verőfényes nappal )
Szabad levegőről <800-as szintre belépve nekem még nem igazán számottevő a különbség, az 1.500 már érezhető
a 2.500 fölötti már fejbevágóan elhasznált levegő. Nekem. -
-
ojb
tag
A P végűnek +20dBm a kimenő teljesítménye.
Az R-esnek, ha jól emlékszem +5dBm körüli
Ez megközelítőleg 20 - 25 szer nagyobb teljesítmény a P javára.
Néhány hozzászólással ezelőtt [#25678] már írtam, hogy ennek csak abban az esetben van jelentősége, ha a szenzorok, routerek is hasonlóan nagy kimenő teljesítménnyel rendelkeznek. Az általánosan elterjedt ZigBee végeszközök és routerek viszont szintén csak néhány (0 ...+10) dBm kimenő teljesítményűek. -
ojb
tag
válasz MaCS_70 #25826 üzenetére
Elnézést kérek, lehet félreérthető volt a hozzászólásom...
Arra szerettem volna utalni, hogy amennyiben lehetőség van rá célszerű egy projekt elején a lehető legnagyobb biztonságra, megbízhatóságra törekedni. SOHA nem szabad figyelmen kívül hagyni, hogy hiba -- legyen az szoftveres vagy hardveres -- bármikor előfordulhat.
Jelen -- redőnyvezérlős -- esetben ezt arra értettem, hogy a felmerült a két jelfogós megoldás estében célszerű az általánosan elterjedt NO kapcsoló páros jelfogók helyett olyat alkalmazni, aminek van NC állapota is (morze érintkezős). Ebben az esetben ugyanis megvalósítható a jelfogóknak egy olyan bekötése, ami az esetleges vezérlési hibákat is képes kiszűrni és megvédeni -- most éppen -- a redőny motorokat. Ezek a hibák lehetnek programozási (pl. nem megfelelően kialakított és védett interlock) , de akár fizikai (tapadva maradt jelfogó érintkező) hibák is. Csak NO érintkezők használatával csak vezérlési oldalon lehet megvalósítani a logikai védelmet, viszont morze érintkezők használatával a végrehajtási oldalon is kialakítható egy -- a vezérlési oldaltól független -- fizikai védelem.
Lefordítva: Morze érintkezők használata és megfelelő bekötés esetében nem tud előfordulni olyan állapot, hogy fizikailag egyszerre mindkét forgásirányra kikerüljön a fázis, még hiba esetében sem. -
-
ojb
tag
"...ne tudj egyszerre két irányút kapcsolni véletlen sem, hiszen a kapcsoló fizikai kialakítása teszi ezt lehetetlenné"
Ez így igaz
Viszont csak a kapcsoló nem védi meg teljesen a rendszert, hiszen nem csak az vezérelheti a jelfogókat működtető GPIO-kat, hanem pl a belső időzítés vagy a WiFi-n érkező parancs is. Tehát a hardveres kapcsoló interlock mellé célszerű kialakítani egy erős szoftveres védelmet is vagy az általam javasolt jelfogós interlock-ot megvalósítani, ami bármilyen logikai vagy vezérlési hiba esetén is véd. -
ojb
tag
válasz gya/352 #25906 üzenetére
Nekem úgy tűnik, mintha valamiért újraindulna (újra konnektálna ) a megadott 2021-04-22 19:00:10 időben az ESP és elküldené a boot state állapotát , ami 0
Tehát a kikapcsolási parancsot sztem az ESP "generája" vagy küldi el .
Valahol megtudod nézni, hogy mikor indult utoljára az ESP:
Valószínűleg 2021-04-22 19:00:08 körül
(ESPEasy-t használok, nem ismerem a Tasmota lekivilágát.)[ Szerkesztve ]
-
ojb
tag
válasz vampire17 #25971 üzenetére
Használhatóak, de...
Amennyiben több GPIO-ra van szükség célszerűbb ESP32-őt használni sztem.
Opentherm adapter esetében mire szeretnéd használni az extender portjait?
(alapból átalában az 1 - 0 ; Pulse ill LongPulse parancsokat teljesítik)
Az ESP HW I2C portját talán ki lehet cserélni Sw-re, de nem igazán célszerű ill. nem szokás szoftveres emulációt használni, ha van hardveres -
ojb
tag
válasz vampire17 #25976 üzenetére
Valóban.
Viszont javasolt I2C pinjei vannak. Pont az a kettő ( GPIO 4 és 5), ami a boot folyamán stabil (low ) marad és nem okoz semmiféle tranzienst az I2C buszon...
GPIO Extenderen keresztül megvalósított TX - Rx UART forgalmat eddig még nem láttam
Nem áll össze a fejemben, hogy hogyan lehet megcsinálni sztem sehogy -
ojb
tag
válasz vampire17 #25979 üzenetére
Hááát a [protocol] leírása szerint (16 - 18 oldal) valami ahhoz nagyon hasonló.
1.000bps körüli sebességgel 32bit-es keretezéssel...
A keretezés alapján UART-nek tűnik, igaz nem (7) 8 bites, de van start és stop bit-je is. -
ojb
tag
válasz zambozoli #26069 üzenetére
"Megyek 15-re, még messzebb is van mint a 3-as wifi csatornától a 11-es."
Nem távolabb, hanem közelebb van!!!A ZigBee ch15 a WiFi 3 -as és 4 -es csatorna között van.
Ha a 3-as csatornán 40MHz-es WiFi-t üzemeltetsz lehet , hogy költöznöd kell, mert oda - vissza bezavarhat időnként.[ Szerkesztve ]
-
ojb
tag
válasz stickermajom #26192 üzenetére
"Vagy ne szórakozzak, tegyek be egy ilyesmit az aljára és számoljak a feszültséggel?"
Amennyiben a tartály kivezetése is alul van akár abba a kivezető csőbe is bele lehet tenni és így nem kell megfúrni a tartályt.
Én a max.170cm -es vízoszlophoz viszont alacsonyabb nyomású érzékelőt használnék -
ojb
tag
válasz stickermajom #26208 üzenetére
"Van tipped alacsonyabb nyomású szenzorra?" [pl]
-
ojb
tag
Néhány hete , hónapja volt róla szó, hogy pl a Shelly eszközei mennyire melegednek... (nagyon)
Párás(abb) környezetben is használhatóak ezek az eszközök pont a hőtermelésük miatt. Ugyanis, ha melegebbek a környezeti hőmérsékletüknél, akkor nem tud kialakulni rajtuk az un. harmatpont , tehát nem csapódik ki rajtuk a víz. A közvetlen környezetükben pedig a páratartalmat változtatják meg.
Természetesen ennek alapfeltétele, hogy állandóan áram alatt legyenek, tehát a tápegységük hőt termeljen. -
ojb
tag
Mivel nem tudni, hogy a sárga vezetéken hány volt a logikai "H" szint, ezért
Nagy érzékenységű ( alacsony dióda áramú ) optocsatoló használatával próbálkoznék
a ventilátor impulzuskimenete és a D1 közé. Ez a megoldás galvanikusan elválasztja egymástól a ventilátort és a Wemost.
A Tasmotát nem ismerem, de biztosan van Pulse Counter lehetőség abban is. Azt használnám. Fél perc impulzus számlálás pontosan a percenkénti fordulat számot adná. (feltéve, hogy fordulatonként valóban kettő impulzust ad ki magából a venti ) -
ojb
tag
Ha csak a Wemos-ra van csatlakoztatva a ventilátor impulzus kimenete egyszerű a fizikai mevalósítás:
kb 3.3kOhm-os felhúzó ellenállás a Vcc-re és a közös pontról (Vout) valamelyik Wemos D - pinre.
( Természetesen a két GND közösítve! )
Abban az esetben amikor nem csak a Wemos, hanem pl tápegység, alaplap stb is használja párhuzamosan az impulzus kimenetet már más helyzet is kialakulhat, ha nem 3.3 - 5V az impulzus kimenet H szintje és nem ismert a collector áram.
Erre javasoltam az optocsatolós leválasztás használatát, ami galvanikusan is elszeparálja a ventilátor eredeti figyelő áramkörét a Wemos-tól.A linken Pulse countert javasol a fordulatszám mérésére...
-
ojb
tag
válasz gya/352 #26591 üzenetére
"I2C-re nem tudom pontosan hogy lehet több eszközt tenni, 2 BME280-at biztos hogy lehet egy I2C busra csak a kis BME panelon át kell állítani az egyiknek a címét."
Az I2C busz rendszer. Nem lehet két azonos című slave
Ill. Nem csak a címet, hanem több eszköz esetében a felhúzást is is illik átállítani, hogy lehetőleg ne minden slave és master adjon pull up ellenállást, mert a sok párhuzamos érték nagyon megnövelheti a GPIO áramokat .
Célszerű 1mA alatt tartani az az SDA - SCL max áramait..
-
ojb
tag
Lehet van, aki szereti a kihívásokat...
#26744 koala69
Ha szereted a kihívásokat , kellően türelmes és kitartó vagy:
AmLogic S905x2 4/32GB vagy 4/64GB -hez még van jó ArmBian ill Debian.
Ennek a teljesítménye feleforma, mint a HA által preferált S922x.
Ez [link] pl működik. (van hozzá .dtb)
Az S922x-re is van, de nem próbáltam még...(nem teszteltem, hogy mindene működik-e ARM64 alatt ill melyik .dtb-vel)[ Szerkesztve ]
-
ojb
tag
válasz grafnet #26821 üzenetére
A 3x5 - 8 m hosszak esetében egy GPIO használatakor (párhuzamosan kapcsolt DS18b20-ak)
már -- jó eséllyel -- figyelembe kell venni a ~20 - 25 m kábel kapacitását is. Ezért a hosszú busz helyett, ha van rá lehetőség inkább három ágú csillag kapcsolást célszerű használni a szenzorok elhelyezésénél, szükség esetén három GPIO használatával.
A felvázolt feladatra én D1 mini pro-t használnék (esetleg külső antennával). Ezt egyszerű programozni a közvetlen USB-ről és megtáplálni egy telefon töltőről...
Érzékelőnek DS18B20 -akat UTP (FTP) kábelezéssel. Szoftvernek a free IoT - OnOff - ot egy Public MQTT bróker közbeiktatásával.
Talán ez a leg - árérzékenyebb "vezetékes" megoldás...
Új hozzászólás Aktív témák
- Xbox Series X|S
- Mobil flották
- Xbox tulajok OFF topicja
- exHWSW - Értünk mindenhez IS
- iPhone topik
- Nokia 3210 - felélni az örökséget
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Androidos tablet topic
- Autós topik látogatók beszélgetős, offolós topikja
- BestBuy ruhás topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen