hiho, ich mal wieder *g*
ich habe eine wetterstation von homematic HM-WDS100-C6-O-2 . damit ich weiß, wie viel es heute/aktuelle stunde geregnet hat, verwende ich das uralt modul "rain".
ich glaub', ich hab das hier irgendwo schon mal erwähnt, aber das ding baut mir gerne mal minus-werte in seine readings, was wunderschöne regenmengen-plots ergibt.
jetzt wollte ich umstellen auf das statistics modul, aber ich steh' irgendwie mal wieder wie 'ne kuh vorm zaun ... da wäre grundlegende hilfe von euch erbeten, um mit statistics mein rain-modul zu ersetzen.
bisheriges verständnis ist da grade 0 vorhanden.
Zitat von: the ratman am 14 März 2023, 10:54:44
aber das ding baut mir gerne mal minus-werte in seine readings, was wunderschöne regenmengen-plots ergibt.
Warum schließt Du negative Werte nicht einfach direkt beim Logging aus?
wenn du mir sagst, wie und wo am besten ... und vor allem: die werte müssen ja woher kommen. wäre in meinen augen also nicht wirklich eine fehlerbehebung.
weshalb ich mittlerweile tatsächlich lieber das statsitc modul bemühen wollen würde.
denke, das wird ein bissi besser betreut, als das uralt-rain-modul *g*.
wenn ichs richtig gelesen hab, würde ein "aktuelles" rain-modul wohl auch generell anders programmiert heutzutage. heißt für mich: irgendwann, nach irgendeinem fhem-update, geht das gar nicht mehr. dann muss ich auch umsteigen, nur unter "stress".
Zitat von: the ratman am 14 März 2023, 13:27:25
wenn du mir sagst, wie und wo am besten
Kommt darauf an, wie Du das Logging machst.
FileLog: da kannst Du mit dem Attribut "acceptedRange" arbeiten
DbLog: da kannst Du das Attribut DbLogValueFn verwenden
Beides in der commandref beschrieben.
Zitat von: the ratman am 14 März 2023, 13:27:25
heißt für mich: irgendwann, nach irgendeinem fhem-update, geht das gar nicht mehr.
Da wäre ich nicht so pessimistisch. Grundsätzlich glaube ich nicht daran, dass sich an den Mechanismen für events in FHEM irgendwas ändern wird.
Das Modul rain ist diesbezüglich so einfach gestrickt, dass es auch in einigen Jahren noch funktionieren sollte.
Zitat von: the ratman am 14 März 2023, 13:27:25
und vor allem: die werte müssen ja woher kommen. wäre in meinen augen also nicht wirklich eine fehlerbehebung.
naja - genau das "woher kommen" ist ja der Punkt, um den es geht. Vermutlich werden die negativen Werte nicht vom rain-Modul erzeugt, sondern vom Sensor selbst. Deshalb könnte es durchaus sein, dass diese Werte auch in statistics ungewollt Einfluß nehmen.
dblog hab ich. werde ich mal als "plan b" speichern, weil jetzt wäre ich mal aufs statistics modul neugierig. ich will nicht unbedingt die nächsten tage mit fehler suchen verbringen, außer, man würde damit das rain-modul auf aktuellen stand bringen und solcherlei probleme wegkriegen (egal, was schuld ist)
Zitat von: betateilchen am 14 März 2023, 13:36:04~~~snip~~~ naja - genau das "woher kommen" ist ja der Punkt, um den es geht. Vermutlich werden die negativen Werte nicht vom rain-Modul erzeugt, sondern vom Sensor selbst. Deshalb könnte es durchaus sein, dass diese Werte auch in statistics ungewollt Einfluß nehmen.
DAS wäre eben sehr interessant, aber ich krieg' das nicht hin, kann nur sagen:
ich hab da echt noch nie was negatives von der wetterstation selber gesehen. ich treibe mich im modul dann ja herum, wenn wieder mal "minus" steht. die wetterstation liefert eigentlich nur fortlaufende werte, die irgendwann mal "überdrehen" und wieder bei 0 anfangen.
tritt das problem auf setz' ich einfach alle aktuellen readings auf 0, was aber auch nicht immer klappt, hab ich feststellen dürfen.
ein teil des listings der wetterstation:
Helper:
DBLOG:
brightness:
logdb:
TIME 1678799228.38727
VALUE 159
dewpoint:
logdb:
TIME 1678799228.38727
VALUE 1.9
humidity:
logdb:
TIME 1678799228.38727
VALUE 57
temperature:
logdb:
TIME 1678799228.38727
VALUE 10
temperature_alt:
logdb:
TIME 1678799228.38727
VALUE 10.1
temperature_komma:
logdb:
TIME 1678799228.38727
VALUE 10
windDirection:
logdb:
TIME 1678799228.38727
VALUE 105
windSpeed:
logdb:
TIME 1678799228.38727
VALUE 21.2
OLDREADINGS:
2023-03-14 13:59:16 temperature 10.1
READINGS:
2023-03-14 10:08:21 Activity alive
2022-10-15 03:00:41 D-firmware 1.6
2022-10-15 03:00:41 D-serialNr OEQ1864809
2023-03-14 09:58:22 IODev hmLan2
2023-03-14 14:07:08 absoluteHumidity 5.3
2023-03-14 14:07:08 battery ok
2023-03-14 14:07:08 brightness 159
2023-03-13 19:30:39 commState CMDs_done
2023-03-14 14:07:08 dewpoint 1.9
2023-03-14 14:07:08 humidity 57
2023-03-14 14:07:08 isRaining 0
2023-03-13 19:30:39 powerOn 2023-03-13 19:30:39
2023-03-14 14:07:08 rain 13.275
2023-03-14 14:07:08 rain_calc_all cH: 0.0 lH: 0.0 cD: 13.3 lD: 0 IR: 1 Rnow: 0.0 Rdif: 0
2023-03-14 14:07:08 rain_calc_d_curr 13.3
2023-03-14 10:39:34 rain_calc_d_last 0
2023-03-14 10:40:04 rain_calc_d_start 0
2023-03-14 00:01:31 rain_calc_d_trig_tsecs 1678834860
2023-03-14 14:07:08 rain_calc_h_curr 0.0
2023-03-14 14:07:08 rain_calc_h_last 0.0
2023-03-14 14:07:08 rain_calc_h_start 13.3
2023-03-14 14:07:08 rain_calc_h_trig_tsecs 1678798800
2023-03-14 14:07:08 rain_calc_now_diff 0
2023-03-14 14:07:08 rain_calc_now_rate 0.0
2023-03-14 14:07:08 rain_calc_now_value 13.3
2023-03-14 14:07:08 rain_calc_tsecs 1678799228.37767
2023-03-13 19:30:39 recentStateType info
2023-03-14 14:07:08 state T: 10 H: 57 W: 21.2 R: 13.275 IR: 0 WD: 105 WDR: 67.5 S: 142 B: 159
2023-03-14 14:07:08 sunshine 142
2023-03-14 14:07:08 temperature 10
2023-03-14 14:07:08 temperature_alt 10.1
2023-03-14 14:07:08 temperature_komma 10
2023-03-13 19:30:39 unknown 06000030
2023-03-14 14:07:08 windDirRange 67.5
2023-03-14 14:07:08 windDirection 105
2023-03-14 14:07:08 windSpeed 21.2
helper:
HM_CMDNR 186
lastMsgTm 1678799228.36928
mId 00AE
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 1p:THSensor,4:THSensor,p:THSensor
regLst 0,1,1p,4p
rxType 140
supp_Pair_Rep 0
cmds:
TmplKey :no:1678784320.07819
TmplTs 1678784320.07819
cmdKey 1:1:0::wetterstation:00AE:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt 4k12v_schalter1,4k12v_schalter2,4k12v_schalter3,4k12v_schalter4,schlafzimmer_rollo,solaranlage_kuehlung,vccu
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 1
raw 1
tpl 1
io:
flgs 0
newChn +62E4AE,00,00,00
nextSend 1678799228.46404
rxt 0
vccu vccu
p:
62E4AE
00
00
00
prefIO:
hmLan2
mRssi:
mNo BA
io:
hmLan2:
-56
-56
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_hmLan2:
avg -59.4489795918367
cnt 98
lst -60
max -52
min -72
tmpl:
Attributes:
IOgrp vccu:hmLan2
actCycle 000:10
actStatus alive
alias wetterstation
autoReadReg 0_off
expert defReg,allReg,rawReg,templ
firmware 1.6
group sensoren
icon weather_station
model HM-WDS100-C6-O-2
oldreadings temperature
peerIDs 00000000
room homematic
serialNr OEQ1864809
stateFormat <font color="darkred"><b>regen</b> </font>rain_calc_d_curr mm<br>
<br>
temp:temperature °c <font color="#600">||</font> lf:humidity %<br>
tp:dewpoint °c (abs:absoluteHumidity %)
subType THSensor
userReadings temperature_komma:temperature.* { my $val = (ReadingsVal($name,"temperature",0)); $val =~ s/\./,/g; return $val;},
temperature_alt:temperature.* { OldReadingsNum($name,"temperature",0); }das schaut dann so aus:
1) (rote balken 50% sind mit heizung des regensensors aus, mit 100% höhe ist die heizung an (ich schalt in der nacht ab))
2) beim gestrigen plot hab ich in der zeit des regens mehrfach alle werte vom rain-modul in der wetterstation mit "minus" auf 0 gesetzt. was dann in der datenbank steht, sieht man ja ...
o.k. mir ist übrigens grade klar geworden, warum keiner was zur hilfe beitragen will ...
das statistics modul ist ja idiotensicher. vielleicht doch vorher probieren und dann fragen *lach*
Zitat von: betateilchen am 14 März 2023, 13:36:04
...
naja - genau das "woher kommen" ist ja der Punkt, um den es geht. Vermutlich werden die negativen Werte nicht vom rain-Modul erzeugt, sondern vom Sensor selbst. Deshalb könnte es durchaus sein, dass diese Werte auch in statistics ungewollt Einfluß nehmen.
Ob mit dem statisitcs-Module ne Änderung eintritt oder wie angenommen "vom Sensor selbst" wäre ne interessante Erkenntnis 8)
sind ma schon 2 interessierte ... ist natürlich klar: gestern regen, heute perfekter sonnenschein ...
könnte was werden. hab noch 1 problem - siehe markierung ... eigentlich müsste die "es regnet" = rote flächen, ja noch bis mindestens zur letzten stufe der blauen regenmengen-anzeige gehen. kann ja nicht ohne regen mehr wasser werden *g* das ging "früher" problemlos.
gibts da vielleicht verzögerungen beim statistik-modul?
test01.png
nachtrag:
aber mitternacht ohne regen hat er schon brav geresettet.
da fehlt also nur mehr eine mitternacht, in der es regnet
zu früh gefreut ...
wo kommt das nu her, wenns nicht am regen-modul und auch nicht am statistik-modul liegt?
oder an beiden?
er zählt scheints auch richtig, nur halt mit einem minus davor.
mitternacht hat er auch immer brav auf 0 gesetzt.
wie und wo könnte ein "workaround" aussehen und wirken?
also z.b. jedes minus bei rain wegmachen.
Zitat von: betateilchen am 14 März 2023, 12:04:39Warum schließt Du negative Werte nicht einfach direkt beim Logging aus?
Wäre betateilchens Vorschlag nicht ne Möglichkeit?
Oder eben die Forschungsarbeit ob die Werte nicht schon so vom Sensor kommen. Ist das nicht sowieso das Wahrscheinlichste?
Gibts die Möglichkeit über verbose 5 im Log zu versuchen die Daten zu interpretieren.
Was der Senso falsch schickt bekommst du ja weiter hinten nicht mehr gerade gezogen - es sei denn negative Werte werden weg geschmissen. ;)
Zitat von: the ratman am 24 März 2023, 08:36:03wie und wo könnte ein "workaround" aussehen und wirken?
also z.b. jedes minus bei rain wegmachen.
Mal ins Unreine: wenn der Zahlenwert plausibel aber mit falschem Vorzeichen ist ein userreading was per int-Funktion das Vorzeichen wegmacht.
Oder.
Zitat von: betateilchen am 14 März 2023, 13:36:04Kommt darauf an, wie Du das Logging machst.
FileLog: da kannst Du mit dem Attribut "acceptedRange" arbeiten
DbLog: da kannst Du das Attribut DbLogValueFn verwenden
Beides in der commandref beschrieben.
Zitat von: RalfRog am 24 März 2023, 18:32:58Mal ins Unreine: wenn der Zahlenwert plausibel aber mit falschem Vorzeichen ist ein userreading was per int-Funktion das Vorzeichen wegmacht.
nicht int() sondern abs()...
zumindest schauts für mich so aus, als ob ein minus nur 1 mal kommt, also dann alle weiteren werte wieder richtig hoch zählen. das beruhigt mich mal, wenns denn wirklich so ist.
verbose 5 wird sicher witzig. wenns wie mit dem alten rain-modul ist, kann das gerne mal ein paar regenschauer andauern, bis wieder mal ein minus-wert alles versaut. wundert mich sowieso, dass ich schon beim ersten regen mein minus kriege *g*
ZitatWäre betateilchens Vorschlag nicht 'ne Möglichkeit?
ZitatMal ins Unreine: wenn der Zahlenwert plausibel aber mit falschem Vorzeichen ist ein userreading was per int-Funktion das Vorzeichen wegmacht.
sicher!
aber du sprichst hier mit der programmier-nulpe no.1, da bräuchte ich also wieder mal dringend hilfe.
was müsste ich also genau eingeben, wenn ich, sagen wir mal jedes reading mit "stat" beginnend generell mal ein eventuelles minus wegnehme?
oder besser? wenn du recht hast und der fehler kommt von meiner wetterstation, müsste ich eher das reading "rain" bereinigen, gar nicht, die statistik?
wäre also folgende vorgehensweise brauchbar?
1) mal das rain-reading bereinigen, gibts dann immer noch fehler
2) die stat-readings bereinigen, gibts dann immer noch fehler
3) die wetterstation sprengen und sich was gscheites kaufen ...
Woher willst Du eigentlich wissen, dass ein aus einem negativen Wert erzeugter positiver Wert "richtig" ist?
Warum gehst Du nicht den einfachsten (und bereits mehrfach vorgeschlagenen) Weg und loggst die negativen Werte einfach überhaupt nicht?
genau das will ich ja *g* ich geb dir ja schon seit deiner ersten wortmeldung recht.
wollt's ja nur berichten, was meiner meinung nach passiert und was ich dazu denke (so als qualitätskontrolle *g*), falls ihr da schon mal was gehört hättet.
was ich eben nicht weiß (wie meistens) ist, wie ich den negativen wert weg-rechnen kann.
Zitat von: the ratman am 25 März 2023, 09:04:53genau das will ich ja *g* ich geb dir ja schon seit deiner ersten wortmeldung recht.
wollt's ja nur berichten, was meiner meinung nach passiert und was ich dazu denke (so als qualitätskontrolle *g*), falls ihr da schon mal was gehört hättet.
was ich eben nicht weiß (wie meistens) ist, wie ich den negativen wert weg-rechnen kann.
Du definierst dir in deiner Wetterstation ein userReading, bei dem du bei neg. Werten undef lieferst, sonst den Wert selbst:
userReadings rain_new {ReadingsVal($name,"rain",0) < 0 ? undef : ReadingsVal($name,"rain",0)}Loggen musst du dann das neue Reading und nicht mehr das alte.
na ja, loggen darf ich das nicht, weil "rain" sammelt ja die menge ohne zu mitternacht zu resetten. das macht erst die statistik.
d.h., ich muss jetzt dem statisitk modul beibringen, dass es rain_new nehmen soll ...
wäre alles viel einfacher, wenn man gleich "rain" beeinflussen könnte ....
Deine Beratungsresistenz hält mich gerade davon ab, Dir weiter helfen zu wollen.
Egal, was Dir vorgeschlagen wird, Du meinst, alles besser zu wissen.
Sehr schade.
wieso?
ich mach' doch eh alles, wie ihrs wollt.
allerdings bringt mir das loggen von "rain_new" nix, weil rain eben einfach weiter zählt (und somit "rain_new" auch, nur endlich wirklich richtig) über mitternacht. darum brauch man doch das statistik-modul erst. ich logge also nach wie vor "statRainDay".
rain_new ist also eh richtig, nur muss das statistik modul natürlich jetzt "rain_new" zum rechnen nehmen und nicht das original "rain".
was ist da bitte beratungsresistent?
nachtrag: hab mal schnell ein paar werte mit rain_new in die db schreiben lassen.
das schaut dann so aus:
rain_new.png
in blau: die (derzeit) richtigen werte aus dem statistik modul
in grau: rain_new mit den werten von "anbeginn" seiner letzten nullung (die die station höchst selbst macht und nichts mit dem stats-modul zu tun hat).
in rot: die anzeige eines regensensors, wann es genau geregnet hat
Puh...
Du loggst mit DBlog?
Zitat von: RalfRog am 25 März 2023, 16:28:36Du loggst mit DBlog?
Das wissen wir doch seit dem 5. Beitrag hier im Thread?
Jo... ::)
Ich bin der Einäugige ;)
So wie ich das sehe würde ich in dem Device (da müsste es ja die Attribute DbLogExclude, DbLogInclude, DbLogValueFn geben) per Attribut so etwas versuchen:
DbLogValueFn { if ($READING eq "rain" and $VALUE < 0){$VALUE=0;}}
Oder was auch immer du aus dem negativen Wert machen möchtest.
Oder klappt das eigentlich #15?
https://forum.fhem.de/index.php?msg=1269556 (https://forum.fhem.de/index.php?msg=1269556)
ach, das ginge auch noch in der db?! hatte ich natürlich wieder mal 0 auf dem radar ... wäre natürlich auch ein schön einfach weg *g*
Oder was auch immer du aus dem negativen Wert machen möchtest.
ja, das ist halt immer noch 'ne frage, die ich grundlegend nicht kapiert hab bisher:
a) schreibt mir meine wetterstion nur einmalig 'nen falschen wert raus und der nächste wäre wieder ein positiver, dann könnte man's so machen.
b) oder schreibt die dann von dem minus-wert ausgehend immer kleinere minus raus - je nach regenmenge halt, bis er eben wieder bei 0 ist. dann würde es warscheinlich nicht so einfach klappen.
und ja, mein statistik-modul schreibt halt dann auch immer noch nach dem "rain"-wert ihre statisitk-readings. ich trau' mich aber wetten, da könnte ich wenigstens den rain_new derweil erzwingen irgendwie (noch neu für mich, das modul). müsste ich halt alle anzeigen, plots usw. ändern.
Zitat von: the ratman am 25 März 2023, 20:02:10ach, das ginge auch noch in der db?! hatte ich natürlich wieder mal 0 auf dem radar
Du musst das nicht auf dem Radar habe, Du musst einfach lesen, was man Dir antwortet.
DbLogValueFn() habe ich schon am Anfang des Threads vorgeschlagen:
https://forum.fhem.de/index.php?msg=1268168
Zitat von: betateilchen am 25 März 2023, 20:13:43DbLogValueFn() habe ich schon am Anfang des Threads vorgeschlagen:
https://forum.fhem.de/index.php?msg=1268168
Ich wollte nett sein und es noch detailiierter ausführen.
Jetzt lieber Rattenman probier mal was.
Gruß und schönes WE
Naja, aber Dein Vorschlag, eine 0 zu loggen ist ja auch keine Lösung, deshalb hatte ich anfangs vorgeschlagen, die negativen Werte einfach gar nicht zu loggen, um die plots nicht zu verschandeln.
Sollte ein Schubs für etwas konkrets sein. Hast sicher recht - nix loggen ist besser.
sorry betateilchen, hab ich tatsächlich gekonnt überlesen. war keine absicht!
bin schon am probieren. mal schritt für schritt, mit option auf andere möglichkeiten.
vorgehensweise ist also mal vom userreading rain_new die stats zu kriegen, was ja dank des moduls wieder dödel einfach ist. krieg schon mal von rain_new die statistikwerte.
--> jetzt warte ich noch, ob ich die auch als singularReadings kriege. erscheinen derzeit (noch?) nicht. hoffe, das ist nicht wieder so n spaß mit "userreadings gehen da nicht" *g*
dblog halt ich mir mal als notfall in der hinterhand.
Zitat von: the ratman am 25 März 2023, 20:31:53... hoffe, das ist nicht wieder so n spaß mit "userreadings gehen da nicht" *g*
geht, mach ich auch
dann bin ich sicher wieder zu blöd für ... ich krieg' da jetzt mal nur:
statRain_newDay 25.075: 00:29:18 25.075_Count: 1 (since: 2023-03-25_20:05:24) 2023-03-25 20:34:42
statRain_newHour 25.075: 00:00:00 25.075_Count: 1 (since: 2023-03-25_20:34:42) 2023-03-25 20:34:42
statRain_newMonth 25.075: 00:29:18 25.075_Count: 1 (since: 2023-03-25_20:05:24) 2023-03-25 20:34:42
statRain_newYear 25.075: 00:29:18 25.075_Count: 1 (since: 2023-03-25_20:05:24) 2023-03-25 20:34:42bei folgenden einstellungen im statistics modul (rain macht er die singular readings 100% richtig):
durationPeriodHour 1
durationReadings rain_new
singularReadings wetterstation:rain:Delta:(Hour|Day)|wetterstation:rain_new:Delta:(Hour|Day)
Bin jetzt nicht der Statistic Held.
Aber wenn rain gut aussieht könnte es eventuell daran liegen, dass du durationReadings Rain_new rain_new nutzt. Wie sieht es denn ohne duration aus - habe das nirgendwo verwendet und kann nicht sagen wie sich das auswirkt.
CommandRef:
durationReadings <Gerätewerte>
Durch Kommas getrennte Liste von weiteren Gerätewerten, für welche die Dauer einzelner Gerätewerte innerhalb bestimmte Zeiträume (Stunde/Tag/Monat/Jahr) erfasst wird
dachte, die brauch ich, weil bei singularReadings steht:
Regulärer Ausdruck statistischer Werte, die zusätzlich auch als einzelne Werte gespeichert werden sollen
1) alle stat.* in der wetterstion gelöscht
2) im statistikmodul das durationReadings rain_new gelöscht und neue stat berechnen lassen.
3) dann kommt gar kein statRain_new[irgendwas] mehr
4) "durationReadings rain_new" wieder eingetragen, kommen auch sofort wieder die 4 readings, die singular nicht.
vielleicht mal die stunde abwarten, oder hast du in deinem gerät irgendwas eingetragen wegen der userreadings?
So habe ich es gemachtAn meinem Shelly Device gibt es diese Readings:- energy = OriginalReading
- energyCum = Userreading
- sowie diese Readings aufgrund der Definition im StatModul:
statEnergyCum (enthält die Werte für Hour: Day: Month: Year: aufgrund Attribut deltaReadings)
statEnergyCumDay (aufgrund singularReadings)
statEnergyCumMonth (aufgrund singularReadings)
statEnergyCumYear (aufgrund singularReadings)
statEnergyCumLast (enthält die Werte für Hour: Day: Month: Year: aufgrund Attribut deltaReadings)
statEnergyCumDayLast (aufgrund singularReadings)
statEnergyCumMonthLast (aufgrund singularReadings)
statEnergyCumYearLast (aufgrund singularReadings)
Im StatModul nutze ich :- ignoreDefaultAssignments 1
Ignoriert die Standardzuordnung von Gerätewerten zu Statistik-Typen..
D.h., nur die Gerätewerte, die über Attribute den Statistik-Typen zugeordnet sind, werden ausgewertet.
- deltaReadings energyCum
Durch Kommas getrennte Liste von weiteren Gerätewerten, für welche die Differenz zwischen den Werten am Anfang und Ende einer Periode (Stunde/Tag/Monat/Jahr) bestimmt wird
- singularReadings shelly_plug_s_df2674:energyCum:Delta:(Day|Month|Year)
Statistik-Typ: Min|Avg|Max|Delta|DurationState|Tendency
Zeitraum: Hour|Day|Month|Year|1h|2h|3h|6h
Regulärer Ausdruck statistischer Werte, die zusätzlich auch als einzelne Werte gespeichert werden sollen. Erleichtert die Erzeugung von Plots und anderer Auswertungen (notify).
Für "duration"-Gerätewerte muss der Name des jeweiligen Statuswertes als Statistiktyp eingesetzt werden.
Aus meiner Sicht arbeiten die Attribute
deltaReadings &
singularReadings zusammen
und Duration wäre anders zu defineiren.
Mit ignoreDefaultAssignments halte ich mit unpassende Standarddefinitionen vom Hals.
Gruß
langsam wirds lustig ...
hab dich jetzt nachgemacht und sobald ich ignoreDefaulAssignments auf 1 setze, verliere ich auch vom rain reading die singularreadings.
hab zum testen sicherheitshalber sowohl deltareadings, als auch durationreadings mit "rain,rain_new" gehabt.
lösche ich ignoreDefaulAssignments, kommen sofort auch wieder die singularreadings von rain, aber nicht von rain_new.
ich bin stark verwirrt ...
nur zur sicherheit:
Internals:
DEF wetterstation
DEV_REGEXP wetterstation
FUUID 64119157-f33f-f543-da14-950c352606ab3f13
NAME stat_regen
NOTIFYDEV global,wetterstation
NR 378
NTFY_ORDER 10-stat_regen
PREFIX stat
STATE Updated stats for: wetterstation
TYPE statistics
eventCount 588
READINGS:
2023-03-25 09:02:39 monitoredDevicesCUL_HM wetterstation
2023-03-26 06:59:55 nextPeriodChangeCalc 2023-03-26 07:59:55
2023-03-26 07:52:31 state Updated stats for: wetterstation
fhem:
modulVersion $Date: 2022-07-12 07:25:06 +0200 (Tue, 12 Jul 2022) $
nextPeriodChangeTime 1679810395
Attributes:
alias regenstatistik
deltaReadings rain_new
durationPeriodHour 1
durationReadings rain_new
group temperaturhilfen
icon weather_rain_gauge
room logik und schalten
singularReadings wetterstation:rain:Delta:(Hour|Day)|wetterstation:rain_new:Delta:(Hour|Day)Internals:
DEF 62E4AE
FUUID 5c62c6bf-f33f-0f9e-8d92-c33bb22adf9d44b4
IODev hmLan2
LASTInputDev hmLan2
MSGCNT 517
NAME wetterstation
NR 124
NTFY_ORDER 48-wetterstation
STATE <font color="darkred"><b>regen</b> </font>0 mm<br>
<br>
temp:8.6 °c <font color="#600">||</font> lf:81 %<br>
tp:5.5 °c (abs:7.0 %)
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
eventCount 539
hmLan2_MSGCNT 517
hmLan2_RAWMSG 05000040B4867062E4AE0000000056518056C0613AD100
hmLan2_RSSI -64
hmLan2_TIME 2023-03-26 07:52:31
lastMsg No:B4 - t:70 s:62E4AE d:000000 0056518056C0613AD100
protCondBurst forced_off
protLastRcv 2023-03-26 07:52:31
protRcv 517 last_at:2023-03-26 07:52:31
rssi_at_hmLan2 cnt:517 min:-72 max:-54 avg:-59.11 lst:-64
Helper:
DBLOG:
brightness:
logdb:
TIME 1679809951.41184
VALUE 0
dewpoint:
logdb:
TIME 1679809951.41184
VALUE 5.5
humidity:
logdb:
TIME 1679809951.41184
VALUE 81
rain_new:
logdb:
TIME 1679741667.49782
VALUE 24.19
statRainDay:
logdb:
TIME 1679809951.41184
VALUE 0
statRainDayLast:
logdb:
TIME 1679785195.01978
VALUE 0.000
temperature:
logdb:
TIME 1679809951.41184
VALUE 8.6
temperature_alt:
logdb:
TIME 1679809951.41184
VALUE 8.7
temperature_komma:
logdb:
TIME 1679809951.41184
VALUE 8,6
windDirection:
logdb:
TIME 1679809951.41184
VALUE 290
windSpeed:
logdb:
TIME 1679809951.41184
VALUE 9.7
OLDREADINGS:
2023-03-26 07:50:28 temperature 8.7
READINGS:
2023-03-25 09:12:23 Activity alive
2022-10-15 03:00:41 D-firmware 1.6
2022-10-15 03:00:41 D-serialNr OEQ1864809
2023-03-25 09:02:23 IODev hmLan2
2023-03-26 07:52:31 absoluteHumidity 7.0
2023-03-26 07:52:31 battery ok
2023-03-26 07:52:31 brightness 0
2023-03-24 04:13:06 commState CMDs_done
2023-03-26 07:52:31 dewpoint 5.5
2023-03-26 07:52:31 humidity 81
2023-03-26 07:52:31 isRaining 1
2023-03-24 04:13:06 powerOn 2023-03-24 04:13:06
2023-03-26 07:52:31 rain 25.37
2023-03-26 07:52:31 rain_new 25.37
2023-03-24 04:13:06 recentStateType info
2023-03-26 07:52:31 statBrightnessDay Min: 0 Avg: 0 Max: 0 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statBrightnessHour Min: 0 Avg: 0 Max: 0 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statBrightnessMonth Min: 0 Avg: 0 Max: 0 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statBrightnessYear Min: 0 Avg: 0 Max: 0 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statHumidityDay Min: 81 Avg: 81 Max: 81 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statHumidityMonth Min: 81 Avg: 81 Max: 81 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statHumidityYear Min: 81 Avg: 81 Max: 81 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statRain Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statRainDay 0
2023-03-26 07:52:31 statRainHour 0
2023-03-26 07:42:54 statRainMonth 25.075: 00:00:17 25.075_Count: 1 (since: 2023-03-26_07:42:37)
2023-03-26 07:42:54 statRainYear 25.075: 00:00:17 25.075_Count: 1 (since: 2023-03-26_07:42:37)
2023-03-26 07:52:31 statRain_newDay 25.37: 00:00:00 25.37_Count: 1 (since: 2023-03-26_07:52:31)
2023-03-26 07:52:31 statRain_newHour 25.37: 00:00:00 25.37_Count: 1 (since: 2023-03-26_07:52:31)
2023-03-26 07:52:31 statRain_newMonth 25.37: 00:00:00 25.37_Count: 1 (since: 2023-03-26_07:52:31)
2023-03-26 07:52:31 statRain_newYear 25.37: 00:00:00 25.37_Count: 1 (since: 2023-03-26_07:52:31)
2023-03-26 07:52:31 statTemperatureDay Min: 8.6 Avg: 8.6 Max: 8.6 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statTemperatureMonth Min: 8.6 Avg: 8.6 Max: 8.6 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statTemperatureYear Min: 8.6 Avg: 8.6 Max: 8.6 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statWindSpeedDay Min: 9.7 Avg: 9.7 Max: 9.7 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statWindSpeedHour Min: 9.7 Avg: 9.7 Max: 9.7 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statWindSpeedMonth Min: 9.7 Avg: 9.7 Max: 9.7 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 statWindSpeedYear Min: 9.7 Avg: 9.7 Max: 9.7 (since: 2023-03-26_07:52:31 )
2023-03-26 07:52:31 state T: 8.6 H: 81 W: 9.7 R: 25.37 IR: 1 WD: 290 WDR: 67.5 S: 209 B: 0
2023-03-26 07:52:31 sunshine 209
2023-03-26 07:52:31 temperature 8.6
2023-03-26 07:52:31 temperature_alt 8.7
2023-03-26 07:52:31 temperature_komma 8,6
2023-03-24 04:13:06 unknown 06000030
2023-03-26 07:52:31 windDirRange 67.5
2023-03-26 07:52:31 windDirection 290
2023-03-26 07:52:31 windSpeed 9.7
helper:
HM_CMDNR 180
_98_statistics stat_regen
lastMsgTm 1679809951.39785
mId 00AE
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 1p:THSensor,4:THSensor,p:THSensor
regLst 0,1,1p,4p
rxType 140
supp_Pair_Rep 0
cmds:
TmplKey :no:1679731359.51381
TmplTs 1679731359.51381
cmdKey 1:1:0::wetterstation:00AE:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt 4k12v_schalter1,4k12v_schalter2,4k12v_schalter3,4k12v_schalter4,schlafzimmer_rollo,solaranlage_kuehlung,vccu
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 1
raw 1
tpl 1
io:
flgs 0
newChn +62E4AE,00,00,00
nextSend 1679809951.49181
rxt 0
vccu vccu
p:
62E4AE
00
00
00
prefIO:
hmLan2
mRssi:
mNo B4
io:
hmLan2:
-60
-60
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_hmLan2:
avg -59.110251450677
cnt 517
lst -64
max -54
min -72
tmpl:
Attributes:
IOgrp vccu:hmLan2
actCycle 000:10
actStatus alive
alias wetterstation
autoReadReg 0_off
expert defReg,allReg,rawReg,templ
firmware 1.6
group sensoren
icon weather_station
model HM-WDS100-C6-O-2
oldreadings temperature
peerIDs 00000000
room homematic
serialNr OEQ1864809
stateFormat <font color="darkred"><b>regen</b> </font>statRainDay mm<br>
<br>
temp:temperature °c <font color="#600">||</font> lf:humidity %<br>
tp:dewpoint °c (abs:absoluteHumidity %)
subType THSensor
userReadings temperature_komma:temperature.* { my $val = (ReadingsVal($name,"temperature",0)); $val =~ s/\./,/g; return $val;},
temperature_alt:temperature.* { OldReadingsNum($name,"temperature",0); },
rain_new {ReadingsVal($name,"rain",0) < 0 ? undef : ReadingsVal($name,"rain",0)}
das muss in ein neues posting *G*
mache soeben meinen allmorgendlichen update ... was steht danach dem fhem wieder hochgekommen ist?
statRain_newDay 0.00 2023-03-26 08:05:32
statRain_newHour 0.00 2023-03-26 08:05:32
o.k. ... ab nun bei stat-modul und userreadings einen restart von fhem machen. wenns weiter nichts ist, kann ich mit leben.
somit bleibt mir nur euch für euer hirnschmalz zu danken!
sodale ... der vollständigkeit halber: ich glaub', ich hab den fehler.
ich betreibe wetterstation und einiges anderes über eine inselsolaranlage. der wandler von 12v auf weniger volt (ist einstellbar) ist scheinbar immer wieder ausgefallen und schon hab ich auch jetzt wieder minus-werte gehabt.
hab jetzt einen ersatz eingebaut - schauen ma mal ...
und nun als abschließende bestätigung: scheint wirklich so zu sein.
nur so als abschluss (hoffe ich zumindest) der geschichte ...
ich musste die wetterstation vom strom nehmen, weil das supergeile chinesen dc-dc-wanlder-dingens nach 2 tagen der meinung war, anstelle der eingestellten 4,5v 19v an die wetterstation liefern zu müssen. ich rede (zur allgemeinen warnung) übrigens von solcherlei produkt: https://www.amazon.de/dp/B08T158WPS?psc=1&ref=ppx_yo2ov_dt_b_product_details
hab mir jetzt ein "fest verdrahtetes" von 12v auf 5v zugelegt. das rennt wieder. und die 5v hat die station vorher auch vertragen. war für 3 jahre was ähnliches (aber um 2/3 billigeres) drinnen.
fazit: nach dem hochfahren waren wir wieder auf -xx mm. wenn ich mich recht erinnere war das jener wert, der vor dem runterfahren +xx mm war.
falls mich jemand aufklären kann:
ist homematic tatsächlich ein so gebranntes kind, dass man ein gerät mit batteriebetrieb so derartig absichert, oder ist das mittlerweile in der elektronik üblich?
ich mein: 19v anstelle 4,5v ist schon recht heftig, denke ich, oder?