Hallo,
neuerdings wird mein log von diesen Meldungen bevölkert:
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
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.
Moin,
ok, ich glaub ich hab den Übeltäter: habe meinen HM_TC batterielos gemacht.
Habe nun gesetzt
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
Tag,
hatte auch sehr sehr oft ERROR-Overload, aber ich meine mit dem letzten Update (gestern) ist es weg.
Beobachten wir mal.
Gruß Otto
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"?
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?
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
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]:
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)
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
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
Danke für den Tipp :-)
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?!?!
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
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.
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
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
Danke.
Hi !
Kannst Du doch über das Attribute "autoReadReg" abklemmen, wenn Du es nicht möchtest.
OK, aber leider erst nach dem Anlernen ...
Gruß, Marc
ein HMLAN verkraftet 610 messages bevor es in high-load geht. und dann noch einmal 60 messages bevor es abschaltet.
wenn es "sofort" in overload geht muss es vorher bereits gestresst worden sein.
ein einzelnes Device schafft das kaum - und schon garnicht in einer Zeit kleiner 15 min, wenn der HMLAN "entspannt" war.
bei den messages sind die "acks" nicht mitgezählt - wenn ihr die message-counter in den Devices beobachtet - da werden auch Acks gezählt. das sind dann weit mehr als das Doppelte.
Abschalten kann man das ganze SEHR einfach und SEHR schnell
-starte FHEM
-save
- open Editor
- replace "autoReadReg 4" mit "autoReadReg 0"
- rereadconfig oder neustart
auch systeme mit zig devices sind in ein paar minuten korrekt eingestellt
die aktuelle Version sendet nachrichten an ein device nach dem anderen. Die Geschwindigkeit von der ihr redet kommt nicht von autoRegRead.
autoRegRead stoppt bei high-load automatisch und wartet auf bessere Zeiten. Normale messages können noch gesendet werden.
man kann einen weiteren sperrlevel einschalten - der aber, wie beschrieben, nach neustart leider bei 0 zu zählen beginnt.
Irgendetwas stimmt nicht - oder ihr seid nicht auf dem Stand. Mit einem RT habe ich nie einen Overload hinbekommen - da muss deutlich mehr los sein.
Gruss Martin
Hallo Martin,
vielen Dank für deine Informationen. Könnte es denn helfen, wenn ich einfach mal den ganzen Message-Verkehr aufzeichne (als FHEM-Log oder TCP-Dump) und du mal drüber schauhst?
Hab echt keinen Schimmer, woran das liegt. So viele Geräte habe ich garnicht. Alles in allem sind es 30 Geräte die da rum schwirren. Ich selber oder FHEM löst nicht von mir gewollte status-Requests andauernd aus oder sowas in der Art wo ich sagen könnte, da kommen die ganzen Messages her.
Hab ein paar Schaltvorgänge beim Aufstehen, Einschlafen und Fernseher anmachen, etc.
Aber nix, was meiner Meinung nach für einen Overload verantwortlich sein könnte.
Was meinst du, wie kann man da am besten ansetzen?
Vielen Dank für deine Hilfe
Gruß
Markus
Hallo Markus,
aufzeichnen ist gut. an schönsten ist das Format aus FFHEM, also
attr global mseglog 1
attr global verbose 1
attr <hmlan> loglevel 1
die logs laufe in das allgemeine logfile
zur systemInfo könntest du, wenn du HMInfo bereit hast
define hm HMInfo
und dann die Ergebnisse von
set hm param -cd model subType autoReadReg
set hm protoEvents
set hm update
list hm
gerne, mach ich heute Abend.
Gruß
Markus
Hallo
ich habe heute meinen Regensensor in Betrieb genommen
und anschließend ein rereadcfg fhem.cfg ausgeührt.
Plötzlich ist mir aufgefallen, dass via HM nichts mehr funktioniert.
Nach einer Kontrolle im Logfile fand ich folgende Einträge:
2013.10.13 16:18:17 1: Including fhem.cfg
2013.10.13 16:18:17 3: telnetPort: port 7072 opened
2013.10.13 16:18:17 3: WEB: port 8083 opened
2013.10.13 16:18:17 3: WEBphone: port 8084 opened
2013.10.13 16:18:17 3: WEBtablet: port 8085 opened
2013.10.13 16:18:17 2: HMLAN_Parse: HMLAN1 new condition disconnected
2013.10.13 16:18:17 3: Opening HMLAN1 device 192.168.18.26:1000
2013.10.13 16:18:17 3: HMLAN1 device opened
2013.10.13 16:18:17 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.13 16:18:17 3: Opening fbaha device localhost:2002
2013.10.13 16:18:17 3: fbaha device opened
2013.10.13 16:18:17 1: FBAHA fbaha registered with handle: 00000015
2013.10.13 16:18:17 3: Opening CUL_0 device /dev/ttyACM0
2013.10.13 16:18:17 3: Setting CUL_0 baudrate to 38400
2013.10.13 16:18:17 3: CUL_0 device opened
2013.10.13 16:18:18 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.10.13 16:18:20 3: myAnroidNotify APIKEY: AIzaSyBofcqSTa0wWBusTJyvEeOsygowATW3Vok REGIDS: AP..
2013.10.13 16:18:21 3: Opening OWio1 device /dev/ttyUSB0
2013.10.13 16:18:21 3: Setting OWio1 baudrate to 9600
2013.10.13 16:18:21 3: OWio1 device opened
2013.10.13 16:18:21 1: OWX: Serial device /dev/ttyUSB0 defined
2013.10.13 16:18:21 1: OWX: 1-Wire bus OWio1: interface master DS2480 detected for the first time
2013.10.13 16:18:21 3: OWTHERM: Device ow_1 defined.
2013.10.13 16:18:21 3: OWTHERM: Device OWX_10_45D070010800 defined.
2013.10.13 16:18:21 3: OWLCD: Device ow_LCD defined.
2013.10.13 16:18:23 1: Including ./log/fhem.save
2013.10.13 16:18:25 2: CUL_HM set Regensensor getConfig
2013.10.13 16:18:25 2: HMLAN_Parse: HMLAN1 new condition ok
2013.10.13 16:18:26 3: Device CUL_HM_HM_SCI_3_FM_20837A added to ActionDetector with 028:00 time
2013.10.13 16:18:33 1: OWX: 1-Wire devices found on bus OWio1 (OWX_10_45D070010800,ow_1)
2013.10.13 16:18:37 2: CUL_HM set CUL_HM_HM_LC_SW1_BA_PCB_1FB77E getConfig
2013.10.13 16:18:37 2: CUL_HM set CUL_HM_HM_LC_SW1_BA_PCB_1FB77E statusRequest
2013.10.13 16:18:37 1: evtWaschmaschine(kg_Waschmaschnie) Value: Current:0
2013.10.13 16:19:06 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2013.10.13 16:19:09 1: evtWaschmaschine(kg_Waschmaschine) Value:on Current:0.0336 A
2013.10.13 16:19:20 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
Bis jetzt ist der Fehler zum ersten Mal aufgetreten.
Erst nachdem ich den HMLan ab- und angesteckt hatte funktionierte alles wieder.
Kann ich irgend etwas dazu Betragen?
Gruß
Hans
auch hier - gleicher hinweis:
HMLAN overload bedeuted, dass HMLAN nicht mehr senden mag, das 1Stunde limit ist erreicht. Je nachdem, wann die vielen Messages gesendet wurde kann es bis zu 1h dauern, bis wieder etwas geht.
Es komme eine neue Version mit verbesserungen und einThreat mit ein paar erklärungen dazu
Hallo Martin
werden nach dem Threat schauen.
Hannes
Gesendet von meinem GT-N5100 mit Tapatalk-4 now Free (http://'http://tapatalk.com/m?id=10')
Hallo Martin
jetzt hatte ich das Problem wieder.
Dabei ist mir aufgefallen, dass es dann kam als ich öfter was an der fhem.cfg änderte und dann rereadcfg fhem.cfg aufrief.
Was auch komisch ist, dass er beim starten im log schreibt
2013.10.18 23:43:22 1: Including ./log/fhem.save
2013.10.18 23:43:24 2: CUL_HM set Regensensor getConfig
2013.10.18 23:43:25 3: Device CUL_HM_HM_SCI_3_FM_20837A added to ActionDetector with 028:00 time
2013.10.18 23:43:25 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2013.10.18 23:43:34 3: OWTHERM: Device OWX_10_98CC70010800 defined.
2013.10.18 23:43:34 3: OWTHERM: Device OWX_10_F1CD70010800 defined.
2013.10.18 23:43:34 1: OWX: 1-Wire devices found on bus OWio1 (OWX_10_98CC70010800,OWX_10_F1CD70010800,OWX_10_45D070010800,ow_1)
2013.10.18 23:50:05 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2013.10.18 23:56:05 2: HMLAN_Parse: HMLAN1 new condition Overload-released
2013.10.18 23:56:07 2: CUL_HM set CUL_HM_HM_LC_SW1_BA_PCB_1FB77E getConfig
2013.10.18 23:56:07 2: CUL_HM set CUL_HM_HM_LC_SW1_BA_PCB_1FB77E statusRequest
2013.10.18 23:56:09 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2013.10.19 00:02:09 2: HMLAN_Parse: HMLAN1 new condition Overload-released
2013.10.19 00:02:09 2: CUL_HM set CUL_HM_HM_SCI_3_FM_20837A getConfig
2013.10.19 00:02:09 2: CUL_HM set CUL_HM_HM_SCI_3_FM_20837A statusRequest
Warum kommt nach dem Starten immer die Teilnehmer mit getConfig?
Kann es sein, dass dadurch der HMLan überlastet wird?
Gruß
Hannes
PS:Sorry aber ich hatte den Bericht zuerst am Tab geschrieben, und dabei hat er alles andere eingefügt nur nicht das was er sollte :-[
Hallo Hannes,
erst einmal ist dein HMLAN in Overload.
Was nicht korrekt implementiert ist: wann overload vorbei ist. Ich hatte einst 6min dauer angenommen und getestet. Das ist aber inkorrekt, werde ich beheben. Der Overload kann bis zu 1h dauern.
Was in deinem Fall passiert ist:
HMLAN hat bereits zwischen 90% und 100% seiner 1h Performance aufgebraucht. Nach dem Start wird das erste Kommando gesendet - und erst hierbei erkennt FHEM dass HMLAN in high-load ist. Alle automatischen Kommandos werden nun geblockt bis wieder normalzustand erreicht ist.
Die gesendeten Kommandos reichen aber die übrigen "Prozente" zu 100 aufzufressen
Der SCI3 sendet aktuell sowieso nichts - er reagiert nur auf wakeup und config - so lange muss er warten.
Was ich nachbessern muss
- overload nicht nach 6min rücksetzten, dynamik einbauen
- Zustand des HMLAN nach hochfahren automatisch erkennen - damit nicht die ersten Kommandos gesendet werden. Diese gehen Verloren.
Wie du den Overload zustand erreicht hast ist hier nicht zu erkennen. Den HMAN kann ich nicht rücksetzten - da hilft nur warten oder strom aus.
Die default-einstellung in CUL_HM ist, dass automatisch alle fehlenden Stati und register gelesen werden. Wenn alle register aus dem statefile kommen wird nur der status gelesen - das sollte m.E. nach restart immer passieren.
Wenn du dies nicht haben willst kannst du es abschalten - in den devices autoReadReg auf "0_off" schalten
Gruss Martin
Hallo Martin,
danke für die Antwort.
So wie es aussieht, geht mein HMLan immer in den Overload wenn ich an der fhem.cfg rumspiele und dabei diese neu geladen wird,
denn dadurch wird ein GetConfig ausgeführt.
Ich denke, dass Du eine viel größere Device Landschaft hast,
wie machst Du das, dass Du nicht immer in diesen Konflikt kommst?
Ist es nicht so, dass die Grenze im HM generell schnell erreicht wird, wenn z.B. meine Tochter an den Schalter rumspielt,
auch wenn diese direkt mit den Aktoren verknüpft sind, weil ja immer ein Akt auch an das HM-Lan geht.
Gruß Hannes
PS: In Chrome kann ich keine Bilder hochladen, kennst Du das Problem?
Hallo Hannes,
in der aktuellen Version - und wenn du autoReadReg 4 eingestellt hast - werden nach dem starten von FHEM (oder rereadcfg) ein getConfig ausgeführt - nur wenn:
- die register aus dem "state-file" nicht korrekt sind
- HMLAN kein "high-load" meldet
die Begrenzung auf eine HM-Last von 40% funktioniert an dieser stelle nur, wenn du HMLAN nicht schon "vorgespannt" hast. Bei mehrfachen reloads kannst du dies also einfach aushebeln.
Kritisch sind weiterhin RT und TC wenn du burst nutzt . Wenn attr "burstAccess" gesetzt ist oder burstXmit genutzt wird.
Ein HMLAN kann 1700 messages je stunde (incl ack). Je nach kommando werden mehr messages gebraicht - meist noch ein ack... also mit mehr als 600 kommandos pro Stunde muss man nicht rechnen.
Wenn du burst-devices hast wird dies dramatisch reduziert. burst (oder conditional burst) kann man max 100/Stunde aufwecken - wenn man noch Kommandos senden will entsprechend weniger.
Fehler beim Senden (missing-ack) erzeugen eine 3-fache Last.
An welchen Device spielt die Tochter - und wie sind die Einstellungen?
Gruss Martin
Hallo Martin,
die Tochter spielt gerne mal an einem Lichtschalter.
Aber jetzt eine generelle Frage:
Ist es dann überhaupt sinnvoll Alles auf homematik umzubauen?
8 Heizungsregeler
2 feuchte Sensoren
Regensensor
15 aktoren
8 6 fach Taster
Einige Status Eingänge
Kann ich den burst Modus abschalten und was hat das für Konsequenzen?
Gruß
Hannes
Gesendet von Unterwegs mit Tapatalk 4
Hallo Hannes,
ob es sinnvoll ist kann/werde ich nicht kommentieren. Aber ich kann einmal laut überlegen... nur so Gedanken eben - und auch nur meine...
HM funktioniert so weit erst einmal gut.
quasi alle HM devices haben einen Overload-zähler - auslesen kann ich den nicht. Nennt sich Duty-cycle.
Wo der Überlast-level eines devices liegt kann ich nicht sagen - aber einen Rollo-aktor habe ich - bei einem test - schon einmal überlastet.
Dennoch denke ich, dass eine Überlast eines Devices sehr selten ist - zumal im operationalen Betrieb. Selbst bei Konfig Antivitäten machen die nich tso schnell schlapp. Da muss man schon richtig hinlangen. Kurzum da sehen ich kein reales Problem.
Somit reduziert sich die "reale" gefahr einer Overload auf HMLAN. Was kann man hier machen, wo sind die Grenzen
Grenzen - errechnen sich etwas komplexer, hier vereinfacht
- 800 kommandos/h = 13 command/min (hier normale messages)
- ein schaltkommando aus der Zentrale ist meist 1 message. Wenn es auf Basis eines externen triggers kommt ist dieser zu bestätigen, also noch einer. Das bleiben - sagen wir 5 Kommandos/min - und das über eine Stunde. sollte reichen.
Jetzt will man auch noch configurieren - das kostet mehr messages. Das ist aber eher selten - oder man sitzt dabei und spielt/testet. Ist also eigentlich ein Sonderfall.
Burst devices: die kosten ordentlich mehr. Aber man muss es nicht immer nutzen (eine deiner Fragen). Bei TC und RT kann man alle Kommandos absetzen und bis zum Aufwachen warten - da braucht man keinen Burst.
Wo man wohl nicht auf burst verzichten kann ist eine RC19, setzen der display-info oder keymatic.
Burst wird von FHEM aus - für RT und TC - nie automatisch genutzt. Freigeschaltet wird es schon - für andere Devices, die TC oder RT triggern wollen. Das kostet aber wiederum nichts.
Und dann - (vorweg, das wird nicht von allen so gesehen) kann man (würde ich immer) die devices a) direkt peeren und b) selbstängig arbeiten lassen.
zu a): das hat (wieder aus meiner sicht) verschiedene Vorteile
aa) HMLAN muss nur eine message senden je schaltkommando(ein ACK, evtl sogar für mehrere schaltungen)
ab) falls HMLAN in overload gehen sollte oder sonst stirbt geht immer noch eine ganze Menge
ac) man kann gerade bei HM sehr viel damit erreichen - sicher nicht alles
zu b)Heizungsregler kann man eigentlich autonom arbeiten lassen - im Normalfall jedenfalls.
Wenn dann ein HMLAN "overloaded" wird immer noch alles mitgeloggt (nicht gesendet...)
Und wenn es eng werden sollte (was so schnell eher nicht passiert... oder) könnte man einen 2. HMLAN einbauen und die Devices splitten. Dann hat man doppelte Kaazität
Gruss Martin
Hallo Martin
vielen Dank für die ausführliche Erklärung :-).
Das hat mich jetzt schon beruhigt, ich hatte sowieso vor die aktoren durekt mit den Taster zu peeren.
Gruß Hannes
Gesendet von Unterwegs mit Tapatalk 4
Hallo zusammen,
ich musste Wandthermostat und Thermostat neu anlernen und habe jetzt auch das Problem mit dem Overload und zwar jedes mal, wenn ich versuche z.B. eine neue Temperaturliste mit set templist zu senden.
Ich habe nur 2 Thermostat, 1 Wandthermostat, 1 UP-Schaltaktor und eine 12/7 RS485 Einheit in Betrieb.
So langsam fange ich an zu verzweifeln :'(
wie machst du das? hast du aus auto-burst attribut gesetzt? nicht clever.
antworten deine RTs überhaupt? wenn nicht sendet sich HMLAN schnell zu tode
Habe den Fehler beseitigen können, ich vermute mal, dass ich die Kanäle irgendwie so verpaart habe, dass sich eine Schleife ergeben hat ...