Mehr Kollisionen als bei älteren CUL_HM-Versionen

Damian · 29 August 2013, 17:32:07

Hallo Martin,

mir ist aufgefallen, dass beim gleichzeitigen Schalten mehrerer Aktoren häufiger Wiederholungen, offenbar aufgrund von Kollisionen, stattfinden als früher.
Wo früher alle Rollläden im Wohnzimmer (vier) gleichzeitig rauf und runter gingen, ist das mit den aktuellen Versionen von CUL_HM nicht der Fall.

Nun wollte ich wissen, ob es nur Einbildung ist oder nicht.

Ich habe mal zum Testen eine ältere Version von CUL_HM vom Februar genommen und siehe da, alle Rollläden laufen gleichzeitig an und es gibt keinen einzigen Resend lt. Readings.

Hat sich grundlegend etwas am Timing geändert?

Gruß

Damian

martinp876 · 29 August 2013, 19:37:54

Hallo Damian,

wenn du daten hast kann ich es gerne prüfen - oder besser darüber nachdenken.
Allerdings solltest du 00_HMLAN nutzen. CUL_HM hat mit gleichzeiten Schalten nichts zu tun, das regelt das IO-device.

Gruss Martin

Damian · 30 August 2013, 10:03:26

Hallo Martin,

folgendes Testszenario:

System wurde heruntergefahren, CUL_HM wurde ausgetauscht. Nach dem Hochfahren wurde im Wechsel 5x

Code Auswählen

set R_W_S,R_W_W[1-3] on und 5x

Code Auswählen

set R_W_S,R_W_W[1-3] on mit Pausen dazwischen (bis jeweils die Aktoren sich mit Endabschaltung zurückgemeldet haben):

hier das Ergebnis mit der alten CUL_HM:

(siehe Anhang / see attachement)

Bei insgesamt 40 Nachrichten war keine einzige Wiederholung.

Der Gegentest mit der aktuellen CUL_HM kommt gleich im nächsten Post, weil ich nur fünf Bilder hier reinstellen kann.

Damian · 30 August 2013, 10:18:56

Das Ganze nach einem Reboot des System mit der aktuellen CUL_HM konnte ich nur 3x jeweils mit den obigen Kommandos absetzten. Danach gab es nur missing_ack und der HM-Adapter ist nicht mehr ansprechbar.

Hier die ernüchternden Ergebnisse:

(siehe Anhang / see attachement)

Die Ergebnisse sind ziemlich eindeutig und ich kann sie beliebig oft reproduzieren.

Ein Loggen mit Verbose 5 habe ich zunächst bei diesen Tests nicht eingeschaltet, weil auf Grund der vielen Meldungen sich das Timing-Problem noch mehr verstärkt (dann habe ich sogar eine Wiederholung bei der alten CUL_HM)

Hier noch die alte CUL_HM, bei der, zumindest bei mir, die Welt noch in Ordnung ist.

FHEM läuft bei mir auf einem Window-Rechner und dürfte, was die Verarbeitungsgeschwindigkeit angeht, schneller sein als jede Fritzbox.

Gruß

Damian

martinp876 · 30 August 2013, 14:32:22

Hallo Damian,

du hast also nur CUL_HM ausgetauscht und nicht HMLAN?

Die Übersicht ist einfacher zu sehen (meine ich) wenn du
define hm HMinfo
set hm protoEvents

ausgibst.

Ich werde einmal nachsehen, was ich finden

Danke Martin

wenn du von beiden Scenarien die roh-messages aufzeichnen könntest? Wäre sehr hilfreich

und noch eins: Welche Version genau hast du ?

Damian · 30 August 2013, 17:08:59

Zitat von: martinp876 schrieb am Fr, 30 August 2013 14:32du hast also nur CUL_HM ausgetauscht und nicht HMLAN?

ja! Sonst habe ich nichts am System geändert.

ZitatDie Übersicht ist einfacher zu sehen (meine ich) wenn du
define hm HMinfo
set hm protoEvents
ausgibst.

habe ich jetzt definiert - kannte ich noch nicht.

Zitatwenn du von beiden Scenarien die roh-messages aufzeichnen könntest? Wäre sehr hilfreich[/code]?

Soll ich dazu bei den jeweiligen Aktoren log auf 5 setzen?

Zitatund noch eins: Welche Version genau hast du

Die alte ist vom (siehe im angehängten CUL_HM Modul oben):

# $Id: 10_CUL_HM.pm 2782 2013-02-21 19:26:18Z martinp876 $

die aktuelle ist vom:

# $Id: 10_CUL_HM.pm 3816 2013-08-28 18:27:41Z martinp876 $

Gruß

Damian

Damian · 30 August 2013, 21:54:57

Hallo Martin,

ich habe mal einfach

Code Auswählen

set R_W_S,R_W_W[1-3] off abgesetzt, obwohl die Rollläden schon unten waren und ausführlich mir Rohmessages protokolliert, siehe angehängte Dateien.

Ich habe es geschafft bei altem wie auch bei neuem CUL_HM-Modul ohne Wiederholung durchzukommen.

