Symcon Enocean LAN Gateway mit Nodon Aktoren, seltsames verhalten

rolf1 · 11. Juni 2022 um 14:18

Hi zusammen,

da ich jetzt von einem „normalen“ Raspi auf die Symbox umgestiegen bin musste ich meinen bisheriges Gateway (USB300) gegen das Symcon Enocean LAN Gateway tauschen.

Das Problem das ich jetzt habe ist, dass mit dem neuen Gateway (aktuell in verbindung mit Nodon Aktoren) der tatsächliche Schaltzustand häufig nicht mit dem an IPS angezeigten übereinstimmt.

Wenn ich z.B. den Aktor über einen gekoppelten Enocean Taster einschalte, wird es in IPS korrekt angezeigt. Wenn ich über IPS ausschalte funktioniert es auch. Wenn ich aber über den Taster ausschalte kommt die Änderung (häufig) nicht im IPS an. Dort wird „aktiv“ angezeigt obwohl tatsächlich „aus“ ist.
Ab dann lässt sich das ganze nicht mehr über IPS steuern, erst wenn ich mit dem Taster wieder einschalte lässt es sich über IPS ausschalten und wird dann korrekt angezeigt (Status emulieren ist aus!)

Mit dem USB300 war das bisher grundsätzlich kein problem (es gab einen Aktor bei dem es alle paar Wochen einmal dazu kam) jetzt mit dem LAN Gateway kann ich es mehr oder weniger für alle Aktoren reproduzieren.

Ich hab schon gemerkt das die Sendeleistung des LAN GW wohl schwächer/anders ist als des USB300, daher hab ich mal testweise einen Repeater aktiviert, hat aber nichts verändert.

Da ich aktuell das LAN Gateway nur für die Nodon Aktoren nutze kann ich nicht sagen ob es bei anderen Aktoren auch Probleme gibt (die sind alle Eltako und gehen über den BUS oder in Verbindung mit dem FTD)

Ich nutze das LAN Gateway auch nur, weil ich es bisher nicht geschafft habe die Nodon mit dem FTD so anzulernen, dass ich den tatsächlichen Status im IPS sehen kann.

Ich kann auch nicht erkennen ob eine Rückmeldung vom Aktor über den Status eintrifft. Im Debug des FGW sieht es aus als wären die Aktoren ausgeblendet und im Debug des Gateway sieht für mich alles komisch (da anders als beim FGW) aus. Ist das Normal?

Dump des LAN GW eines PTM Tastendruck:

TXT: 11.06.2022, 16:15:32 | Parse Buffer | U
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | U
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | U
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | U
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz�
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz�
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF FF
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF FF FF
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz��
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF FF FF FF
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz�� K
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF FF FF FF 4B
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz�� K
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF FF FF FF 4B 00
TXT: 11.06.2022, 16:15:32 | Chunk Incomplete |
HEX: 11.06.2022, 16:15:32 | Chunk Incomplete |
TXT: 11.06.2022, 16:15:32 | Parse Buffer | Uz�� K�
HEX: 11.06.2022, 16:15:32 | Parse Buffer | 55 00 07 07 01 7A F6 00 FE F2 FA 0F 20 01 FF FF FF FF 4B 00 F0
TXT: 11.06.2022, 16:15:32 | Parse Data: 01 | ��
HEX: 11.06.2022, 16:15:32 | Parse Data: 01 | F6 00 FE F2 FA 0F 20
TXT: 11.06.2022, 16:15:32 | Parse Data (Opt) | ��K
HEX: 11.06.2022, 16:15:32 | Parse Data (Opt) | 01 FF FF FF FF 4B 00

Hat jemand eine Idee?

Grüße
Rolf

rolf1 · 11. Juni 2022 um 14:50

Nachtrag,
da ich jetzt den USB Stick rumliegen habe, hab ich mal DolphinView angeworfen.

Was mir jetzt mehrfach aufgefallen ist:

Ausschalten über Webfront
LAN-GW sendet Telegram (steht auch im Debug des LAN-GW)
Aktor schaltet
Aktor sendet Bestätigungstelegram (sehe ich im DolphinView)
Debug des LAN-GW zeigt Bestätigungstelegram NICHT an
Status im Webfront springt zurück auf An (Aktor bleibt aus)

Gleiches passiert auch beim Einschalten.

Wenn ich über einen Taster (auch in schneller folge) schalte, springt der Status im Webfront fast immer korrekt um (nicht immer). Sobald aber IPS selbst sendet „verpasst“ es quasi die Antwort und springt daher zurück.

Das Problem scheint also aufzutreten wenn das Gateway Senden und Empfangen/Auswerten quasi direkt nacheinander durchführen muss. Dann bleibt das Empfangen/Auswerten auf der Strecke.
Wenn ich dann wieder im Webfront schalte sendet zwar das Gateway, da der Aktor aber schon Aus bzw. An ist und somit nicht schaltet schickt er auch keine Antwort mehr mit seinem Status.

