-
Fototrend
Okos Otthon összefoglaló
Új hozzászólás Aktív témák
-
vampire17
addikt
hasonlora gondoltam en is. Az egyik kerdes az, hogy az egy ora az az aktualis eszleleshez kepest egy ora, vagy a kovetkezo egesz oraig hatralevo ido? (En az elsot gondolom logikusnak)
Tehat az en ertelmezesem szerint, ha 15:23-kor 0 mm-t mutat mondjuk a szint es 15:30-kor 0.5 mm-t, akkor az eso intenzitas kb 4.2 mm/ora? ((60/7)*0.5) Ez igy helyes?
Ha eddig jo a gondolatmenetem, akkor csak azt a dolgot kene valahogy kezelnem, hogy mi van akkor, ha ket meresi periodus kozott nem valtozik az ertek? Ez ugyanis siman lehetseges, az esomero 1 perc alatt tobbszor is jelent(het), de a kis "merokanala" 0.3 mm kulonbseget tud erzekelni, minimum. Tehat siman lehet, hogy a ket jelentes kozott nem valtozik a kuldott ertek.(Az eso persze esik, csak nem telt meg meg a kanal) Persze mondhatom azt, hogy ha az elozo es az aktualis jelentett ertek hanyadosa 1, akkor ne kuldjon uj adatot (maradjon "ervenyben" az elozo). Persze ezzel megint az a gond, hogy honnan tudom meg, hogy elallt az eso? (pl mondhatom, hogy 10 db "1-es" jelentes utan vegye ugy hogy elallt, de ekkor is lehet, hogy meg szemerkel... )
Bocs amugy az eszmefuttatasert, csak gondoltam ha leirom, en hogyan kepzelem, talan valaki kijavit (vagy a legjobb az lenne, ha valaki ismerne a hivatalos szamitasi modot )
[ Szerkesztve ]
-
szat8
tag
válasz vampire17 #15753 üzenetére
Értem a dilemmát.
Szerintem az aktuális mérőeszköz pontosságához (jelen esetben 0.3 mm) kell belőni, hogy hány perc eltelte után ítéled úgy: ha ennyi idő alatt kevesebbet esett, mint a mérési pontosság, akkor az elhanyagolható, egyenértékű a "nem esik" állapottal.
Írok egy példát, milyen logikát gondolok jónak nagy vonalakban, de ez csak ötletelés.
Mondjuk belövöd a max időt 15 percre. Vagyis 5 perc alatt < 0.1 mm eső, az nem eső.
Az első olyan jelentésnél, ahol az érték nem változik, indítasz egy számlálót. A kezdő értéke legyen az előző mérés óta eltelt idő, vagy az utolsó 2 időpont átlaga, amit lehetséges kiindulópontnak szeretnél.
Ha közben bejön egy mérhető érték, akkor nem az utolsó 2 mérés között eltelt idővel, hanem a számláló aktuális értékével osztod az eső növekményt. (A számlálót ki lehet nullázni.) Így tudsz kisebb intenzitást is mérni, mint amit a 0.3 mm / két mérés közt eltelt idő adhatna.
Ha a számláló eléri a 15 percet, akkor azt mondod: elállt az eső, tehát az intenzitás 0, és a számlálót is kinullázhatod.Szerintem így működhet, de csak logikázom, úgyhogy lehet teljes téves is a gondolatmenetem.
-
vampire17
addikt
Koszi a valaszt! Rakerdeztem a wunderground-nal is ugyanerre, ezt a valaszt kaptam:
Hi Vamp.
This is a great question, and one we don't have a hard and fast rule for. Since stations all report differently you'll want to find a sampling interval that will provide good information for all conditions, from small amounts per hour to large. We are working on a revision to our upload specification documentation, and we'll try to come up with a good answer for you here.Szoval nincs kobe vesve, kb en dontom el jelen esetben.
-
szat8
tag
válasz vampire17 #15755 üzenetére
Ki kell próbálni, hogy mennyire ad egyenletes, értelmezhető eredményt a fenti módszerrel.
Ha kis intenzitásnál nagyon elkezd ugrálni az érték, esetleg lehet több egymás utáni adatból súlyozott átlagot számolni.
Mindenképp oszd majd meg, mire jutottál, mert érdekes projekt.
(Még nem kezdtem bele, de én azzal is megelégszem majd első körben, ha a xiaomi door sensorból átalakított eső érzékelővel hamar értesülök az eső kezdetéről. Csak az nem tiszta abban, hogy a rain panelt közvetlenül be lehet forrasztani a mágnes érzékelő helyére, vagy kell közé az a cucc, amit az esőérzékelő panelhez lehet kapni? ) -
Degeczi
nagyúr
Kell, persze. Az esőcseppek ellenáálása sokkal nagyobb, mint egy kapcsolóé, amire a Xiaomi szenzor számít. Az esőérzékelő panelján a potméterrel az érzékenységet is be kell szabályoznod.
Erre egyébként bármi más is használható, aminek van szabad digitális bemenete. Bár lehet, h jobb lenne egy analóg.
[ Szerkesztve ]
-
vampire17
addikt
jelenleg igy szamolom az erteket:
var value_difference = msg.paths.path_2.rain-msg.paths.path_1.rain;
var startTime = new Date(msg.paths.path_1.time);
var endTime = new Date(msg.paths.path_2.time);
var difference = endTime.getTime() - startTime.getTime(); // This will give difference in milliseconds
var resultInMinutes = Math.round(difference / 60000);
final_rate = ((60/resultInMinutes)*value_difference);
msg.payload = final_rate;
return msg;
Egyelore teszt adatokkal dolgozom. Ha beadom azt, h a ket datum kozott 10 perc telt el es ezen ido alatt 1 mm eso esett, akkor az eredmeny 3 mm lesz, ami pont a fele annak, amit varok (6 mm). A kerdes, hol hibadzik a matek? Ha afinal_rate
nal atirom az ertekeket 60-rol 120-ra, akkor ok a vegeredmeny, de ez akkor sem okes igy -
vampire17
addikt
válasz vampire17 #15762 üzenetére
Hat ezt lehet picit tulvezereltem (nyilvan nem latszik maga a kod, csak a meretet akartam prezentalni )
Elv most vizsgalja a ket utolso ertek kulonbseget(elozo ertek egy fajlbol kiolvasva):
Ha nulla: Ha 20x egymas utan nulla, akkor 0 erteket kuld (ez kb 15 perc)
Ha nagyobb mint nulla: kuldi a kiszamolt erteket, illetve beirja az aktualis erteket a fajlba (foluliras)
Ha kisebb mint nulla (pl elemcsere eseten): beirja az aktualis erteket fajlba, mast nem csinal (igy a kovetkezo ciklusnal mar csak a masik ket irany elhet)
Ez a harom ag egy "message resend" nevu node-ban fut ossze, ami azt tudja, hogy beallitott idokozonkent ujrakuldi az inputjat, amig az input erteke meg nem valtozik (nyilvan ez utan az uj erteket kuldi tovabb)
[ Szerkesztve ]
-
Sebiferi
tag
A kör alakú van.
Domoticz
-
sambenez
addikt
válasz kenand #15767 üzenetére
Csak a zigbee-s ritkán küld adatokat, illetve nagyobb változáskor. A BT-ost pedig akár percenként is le lehet kérdezni.
Ha nincs valami anomália. Nekem pl. simán megy, persze elvétve előfordul hogy megakad a lekérdezés, de szerintem ez inkább lesz rpi oldali hiba, mert egy restart után meg minden megy tovább anélkül hogy a hőmérőkkel bármit csinálnék. -
kenand
veterán
válasz Sebiferi #15769 üzenetére
Növényim miatt mifloret is szerttem volna jól beüzemelni, de az még problémásabb. Készítettem emiatt 2 db BTMQTT gatewayt is PizeroW alkapon, de az meg néhány óra után elérhetetlenné válik SSH-n, 2x is nekiálltam 0-ról , 2 PizeroW-m is van, de mindig ugyan az lesz az eredmény...
Most próbálom majd a Miflorátat "butábban" Xiaomi BT gatewayel, (még úton van) MI Home-val. talán az majd menni fog. (egy éve még nem volt különálló BT gateway) -
vampire17
addikt
válasz vampire17 #15764 üzenetére
na ma esett az eso, szal volt teszt. azota airtam kicsit a scriptet, megpedig ugy, hogy 10 perces idokozoket figyeljen intenzitasnak. De az nagyon nem jo... Este esett, nekem 18mm/h-t mutatott, a hozzam 1 utcanyira levo idokepre jelento allomas 1.5-ot. Szal ez alapjan az 1 perces idokoz lesz a megfelelobb. (ugy nalam kb 1.8mm lett volna, ami mar realis, persze ha hihetek az idokepes allomasnak )
vaaagy, arra gondoltam meg, hogy meghagyom a 10 percet, hogy ertekeljeto mennyiseg jojjon be, es ezt visszaosztom 10-el. Esetleg 5 percet merek es 5 el osztom vissza (ugy talan pontosabb)
[ Szerkesztve ]
-
LouiS22
veterán
válasz kenand #15771 üzenetére
szerintem az mqtt-s résznél vérezhet el a cucos, én egy ősrégi, mezei python scriptet használok (igaz, domoticz alatt) és hibátlanul teszi a dolgát, akkor van szoppancs, ha valamelyik elem lemerül (vagy maga a szenzor fagy le, néha előfordul), de azt viszonylag gyorsan észreveszem.
Mielőtt kérdezel, nézd meg az 1. számú hozzászólást, vagy használd a keresőt, azért van!
-
kenand
veterán
válasz LouiS22 #15773 üzenetére
BTMQTT nélkül is használnám, azokat amik közel vannak a géphez...... azok is bizonytalanok . BTMQTT-PizeroW-k a hatástáv növeléséhez lennének beiktatva....de úgy látom jön a tavasz, vs még egy évet halasztom, mert már nem érek majd rá.... (bár olyan tűrhető idő volt, hogy télen is tudtam haladni a kerti földmunkával)
-
szat8
tag
válasz vampire17 #15772 üzenetére
Akkor ott valami nagyon nem jó. Az értéknek többnyire függetlennek kéne lennie az intervallumtól, illetve nagyobb időegységek alatt legfeljebb kiegyenlítettebb lehetne az érték.
Tudnál rá írni egy példát, milyen input adatokból jött ki 18mm/h?
(Az nem lehet, hogy 10 perc alapján 18mm/h az intenzitás, 1 perc alatt meg 1.8mm/h.) -
vampire17
addikt
jelenleg ugy nez ki a dolog, hogy beirok egy fajlba egy erteket, amit mutat jelenleg a merom, teszem azt legyen ez 10 mm. Illetve beirom az idobelyeget is. (kesobb nem kell kezzel irni semmit, ezt csak a ciklus beindulasa miatt kell)
Elkezdem vizsgalni a kulonbseget folyamatosan a bejovo ertekekhez kepest. ha a kulonbseg 0 mm, akkor tovabb kuldok egy 0-at es ennyi. Ha a kulonbseg nagyobb mint 0 mm akkor egyreszt kiertekelem, illetve felulirom fajlban szereplo erteket es idobelyeget. Nyilvanvaloan ez az elso ilyen kiertekeles nagyon alacsony, szinte merhetetlen erteket ad, hiszen lehet 1 hete nem esett es ezert nem kerult felulirasra az idobelyeg. De ezt elkolnyvelem vesztesegnek, a kovetkezo ciklusnal mar a tenyleges idokulonbseget fogja mutatni. mivel minden bejovo erteket vizsgalok ezert a kovetkezo kiertekeles akkor lesz, amikor a kanal legalabb egyszer atbillent (egy billenes 0.3 mm). Ha ket meres kozott 0 a kolonbseg (mert olyan kicsi az intenzitas) akkor nem kuld nullat egybol, legalabb 20 egymast koveto nulla kell ehhez. Ilyenkor addig kuldi a legutobbi intenzitast, amig nem jon uj kulonbseg, vagy nem lesz 20 egymast koveto 0 (tehat elallt az eso)
A kepletem :
( 60 / idoblelyegek kozotti kulonbseg ) * ket meres kozotti kulonbseg milimeterben.Szal igy nez ki a dolog.
Hol a hiba?
-
szat8
tag
válasz vampire17 #15780 üzenetére
Szerintem mindenképp érdemes lenne legalább addig tárolni az értékeket valahol, amíg ki nem forr ez a rendszer. Így most nem tudhatod, hogy mérésben, vagy valahol az adatok feldolgozásában történik hiba.
Javaslom, hogy loggolj pár eső adatot, és számolj utána "kézzel" is, mi jön ki intenzitásra.
Azt hittem egyébként, hogy az eső növekményt külön is gyűjtöd a leesett eső mennyiségének számításához. Abból is vissza lehetne követni, hány perc alatt hány mm eső esett.
Egyébként ha jól értem, ha felrajzolnál egy grafikont, ahol az X tengely az idő, az Y pedig a szumma leesett eső, akkor az intenzitást a grafikon pontbeli meredeksége alapján ki lehetne számolni, csak fel kéne szorozni 60 perccel. -
blackfly
tag
Sziasztok!
Van egy működő home assistant szerverem és szeretnék statisztikát készíteni a gyűjtött adatokból. Egészen pontosan, a világítás kapcsolók adatai alapján mennyi ideig volt fel illetve lekapcsolva. Az adatbázis már át van irányítva influxdb re. Próbálkoztam grafana val de szép hőmérséklet diagrammok rajzolásán kívül nem tudtam mást megvalósítani. Van valakinek ötlete hogyan tudok ilyen statisztikát megjeleníteni? -
szat8
tag
válasz blackfly #15783 üzenetére
Szerintem megoldható HA-n belül is, history stats sensorral.
Utána pofás diagramot is lehet neki csinálni mini graph card segítségével. -
Chal
addikt
+1
Egyébként ha megvan az említett szenzor HA oldalon, akkor a Grafana is kezesebb lesz. Megoldható nyilván ott is, csak bonyolult a query, mert a db-ben (mármint az influxban) az egyes state change események mindegyike generál egy sort, a hozzá tartozó adatokkal (timestamp, on/off state, brigthness/color settings, stb...). Ezeket alapul véve kellene kiszámolni az "on state" időket pl. adott naptári napra, majd összeadni. Én sem szöszöltem vele, HA oldalon egyszerűbb ez, ráadásul úgy mindkét oldalon (HA+Grafana) is használható a kapott érték.
[ Szerkesztve ]
-
DougButabi
tag
Ha már itt tartunk, akkor grafanában kellene egy kis segítség:
Grafikonok készen vannak, de egyszerűen nem tudom beletenni jól a dashboardba.
első problémám, hogy azon a gépen ahol hozzáadom látom, de másik gépről 401: Unauthorized hibaüzenetet kapok ,mindenhol azt írják, hogy a- name: GF_AUTH_ANONYMOUS_ENABLED
value: 'true'
megoldja a problémám, hát nem.
A másik, hogy nem jöttem rá, hogy lehetne jó szélessé tenni egy grafikont, grafana szerkesztőbe látom tök jól egy egy grafikon kb 5x szélesebb, mint a magassága, Dashboardra téve, már csak kétszer, és így panel módban 1 darab jó magas grafikonom van csak a tervezett 3-4 helyett.Valakinek van
ötlete? -
addikt
Mivel új rpi-t vettem kísérletképpen feltettem a HA-t (raspbian-ra, nem a hass.io-t). Megy a rendszer szépen csak nem tudom, h kell felvarázsolni rá a hass.io kiegészítőket...
Mindenhol olyan leírások vannak, h kompletten az img-t használják de de nekem meglévő rendszerre kellene. Tudja vmi, h kell telepíteni?Mindenkit egyforma külső inger ér, de egyén függő, h éljük meg :P
-
fecus
őstag
válasz body007 #15790 üzenetére
+1
Erre én is kíváncsi vagyok.
Most virtuális szerveren, dockerben fut a HA, de attól még nem tudom használni a hass.io kiegészítőket (Pl. Let's Encrypt and DuckDNS)
Külön-külön meg tudom csinálni, de nem tudom használni az egyszerű add-on-t.
A végleges fizikai szerveren nem szeretnék dockert. Felesleges erőforrás zabáló.[ Szerkesztve ]
"Szörnyek léteznek, de túl kevesen vannak ahhoz, hogy igazán veszélyesek legyenek. Sokkal veszélyesebbek az átlagemberek, a funkcionáriusok, akik készek hinni és cselekedni anélkül, hogy kérdéseket tennének fel." (fordította DeepL ) - Primo Levi
-
haxiboy
veterán
válasz body007 #15790 üzenetére
Kicsit megkeveredtem a nevezéktannal. Tehát a Home Assistant (Core) az a python alapú mindenen futó változat, a hass.io pedig a különböző hardverekre megírt standalone megvalósítás?
FreeNAS-alatt jail-be melyik telepíthető? Illetve a Core vs hass.io funkcionalitásba mennyire tér el, mert ezt elfelejtették részletezni.
Edit: Közben megtaláltam. Így marad a hass.io az addonok miatt
A FAQ-ban leírják hogy csak a hass.io-n vannak addonok, a home assistantban nem használhatók külön.(#15792) fecus : A Docker nem fogyaszt különösebben több erőforrást. Napi szinten használok dockert, tény, nem gyorsabb mint egy VM, viszont a host OS erőforrásait/libjeit használja így elég hatékony. A performance vesztés nagy előnyöket is hoz magával.
[ Szerkesztve ]
Premium Mining Rigek és Gamer/Workstation gépek: tőlem, nektek :)
-
fecus
őstag
válasz haxiboy #15793 üzenetére
Most tanulgatom a dockert, de nekem nagyon sok helyet foglalt.
A jó kérdés az, hogy ha hass.io-t teszek fel dockerben, akkor mi az amit meg nem tudok megcsinálni a natív HA-hoz képest? Tehát az előnye már megvan (add-onok), de mi a hátránya?
Azért érdeklődöm, mert a szerveremen (16.04) az Ubuntu 20.04 megjelenése után szeretnék frissíteni és akkor kellene jó döntéseket hozni."Szörnyek léteznek, de túl kevesen vannak ahhoz, hogy igazán veszélyesek legyenek. Sokkal veszélyesebbek az átlagemberek, a funkcionáriusok, akik készek hinni és cselekedni anélkül, hogy kérdéseket tennének fel." (fordította DeepL ) - Primo Levi
-
Degeczi
nagyúr
Ha nem szeretsz szívni függőségekkel, akkor az élesen pláne szeretnél Dockert használni...
Pl. pár hónapja lett a Home Assistantban deprecated a Python 3.6, de ha Dockert használtál, ebből semmit nem vettél észre, hiszen a HA docker image hoz magával mindent, amire szüksége van - és mivel egy elkülönülő környezet, ez semmivel nem akad össze a gazdarendszeren, ott továbbra is használhatsz bármit, ami meg esetleg egy régi verzióhoz ragaszkodik.
Ha pedig egy új verzióban bármi probléma derül ki ami miatt vissza kell állnod a korábbi változatra, a korábbi docker image lehúzása egy-két paranccsal gyorsan megvan.Teljesítményben semmit nem veszel észre, ugyanolyan gyorsan fut, mintha natív lenne, egyedül memóriából eszik többet - de az erre van. És sok abból sem kell: egy tucatnyinál is több docker konténerrel is alig 2 GB körüli van használatban a gépemen.
Egyedül akkor érthető a docker kerülése, ha fixen kevés memóriás minimálkonfigon futtatod, mint egy 1 GB-os Rpi.
[ Szerkesztve ]
-
fo_di
őstag
láttátok, hogy kijött egy hacs-ben felrakható home assistant addon, amivel gyári firmware-es sonoffokat lehet lokálisan vezérelni? egyszer hozzá kell őket adni az ewelinkhez, de utána elvileg lokálba nyomja
-
DJGABI
addikt
Remek... Feleslegesen flasheltem a cuccokat? Jó mondjuk a kis kínai bármikor be is zárhatja ezt a kiskaput...
Amúgy ESPHome felmegy pl led lámpákra, ilyesmire? (Alexa miatt) Wemo emuval persze egyből látja a tasmota cuccot HA, az tök szimpi... Sima mqtt-vel miért nincs ilyen? Miért kell egyből mélyvízbe ugrani? Rohadtul nem felhasználóbarát
Szerk: ja, oké, hogy van mqtt discovery is... [link] miért nincs default bekapcsolva? istenem... vagy telepítés után... megkérdezi asszem a hubokat, miért nincs valami lehetőség hogy "ez legyen a hub"....
[ Szerkesztve ]
<< "stabil, de mégse" >> << MX440 FTW! >>
Új hozzászólás Aktív témák
- Amlogic S905, S912 processzoros készülékek
- Nyíregyháza és környéke adok-veszek-beszélgetek
- A régi node-okra koncentrál a szankciók miatt Kína
- Magga: PLEX: multimédia az egész lakásban
- Azonnali VGA-s kérdések órája
- Windows 11
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Facebook és Messenger
- Autós topik
- Mozilla Firefox
- További aktív témák...
- 205/55 R16 5x112 alufelni michelin nyári gumival
- Ikea falilámpa
- Kibernetik Mobil klíma, 3,5kW légkondi, légkondícionáló
- LAICA Genova HYDROSMART rendszerű csapra szerelhető mikroplasztik-stop vízszűrő + ajándék LAICA fém
- Eladò Philips Series 2000 LatteGo automata kávégèp tejhabosìtòval ùjszerű àllapotban