HMLAN overload

Begonnen von hobbyprovider, 16 November 2013, 13:11:23

Vorheriges Thema - Nächstes Thema

hobbyprovider

Hallo,
seit meinem letzten Update am 13.11.13 (bis 16.11. unverändert) geht mein HMLAN nach kurzer Zeit in den Status "overoad".
Evtl ist der Fehler schon länger, da mein vorletztes Update 1-2 Wochen her ist.
Wenn ich ein älteres Image in meinen RPI lade und die gleichen .cfg benutze ist alles gut.
Nach "update" ohne sonstige Änderungen ist der Fehler wieder da.

Mein Fhem info:
  Release  : 5.5
  Branch   : DEVELOPMENT
  OS       : linux
  Arch     : arm-linux-gnueabihf-thread-multi-64int
  Perl     : v5.14.2
  uniqueID : bf2d90fd05410e50e30ed25bf1aca9fd

Defined modules:
  CUL_HM     : 22
  FHEMWEB    : 8
  FLOORPLAN  : 1
  FileLog    : 26
  HMLAN      : 1
  OWDevice   : 6
  OWServer   : 1
  SVG        : 1
  at         : 1
  autocreate : 1
  dummy      : 1
  notify     : 12
  telnet     : 2

Defined models per module:
  CUL_HM     : HM-LC-Bl1PBU-FM,HM-LC-SW1-FM,HM-LC-SW2-FM,HM-LC-SW4-PCB,HM-PB-2-WM55,HM-RC-SEC3-B,HM-SEC-SC
  OWDevice   : DS1420,DS18S20,DS2406,DS2408
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

martinp876

Hallo hobbyprovider,

je nachdem wie alt dein altes image ist wurde overload garnicht angezeigt.

Ein weiterer Grund könnte mit dem Attribut autoReadReg zu tun haben - FHEM versucht je nach level - die Configuration des device zu lesen. Zum einen ist zu erwähnen, dass garnicht gelesen wird, wenn die Daten schon gelesen und im statefile gespeichert sind. Zum Anderen wird, wenn ein high-load erkannt ist - das automatische lesen gestoppt/verzögert.

hast du schon einmal nachgesehen, was so gesendet wird? kannst du manuell machen oder über HMinfo:

define hm HMinfo
set hm set hm protoEvents short
set hm set hm msgStat

Gruss Martin

hobbyprovider

Hallo Martin,
Danke für die Antwort

Im Moment läuft bei mir FHEM 5.4.
Der Zustand "overload" kommt auch hier manchmal. Der HMLAN beruhigt sich aber wieder. In Version 5.5 mit den aktuellen Updates (vor 2 Wochen lief es auch unter 5.5 problemlos) hängt sich aber der HMLAN auf und braucht einen Powerreset.

autoReadReg steht bei allen Devices auf "4" (default)
ich werde mal damit spielen....

Das mit dem "nachsehen was so gesendet wird" habe ich nicht ganz begriffen.
Wenn ich Deine Befehlszeilen eingebe - wo finde ich dann die Ausgabe ?

Sooooo viel kann eigentlich nicht laufen.
Beim Kaputspielen ging es am schnellsten, wenn ich den Fensterkontakt "FK_01" betätigt habe.
Der het einen Notify zu Folge der Abhängig von dem Aktor "Al_scharf" den Aktor "Al_Alarm" schaltet:
define not_FK_01 notify FK_01 {my $fk = $value{"FK_01"};;my $al = $value{"Al_scharf"};;if ($fk eq "open" && $al eq "on") {fhem "set Al_Alarm on"}}

mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

martinp876

Hi hobbyprovider,

was bedeuted "HMLAN hängt sich auf"? Gibt es einen Status im HMLAN? Overload? oder garnichts?

wenn du die kommandos zu HMinfo eingibst bekommst du sofort eine Antwort zurück.

ein Fensterkontakt sollte nicht soo viel traffic erzeugen. Du kannst dies aber einmal aufzeichnen - Rohmessages nach
http://forum.fhem.de/index.php/topic,16563.0.html

