HMLAN disconnected und Messages verloren ?!

[bugster_de]

Hi,

die Rolläden hier sind alle so eingestellt, dass sie um 18:30:00 mit jeweils 2 Sekunden Versatz via at zufahren sollen (also 18:30:00, 18:30:02: 18:30:04, usw)

Ich hatte dieser Tage den Effekt, dass FHEM die Verbindung zum HMLAN genau um 18:29:59 verloren hat und erst ca. 30 Sekunden später wieder aufnahme. Also just in dem Moment, als dfas HMLAN weg war. Ergo blieben die Rolläden oben.

Kann es sein, dass die FHEM MEssages zwischen disappeared und re-appeared des HMLAN dann verloren sind? Und was passiert, wenn genau in so einem Moment ein Fenstersensor einen Einbruch meldet?

[betateilchen]

Das wäre dann unter "dumm gelaufen" zu verbuchen. Der Fensterkontakt schickt seine Meldung ab und bekommt kein ACK. Er wird dies einfach mit rotem Licht signalisieren und das wars. Deshalb sollte man eine Alarmanlage nie mit Funkkontakten ausstatten, wenn man wirklich auf Zuverlässigkeit angewiesen ist.

Zu Deinem Rollladenproblem: Wieviele Rollläden steuerst Du im 2-Sekunden-Takt? Dir ist schon bewusst, dass es eine maximal erlaubte Menge von Funkübertragungen pro Minute gibt?

[martinp876]

interessanter Fall.

Problem 1) FHEM will etwas senden und der HMLAN adapter verschwindet. Es können ein paar messages verloren gehen, wenn sie gerade in Bearbeitung sind. Weiteres Senden wird verzögert.
=> der Fehler ist in proto... Variablen nachzulesen. Einen triggerfähigen output gibt es (noch) nicht.

Problem 2) ein Device will eine Meldung absetzen während HMLAN disconnected ist. Nach meinen Tests speichert der HMLAN die Messages und sendet die nach reconnect. Umklar ist die Speichertiefe. Ausserdem werden Antworten(acks) von FHEM zu spät kommen. Konkrete Probleme sehe ich nicht. Falls der Auslöser natürlich ein Absturz des HMLAN war sind die Meldungen weg.

Prinzipiell sollte man einen "systemAlarm" einbauen auf den man triggern kann. Protokoll Probleme und disconnects sollten dabei erfasst werden. Mal sehen - ich sehe hier HMInfo als möglichkeit.

[bugster_de]

Hi,

also ich steuere im Moment 'nur' 6 Rolläden. Da kommen aber noch 13 Stck. dazu. ich gebe das geld für die weiteren Rolläden aber erst aus, wenn die 6 Stück mal zufrieden stellend laufen :-)
Desweiteren habe ich zwei Homemmatic Temperatur Sensoren sowie 2 Homematic Fensterdrehgriffsensoren im Einsatz. Ansonsten ist auf 868MHz nichts angeschlossen.

Dir ist schon bewusst, dass es eine maximal erlaubte Menge von Funkübertragungen pro Minute gibt?

irgendwie ja. Aber diese Frage hatte ich in einem anderen Fred ja schonmal gestellt. Wieviele sind das dann?

Und genau deshalb versuche ich die einzelnen Devices ja auch mit einem gewissen Zeitversatz zu anzusteuern, um so weit als möglich aus diesen Konflikten raus zu kommen.
Allerdings scheinen nur wir mit FHEM dieses problem zu haben. Ein Arbeitskollege, der 1 büro weiter sitzt hat sein ganzes Haus mit Homematic ausgerüstet. Im prinzip hat der einmal den ELV Katalog bestellt und auch die Hoemmatic Zentrale dazu. Ihm sind solche Probleme völlig unbekannt. Allerdings hat er natürlich auch nicht den Freiheitsgrad, den wir mit FHEM haben.

meine erste Umsetzung der Ansteuerung war wie folgt
set Rolladen off
sleep 0,2
set Rolladen2 off
usw

Da war dann die Anmerkung hier im Forum, dass dies nicht geht, da sleepx FHEM lahmlegt und somit ankommende Messages (ACK) der Aktoren nicht behandelt werden können.

zweiter Versuch war dann.
set Rolladen off
set Rolladen2 off
usw
das führt dann zu missing ack, da wohl einfach zu viel Traffic in der Luft ist und die Messages kollidieren. Wobei ich mir aber nicht vorstellen kann, dass dies im Protokoll von Homematic nicht erkannt und abgefrühstückt wird. Wäre ja ziemlich dämlich, wenn alle Devices einfach mal drauf los senden ohne erst mal zu horchen, was überhaupt in der luft los ist.

Nun mein dritter Versuch der Umsetzung
define myRoll_auto at +00:01:00 set Rolladen off
define myRoll2_auto at +00:01:02 set Rolladen2 off
usw

Sprich zeitversatz von 2 Sekund und Aufruf mittels at, um danach die Kontrolle wieder an FHEM zugeben.

