[gelöst] EnOcean: Telegramm-Konflikte nach Upgrade auf IP-Symcon 6.2

Das Upgrade auf IP-Symcon 6.2 hat einwandfrei funktioniert. Allerdings habe ich jetzt das Problem mit meinem Eltako-BUS, den ich per USB an IPS angeschlossen habe. Wenn ich mehrere Befehle gleichzeitig abfeuere, kommt es seit V6.2 zu Telegramm-Konflikten, so dass nur ein Teil der Befehle ausgeführt wird. Bis V6.1 hat das immer einwandfrei funktioniert.
@paresy kennt Ihr das Problem? Lässt sich da etwas machen?
Grüße
Jürgen

Kannst du das irgendwie eingrenzen oder im Debug nachvollziehen? Wir hatten zur 6.2 keine Änderungen an EnOcean gemacht - die Frage ist also wodurch diese Wechselwirkung entsteht.

paresy

ich habe mir ein Modul geschrieben, dass abhängig vom Sonnenstand die Lamellen der Jalousien stellt. Da alle auf den selben Sonnenstand reagieren, feuern alle ihren Befehl gleichzeitig ab. Das läuft jetzt seit 2 Jahren fehlerfrei Seit 6.2 hat immer ein oder zwei Jalousien keinen Befehl erhalten ( immer unterschiedliche). Könnte es sein, dass 6.2 einfach schneller in der allgemeinen Abarbeitung geworden ist und sich damit der Abstand zwischen zwei Befehlen verkürzt hat?
Grüße
Jürgen

Oh, ja. Bisher wurden Nachrichten seriell abgearbeitet. Ab der 6.2 läuft alles parallel. D.h. du müsstest die Abarbeitung über Semaphoren wieder serialisieren in deinem Modul, damit die Wartezeit korrekt ist.

paresy

Das kann nicht das richtige Vorgehen sein. Das Modul kann nicht wissen, welches andere Modul von wem auch immer gerade eine Nachricht auf den BUS schickt. Das weiß nur das Gateway. Dementsprechend muss (und kann auch nur) das Gateway für die konfliktfreie serielle Abarbeitung der Telegramme sorgen.
Grüße
Jürgen

Hi Jürgen,

das würde aber bedeuten, dass dieses Problem bereits vor der 6.2 auftreten konnte, wenn du direkt hintereinander in einem Skript alles ansprichst. Könntest du dies mal gegentesten? Passiert das dann auch (ist egal ob 6.1/6.2).

Wir haben intern beim FGW14 Modus eine Verzögerung von 50ms nach jedem Telegramm. Sollte dies zu wenig sein, kann ich diese Verzögerung ja konfigurierbar machen, sodass du einen besseren Wert ermitteln kannst.

paresy

So, ich habe das jetzt mal intensiv getestet (habe immer 10 Schaltvorgänge per foreach und RequestAction ausgelöst).
Ergebnis:

  • in 80-90% der Fälle laufen alle Befehle sauber durch.
  • in den übrigen Fällen sind zwischen 10-30% der Befehle nicht durchgekommen.

Mein Eindruck ist, dass die Telegrammverluste immer dann auftreten, wenn gerade Statusmeldungen vom BUS reinkommen. Das ist aber nur eine Vermutung auf Basis der Beobachtungen von eben.

Das hört sich zunächst nach einer guten Lösung an, wenn ich allerdings IPS_SLEEP in die Schleife einbaue, kann ich bis 250 Millisekunden keine Verbesserung erzielen. Ist der Effekt Gateway-intern ggf. ein anderer?

Der BUS selbst hat eine HOLD-Leitung, damit die BUS-Geräte keine Nachrichten senden, wenn bereits eine Nachricht auf dem BUS ist. Ggf. muss das Gateway auch so eine Funktion haben (oder hat sie vielleicht auch). Aus meiner Sicht müsste die Verzögerung zwischen empfangener und gesendeter Nachricht ebenfalls 50ms betragen.

Danke und Grüße
Jürgen

Hi Jürgen,

intern wäre der Effekt der selbe, das es beim ESP2 Protokoll (soweit ich das hier sehe) keinerlei Bestätigung gibt, ab wann wir wieder senden können. Sofern bei deinem Test nicht zusätzliche Befehle vom laufenden Betrieb dazwischen kamen, wäre das natürlich echt viel Verlust.

Falls du es Testweise mit der 6.1 versuchen willst könnte man ausschließen, dass es irgendwie daran liegt - ich kann mir jetzt aber nicht vorstellen, warum es dort anders sein sollte.

Mein FGW-14 (RS232 Variante) hat eine HOLD Leitung, die man ja laut Anleitung auch passend verbunden haben muss. Somit dürfte das FGW doch nicht senden, wenn „Gegenverkehr“ unterwegs ist, oder?

paresy

Hi paresy,

das sehe ich genauso. Die Frage ist allerdings, ob das Gateway sendet, wenn gerade ein Telegramm reinkommt. Oder gibt es im Gateway eine softwareseitige Hold-Funktion? Diese müsste es doch eigentlich bereits im SerialPort geben, oder?

