[wiregate] Wiregate sendet mit Routingzähler = 7 / Problem mit Linienkoppler

[Nutshell]

Hallo,

bin nach langem endlich dabei, meine 1-Wire-Sensoren ans Wiregate zu hängen. Vorerst sollen die Temperaturen nur in der CometVisu angezeigt werden. Dazu habe ich in der Konfiguration der Sensorwerte eine entsprechende Gruppenadresse zugeordnet. So weit, so gut. Werte werden in der CometVisu angezeigt.

Allerdings ergibt sich ein anderes Problem. Durch die Gruppenadresse sendet das Wiregate jetzt den Wert über den TP-Uart auf den KNX-Bus. Und wie mir der Gruppenmonitor in der ETS4 anzeigt, mit Routingzähler = 7. Und damit meckert dann mein Linienkoppler mit einer roten Statusanzeige auf der Unterlinie wie im Thread

https://knx-user-forum.de/forum/%C3%...er-7-beim-eibd

beschrieben. Denn eigentlich haben die Telegramme auf der Unterlinie nichts zu suchen.

Leider blieb das Problem auch nach einem Update des Wiregate auf die aktuellste Version bestehen. Kennt jemand eine Lösung für das Problem?

Gruß Nutshell

[makki]

Ich hab das mal wieder aufgegriffen; zumindest was den knxd angeht:
https://github.com/knxd/knxd/issues/45
https://github.com/knxd/knxd/commit/...e08e8d50862bf9

Denn smurfix hat völlig recht, das ist entweder Quatsch oder zumindest ziemlich "suboptimal"

Teste das die Tage im Detail, muss aber erst die Testumgebung wieder komplett ausgraben

Makki

[StefanW]

Allerdings ergibt sich ein anderes Problem. Durch die Gruppenadresse sendet das Wiregate jetzt den Wert über den TP-Uart auf den KNX-Bus. Und wie mir der Gruppenmonitor in der ETS4 anzeigt, mit Routingzähler = 7. Und damit meckert dann mein Linienkoppler mit einer roten Statusanzeige auf der Unterlinie wie im Thread

Hallo, das ist ein Fehler in der Open Source Komponente 'eibd' und betrifft auch sämtliche andere Projekte seit sieben Jahren. Es entspricht nicht dem Standard, war aber bislang kein so großes Problem, weshalb es bisher von keinem Maintainer gefixed wurde.

Dieser Fehler und noch ein paar andere sind auch der Grund, warum wir beim WG New Gen. mittelfristig auf einen eigenen KNX Stack setzen werden.

Wir werden das aber nochmal intern besprechen, ob und wie wir das übernehmen, falls Makki den Fix liefern möchte.


lg

Stefan

[Nutshell]

Hallo Makki,

obwohl ich in C nicht firm bin (hatte bisher nur mit anderen Programmiersprachen zu tun) hab ich mir mal auf GitHub den Code ein bisschen angeschaut um evtl. auch etwas beitragen zu können.

Dabei ist mir in der lpdu.cpp die Zeile 215 aufgefallen. Kann es sein, dass dort das Datenpaket mit dem hopcounter = 7 initialisiert wird?

L_Data_PDU::L_Data_PDU (Layer2 *layer2) : LPDU(layer2)
{
  prio = PRIO_LOW;
  repeated = 0;
  valid_checksum = 1;
  valid_length = 1;
  AddrType = IndividualAddress;
  source = 0;
  dest = 0;
[COLOR=#FF0000]  hopcount = 0x07;[/COLOR]
}

Gruß Nutshell

[Nutshell]

So, jetzt muß ich nochmal nen Eintrag schreiben. Hat keiner das gleiche Problem?

Liegt es an der Kombination von TP-Uart und Linienkoppler? Lässt sich das Problem mit z. B. einem IP-Interface/-Router beheben? Dann würde ich mir überlegen nochmal in die Tasche zu greifen und sowas zuzulegen.

Gruß Nutshell

[StefanW]

Hallo

So, jetzt muß ich nochmal nen Eintrag schreiben. Hat keiner das gleiche Problem?

Der eibd schreibt Telegramme mit einem falschen Eintrag - oder sagen wir extrem unüblichen - Vorgabe für den Routingzähler. Normalerweise wird eine "6" eingetragen, der eibd gibt die "7" vor. Der Unterschied: Alles mit 6 und weniger wird bei jedem Hop dekrementiert. Damit sorgt man bei großen Installationen dafür, dass Pakete nicht alle Linien fluten, sondern nach dem 6 Hop eben nicht mehr weitergereicht werden.

Bei einem Routingzähler von 7 wird nicht dekrementiert und die Reichweite des Paketes wäre länger.

In üblichen Installationen mit wenigen Linien spielt das praktisch keine Rolle, daher ist das trotz der vielen tausend Installationen des eibd bisher nicht oder nur unwesentlich störend in Erscheinung getreten. Dass Dein LK (und ggfls. andere Geräte einen Fehler aufzeigen mag natürlich sein. Korrekt ist es schließlich auch nicht, allerdings auch nicht wirklich eine störende Größe, wenn es nicht im Kreis läuft durch ungeschickte Topologie.

Liegt es an der Kombination von TP-Uart und Linienkoppler?

Nein. Bislang haben wir dazu in den letzten acht Jahren auch keine Klage gehört von Kunden, die alleine darauf zurückzuführen währen.

Lässt sich das Problem mit z. B. einem IP-Interface/-Router beheben?

Nein. Der eibd gibt einen Wert für den Routingzähler vor, der von den Systemgeräten nicht mehr dekrementiert wird. Daran ändern auch nichts, andere Systemgeräte zu verwenden, die verhalten sich gleich. Der eibd sendet die Pakete eben so, egal über welchen LK / BK / Router. Diese ändern normgemäß nichts am RZ.

Wenn es wirklich stört, der Timbverwold Server wird einen zertifizierte KNX Stack enthalten, dieser hat diesen Fehler des eibd nicht mehr.



lg

Stefan

[gbglace]

Hallo


Wenn es wirklich stört, der Timbverwold Server wird einen zertifizierte KNX Stack enthalten, dieser hat diesen Fehler des eibd nicht mehr.

Stefan, sollst Doch nicht in der Nacht Arbeiten, neue Tastenkombinationen sind da dann noch nicht ganz drinnen.

[StefanW]

Ui, was für ein optisch schöner Tippfehler

Richtig, muss die Nachtsessions mal wieder zurückfahren.