Die MISSING ACK sind momentan weg, aber nun poppt das lustige Problem des verschwundenen HMLAN auf.


In diesem fred: Link, der mittlerweile etwas off-topic ist, wird das asynchrone Verhalten diskutiert.

Deshalb sollte man eine Alarmanlage nie mit Funkkontakten ausstatten

:-) War ja auch nur ein Beispiel. Momentan schaffe ich es ja nicht mal die Rolläden mehr als eine Woche am Stück zuverlässig zu schalten, ohne dass ich Hand anlegen muß. Für eine Alarmanlage wäre mir etwas mehr zuverlässigkeit schon lieb. Und die Alarmanalge soll ja eh nur scharf sein, wenn keiner zu Hause. Und da sind wir noch bei der Baustelle iPhone meiner Frau und Anwesenheitserkennung :-)

[martinp876]

hi bugster_de

Dir ist schon bewusst, dass es eine maximal erlaubte Menge von Funkübertragungen pro Minute gibt?

irgendwie ja. Aber diese Frage hatte ich in einem anderen Fred ja schonmal gestellt. Wieviele sind das dann?

eigentlich ist dies nicht Aufgabe des Users sondern von FHEM. Ich habe nach besten Erkenntnissen verzögerungen und repeats eingebaut. Falls jemand belastbare Infos hat über maximale msg/sec in irgendeiner Form sollten wir dies einbauen.
Eine Beschränkung aufgrund der Übertragungsgeschwindigkeit ist eh klar - was kennt ihr noch?

zweiter Versuch war dann.
set Rolladen off
set Rolladen2 off
usw
das führt dann zu missing ack, da wohl einfach zu viel Traffic in der Luft ist und die Messages kollidieren. Wobei ich mir aber nicht vorstellen kann, dass dies im Protokoll von Homematic nicht erkannt und abgefrühstückt wird. Wäre ja ziemlich dämlich, wenn alle Devices einfach mal drauf los senden ohne erst mal zu horchen, was überhaupt in der luft los ist.

doch, so ist es wohl. sonst wären die ACKs alle da. Aber hast du wirklich ein Problem? Wenn es ein missing ACK gibt wieder holt FHEM. Missing ACKs sind nicht weiter schlimm - wirkliche Probleme gibt es erste, wenn protoResendFail gezählt wird.
Wo sind die Beispiele deiner Rollos? und sind sie nicht gefahren oder hast du "nur" missing Ack?

wäre cool einmal bei deinem Kollegen in der Luft zu sniffen, wenn er 20Rollos am Stück runterfahren lässt :) wie schnell fahren die an?...

Gruss Martin

[betateilchen]

meine erste Umsetzung der Ansteuerung war wie folgt
set Rolladen off
sleep 0,2
set Rolladen2 off
usw

Da war dann die Anmerkung hier im Forum, dass dies nicht geht, da sleepx FHEM lahmlegt und somit ankommende Messages (ACK) der Aktoren nicht behandelt werden können.

Deshalb würde ich sowas immer mit select() machen.

Code Auswählen Erweitern


set Rolladen off
select(undef, undef, undef, 2);
set Rolladen2 off


Und ich würde die Abstände größer als 2 Sekunden wählen (vermutlich würde ich 10 Sekunden nehmen, aber bei mir gibt es gar keine Rollläden) Außerdem würde ich mit at arbeiten und nicht alle Rollläden in einem einzigen Aufruf abhandeln.

[betateilchen]

interessanter Fall.
Problem 1)

Problem 2)

Problem 3) HMLAN verschwindet komplett, weil er gerade neu bootet (beispielsweise per Parameter -r im hmland) oder Stromausfall war.

[martinp876]

was geht bei Problem3 verloren?
ok, bei Stromausfall ist mehr hin. Da muss man komplett neu aufsetzen. Welchen Stronkreis hat es erwischt?
Aber bei ethernet-disconnect sollte es weitgehend klappen , wie beschrieben.

[bugster_de]

Deshalb würde ich sowas immer mit select() machen.

und das bringt was genau? Ist ja eigentlich auch egal, da ich ja nun auf at umgestellt habe

Und ich würde die Abstände größer als 2 Sekunden wählen

naja, das bedeutet dann bei 19 Rolläden eine ordentliche Fahrzeit und Geräuschkulisse. Denn die Rolläden fahren ca. 30 Sek. um komplett zu schliessen. Während dieser Zeit senden sie auch ihre jeweils aktuelle Position, sprich es gibt Traffic in der Luft. Um dem also komplett aus dem Weg zu gehen, müsste der Abstand pro Rolladen größer 30 Sekunden sein. Bei 19 Rolläden sind das dann mal schlanke 9:30h. Der WAF wird da nicht hoch sein :-)
Und während dieser Zeit darf dann auch kein HM Sender irgendwas funken.

Außerdem würde ich mit at arbeiten und nicht alle Rollläden in einem einzigen Aufruf abhandeln

