energyOffset

Begonnen von Nobby1805, 03 September 2019, 19:15:14

Vorheriges Thema - Nächstes Thema

Nobby1805

Hallo,
ich habe 10 HM-ES-PMSW1-PL (3 davon sind ...-DN-R1)
Bei einem davon wird ab und zu der energyOffset erhöht, obwohl der energy-Wert unverändert ist.  Dadurch wird energyCalc immer sprunghaft erhöht und ist völlig falsch :(

Ich habe mal aus dem Log die letzten Fälle heraus gesucht

31.8. 13:21:41 auf 4.200.407,7 gesetzt
31.8. 17:13:32 auf 5.039.268,4 gesetzt, also um    838.860,7 erhöht
02.9. 04:08:26 auf 5.878.129,1 gesetzt, also um    838.860,7 erhöht
02.9. 11:16:19 auf 6.716.989,8 gesetzt, also um    838.860,7 erhöht

Warum passiert das? Woher kommt der Wert 838860,7? Die Ganzzahl 8388607 ist Hex 7FFFFF

Gruß Nobby

PS während ich das geschrieben habe ist es gerade wieder passiert :(
03.9. 18:39:33 auf 8.394.711,2 gesetzt, also um 1.677.721,4 erhöht (das ist 2x838.860,7)
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

frank

normaler weise wird der offset neu gesetzt nach wiedereinschalten der versorgungsspannung.

ändert sich das poweron reading?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Nobby1805

Nein
powerOn   2018-06-22 16:37:50

an dem Schaltaktor hängt auch mein Haupt-Rechner und der Server, das würde ich sofort merken wenn da zwischendurch der "Strom" ausfällt
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

aus 10_CUL_HM
      elsif($el > 800000 && $el > $eCnt ){# handle overflow
        $eo += 838860.7;
        push @evtEt,[$mh{shash},1,"energyOffset:".$eo];

sollte man da nicht eine Meldung im Log ausgeben? Unklar ist mir, warum das bei Überschreitung von 800.000 dann nicht bei jedem Update vom Aktor passiert?
und warum wird das schon bei 800.000 gemacht und nicht erst beim wirklichen Überlauf?
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

#4
Zitat von: Nobby1805 am 04 September 2019, 09:59:36
aus 10_CUL_HM
      elsif($el > 800000 && $el > $eCnt ){# handle overflow
        $eo += 838860.7;
        push @evtEt,[$mh{shash},1,"energyOffset:".$eo];

sollte man da nicht eine Meldung im Log ausgeben? Unklar ist mir, warum das bei Überschreitung von 800.000 dann nicht bei jedem Update vom Aktor passiert?
und warum wird das schon bei 800.000 gemacht und nicht erst beim wirklichen Überlauf?

Edit: ich sollte jetzt eigentlich den Aktor kurz vom Strom nehmen um das "Problem" zu beheben, aber jetzt will ich sehen, was beim wirklichen Überlauf passiert  ;)

Edit2: jetzt passiert natürlich (erst mal) nix mehr :( da habe ich mal die Logs durchforstet und versuch den Code (wirklich) zu verstehen

$el ist wohl der vorgerige Energie-Wert
$eCnt ist der Energie-Wert in der aktuelle Message

Aha, was steht im Log

09:38:47 energy 822317.7
09:39:06 energy 822318.5
09:39:15 energy 822318.8
09:39:23 energy 822319.2
09:39:31 energy 822319.5
09:39:39 energy 822319.8
09:40:14 energy 822318.5  <----
09:40:15 energy 822319.2
09:40:15 energy 822319.5
09:40:15 energy 822319.8
09:41:06 energy 822323.3

Um 9:40:14 wird ein niedrigerer Energie-Wert empfangen als in der Message davor  :o und das ist der Auslöser, zusammen mit der Abfrage ob der energy-Wert größer 800000 ist (und das ist er ja), den Offset um die maximale Zahl 838860.7 zu erhöhen.

Fragen: warum wird ein niedrigerer energy-Wert übertragen als zuvor? Warum liegt die Überlauf-Grenze bei 800000 und nicht näher beim wirklichen Überlauf?
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

und wieder ...

10:14:04 energy 825595.8
10:14:20 energy 825596.5
10:14:28 energy 825596.9
10:14:38 energy 825597.1
10:14:39 energy 825597.2
10:14:40 energy 825597.1  <----
10:14:40 energy 825597.2
10:16:48 energy 825602.9
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

und schon wieder

11:39:46  825801.7
11:40:02  825802.4
11:40:17  825802.7
11:40:17  825802.9
11:40:18  825802.7  <------
11:40:19  825802.9
11:40:20  825803.1

Warum werden denn eigentlich so häufig aktualisierte Werte übertragen? Interessanterweise sieht in der grafischen Darstellung seit einigen Tagen komische "Schwingungen"

Mein Verdacht ist das bei den schnell nacheinander kommenden Messages die Reihenfolge über HMLAN1 und HMLAN2 nicht eingehalten wird und die VCCU dann nicht erkennen kann, dass die Message schon auf dem anderen Weg bearbeitet worden ist
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

frank

zeig mal je ein list vom device und chn2.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Nobby1805

die txThr... habe ich jetzt auf unused gesetzt, leider funktioniert das bei txThrPwr nicht
Internals:
   DEF        2C918E
   FUUID      5c7d4bb8-f33f-092f-acef-4e59e9e8a3b4acbd
   HMLAN1_MSGCNT 2213
   HMLAN1_RAWMSG E2C918E,0000,13211872,FF,FFCE,22845E2C918E020000FE0CEC00386002C508D4FE
   HMLAN1_RSSI -50
   HMLAN1_TIME 2019-09-05 13:29:27
   HMLAN2_MSGCNT 2192
   HMLAN2_RAWMSG E2C918E,0000,15F28350,FF,FFA3,22845E2C918E020000FE0CEC00386002C508D4FE
   HMLAN2_RSSI -93
   HMLAN2_TIME 2019-09-05 13:29:27
   IODev      HMLAN1
   LASTInputDev HMLAN2
   MSGCNT     4405
   NAME       Buero
   NOTIFYDEV  global
   NR         215
   NTFY_ORDER 50-Buero
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Buero_Sw
   channel_02 Buero_Pwr
   channel_03 Buero_SenPwr
   channel_04 Buero_SenI
   channel_05 Buero_SenU
   channel_06 Buero_SenF
   lastMsg    No:22 - t:5E s:2C918E d:020000 FE0CEC00386002C508D4FE
   protLastRcv 2019-09-05 13:29:27
   protRcv    2226 last_at:2019-09-05 13:29:27
   protResnd  1 last_at:2019-09-05 13:16:53
   protSnd    1310 last_at:2019-09-05 13:21:03
   protState  CMDs_done
   rssi_HMLAN1 cnt:1 min:-51 max:-51 avg:-51 lst:-51
   rssi_at_HMLAN1 cnt:2213 min:-73 max:-43 avg:-47.65 lst:-50
   rssi_at_HMLAN2 cnt:2192 min:-99 max:-92 avg:-94.02 lst:-93
   READINGS:
     2019-09-03 22:31:59   Activity        alive
     2019-09-05 13:21:00   CommandAccepted yes
     2015-03-24 23:57:01   D-firmware      2.5
     2015-03-24 23:57:01   D-serialNr      LEQ0535594
     2018-06-22 16:38:14   PairedTo        0x2AEDA2
     2015-03-24 23:57:03   R-pairCentral   0x2AEDA2
     2018-06-22 16:38:14   RegL_00.        02:01 0A:2A 0B:ED 0C:A2 15:FF 18:00 00:00
     2018-06-22 16:37:50   powerOn         2018-06-22 16:37:50
     2019-09-03 22:22:13   rssi_HMLAN1     -51
     2019-08-19 14:14:41   rssi_HMLAN2     -84
     2019-09-05 13:29:27   rssi_at_HMLAN1  -50
     2019-09-05 13:29:27   rssi_at_HMLAN2  -93
     2019-09-05 13:21:03   state           CMDs_done
   helper:
     HM_CMDNR   34
     PONtest    1
     cSnd       012AEDA22C918E0206,012AEDA22C918E02040000000001
     mId        00AC
     peerFriend
     peerOpt    -:powerMeter
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +2C918E,00,00,00
       nextSend   1567682967.35171
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         2C918E
         00
         00
         00
     mRssi:
       mNo        22
       io:
         HMLAN1:
           -44
           -44
         HMLAN2:
           -93
           -93
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       HMLAN1:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
       at_HMLAN1:
         avg        -47.6588341617714
         cnt        2213
         lst        -50
         max        -43
         min        -73
       at_HMLAN2:
         avg        -94.029197080292
         cnt        2192
         lst        -93
         max        -92
         min        -99
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   2.5
   model      HM-ES-PMSW1-PL
   room       hidden
   rssiLog    1
   serialNr   LEQ0535594
   subType    powerMeter
   webCmd     getConfig:clear msgEvents

Internals:
   DEF        2C918E02
   FUUID      5c7d4bb8-f33f-092f-e649-0eeb4b99290da9e9
   NAME       Buero_Pwr
   NOTIFYDEV  global
   NR         218
   NTFY_ORDER 50-Buero_Pwr
   STATE      826084.4
   TYPE       CUL_HM
   chanNo     02
   device     Buero
   READINGS:
     2015-03-24 23:57:04   R-averaging     1 s
     2015-03-24 23:57:04   R-sign          off
     2015-03-24 23:57:04   R-txMinDly      8 s
     2019-09-05 13:18:10   R-txThrCur      unused
     2019-09-05 13:18:57   R-txThrFrq      unused
     2019-09-05 13:08:18   R-txThrPwr      1000 W
     2019-09-05 13:21:03   R-txThrVlt      unused
     2019-09-05 13:21:03   RegL_01.         00:00 08:00 7A:01 7B:08 7C:01 7D:86 7E:A0 7F:00 80:00 81:00 82:00 83:00
     2019-09-05 13:29:27   boot            off
     2019-09-05 13:29:27   current         709
     2019-09-05 13:29:27   eState          E: 826084.4 P: 144.32 I: 709 U: 226 f: 49.98
     2019-09-05 13:29:27   energy          826084.4
     2019-09-05 13:29:27   energyCalc      4187631.4
     2019-09-05 12:15:37   energyOffset    3361547
     2019-09-05 13:29:27   frequency       49.98
     2019-09-05 13:29:27   power           144.32
     2019-09-05 13:29:27   state           826084.4
     2019-09-05 13:29:27   voltage         226
   helper:
     cfgChkResult No regs found for:

Buero_Pwr type:powerMeter -
list:peer register         :value
   1:      averaging        :1 s
   1:      sign             :off
   1:      txMinDly         :8 s
   1:      txThrCur         :1000 mA
   1:      txThrFrq         :2 Hz
   1:      txThrPwr         :1000 W
   1:      txThrVlt         :23.2 V
                       
                       

     getCfgListNo
     peerFriend
     peerOpt    -:powerMeter
     regLst     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
   nb:
     cnt        3
Attributes:
   model      HM-ES-PMSW1-PL
   room       Büro,_Wh
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

frank

Zitatleider funktioniert das bei txThrPwr nicht
leider schon lange.

setze mal den hmlan1 als prefered io.

jetzt sollte es nur noch alle 2.5 min daten geben und zusätzlich bei sprüngen grösser 1000w.

an deine hmlan1/2 theorie glaube ich noch nicht. eher fhem freezes. oder gibt es ein umswitchen der io durch die vccu?

die "negativen" energywerte müssten ja auch unterhalb von 800000 zu sehen sein.

vielleicht auch txmindly mal mit 0 probieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Nobby1805

Zitat von: frank am 05 September 2019, 14:08:06
setze mal den hmlan1 als prefered io.
Wie mache ich das denn? :-[
Zitat von: frank am 05 September 2019, 14:08:06
jetzt sollte es nur noch alle 2.5 min daten geben und zusätzlich bei sprüngen grösser 1000w.
Solche Sprünge wird es an dem Anschluß nie geben  8)
Zitat von: frank am 05 September 2019, 14:08:06
an deine hmlan1/2 theorie glaube ich noch nicht. eher fhem freezes. oder gibt es ein umswitchen der io durch die vccu?
freezes gab es zeitlich korrespondierend keine ... Gestern 9:40 gab es zeitgleich
2019.09.04 09:40:14.790 1: HMLAN_Parse: HMLAN2 new condition init
2019.09.04 09:40:14.805 1: 192.168.1.43:1000 reappeared (HMLAN2)
2019.09.04 09:40:15.866 1: HMLAN_Parse: HMLAN2 new condition ok

das passiert leider immer wieder, anscheinend haben andere auch das Problem wenn der HMLAN hinter einer Devolo-Strecke hängt
Zitat von: frank am 05 September 2019, 14:08:06
die "negativen" energywerte müssten ja auch unterhalb von 800000 zu sehen sein.
da habe ich nicht verstanden was du meinst  :-[

Letztlich vermute ich, dass das Problem jetzt gar nicht auftreten wird weil durch die Thresholds die Messages nur noch alle 2-3 Minuten kommen
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

zum Thema "Verzögerung einer Message zwischen den beiden HMLAN" habe ich folgendes Logging erzeugt
2019.09.06 09:10:38.842 0: HMLAN_Parse: HMLAN1 R:E2C918E   stat:0000 t:175AB146 d:FF r:FFCC     m:F4 845E 2C918E 020000 FE647E003C9602FC08B4FD
2019.09.06 09:10:56.953 1: HMLAN_Parse: HMLAN2 new condition disconnected
2019.09.06 09:10:56.969 1: 192.168.1.43:1000 disconnected, waiting to reappear (HMLAN2)
2019.09.06 09:10:56.970 1: HMLAN_Parse: HMLAN2 new condition disconnected
2019.09.06 09:11:58.027 1: HMLAN_Parse: HMLAN2 new condition init
2019.09.06 09:11:58.043 1: 192.168.1.43:1000 reappeared (HMLAN2)
2019.09.06 09:11:58.193 0: HMLAN_Parse: HMLAN2 R:E2C918E   stat:0000 t:1A2C1982 d:FF r:FF9F     m:F4 845E 2C918E 020000 FE647E003C9602FC08B4FD
2019.09.06 09:11:58.931 1: HMLAN_Parse: HMLAN2 new condition ok

Hier kommt die Message vom Gerät über den HMLAN2 Weg 79,4 Sekunden nach derselben Message über HMLAN1 an.

Ich bin mir ziemlich sicher, dass die von mir vermutete Überholung auftritt wenn die Messages vom Gerät in kürzerem Abstand gesendet werden. (Ich müsste testweise mal wieder die Default-tresholds einstellen)
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

So, es ist bei eingeschaltetem Log passiert

2019.09.06 15:09:50.322 0: HMLAN_Parse: HMLAN2 R:E2C918E   stat:0000 t:1B74FF5B d:FF r:FFA2     m:82 845E 2C918E 020000 FE86A700338B027308D202
2019.09.06 15:12:54.060 0: HMLAN_Parse: HMLAN2 R:E2C918E   stat:0000 t:1B77BF92 d:FF r:FFA3     m:83 845E 2C918E 020000 FE86E7003540028608D0FF
2019.09.06 15:12:54.410 0: HMLAN_Parse: HMLAN2 R:E2C918E   stat:0000 t:1B77C21D d:FF r:FFA3     m:78 A45F 2C918E 2AEDA2 FE86E800381002A508D3FF
2019.09.06 15:12:54.718 0: HMLAN_Parse: HMLAN2 R:E2AEDA2   stat:0000 t:1B77C292 d:FF r:FFAE     m:78 8002 2AEDA2 2C918E 00
2019.09.06 15:12:54.733 0: HMLAN_Parse: HMLAN1 R:E2C918E   stat:0000 t:18A65833 d:FF r:FFD2     m:83 845E 2C918E 020000 FE86E7003540028608D0FF
2019.09.06 15:12:55.227 0: HMLAN_Parse: HMLAN1 R:E2C918E   stat:0000 t:18A65ABD d:FF r:FFD2     m:78 A45F 2C918E 2AEDA2 FE86E800381002A508D3FF
2019.09.06 15:13:23.289 0: HMLAN_Parse: HMLAN1 R:E2C918E   stat:0000 t:18A6D92B d:FF r:FFD2     m:79 A45F 2C918E 2AEDA2 FE86F4002E3B023908D0FF


2019-09-06_15:09:50 Buero_Pwr energy: 829200.7
2019-09-06_15:12:54 Buero_Pwr energy: 829207.1
2019-09-06_15:12:54 Buero_Pwr energy: 829207.2
2019-09-06_15:12:54 Buero_Pwr energy: 829207.1
2019-09-06_15:12:54 Buero_Pwr energyOffset: 4200407.7
2019-09-06_15:12:55 Buero_Pwr energy: 829207.2
2019-09-06_15:13:23 Buero_Pwr energy: 829208.4


Leider habe ich keine  Ahnung wieso dazwischen eine Message (... m:78 8002 ...) vom HMLAN zum Aktor geloggt wird?

Und jetzt setzte ich die Thresholds wieder in den Safe-Mode  8)
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)