HMLAN new condition ERROR-Overload

[UliM]

Hallo,
neuerdings wird mein log von diesen Meldungen bevölkert:

Code Auswählen Erweitern

2013.10.01 00:12:00.956 2: CUL_HM set HM_TC desired-temp 17.5
2013.10.01 00:12:06.614 2: HMLAN_Parse: HMLAN new condition Warning-HighLoad
2013.10.01 00:12:21.087 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:18:21.097 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:18:24.133 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:24:24.136 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:24:29.434 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:30:29.438 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:30:35.828 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:36:36.113 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:36:38.794 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:42:41.215 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:42:44.510 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:48:47.356 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:48:49.918 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 00:54:49.929 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 00:54:55.438 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
2013.10.01 01:00:55.445 2: HMLAN_Parse: HMLAN new condition Overload-released
2013.10.01 01:00:59.795 2: HMLAN_Parse: HMLAN new condition ERROR-Overload
Use of uninitialized value in string eq at (eval 1069) line 1.

Effekt tritt seit letzer Woche auf, habe es zunächst als Seiteneffekt von Calendar.pm verbucht, das Problem ist jedoch behoben.
HM-Geräte sind nun unzuverlässig - manchmal schalten sie, manchmal nicht.

Wo kann ich mit der Fehlersuche ansetzen?

Gruß und danke für eure Hilfe,
Uli

[betateilchen]

Du musst versuchen rauszufinden, welches Deiner Homematic-Geräte den vielen Traffic verursacht, der dazu führt, dass das maximale Sendevolumen pro Zeiteinheit überschritten wird.

[UliM]

Moin,
ok,  ich glaub ich hab den Übeltäter: habe meinen HM_TC batterielos gemacht.
Habe nun gesetzt

Code Auswählen Erweitern

attr HM_TC do_not_notify 1
und seitdem diese Meldungen nicht mehr. Werd's weiter beobachten, das könnte es aber gewesen sein.
Ein "disable" gibt's ja nicht, hoffe dass do_not_notify quasi dasselbe macht?

Gruß, Uli

[Otto]

Tag,

hatte auch sehr sehr oft ERROR-Overload, aber ich meine mit dem letzten Update (gestern) ist es weg.

Beobachten wir mal.


Gruß Otto

[jhohn]

Ich habe diese Fehlermeldung auch. Ich habe eban mal nachgesehen, die ist im Log seit dem Update am letzten Sonntag (29.09.).
Es sind keine Geräte dazugekommen und es wurde nichts an der Konfig geändert.

was genau tut "do_not_notify"?

[AbeamStart]

Hallo habe heute auch noch ein paar TCs VDs und SCs bekommen (weil sind ja abgekündigt).
Beim Anlernen hatte ich auch heute oft overload!
Dann geht erstmal gar nichts...
Was bedeudet overload genau? Stau?
Wie erkenne ich die Ursache und was genau kann man dagegen tun?

[martinp876]

hi,

HMLAN sendet eine status-condition die wohl overload bedeuted. Sicher ist, dass HMLAN dann immer noch alles mithört, aber nichts mehr sendet. Der Zustand dauert ~6min wenn man keinen Sendeversuch in der Zwischenzeit macht. FHEM sperrt deshalb alles senden für 6min. Alternativ kann man den HMLAN stromlos manchen. wenn er dann gebootet hat geht es auch weiter.

Kommandos in der Warteschlange, die zum Abarbeiten frei sind werden aufgrund eines timeout gelöscht werden. Das ist Absicht, da Schaltkommandos mit Verzögerungen größer 1-2min  veraltet und somit unsicher sind.
Kommandos an ein wakeup-device (TC ohne cond-burst) überleben evtl. Diese sind auch nicht Zeitrelevant.