genau so mache ich das doch. Ein at pro Rolladen.

Ich bin aber überzeugt davon, dass dies alles nur dem Kurieren der Symptome dient. Der Hase liegt irgendwo anders im FHEM-Pfeffer. Wie gesagt ist die Homematic Installation meines Kollegen deutlich umfangreicher und rennt seit Monaten einfach durch. Irgendwas geht da in den unteren Schichten von FHEM schief. Leider habe ich keine Ahnung, wo anfangen mit suchen.

Und gerade wo ich dies hier schreibe habe ich wieder einen MISSING ACK auf einem Rolladen. Hat ja auch ganze 5 Tage funktioniert :-(

[Dirk]

Man kann doch alle bzw. eine Gruppe von Rolladenaktoren direkt mit einer Fernbedienung, also auch der virtuellen Peeren.
Dann sollte z.B. ein "set vitualButton01 press_short" alle Aktoren bzw. alle der Gruppe zeitgleich in Bewegung setzen.
Somit reduziert sich die Funklast hier deutlich. Oder übersehe ich hier was?

Gruß
Dirk

[bugster_de]

Hi,

keine Ahnung ob Du was übersiehst. Ich kenne die virtuellen Fernbedienungen nicht. Wie geht das?

[Dirk]

Aus der Commandref:

Code Auswählen Erweitern


define vRemote CUL_HM 100000 # the selected HMid must not be in use
set vRemote virtual 20 # define 20 button remote controll
set vRemote_Btn4 peerChan 0 <actorchannel> # peers Button 4 and 5 to the given channel
set vRemote_Btn4 press


Wenn deine Rolladenaktoren signiert kommunizieren, dann muss die HM-ID oben die selbe ID deines HM-LAN sein. Ansonsten ist die ID frei wählbar.

Jede Taste kannst du dann mit deinen Aktoren deiner Wahl peeren. Genau so wie mit einer echten Fernbedienung.

So kannst du dann an eine Taste auch mehrere Rolladenaktoren peeren, welche dann alle nahezu gleichzeitig losfahren sollten. Bei eingeschalteter Signierung werden die vermutlich nacheinander loslaufen, da jeder Aktor noch seine Challenge gelöst bekommen haben möchte.

Gruß
Dirk

[bugster_de]

Hi,

Danke. Ich hatte die Definition parallel auch gerade gefunden. Sorry.
Das probiere ich gleich mal aus !

Wenn deine Rolladenaktoren signiert kommunizieren,

ich wär ja schon froh, wenn sie mal mehr wie 5 Tage am Stück normal kommunizieren würden ohne MISSING ACK :-) Ich hab das signierte noch nicht eingescahltet.

[bugster_de]

das glaub ich jetzt nicht. Habe den vRemote gepeered und sogar der Rolladen Aktor, der gerade wieder in MISSING ACK stand kann nun angefahren werden. Bisher musste ich da immer mittels Sicherung raus / Sicherung rein für reset sorgen, damit ich mit FHEM überhaupt wieder drauf kam.

Sprich wäre das nun eine intelligente Lösung, für alle Rolläden ein solches Peering zu machen und die Rolläden dann via diesen vRemotes fahren zu lassen? Zumindest bis komplett auf und komplett zu? Set Rolladen01 20 geht ja damit nicht, oder?

[EDIT]
vergiss die Fragen oben. Nun habe ich ja damit die Möglichkeit, mir eine Diagnose Routine in Perl zu machen, die einmal am Tag alle Rolläden auf MISSING ACK checkt und im Fall der Fälle den Rolladen per vRemote wieder ins FHEM Leben ruft. Sprich falls ein MISSING ACK gefunden wird, dann kann ich diesen Rolladen per set vRemote_Btn4 press und set vRemote_Btn5 press einmal runter und wieder hoch fahren lassen und er steht FHEM wieder zur Verfügung.
Hach ich freu mich ja so :-)

[Dirk]

Sprich wäre das nun eine intelligente Lösung, für alle Rolläden ein solches Peering zu machen und die Rolläden dann via diesen vRemotes fahren zu lassen?

Aber nicht jeden einzelnen Rolladen einen Taster zuweisen. Sondern gruppenweise, oder ggf. auch alle. Nur dann bewegen sich alle gleichzeitig. Ansonsten musst du wieder mehrere Befehle absetzen und hättest wieder die Gefahr der Kollision.

Set Rolladen01 20 geht ja damit nicht, oder?

Nicht so direkt. Die virtualRemote arbeitet halt ähnlich wie eine rechte FB. Ich kenne die Register vom Rolladenaktor jetzt nicht. Aber man kann einer gepeerten Taste bestimmt sagen dass dass Rollo auf eine bestimmte Position fahren soll?
Somit müsste man dann pro gewünschter Position auch eine eigene "taste" definieren. Ggf. unterschiedliche Werte für einen kurzen und langen Tastendruck?

Gruß
Dirk