Allerdings zähle ich bei altem CUL_HM (log CUL_HM old.txt) 8 Send-Befehle bei neuem (log CUL_HM new.txt) 12! Das wäre ein Zuwachs von 50% und würde die höhere Wahrscheinlichkeit von Kollisionen erklären.

Gruß

Damian

martinp876 · 31 August 2013, 18:11:08

Hallo Damian,

die 50% zuwachs sind korrekt. Je rollo wird ein "set" und hintennach ein ACK gesendet, also 2 messages. Neu ist, dass vor jeden Fahren ein "stop" gesendet wird. Grund waren die durchgebrannten Relaiskontakte der BLs. Ich denke, dass es eigentlich nicht notwendig ist, ein "stop" zu senden, sondern, dass das Problem in der falschen registerprogrammierung lag.

Da du nur gutfälle gesendet hast,kann ich keine Aussage dazu machen. Gerne kannst du ein file ohne zwangs-stop ausprobieren.

Gruss Martin

Damian · 31 August 2013, 18:45:16

Hallo Martin,

und schon angetestet.

Das war es wohl:

protoEvents done:
name :protState |protCmdPend |protSnd |protLastRcv |protResndFail |protResnd |protNack
R_W_S : CMDs_done_events:2 |- |10:08-31 18:23:54 |08-31 18:23:59|- |2:08-31 18:23:25 |-
R_W_W1 : CMDs_done |- |10:08-31 18:23:54 |08-31 18:23:59|- |- |-
R_W_W2 : CMDs_done |- |10:08-31 18:23:54 |08-31 18:24:00|- |- |-
R_W_W3 : CMDs_done_events:1 |- |10:08-31 18:23:54 |08-31 18:23:59|- |1:08-31 18:21:56 |-

Bei gleichen Testbedingungen (insgesamt 40 Sendebefehle) nur 3 Resends.

So ist die Welt wieder ok!

Ich denke, dass es nicht gut ist die Stopps drin zu lassen.

Denn der zusätzlicher Traffic hat ja gravierende Folgen, wie meine Tests ergaben (missing_act bis hin zum kompeletten Absturz des HM-LAN-Adapters - reproduzierbar), wenn man mehrere HM_Aktoren "gleichzeitig" schaltet.

Vielleicht erspart die neue Version bereits einigen Usern unnötige Kopfzerbrechen.

Gruß

Damian

martinp876 · 01 September 2013, 07:51:14

Hallo Damian,

ich denke, die Stops werde ich entfernen.
Aber ich hoffe, es liegt nicht am zusätzlichen Traffic. Das sind ja "gerade einmal" 6 Aktoren. Wenn es am Messagesaufkommen liegt müssen wir nachbessern. Es könnte aber auch am "stop/go" liegen... Vieleicht mag es der Aktor nicht.
So oder so sollte es stabiler werden.

Gruss Martin

locodriver · 03 September 2013, 12:01:10

Hallo ihr beiden,

ich finde auch, die zusätzlichen Stopps wieder rauszunehmen. Jeder, der Rolas betreibt, sollte als erstes prüfen, ob die DriveTurn-Zeit gesetzt ist (sollte evtl. im Wiki o.ä. vermerkt werden). Zusätzlich kann man ja im fhem-Code noch prüfen, ob der Rola fährt und ihn stoppen bevor man einen Fahrbefehl in die andere Richtung gibt.

Uwe

Damian · 03 September 2013, 12:05:46

Zitat von: locodriver schrieb am Di, 03 September 2013 12:01Hallo ihr beiden,

ich finde auch, die zusätzlichen Stopps wieder rauszunehmen. Jeder, der Rolas betreibt, sollte als erstes prüfen, ob die DriveTurn-Zeit gesetzt ist (sollte evtl. im Wiki o.ä. vermerkt werden). Zusätzlich kann man ja im fhem-Code noch prüfen, ob der Rola fährt und ihn stoppen bevor man einen Fahrbefehl in die andere Richtung gibt.

Uwe

So etwas muss der Aktor verhindern, oder es ist ein Bug in der Firmware des Aktors.

Gruß

Damian

Damian · 03 September 2013, 12:25:34

[quote title=Damian schrieb am Di, 03 September 2013 12:05]

Zitat von: locodriver schrieb am Di, 03 September 2013 12:01So etwas muss der Aktor verhindern, oder es ist ein Bug in der Firmware des Aktors.

Gruß

Damian

Ich habe gerade mit der CUl_PM-Version ohne Stopps, "set Rollladen off" und während der Laufzeit "set Rollladen on" per Software abgesetzt - ohne Probleme. Der Rollladen hat die Richtung gewechselt, ohne dass irgendetwas Auffälliges passieren würde - geschweige denn der Rollladen durchgeschmort wäre.

Gruß

Damian

martinp876 · 04 September 2013, 12:10:24

Hi,

ich werden es rausnehmen.
driveTurn kann man "legal" mit FHEM nicht mehr unter 0.5sec setzen, habe ich verriegelt.

zusätzlich auch hier der Hinweis auf
http://forum.fhem.de/index.php?t=msg&goto=93257&rid=251#msg_93257

comming as...
tests mit AES-systemen und systemen mit vielen TCs wären hilfreich.

Gruss Martin