Grund für den Overload habe ich nicht klar identifiziert. Es hat sicher etwas mit der Anzahl der zu sendenden Messages, evtl auch mit der Anzahl der verschiedenen Devices zu tun. Wenn ich den Mechanismus verstanden habe kann ich über einen sicherungs-mechanismus nachdenken. Wenn einer Infos hat, die man prüfen kann werde ich es austesten.
Leider kenne ich auch keinen mechanismus, den Zustand zuckzusetzen.

Gruss Martin

[Jaydee]

Hallo! bei mir tritt dieses Problem auch seit kurzem auf - den genauen Zeitpunkt kann ich leider nicht feststellen...

nach einem shutdown restart von fhem sieht es so aus [gekürzt]:

Code Auswählen Erweitern


2013.10.06 09:09:56 2: HMLAN_Parse: HMLAN1 new condition disconnected
2013.10.06 09:09:56 3: Opening HMLAN1 device 192.168.0.15:1000
2013.10.06 09:09:56 3: HMLAN1 device opened
2013.10.06 09:09:56 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.06 09:10:09 3: Device THO_1 added to ActionDetector with 000:10 time
2013.10.06 09:10:14 2: CUL_HM set CUL_HM_HM_LC_Dim1PWM_CV_21F524 getSerial
2013.10.06 09:10:14 2: CUL_HM set CUL_HM_HM_LC_Dim1PWM_CV_21F524 getConfig
2013.10.06 09:10:14 2: CUL_HM set CUL_HM_HM_LC_Dim1PWM_CV_21F524 statusRequest
2013.10.06 09:10:14 2: HMLAN_Parse: HMLAN1 new condition ok
2013.10.06 09:10:26 2: CUL_HM set CUL_HM_HM_LC_SW4_BA_PCB_20D684 getSerial
2013.10.06 09:10:26 2: CUL_HM set CUL_HM_HM_LC_SW4_BA_PCB_20D684 getConfig
2013.10.06 09:10:26 2: CUL_HM set CUL_HM_HM_LC_SW4_BA_PCB_20D684 statusRequest
Use of uninitialized value $arr1[0] in sort at ./FHEM/10_CUL_HM.pm line 2095.
Use of uninitialized value $arr1[0] in join or string at ./FHEM/10_CUL_HM.pm line 2095.
2013.10.06 09:10:38 2: CUL_HM set CUL_HM_HM_LC_SW4_PCB_15F390 getSerial
2013.10.06 09:10:38 2: CUL_HM set CUL_HM_HM_LC_SW4_PCB_15F390 getConfig
2013.10.06 09:10:38 2: CUL_HM set CUL_HM_HM_LC_SW4_PCB_15F390 statusRequest
2013.10.06 09:10:50 2: CUL_HM set DimmDFluter getSerial
2013.10.06 09:10:50 2: CUL_HM set DimmDFluter getConfig
2013.10.06 09:10:50 2: CUL_HM set DimmDFluter statusRequest
2013.10.06 09:11:02 2: CUL_HM set HM_Doppelsteckdose01 getSerial
2013.10.06 09:11:02 2: CUL_HM set HM_Doppelsteckdose01 getConfig
2013.10.06 09:11:02 2: CUL_HM set HM_Doppelsteckdose01 statusRequest
2013.10.06 09:11:14 2: CUL_HM set HM_Doppelsteckdose02 getSerial
2013.10.06 09:11:14 2: CUL_HM set HM_Doppelsteckdose02 getConfig
2013.10.06 09:11:14 2: CUL_HM set HM_Doppelsteckdose02 statusRequest
2013.10.06 09:11:26 2: CUL_HM set THO_1 getSerial
2013.10.06 09:11:26 2: CUL_HM set THO_1 getConfig
2013.10.06 09:11:26 2: CUL_HM set THO_1 statusRequest
2013.10.06 09:12:42 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2013.10.06 09:12:57 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload


kann dieser Use of uninitialized value etwas damit zu tun haben? das ist nämlich auch neu... taucht immer mal wieder im log auf...

Gruß
Jan

