Mit den Updates von gestern hatte ich jetzt erstmals einen Overload. Ich habe die beiden HM-Dateien wieder auf den Stand vom Samstag zurückgedreht.
Ich hatte gestern nach dem Update auch sofort ein Overload, obwohl ich nur einen neuen Actor angelernt habe, sonst waren nur zwei Temperatursensoren aktiv, mit denen ich noch nie ein Overloadproblem hatte.
Chipmunk
Hallo,
HM-CFG-LAN: Update auf Firmware 0.964
HM-CFG-USB: Update auf Firmware 0.967, update hmland auf aktuellen git-Head (git pull && make)
Alte Firmwareversionen senden kein Load-Byte in der Antwort auf 'K'.
Gruss
Michael
Danke für den Hinweis. Meine Firmware war auf 0.967, aber mein hmland auf Stand 12/2014.
Ich fände es schön, wenn so eine Änderung mit Abhängigkeit zu externen Komponenten als Change in der CHANGED Datei auftaucht, dann wird es im Screen angezeigt und man hat die Möglichkeit zu reagieren.
Das macht auch zum jetzigen Zeitpunkt noch Sinn. ;)
Viele updaten in größeren Abständen und werden davon auch eher überrascht werden.
Ich habe die aktuelle FW-Version des HM-CFG-USB und auch den HMLAND aktualisiert und noch ein Update des FHEM gemacht, bekomme aber immer noch sofort nach dem Start ein overload. Bis zur vorletzten Version war alles in Ordnung. Da ich noch nicht im Echtbetrieb bin, habe ich eigentlich keine Sendelast.
Chipmunk
Ich schließe mich dem an. Git-Repo ist aktuell.
Und mit dem heutigen FHEM-Update kamen diese Overload-Hinweise.
Nach dem update vom hmland diesen auch neu gestartet?
hm - meiner läuft einwandfrei
geändert ist nur die Berechnung - das ist ein Anzeigewert.
Könnt ihr einmal loggen, was passiert?
ich habe 0.964 - muss auch einmal einen update machen... vielleicht kommen in der neuen Version jetzt andere Werte?
Ja. Ich hatte hmland natürlich neu gestartet. Anders kann ich auch kein Git-Pull machen.
Die Fehler sind durch das FHEM-Update aufgetaucht. Hmland habe ich daraufhin nur aktualisiert, weil hier im Thread so etwas ähnliches erwähnt wurde.
Also bei mir hat der git pull und ein anschließender RasPi Neustart das Problem gelöst.
Hi Martin,
Zitat von: martinp876 am 22 Juni 2015, 22:09:47
hm - meiner läuft einwandfrei
geändert ist nur die Berechnung - das ist ein Anzeigewert.
Overload kommt durch autoreadreg wenn das Load-Byte nicht vorhanden ist, da dann 0% als Load angenommen wird...
Gruss
Michael
Muss ich mir ansehen. Overload sollte nur durch den status gesetzt werden, egal was die berechnung sagt.
Autoreadreg ist eine hintergrundaktion welche das senden stopt, wenn 40% erreicht sind.
Ah, da haben wir es. Wenn die load nicht angezeigt wird sendet fhem bis zum overload. Das werde ich kontrolieren, da fehlt noch etwas.
Wollte mich auch gerade melden. Heute mal ein update gemacht (das erste seit 5 Monaten) beide HM-CFG-Lan auf Firmware 0.964 gebracht und der HMLAN1 macht jetzt auch ständig einen Overload, aber Martin ist ja drann.
VG
Frank
habe es geprüft. im Prinzip funktioniert es.
- mit dem keepalive wird alle 25sec die load vom IO gelesen.
- die Bremse steht auf 40% default - wenn also die Load (internal msgLoadCurrent) den Wert überschreitet werden die automatischen readings unterbrochen.
Lücke ist also, wenn in den 25 sec die Load von 39% auf 100 ansteigt. Das sieht FHEM nicht, da eben nur alle 25sec nachgesehen wird.
setzt einmal attr wdTimer auf 5. Dann sollte es nicht mehr passieren, es wird alle 5sec gepollt. Das ist kaum zeit, in overload zu kommen.
ich habe auch FW 0.964 - und es klappt.
Hallo Martin, dachte mir gestern schon so etwas und habe gestern Abend wdTimer vom betroffenen HMLAN schon auf 5 gestellt. Bis jetzt hat es keinen Overload mehr gegeben. Darauf gekommen bin ich durch den zweiten HMLAN, der stand schon seit der Inbetriebnahme auf wdTimer 5 und hatte nie einen Overload.
VG
Frank
hm - mitrechnen will ich nicht immer. Vielleicht schicke ich die keepalive etwas öfter, wenn viele messages kommen.
ihr habt sicher viele burst devices.
die neue Version wird nach 10 messages den Status automatisch prüfen. Damit sollte es keine Probleme mehr geben - so lange man nicht Burst auf nicht vorhandene Devices sendet ;)
Eigentlich habe ich keine burst devices.
Ausserdem habe ich die seltsame Anzeige eines negativen Wertes in der load history
ZitatmsgLoadCurrent 100
msgLoadHistory 5min steps: -99/0/0/0/0/0/0/0/100/0/-/-
Chipmunk
ZitatAusserdem habe ich die seltsame Anzeige eines negativen Wertes in der load history
das sollte grundsätzlich ok sein. => in den letzten 5 min ist die load um 99% gesunken. aber passt irgendwie nicht zu 100% loadcurrent. das müsste wohl dann auf 1% stehen.
Zitat von: martinp876 am 24 Juni 2015, 20:27:45
ich habe auch FW 0.964 - und es klappt.
0.964 ist die aktuelle fuer den HM-CFG-LAN, die unterstuetzt das Load-Byte. Die alte 0.961 wohl leider nicht.
Beim HM-CFG-USB braucht man mindestens 0.967 und einen neuen hmland fuers Load-Byte (ich gebe am WE die 0.100 als Release frei, die meldet sich dann auch als HM-USB-IF).
Zitat von: martinp876 am 24 Juni 2015, 20:39:21
hm - mitrechnen will ich nicht immer. Vielleicht schicke ich die keepalive etwas öfter, wenn viele messages kommen.
Ne, immer mitrechnen waere Quatsch. Halt irgendwo schreiben, dass man ne aktuelle Firmware auf den IOs braucht (CHANGES-Datei wie vorgeschlagen?)
Gruss
Michael
ZitatHalt irgendwo schreiben, dass man ne aktuelle Firmware auf den IOs braucht
im reading "D-firmware"
Das mit der HMLAN 0.964 kann ich so nicht unterschreiben. Ich hatte gestern morgen den HMLAN extra ein Firmwareupdate auf die 0.964 verpasst und gestern Nachmittag dann trotzdem die Overload Meldung. Abhilfe brachte erst wdTimer auf 5 zu setzen.
VG
Frank
Nach den negativen Werten kommt in der History im nächsten Reading sofort immer ein gleich hoher positiver Wert.
Es passt aber trotzdem irgendwie nicht zum current Reading von 100%
Ich habe einige Devices, die nicht in Betrieb sind. Der Loadaufbau scheint davon zu kommen,dass auf Teufel-komm-raus versucht wird, von diesen ein ACK zu erhalten, bis der Overload erreicht wird.
Da wäre vieleicht irgendein Schutzmechanismus nötig, der ab einer gewissen Loadmarke den verzweifelten Verbindungsversuchen ein Ende setzt.
Chipmunk
ZitatIch habe einige Devices, die nicht in Betrieb sind.
setze dort autreadreg=0
Danke, das hat geholfen, ich muss dann nur bei Inbetriebnahme daran denken, dass ich bei allen Devices das wieder auf 4 zurücksetze.
Chipmunk
Könnte man mit einem Notify machen.
nur mal so als hinweis:
nach einem "condition timeout/disconnected" beim hmlan meldet sich dieser mit load=0% zurück. somit könnte man durch auslassen der keepalive message einen overload zurücksetzen. ;)
ich finde, das könnte man in eine funktion einbauen:
set hmlan disconnect
gruss frank
ich hatte in der nacht auch einen overload, der durch einen permanenten statusrequest auf einen ausgebauten aktor entstanden ist (ich hätte auf meinen tipp mit autoreadreg=0 hören sollen ;) ). ausgelöst wurde die aktion wohl durch einen selbstständigen reboot der fritzbox. auf dem weg zum overload gab es genügend loadmeldungen über 40%. im log nach restart fällt auf, dass es eine k-message zu wenig für die antworten des hmlan gibt.
2015.06.25 03:42:30.969 0: HMLAN_Send: hmlan1 I:K
2015.06.25 03:42:30.975 0: HMLAN_Send: hmusb1 I:K
2015.06.25 03:42:30.985 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:00CAFCA8 IDcnt:0015 L:19 %
2015.06.25 03:42:31.014 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:022BC224 IDcnt:000A L:4 %
########### reboot fritzbox ###################
2015.06.25 03:44:31.488 1: Including fhem.cfg
2015.06.25 03:44:36.963 1: HMLAN_Parse: hmusb1 new condition disconnected
2015.06.25 03:44:37.102 1: HMLAN_Parse: hmusb1 new condition init
2015.06.25 03:44:37.146 1: HMLAN_Parse: hmlan1 new condition disconnected
2015.06.25 03:44:37.167 1: HMLAN_Parse: hmlan1 new condition init
2015.06.25 03:45:23.936 0: Server started with 316 defined entities (version $Id: fhem.pl 8574 2015-05-14 07:59:32Z rudolfkoenig $, os linux, user root, pid 1832)
2015.06.25 03:45:27.125 0: HMLAN_Send: hmusb1 I:K
2015.06.25 03:45:27.132 0: HMLAN_Send: hmlan1 I:K
2015.06.25 03:45:27.859 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:00CCE9B3 IDcnt:0015 L:19 %
2015.06.25 03:45:30.144 1: HMLAN_Parse: hmlan1 new condition ok
2015.06.25 03:45:31.716 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:00CDACE3 IDcnt:0016 L:19 %
2015.06.25 03:45:31.722 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0000EFCB IDcnt:0000 L:0 %
2015.06.25 03:45:32.416 1: HMLAN_Parse: hmusb1 new condition ok
2015.06.25 03:45:47.093 0: HMLAN_Send: hmlan1 S:+285A44,00,01,00
2015.06.25 03:45:47.095 0: HMLAN_Send: hmlan1 S:S28646EA2 stat: 00 t:00000000 d:01 r:28646EA2 m:01 A001 1ACE1F 285A44 010E
2015.06.25 03:45:47.159 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00020146 d:FF r:FFDE m:01 A001 1ACE1F 285A44 010E
2015.06.25 03:45:47.351 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0002020E d:FF r:FFDE m:01 A001 1ACE1F 285A44 010E
2015.06.25 03:45:47.587 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:000202D6 d:FF r:FFDE m:01 A001 1ACE1F 285A44 010E
2015.06.25 03:45:47.708 0: HMLAN_Parse: hmlan1 R:R28646EA2 stat:0008 t:00000000 d:FF r:7FFF m:01 A001 1ACE1F 285A44 010E
2015.06.25 03:45:52.719 0: HMLAN_Send: hmusb1 I:K
2015.06.25 03:45:52.725 0: HMLAN_Send: hmlan1 I:K
2015.06.25 03:45:52.737 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:00CE10DD IDcnt:0019 L:25 %
2015.06.25 03:45:52.788 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0002172A IDcnt:0004 L:1 %
#
#
2015.06.25 03:49:38.008 0: HMLAN_Send: hmusb1 I:K
2015.06.25 03:49:38.033 0: HMLAN_Send: hmlan1 I:K
2015.06.25 03:49:38.043 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:00D18124 IDcnt:0019 L:41 %
2015.06.25 03:49:38.059 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0005874B IDcnt:0004 L:1 %
#
#
2015.06.25 04:09:13.664 0: HMLAN_Send: hmusb1 I:K
2015.06.25 04:09:13.669 0: HMLAN_Send: hmlan1 I:K
2015.06.25 04:09:13.679 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:00E37213 IDcnt:0019 L:100 %
2015.06.25 04:09:13.730 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:001777BD IDcnt:0004 L:1 %
2015.06.25 04:09:13.761 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:001777E7 d:FF r:FFDE m:CA A001 1ACE1F 285A44 010E
2015.06.25 04:09:13.985 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:001778AF d:FF r:FFDE m:CA A001 1ACE1F 285A44 010E
2015.06.25 04:09:14.124 0: HMLAN_Parse: hmlan1 R:R2879E478 stat:0208 t:00000000 d:FF r:7FFF m:CA A001 1ACE1F 285A44 010E
2015.06.25 04:09:14.126 0: HMLAN_Parse: hmlan1 no ACK from 285A44
2015.06.25 04:09:15.021 0: HMLAN_Parse: hmlan1 R:E2064CB stat:0000 t:00E3774A d:FF r:FFB4 m:A2 8670 2064CB 000000 00963F
2015.06.25 04:09:15.050 0: HMLAN_Parse: hmusb1 R:E2064CB stat:0000 t:00177CDB d:FF r:FFA8 m:A2 8670 2064CB 000000 00963F
2015.06.25 04:09:15.180 0: HMLAN_Send: hmlan1 S:S2879EAF8 stat: 00 t:00000000 d:01 r:2879EAF8 m:CB A001 1ACE1F 285A44 010E
2015.06.25 04:09:15.789 0: HMLAN_Parse: hmlan1 R:R2879EAF8 stat:0408 t:00000000 d:FF r:7FFF m:CB A001 1ACE1F 285A44 010E
2015.06.25 04:09:15.909 1: HMLAN_Parse: hmlan1 new condition ERROR-Overload
2015.06.25 04:09:19.214 0: HMLAN_Parse: hmlan1 no ACK from 285A44
nach dem overload wird kein versuch mehr unternommen einen statusrequest auf diesen aktor zu senden. eigentlich hätte ich ein umassignen auf den hmusb erwartet.
list vom aktor
Internals:
DEF 285A44
IODev hmlan1
NAME SwitchUP02
NR 493
NTFY_ORDER 50-SwitchUP02
STATE IOerr
TYPE CUL_HM
peerList self01,
protCmdDel 2
protIOdly 459 last_at:2015-06-25 04:09:19
protIOerr 1 last_at:2015-06-25 04:10:20
protSnd 459 last_at:2015-06-25 04:09:15
protState CMDs_done_Errors:1
Readings:
2015-01-03 17:34:33 .D-devInfo 010100
2015-01-03 17:34:33 .D-stc 10
2015-01-03 17:35:06 .protLastRcv 2015-01-03 17:35:06
2015-01-03 17:34:34 CommandAccepted yes
2015-01-03 17:34:33 D-firmware 1.12
2015-01-03 17:34:33 D-serialNr LEQ0130401
2015-01-03 17:35:02 PairedTo 0x1ACE1F
2015-01-03 17:35:02 R-intKeyVisib visib
2015-01-03 17:35:02 R-pairCentral 0x1ACE1F
2015-01-03 17:35:05 R-self01-lgActionType jmpToTarget
2015-01-03 17:35:05 R-self01-lgCtDlyOff geLo
2015-01-03 17:35:05 R-self01-lgCtDlyOn geLo
2015-01-03 17:35:05 R-self01-lgCtOff geLo
2015-01-03 17:35:05 R-self01-lgCtOn geLo
2015-01-03 17:35:05 R-self01-lgCtValHi 100
2015-01-03 17:35:05 R-self01-lgCtValLo 50
2015-01-03 17:35:05 R-self01-lgMultiExec on
2015-01-03 17:35:05 R-self01-lgOffDly 0 s
2015-01-03 17:35:05 R-self01-lgOffTime unused
2015-01-03 17:35:05 R-self01-lgOffTimeMode absolut
2015-01-03 17:35:05 R-self01-lgOnDly 0 s
2015-01-03 17:35:05 R-self01-lgOnTime unused
2015-01-03 17:35:05 R-self01-lgOnTimeMode absolut
2015-01-03 17:35:05 R-self01-lgSwJtDlyOff off
2015-01-03 17:35:05 R-self01-lgSwJtDlyOn on
2015-01-03 17:35:05 R-self01-lgSwJtOff dlyOn
2015-01-03 17:35:05 R-self01-lgSwJtOn dlyOff
2015-01-03 17:35:05 R-self01-shActionType jmpToTarget
2015-01-03 17:35:05 R-self01-shCtDlyOff geLo
2015-01-03 17:35:05 R-self01-shCtDlyOn geLo
2015-01-03 17:35:05 R-self01-shCtOff geLo
2015-01-03 17:35:05 R-self01-shCtOn geLo
2015-01-03 17:35:05 R-self01-shCtValHi 100
2015-01-03 17:35:05 R-self01-shCtValLo 50
2015-01-03 17:35:05 R-self01-shOffDly 0 s
2015-01-03 17:35:05 R-self01-shOffTime unused
2015-01-03 17:35:05 R-self01-shOffTimeMode absolut
2015-01-03 17:35:05 R-self01-shOnDly 0 s
2015-01-03 17:35:05 R-self01-shOnTime unused
2015-01-03 17:35:05 R-self01-shOnTimeMode absolut
2015-01-03 17:35:05 R-self01-shSwJtDlyOff off
2015-01-03 17:35:05 R-self01-shSwJtDlyOn on
2015-01-03 17:35:05 R-self01-shSwJtOff dlyOn
2015-01-03 17:35:05 R-self01-shSwJtOn dlyOff
2015-01-03 17:35:03 R-sign off
2015-01-03 17:35:02 RegL_00: 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1A 0B:CE 0C:1F 00:00
2015-01-03 17:35:03 RegL_01: 08:00 00:00
2015-01-03 17:35:05 RegL_03:self01 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
2015-01-03 17:34:56 deviceMsg off (to ccu)
2015-01-03 17:34:56 level 0
2015-01-03 17:34:56 pct 0
2015-06-25 03:45:11 peerList self01,
2015-01-03 17:34:56 recentStateType info
2015-06-08 13:59:39 sabotageAttack ErrIoAttack cnt:11
2015-06-25 04:10:20 state IOerr
2015-01-03 17:34:56 timedOn off
Helper:
HM_CMDNR 203
cSnd 011ACE1F285A44010E,011ACE1F285A44010E
mId 0004
rxType 1
Bm:
Cul_hm_get:
cnt 1
dmx 0
max 1
tot 1
mAr:
HASH(0x16fd198)
SwitchUP02
?
Cul_hm_set:
cnt 2
dmx 0
max 6
tot 11
mAr:
HASH(0x16fd198)
SwitchUP02
?
Io:
newChn +285A44,00,01,00
rxt 0
vccu ccu
p:
285A44
00
01
00
prefIO:
hmlan1
Mrssi:
mNo
Io:
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
Attributes:
IODev hmlan1
IOgrp ccu:hmlan1
autoReadReg 4_reqStatus
expert 2_full
firmware 1.12
model HM-LC-SW1-FM
peerIDs 00000000,285A4401,
room CUL_HM
serialNr LEQ0130401
subType switch
webCmd statusRequest:toggle:on:off
das mit dem Overload verstehe ich nicht - das log ist nicht komplett.
Nach 41% kommt 100% ohne zwischenwerte.
Was auch immer am 285A44 passiert ist auch unklar.
anbei das komplette log. kurz vor reboot fritzbox bis overload.
ZitatWas auch immer am 285A44 passiert ist auch unklar.
der reale aktor liegt im schreibtisch. war bisher kein problem.
ich hätte auch noch einen fall von gestern nachmittag mit einem "aktiven" energie messstecker, der wohl nicht geantwortet hat. die funkverhältnisse zum messstecker sind grenzwertig. der vorfall war wiederum nach reboot.
das umschalten auf ersatzdevice bei Overload habe ich eingebaut.
das umschalten bei overload ist zwar schoen, aber "verschiebt" doch eigentlich nur das problem. du hattest doch vor einiger zeit einen mechanismus eingebaut, der bei restart anstehende autoreadregs verzoegert und/oder aussetzt, wenn sich ein device nicht meldet. das sollte doch eigentlich greifen, wenn du es nicht ausgebaut hast. werde morgen weiter testen.
das funktioniert auch. Bei 40% wird gestoppt. Den wert kannst du auch ändern.
Aber hier handelt es sich um einen StatusRequest. Die gehen durch, da sie zum Anzeigen eines korrekten Status notwendig sind.
Das soll auch s0 bleiben.
In deinem Fall wird aber der Status nicht beantwortet - das geht so natürlich auch nicht. Ich muss also abbrechen... aber was dann....
der Status muss auf "unreachable" gesetzt werden. Dann sollte nach sagen wir 1h noch einmal probiert werden... usw.
so - statusrequest wird jetzt nur einmalprobiert. Sollte es nicht klappen wird der Status entsprechend gesetzt und nach 0,5h wird es noch einmal probiert.
Sollte man lauter tote Devices haben werden ist das immer schlecht - ein Overload sollte es aber hierdurch nicht geben
Gute Idee!