Gruss Martin

alipp

Hallo

Ich habe vor 2 Tagen ebenfalls das o.g. update gemacht und ebenfalls jetzt häufig ein HMLAN overload - meine Hausautomatisierung läuft seit 2 Jahren stabil, bisher noch nie (bewusst) ein HMLAN overload produziert.
Ich poste hier um zu zeigen dass es (wahrscheinlich) nicht an Deiner konfiguration liegt, sondern möglicherweise doch am letzten update.
Ich werde heute Abend meine Specs posten, worauf kommt es besonders an?

LG, alipp

hobbyprovider

#5
Hallo Martin,
der HMLAN geht in "Overload". Der lässt sich nur durch Powerreset des HMLAN wieder in Betrieb nehmen.
mit Rel 5.4 und den "älteren" 5.5 konnte ich den Zustand "Overload" auch provozieren. Der HMLAN ist dann aber eigenständig nach ein paar Sekunden wieder in "opend" gegangen.

Ich habe noch mal mit V5.5 und aktuellen Updates probiert und den Fehler provoziert.
Ich schicke Dir den LOG als PM.
ab dem Fehlereintrag "overload" war der HMLAN tot obwohl noch Nachrichten in Folge von Tastendruck eines Handsenders liefen.
Vorher war noch alles OK

Ich sehe einige Messages, kann mir aber nicht vorstellen, dass das die Performance des HMLAN-Adapters sprengen soll
Noch ein Hinweis: ich benutze für die Tests SW alt/neu immer die exakt gleichen .cfg
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

martinp876

Hallo,

der HMLAN hat eine begrenzte Sendekapatität. Er "zählt" messages und wakeup-versuche (burst). Ereignisse werden nach 1h aus der Berechnung geworfen. Aus overload kommt der HMLAN also immer, wenn der Zählerstand unterschritten ist. Nach 1h NICHTS senden ist er IMMER 0.
=> der HMLAN kommt auch jetzt wieder selbst aus der Situation - es dauert so lange bis die nächsten messages aus seiner Berechnung fallen. Das Theoretische max ist somit 1h.
=> an diesem Verfahren hat sich nichts geändert, da es IM HMLAN stattfindet und ich keine möglichkeit kenne, es irgendwie zu beeinflussen.

Wenn Overload nun häufiger auftritt liegt es an den messages, die gesendet werden. Das ist individuell - aber man kann einmal nachsehen, wer wieviel sendet. HMinfo stellt (wie ich hoffe einfache) mittel zu verfügung, das zu prüfen.

Hierzu könnt ihr eine instanz bauen
define hm HMinfo

und dann nachsehen mit
set hm protoEvents short

in Snd steht nun, was ein device gesendet hat.
msgLoadEst: 1hour:8% 10min steps: 0/0/0/8/0/0
zeigt den errechneten Füllstand des HMLAN
wenn ihr das posten könnt und dazu ein
set hm param -d model

ausserdem, falls es länger dauert, kann man mit
set hm msgStat
nachsehen, wann - im stundenraster - am Tag ein hotspot ist. Ein Wochekalkulation ist auch dabei, im Tagesraster.

Wenn ihr das anseht oder hier einstellt kann ich einmal nachsehen, ob und wo fhem zu viel sendet ... oder was sonst zu tun ist.

Ihr seid auf der aktuellen Version, davon gehe ich aus.
Gruss Martin

hobbyprovider

Verwirrend....

es scheint ein Unterschied zu sein ob ich den
"Al_Controler" (ein 4-K Aktor HM-LC-SW4-PCB)
oder
"SW_Stromvert" (2-Fach Switch HM-LC-SW2-FM)
schalte
es werden jeweils in der entsprechenden Zeile unter "Snd" 2 Zähler hochgezählt.
aber unter "msgLoadEst" sind es für 5 Schaltvorgänge beim "SW_Stromvert" 1%
beim "Al_Controler" sind es dagegen 2% pro Schaltvorgang


@ Martin: funktionieren die Logeinstellungen schon unter 5.4 ?
dann kann ich damit nochmal testen
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