______________________
EDIT:
das letzte hinzugefügte gerät ist übrigens der HM PWM-LED-Dimmer, der mit seinen virtuellen Kanälen EXTREM viel im EventLog rummüllt... Ich weiß ja nicht, ob bei anderen Geräten auch so viel gesendet wird und ob es nur hier so umfangreich angezeigt wird...

Dies ist nur von einmal an- und ausschalten (toggle)

Code Auswählen Erweitern

2013-10-06 09:25:56 CUL_HM LEDPWM_Bett set_toggle
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett level: 100 %
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett deviceMsg: on (to HMLAN1)
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett on
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett running: -
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett dim: stop:on
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett overload: off
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett overheat: off
2013-10-06 09:25:56 CUL_HM LEDPWM_Bett reduced: off
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett phyLevel: 100 %
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett level: 100 %
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett deviceMsg: on (to HMLAN1)
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett on
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett running: -
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett dim: stop:on
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett overload: off
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett overheat: off
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett reduced: off
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett_V01 chn:off phys:100 %
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett_V01 phyLevel: 100 %
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett_V02 chn:off phys:100 %
2013-10-06 09:25:59 CUL_HM LEDPWM_Bett_V02 phyLevel: 100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett on
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett phyLevel: 100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 phyLevel: 100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 level: 0 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 deviceMsg: off (to HMLAN1)
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 chn:off phys:100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 running: -
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 dim: stop:off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 overload: off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 overheat: off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V01 reduced: off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett on
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett phyLevel: 100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 phyLevel: 100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 level: 0 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 deviceMsg: off (to HMLAN1)
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 chn:off phys:100 %
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 running: -
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 dim: stop:off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 overload: off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 overheat: off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 reduced: off
2013-10-06 09:26:00 CUL_HM LEDPWM_Bett_V02 powerOn: -

2013-10-06 09:26:04 CUL_HM LEDPWM_Bett set_toggle
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett level: 0 %
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett deviceMsg: off (to HMLAN1)
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett off
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett running: -
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett dim: stop:off
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett overload: off
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett overheat: off
2013-10-06 09:26:05 CUL_HM LEDPWM_Bett reduced: off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett phyLevel: 0 %
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett level: 0 %
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett deviceMsg: off (to HMLAN1)
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett running: -
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett dim: stop:off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett overload: off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett overheat: off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett reduced: off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett_V01 off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett_V01 phyLevel: 0 %
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett_V02 off
2013-10-06 09:26:08 CUL_HM LEDPWM_Bett_V02 phyLevel: 0 %
2013-10-06 09:26:08 HMLAN HMLAN1 cond: ERROR-Overload
2013-10-06 09:26:08 HMLAN HMLAN1 Xmit-Events: ERROR-Overload:1
2013-10-06 09:26:08 HMLAN HMLAN1 prot_ERROR-Overload: last

[martinp876]

Hallo Jan,

der overload liegt weder an dem uninitialized  noch an den vielen Events.

Dennoch empfehle ich dir ein event-on-change-readings .* in allen devices als default zu setzen.

Je nachdem, wann dein letzter update war - früher wurde dieser Zustand weder erkannt noch gemeldet. er könnte also schon aufgetreten sein.

Gruss Martin

[Jaydee]

Danke für den Tipp :-)

[AbeamStart]

Hallo Martin,
habe heute mein 8. Set HM CC TC (Insgesamt 8 TCs 8 Secs und 10 VDs) in Betrieb genommen und es war alles ohne Probeme pair und peerbar ohne overloads des HMLANs...
Irgendwie lässt sich das ganze nicht wirklich reproduzieren?!?!

[martinp876]

ja, mein Problem.
wenn ich das Verfahren verstanden hätte, hatte ich einen "protection-mechanismus" eingebaut.
Falls also jemand infos und Fakten dazu gesammelt hat, bitte teilen.

Gruss Martin

[jhohn]

