Für Regenmesser monotonic Userreading in Dummy für "statistics"-Modul?

[FFHEM]

Guten Tag allerseits,

ich möchte meinen seit Jahren funktionierenden Regensensor (Reedkontakt in Wippe aus altem ELV-Regensensor mit Homematic-Kontakt HM-SCI-3-FM), der ein notify auslöst und dann z. Zt. noch quasi handgestrickt die Werte für Regen/letzte Stunde, Regen/Tag, usw. in Dummys ablegt, ersetzen durch eine Lösung, die das "statistics"-Modul verwendet.
Dazu muss ich dem statistics-Modul ja irgendwie ein Reading anbieten - welches ich nicht habe, da ich ja keinen "echten" Regensensor mit einem Reading habe.
Deshalb, dachte ich mir, baue ich mir eine Dummy-Variable mit einem eigenen Reading namens "neu", in die vom notify immer der aktuelle Regenwert (ist immer 0.36) geschrieben wird und der dann ein Userreading "Gesamtregen" mit "monotonic" zum Aufsummieren benutzt. Dieses Userreading soll dann später in statistics verwendet werden.
Also so etwas:

Code Auswählen Erweitern

Internals:
   CFGFN     
   FUUID      606ad6e3-f33f-26cd-8d68-09b3e9613ee967f8
   NAME       Regensumme
   NR         25368
   STATE      0.36
   TYPE       dummy
   READINGS:
     2021-04-05 12:05:52   Gesamtregen     128.66
     2021-04-05 12:05:52   neu             0.36
     2021-04-05 12:05:34   state           0.36
Attributes:
   room       Wetterstation
   userReadings Gesamtregen monotonic { ReadingsVal("Regensumme","neu", 0); }

Leider funktioniert das nicht so wie gedacht: Wenn ich mit

Code Auswählen Erweitern

setreading Regensumme neu 0.36
einen Eintrag generiere, ändert sich Gesamtregen nicht!

Falls man nun statt des Readings "neu" den state mit set Regensumme 0.36 setzt und das Userreading entsprechend auf "state" ändert, wird "Gesamtregen" zwar hin und wieder erhöht, aber nicht zuverlässig.
Hat jemand eine Idee?






https://forum.fhem.de/index.php?topic=98851.0

[Otto123]

Moin,

ja eine aber nur eine Idee:
Ich habe mal beobachtet (und verwende es auch so) das ein Zähler der immer mal ein Reset (0) erfährt mit dem Zusatz monotonic wirklich kontinuierlich erhalten bleibt. Er ist offenbar nicht für die Summenbildung von Einzelwerten:
Probiere also mal

Code Auswählen Erweitern

setreading Regensumme neu 0.36
setreading Regensumme neu 0
setreading Regensumme neu 0.36
setreading Regensumme neu 0.56
setreading Regensumme neu 1.36

Typische Anwendung: Energiezähler in Messteckdosen die bei Stromlos ihren alten Wert vergessen und auf null setzen.
Steht von der Sache her auch genau so in der Doku:

monotonic: if the difference between the current and the previously evaluated value is positive the reading is incremented by this difference. this allows to derive a monotonic growing counter from an original counter even if the original will be rest by a power loss

Wenn ich Dich richtig verstehe, musst Du einfach den Wert auf den alten auf addieren?

Gruß Otto

[justme1968]

warum denn ein extra dummy und notify?

du kannst doch direkt im regensonor device aufsummieren und user readings verwenden.

ansonsten: monotonic braucht mindestens zwei events da immer die differenz aus aktuellem und letzen wert aufsummiert wird und negative differenzen ignoriert werden.

[FFHEM]

Wenn ich Dich richtig verstehe, musst Du einfach den Wert auf den alten auf addieren?

@Otto: Exakt!
Habe Deinen Tipp ausprobiert, und wenn ich das folgende Befehlspaar im notify verwende, müsste es klappen:

Code Auswählen Erweitern


setreading Regensumme neu 0
setreading Regensumme neu 0.36
Vielen Dank!

@justme:
Ich habe leider keinen dezidierten Regensensor, sondern nur den o. g. Homematickontakt, deshalb muss ich eine Dummyvariable nehmen.
Falls ich ein Reading im HM-Kontakt erzeugen wollte, hätte ich ja noch keinen Wert, den ich ins Userreading schreiben könnte - es müssten ja auch 2 Werte sein (0 gefolgt von 0.36, s. oben). Sehe ich das so richtig?
Ebenfalls vielen Dank!

[Otto123]

Für meine Begriffe könntest Du einfacher den trigger_cnt im SCI (den gibt es doch da?) mit einem userReadings monotonic dort im Device aufsummieren. Der dann mit 0.36 multipliziert ergibt Deine absolute Gesamtregenmenge. Das wäre doch um einiges einfacher alles mehrfach mit notify usw. umher zu schubsen.
Also dort (im Channel Device des SCI)

Code Auswählen Erweitern

Gesamtregen:trigger_cnt.* monotonic { ReadingsNum($name,"trigger_cnt", 0)*0.36 }

Übrigens kann man ein solches Reading mit setreading einfach auf einen Startwert setzen, z.B. um alte Stände zu erhalten.

[FFHEM]

Habe Deinen Vorschlag ausprobiert, war mir sicher, das müsste klappen, aber es wird kein neues Userreading erzeugt:
Nach 2-maligem Wippenschlag hat sich nur die trigger_cnt-Zahl um 2 erhöht.
Der trigger_cnt hat aber nur 8 Bit und zählt nach 255 bei 0 weiter. Das würde dann nicht funktionieren?

Habe wegen besserer Testmöglichkeit das ganze mit einem HM-SEC-SCO getestet, der auch trigger_cnt besitzt.
Auch hier bekomme ich kein Userreading erzeugt.

Code Auswählen Erweitern


attr userReadings Melder_Arbeitszimmer_Fenster Regengesamt monotonic { ReadingsNum($name,"trigger_cnt", 0)*0.36 }

Vielleicht mache ich das doch mit dem notify und dem Dummy.

Code Auswählen Erweitern