martinp876

Hallo Hobbyprovider,

war mein Fehler. habe den HM-LC-SW4-PCB auf burst gesetzt, das gilt aber nur für den HM-LC-SW4-BA-PCB.
wenn ein device burst schaltet (was hier der Fall war) kostet das die 16-fache "HMLAN-performance".
ist in 4252 behoben (HMConfg.pm)

nein, die logs funktionieren wohl nicht in 5.4 in dieser Form.

hobbyprovider

Hallo Martin,
das könnte helfen.

evtl ist da aber noch mehr zu korrigieren......
Der HMLAN geht nicht nach 1h in Betrieb (auch nicht über Nacht).
Ich habe ihn gestern Abend in den Overload getrieben und heute Morgen war er immer noch in Overload.


mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

hobbyprovider

wenn der HMLAN grundsätzlich so schwach performt, wäre da evtl der USB-CUL für mich die bessere Lösung?
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

martinp876

Hi,

dass sich ein HMLAN nicht nach 1h erholt habe ich noch nicht gesehen.
wenn du einen fhem-restart machst und der HMLAN dann geht liegt es an mir. Ich prüfe ob er wieder wach ist, die Überwachung hätte einen bug. Alternativ - wenn er mehr als 1h weg ist bitte log einschalten und 20min warten.
Der Zustand war "overload", nicht etwa disconnect?
Eine CUL hat diese Einschränkung nicht - die kann - meines Wissens - rund um die Uhr senden.

Gruss Martin

CQuadrat

Zitat von: martinp876 am 21 November 2013, 07:41:23
Eine CUL hat diese Einschränkung nicht - die kann - meines Wissens - rund um die Uhr senden.

Jetzt muss ich doch mal nachfragen: Habe ich das richtig verstanden, dass der HMLAN hardwareseitig die 1%-Sendegrenze eingebaut hat? Bei einem CUL hingegen kann/könnte ich diese gesetzliche Bestimmung umgehen?
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

martinp876

HMLAN hat die begrenzung eingebaut - HW oder FW, kann ich nicht sagen.
HMLAN hat noch jeden Menge Einstellmöglichkeinten - von denen ich noch nicht einmal die Adresse kenne. Ob man da etwas drehen könnte, also ob die Zentrale es "aufbohren" könnte entzieht sich meiner Kenntniss.

CUL FW ist offen gelegt. Ob und welche Grenzen hier eingebaut sind kann ich nicht sagen (konnte es einmal testen....) Jedenfalls hat man Zugriff auf die FW und die HW. Das ist ein ganz anderer Level.

Gruss Martin

hobbyprovider

Hallo Martin

ich glaube das Zauberwort heisst "burst".
Alles rund um den 4K-Aktor ist gefühlt 5x schneller (bisher noch keine Änderungen an meiner Config)

Provozieren von "Overload":
Ich hämmere wie Irre auf der RC rum. Was als erstes auffällt, mit
set hm protoEvents short
zählt "Snd" wie gewohnt hoch, aber kaum die Prozente bei "msgLoadEst".
Gestern hatte ich bei ca 70 Snd schon msgLoadEst 100% und damit Overload.
Also hier schon eine deutliche Verbesserung!!!
Aber mein Auftrag lautet ja "Overload"
Da ich weder mein Daumengelenk noch die Knöpfe meiner Fernbedienung opfern wollte habe ich erstmal ein Monster-Notify gebastelt (1x Drüchen = 15x schalten)
Los ging's - "CmdPend" hat fast gekotzt - irgendwann war "Overload"
aber dann hatte ich fast 2000 "Snd" auf dem Zähler - in der Praxis wohl kaum zu erreichen.
Log gelöscht - "shutdown restart" - 2h gewartet - immernoch "Overload" - nochmal "shutdown restart" - "Overload" weg (opend)
zur Erinnerung: gestern war noch Powerreset des HMLAN nötig

Damit ist mein gemurre über die Performance des HMLAN hinfällig (ich hätte jetzt fast so'n CUL bestellt....)
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R