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
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
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"}}
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
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
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
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
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
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.
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.
wenn der HMLAN grundsätzlich so schwach performt, wäre da evtl der USB-CUL für mich die bessere Lösung?
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
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?
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
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....)
als Anhaltspunkt:
HMLAN kann je Stunde 1600messages.
ein burst kostet 16 messages
wenn nicht geantwortet wird wiederholt hmlan 3-mal.
wenn du bursts an ein nicht antwortendes Device sendest ist nach etwa 30 versuchen overload (30*3*16)
100 bursts klappen bei antwortendem Device.
2000 schafft er meinen Messungen nach nicht :-(
Beachte, dass auch die ACKs, die du nicht explizit siehst, gezählt werden müssen.
Der eingebaute Zähler berücksichtigt dies alles so gut wie möglich
Wenn du licht einschaltest (1 message) und das device hernach seinen Status an die Zentrale meldet (1 ack) zählt dies doppelt.
Jede nicht beantwortete message zählt 3-fach. Wenn du 5 repeats eingestellt hast (aus FHEM) und es nicht klappt sind es 15 Zähler
Gruss Martin
hm - vielleicht habe ich auch ein bisschen übertrieben mit 2000.
ich habe zwischendurch ja meine Config geändert und dannn stellt sich der Snd-Zähler zurück.
1600 kann schon hinkommen - immer noch OK
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
nochmals vielen Dank für die umfassende Hilfe und schnelle Fehlerkorrektur !!!
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
Hallo an Alle!
ich habe das selbe Problem!
In der 5.4 er Version lief bei mir alles problemlos, fehlerfrei.
Seit der update auf 5.5 geht fast nichts mehr. Selbst wenn keine befehle gesendet werden geht der HMLAN in
overload status und ohne reset dauert es ewig bis wieder was geht. Allerdings kurze zeit später ist wieder alles aus.
Bin Überzeugt, dass es auch mit der Update zusammenhängt!
Gruss Michael
Hallo Misi,
hast Du alle aktuellen Updates drauf?
Mit der Fehlerkorrektur von Martin am 20/21.11.2013 ist der Fehler in der Praxis nicht mehr aufgetreten.
Siehe Antwort 13.
Mit der "Brechstange" konnte ich den Fehler aber noch provozieren.
Vielleicht hast Du ein Device welches Wakeup/Burst nutzt.
Das scheint ein Problem zu sein
Hi,
auch hier noch einmal ein paar Tips:
a) Version 5.5 sagt mir fast garnichts. Das ist viel zu grob. Bitte ein "version" machen oder die Versionen der Module benennen
b) HMinfo mit set hm protoEvents short
c) HMinfo mit set hm msgStat
b) und c) sollten aufschluss geben, wer hier viel sendet - und wann
Gruss Martin