Das probiere ich morgen mal aus und berichte.
Grüße
Jürgen

Also ich bin noch auf der 6.1 dann hab ich ja gerade Angst. Da lass ich mal nen update sein. Denn das wäre nicht nice wenn wir jetzt drum rum coden müssten.

Ich hatte das Phänomen eher als ich noch alles über BSC im Funkbetrieb hatte. Ich kann das bei Busbetrieb nicht feststellen.

Ich hatte auch schon immer mal dran gedacht „eigene“ Module zu machen. Wo die Module die Rückantwort abwarten. Nach dem Motto wenn in 1 Sek keine Antwort dann nochmal schicken.

Hi paresy,
habe heute noch einmal intesiv getestet und ein spannendes Ergebnis:
Unabhängig von der IPS-Version trat kein einziger Fehler auf. Jetzt bin ich ratlos. Hast Du noch eine Idee? Ansonsten muss ich einfach weiter beobachten.
Grüße
Jürgen

Leider nein :frowning:

paresy

ok, hoffen wir mal, dass es ein Fehlalarm war. Ich beobachte das mal weiter.
Danke für Deine Unterstützung
Jürgen

Leider war es kein Fehlalarm. Das Problem scheint aber gefunden und abgestellt zu sein. Ich berichte hier mal etwas ausführlicher, da andere ggf. in ähnliche Probleme laufen können.

Bisheriger Stand:

Um die Lamellen meiner Jaloussien auf einen bestimmten Winkel ohne Drift zwischen Soll- und Istwert zu bringen, werden die Lamellen zunächst komplett geschlossen und danach wieder auf den vorgegebenen Wert geöffnet. Bei Eltako kann man dafür die Sollfahrzeiten vorgeben. Symcon muss bis zum Ende der Fahrzeit warten und dann den nächsten Befehl abfeuern. Bei der seriellen Abarbeitung unter IPS V6.1 hat das auch super funktioniert. 200ms Abstand vom Ende der Fahrzeit bis zum nächsten Befehl haben genug Sicherheitsreserve geboten. Meine 8 Jaloussien haben wie bei einer Laolawelle eine nach der anderen ihr Tänzchen vollführt.

Stand ab V6.2:

Alle Lamellen erhalten zeitgleich ihren Befehl und würden diesen auch exakt zeitgleich ausführen. Da der Eltako-BUS aber seriell arbeitet, hängen die Befehle im Stau/der Queue vor dem BUS und werden mit 50ms(? …kommt mir deutlich weniger vor) Versatz abgefeuert. Hierdurch gibt es bei 8 Aktoren einen Zeitverzug von 400ms zwischen dem Versand des Befehls im Modul und dem Versand auf den BUS und dadurch zu einem verfrühten Absenden des Folgebefehls. Kommt der Folgebefehl nun zu früh am Jalossien-Aktor an, wird dieser vom Aktor verworfen.

Änderung der Steuerung

Dadurch dass IPS V6.2 jetzt parallel arbeitet, kann die gesamte Zeitsteuerung der Jaloussie aus Symcon erfolgen. Damit verwerfen die Aktoren keine Befehle mehr.

Ergebnis

Bisher sind keinerlei Störungen mehr aufgetreten und die Jaloussien laufen jetzt gefühlt komplett zeitgleich, obwohl jetzt doppelt soviele Befehle auf den BUS geschickt werden müssen.

Danke nochmal für die Unterstützung und hoffentlich ist das Problem damit behoben.
Grüße
Jürgen

1 „Gefällt mir“

Das habe ich nicht verstanden. Hast du nun Wartezeiten in IPS vor dem versenden eingefügt?

Nein, ich habe andere Befehle eingesetzt. MEF_ShutterMoveDown und MEF_ShutterStop anstelle von MEF_ShutterMoveDownEx. Das Einfügen von Wartezeit ist nur bedingt zielführend, da ich nicht wissen kann, wieviele Befehle aus anderen Modulen sich gerade in der Warteschlange vor dem BUS eingereiht haben und wieviele Statusmeldungen in dem Moment gerade über den BUS kommen.

Okay ich nutze _EX gar nicht.
Aber eigentlich senden ShutterMoveDown und ShutterMoveDown_EX doch nur einen Befehl?

dann hast Du das Problem auch nicht.

was ist denn der unterschied zwischen ShutterMoveDown und ShutterMoveDown_EX ich habe gerade ähnliche Probleme mit meinem Befehl „Alle Rollläden schließen“ und nutze seit Beginn ShutterMoveDown_EX! sollte ich jetzt auch zu ShutterMoveDown wechseln???

sorry stimmt nicht ich habe folgende Befehle drin und trotzdem fährt der ein oder andere Rollo nicht runter?
ENO_ShutterMoveDown(37394);

IPS_Sleep(50);

ENO_ShutterMoveDown(47132);

IPS_Sleep(50);

ENO_ShutterMoveDown(41695);