Internals:
   DEF        6BC6A2
   FUUID      5f3e93a1-f33f-26cd-4dd8-9e231c3d21e696a7
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     65
   NAME       Melder_Arbeitszimmer_Fenster
   NOTIFYDEV  global
   NR         1250
   NTFY_ORDER 50-Melder_Arbeitszimmer_Fenster
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:30 - t:41 s:6BC6A2 d:6339D2 012F00
   myHmUART_MSGCNT 65
   myHmUART_RAWMSG 0500002E30B6416BC6A26339D2012F00
   myHmUART_RSSI -46
   myHmUART_TIME 2021-04-05 17:16:52
   peerList   Arbeitszimmerthermostat_WindowRec,HT_Arbeitszimmer_WindowRec
   protLastRcv 2021-04-05 17:16:52
   protRcv    65 last_at:2021-04-05 17:16:52
   protRcvB   10 last_at:2021-04-05 17:16:52
   protSnd    55 last_at:2021-04-05 17:16:51
   protState  CMDs_done
   rssi_at_myHmUART cnt:65 min:-51 max:-45 avg:-47.15 lst:-46
   READINGS:
     2021-04-03 17:19:38   Activity        alive
     2020-08-20 17:36:33   CommandAccepted no
     2020-08-20 17:36:09   D-firmware      1.0
     2020-08-20 17:36:09   D-serialNr      PEQ2235033
     2020-08-20 17:52:21   PairedTo        0xFF3004
     2020-08-20 17:36:19   R-Arbeitszimmerthermostat_WindowRec-expectAES off
     2020-08-20 17:36:19   R-Arbeitszimmerthermostat_WindowRec-peerNeedsBurst on
     2020-08-20 17:24:19   R-HT_Arbeitszimmer_WindowRec-expectAES off
     2020-08-20 17:24:19   R-HT_Arbeitszimmer_WindowRec-peerNeedsBurst on
     2020-08-20 17:20:17   R-cyclicInfoMsg on
     2020-08-20 17:20:18   R-eventDlyTime  0 s
     2020-08-20 17:20:17   R-pairCentral   0xFF3004
     2020-08-20 17:20:17   R-sabotageMsg   on
     2020-08-20 17:20:18   R-sign          on
     2020-08-20 17:52:21   RegL_00.        00:00 02:01 09:01 0A:FF 0B:30 0C:04 10:01 14:06
     2020-08-20 17:52:22   RegL_01.        00:00 08:01 20:9C 21:00 30:06
     2020-08-20 17:52:23   RegL_04.Arbeitszimmerthermostat_WindowRec 00:00 01:01
     2020-08-20 17:52:23   RegL_04.HT_Arbeitszimmer_WindowRec 00:00 01:01
     2021-04-05 17:16:52   Regengesamt     20.88
     2020-08-20 17:36:12   aesCommToDev    ok
     2020-08-20 17:36:12   aesKeyNbr       00
     2021-04-05 16:37:46   alive           yes
     2021-04-05 17:16:52   battery         ok
     2021-02-05 10:13:30   cfgState        ok
     2021-04-05 17:16:51   commState       CMDs_done
     2021-04-05 17:16:52   contact         closed (to Arbeitszimmerthermostat)
     2021-04-03 17:09:45   peerList        Arbeitszimmerthermostat_WindowRec,HT_Arbeitszimmer_WindowRec
     2020-08-20 17:52:19   powerOn         2020-08-20 17:52:19
     2021-04-05 16:37:46   recentStateType info
     2021-04-05 16:37:46   sabotageError   off
     2021-04-05 17:16:52   state           closed
     2021-04-05 17:16:52   trigger_cnt     47
   helper:
     HM_CMDNR   48
     mId        00C7
     peerFriend peerAct,peerVirt
     peerIDsState complete
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_myHmUART:
         avg        -47.1538461538462
         cnt        65
         lst        -46
         max        -45
         min        -51
     shadowReg:
     tmpl:
Attributes:
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   actCycle   002:50
   actStatus  alive
   alias      ArbeitszimmerFenster
   autoReadReg 5_readMissing
   devStateIcon open:10px-kreis-rot closed:10px-kreis-gruen
   expert     defReg,rawReg
   firmware   1.0
   group      Fenster/Tür
   model      HM-SEC-SCO
   peerIDs    00000000,44E88103,6339D203
   room       Alarmanlage
   serialNr   PEQ2235033
   subType    threeStateSensor
   userReadings Regengesamt monotonic { ReadingsNum($name,"trigger_cnt", 0)*0.36 }
   userattr   room_map structexclude

[Otto123]

Und was ist das ?  2021-04-05 17:16:52   Regengesamt     20.88

Aber Du ignorierst den Trigger im userReadings in meinem Konstrukt! Der ist gerade bei Homematic Geräten wichtig! -> :trigger_cnt.*

Der trigger_cnt hat aber nur 8 Bit und zählt nach 255 bei 0 weiter. Das würde dann nicht funktionieren?

Das ist doch aber genau die Funktion von monotonic, wenn der Zähler mal ein Reset macht geht es danach weiter. Kannst Du doch an deinem Dummy prima testen!
Man müsste überlegen ob man diesen einen Wippenschlag von 255 auf 0 korrigieren müsste - da bin ich nicht sicher.

[FFHEM]

Und was ist das ?  2021-04-05 17:16:52   Regengesamt     20.88

Komplett übersehen!!
Vielen Dank, werde ich morgen genauer ansehen, für heute bin ich zu nichts mehr zu gebrauchen....