HMLAN new condition ERROR-Overload

[betateilchen]

Danke.

[marc2]

Hi !

Kannst Du doch über das Attribute "autoReadReg" abklemmen, wenn Du es nicht möchtest.
OK, aber leider erst nach dem Anlernen ...

Gruß, Marc

[martinp876]

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

[Markus Bloch]

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

[martinp876]

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

[Markus Bloch]

gerne, mach ich heute Abend.

Gruß
Markus

[AHA1805]

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:

Code Auswählen Erweitern

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

[martinp876]

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

[AHA1805]

Hallo Martin

werden nach dem Threat schauen.

Hannes

Gesendet von meinem GT-N5100 mit Tapatalk-4 now Free

[AHA1805]

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

Code Auswählen Erweitern

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 

[martinp876]

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

[AHA1805]

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?

[martinp876]

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

[AHA1805]

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

[martinp876]

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