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)
normaler weise wird der offset neu gesetzt nach wiedereinschalten der versorgungsspannung.
ändert sich das poweron reading?
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
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?
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?
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
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
zeig mal je ein list vom device und chn2.
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
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.
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
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)
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)