Ich kann es sehr gut nachstellen aber es tritt nicht durchgehend auf, zwischendurch klappt der Schaltvorgang im Webfront wie er soll.

Edith sagt: ich sollte mich mehr aufs schreiben konzentrieren.

kdm · 13. Juni 2022 um 09:34

Hallo Rolf,

nur als kurze Ergänzung aus eigener Erfahrung:

Ich kann mich des Eindrucks nicht erwehren, dass die aktuellen EnOcean-Gateways empfangstechnisch spürbar schlechter sind, als die „alte“ Bauweise. Zumindest ist dies bei meinem vor kurzem als Reserve-Gateway für einen Geräteausfall gekauften Gerät definitiv der Fall.

Eigentlich war ich der Meinung, dass „neuer“ = „besser“ zu erwarten wäre, aber ein 1:1-Tausch an gleicher Stelle im Haus hat gezeigt, dass das neue Gateway im Erdgeschoss Telegramme von EnOcean-Geräten in der 2. Etage nicht mehr mitbekommt, während das alte an gleicher Stelle problemlos funktioniert.

Von daher kann es sein, dass bei Dir die Probleme ebenfalls an der beschränkten Empfangsempfindlichkeit des Gateway liegen.

Ob dies an der generell schwächeren Receiver Sensitivity des TCM 515 (-92dBm) gegenüber dem TCM310 (-96dBm) liegt, oder an der fehlenden externen Antenne oder am eventuellen Störnebel des im Gateway verbauten Schaltreglers, kann ich mit meinen heimischen Bordmitteln leider nicht ermitteln…

Zumindest war die Erfahrung mit meinem Exemplar der aktuellen EnOcean-Gateways etwas frustrierend…

Gruß Klaus

paresy · 14. Juni 2022 um 15:09

@kdm: Das liegt (unserer Meinung) tatsächlich am TCM515 Chip, welcher etwas schlechter als der TCM310 performt. Es sollte aber wirklich nur ein wenig sein und nicht merklich. @rolf1 Im Zweifelsfall können wir dein Gateway mal austauschen - nicht, dass du zufällig ein Montags-Gerät bekommen hast, das nicht vernünftig arbeitswillig ist. Evtl. können wir noch an der Empfangssensitivität drehen, um die Zuverlässigkeit zu verbessern.

Der Debug sieht aber soweit gut aus. Per LAN kommen die Bytes gerne mal sehr segmentiert an.

Was steht denn bei dir unterhalb der Gateway Instanz bei Version drin?

paresy

rolf1 · 14. Juni 2022 um 15:40

Hi @paresy

Version steht „TCM515 (DC)“

Die Darstellung im Debug ist so segmentiert nur sehr ungewohnt, beim anderen sieht das so schön „ordentlich“ aus

Da aktuell die betroffenen Geräte hauptsächlich direkt via Taster gesteuert werden ist das Problem zum glück nicht ganz so akut. Ich hab heute mal versucht das Problem nachzustellen und hab es nicht geschafft (mit einem Testaktor). Es kam mir so vor, als würde das Debug sehr viel schneller gefüllt, nicht wie beim letzten mal wo alles so zäh war.
Das System wurde seither allerdings nicht verändert, nicht neu gestartet, es lief einfach nur ein paar Tage.

Was mir jetzt allerdings neu aufgefallen ist, ist ein häufiges auftreten folgender Meldung:

14.06.2022, 12:16:36 | FlowHandler | Kann Daten nicht zur Instanz #26046 weiterleiten: Received unsupported Device data 00

Die Meldung hatte ich beim „alten“ System mit dem USB300 auch mal, allerdings mit einem Data 05 und auch nur alle paar wochen 1x. Jetzt alleine 11x seit gestern abend. (26046 ist die splitter instanz des GW). Welches Debug müsste ich anwerfen um die Geräte ID zu finden die das angeblich sendet?

Grüße
Rolf

rolf1 · 17. Juni 2022 um 22:09

Kleiner Nachtrag.

Auf der Suche nach dem Phantom habe ich unbeabsichtigt das LAN Gateway einem stresstest unterzogen (hatte versehentlich das LAN GW anstelle des FGW14 ausgewählt für eine Instanz).

Das Gateway hat dabei nur Empfangen und nichts gesendet. Ergebnis war leider das ich ein Verlust von grob 5-10% der Telegramme hatte. Also Nachrichten die es nicht bis zur Instanz geschafft haben und daher dort nicht der korrekte Status gesetzt war.

Die Pakete müssen irgendwo zwischen Gateway und Instanz verloren gegangen sein. Ein Signalproblem kann ich 100% ausschließen, die Telegramme wurden vom FAM14 (ca. 10cm) und vom USB300 empfangen der deutlich weiter (ca 7m und 2 Wände) vom Sender entfernt wahren als das LAN Gateway (ca.1m).

Die Frage ist jetzt woran es liegt? Doch am Gateway (Hardware bzw Firmware) oder an Schnittstelle im Symcon? So kann es aber definitiv nicht bleiben.

Grüße
Rolf