Bei mir ist die Meldung seit dem Update letzten Dienstag (01.10.) nicht mehr aufgetreten.
Den ganzen Tag kam die Meldung mehrmals pro Stunde und nach dem Update und Restart am Abend war dann plötzlich Ruhe.

[martinp876]

Hallo,

ich habe HMLAN einmal "ausgelitert" - fast jedenfalls.
die kapaität ist so etwa 600 messages/h - die reale Zahl hängt etwas von der Message und der Anzahl der HMLAN intern generierten ACKs/repeats ab.
Das Eigentliche Limit sind wohl mehr als 1500message incl ACK/repeat

Wenn ein "füllstand" von 90% erreicht ist wird high-load signalisiert (schon länger eingebaut...)

Vorgesehen habe ich nun
A) Füllstandsanzeige: Zählen gesendeter messages. Das wird in HMLAN (und natürlich in HMInfo - protocoll) dargestellt.
msgLoad total 1h:109 recentSteps: 0/102/7/0/0/0
=> 102 messages in der laufenden Stunde, davon 0 in den aktuellen 10min. 102 in den 10min davor, 0 davor...
Das Zählen ist lückenhaft da FHEM a) nur zählen kann wenn es läuft b) die vorgeschichten des HMLAN nicht bekannt ist c) nach disconnect ein ählerstand von "0" angenommen wird.
den echten Zähler kann ich nicht auslesen

B) Low-Prio holdoff: autoReadReg wird als sekundär eingestuft (bisher als einzige Klasse). Wenn HMLAN 'highload' meldet wird die Bearbeitung zurückgehalten bis der Zustand beendet ist.
Für operationelle messages besteht dann noch ein Puffer von ~60 Messages.
Weiterhin hat der User die Möglichkeit das Attribut hmMsgLowLimit zusetzen. Wenn dieses Limit erreicht ist wird auch die Verarbeitung ausgesetzt. Damit lässt sich die Pause noch früher einrichten

C) über HMInfo kann man die Verarbeitung der AutoReadReg queue timen Attribut hmAutoReadScan legt fest, wie schnell die queue geprüft wird. Man kann zwischen Zeiten 1sec und 300sec einstellen. damit kann man die Verarbeitung extrem verzögern, wenn gewünscht.

Achtung - für alle Beta-Teilchen:
auch der Update ist nicht empfehlenswert. Es ist in einem ungenügenden Environment getestet, von einer nicht hinreichendenAnzahl Tester und eine ungenügende Zeit.
Es werden wieder einmal neue Attribute eingeführt und gesetzt!
Es wird weiter nach der Philosophie codiert, dass FHEM alles was zu einer guten Grundeinstellung führt automatisch gesetzt werden soll. Im Gegesatz zum Ansatz "nur auf einem steinigen Weg kann man lernen, besser ein paar Fallen addieren".
Aufwärts/abwärts und seitwärtskompatibilität sind nicht garantiert (manche sollten sich einmal erklären lassen was das ist, bevor sie darüber referieren)
Der Autor ist nicht vertrauenswürdig, ist schon mehrfach aufgefallen.
Also besser nicht nutzen!

Gruss Martin

[Markus Bloch]

Hallo zusammen,

ich habe heute meinen ersten HM-CC-RT-DN installiert und bin dabei reihenweise in Overloads gelaufen. Sobald man den Thermostat an FHEM anlernt war ich sofort im Overload drinn.

Ist es wirklich umbedingt notwendig nach jeder Anlernmessage sofort alle Kanäle mit einem getConfig Request zu befeuern? Ich hatte mindestens 14 Cmds in der Warteschlange und wollte noch den Drehfensterkontakt verbinden, aber als er aus dem Overload raus war, war er sofort wieder im Overload, so das ich da zu garnix kam.

Ebenso wenn ich mein FHEM neustarte, habe ich sofort einen Overload.

Wenn ich da unterstützen kann, liebend gern.

Viele Grüße

Markus