ETS 6.3: Keine Rückmeldungen von der Außenlinie

[CarstenF]

Hallo liebe Leute,

zuerst der Überblick:

• Die Visu (Home Assistant, easyKNX) ist über ein IP-Interface auf der Hauptlinie,
• ein Schaltaktor für die Beleuchtung ist ebenfalls auf der Hauptlinie,
• ein weiterer Schaltaktor ist über einen Linienkoppler auf der Außenlinie.

Topologie:
grafik.png

In der ETS 6.3 habe ich für jede Lampe zwei Gruppenadressen angelegt (Schalten und Rückmeldung) und diese dem passenden Kommunikationsobjekt des Schaltaktors zugeordnet. Geschaltet wird über die Visu. Für den Schaltaktor auf der Hauptlinie funktioniert das auch einwandfrei einschließlich der Rückmeldungen.

Aber nicht auf der Außenlinie.

Ich befinde mich vermutlich in der Situation, die in der ETS 6 Dokumentation im Kapitel "Übersicht über Filtertabellen und bewährte Praktiken für eine effektive Visualisierung" geschildert wird.

Dort wird auch die Lösung genannt: "Bus-Schnittstellen verwenden".
Weil mein IP Interface (Weinzierl KNX IP BAOS 777) es ermöglicht, Räume anzulegen, für die dann Kommunikationsobjekte bereitstehen, habe ich die beiden Gruppenadressen einer jeden Lampe dort entsprechend zugeordnet. Das Topologie-Bild oben zeigt das auch.

Dies sollte gemäß des o. g. Artikels die ETS dazu veranlassen, die passende Filtertabelle für den LK zu erstellen.
Und tatsächlich: Das Ein- und Ausschalten klappt nun, d. h. die Schaltbefehle passieren den Linienkoppler wie gewünscht.

Aber ich bekomme von der Außenlinie keine Rückmeldungen zurück.

Woran kann das liegen?

Beim Vergleich mit der funktionierenden Hauptlinie kann ich keinen Hinweis auf den Fehler finden.


Am Rande hätte ich auch noch zwei weitere Fragen:

• Warum hat mein IP-Interface mehrere physikalische Adressen?
• Warum hat ein Linienkoppler nicht zwei physikalische Adressen: Eine auf der Haupt- und eine auf der Nebenlinie?

Viele Grüße
Carsten

[Klaus Gütter]

Hallo Carsten,

Wenn du die Geräteinfo "mit Gruppenadressen" des Linienkopplers ausliest, ist da die Rückmeldeadresse in der Filtertabelle enthalten?

> Warum hat mein IP-Interface mehrere physikalische Adressen?
Es können sich mehrere Clients gleichzeitig verbinden, jeder muss dabei eine eigene Tunnel-Adresse bekommen

> Warum hat ein Linienkoppler nicht zwei physikalische Adressen: Eine auf der Haupt- und eine auf der Nebenlinie?
Warum sollte er, ist doch nur ein Gerät (ein Management-Server)

Gruß, Klaus

[CarstenF]

Hallo Klaus,

Wenn du die Geräteinfo "mit Gruppenadressen" des Linienkopplers ausliest, ist da die Rückmeldeadresse in der Filtertabelle enthalten?

Nein, da steht nur die Schaltadresse 1/0/0, aber nicht die Rückmeldeadresse 1/1/0.

Was natürlich die Frage aufwirft, warum sie dort fehlt? Ich habe sie nämlich dem Status-Kommunikationsobjekt des Schaltaktors auf der Außenlinie und dem IP-Interface auf der Hauptlinie analog zugeordnet wie bei den Zwillingen auf der Hauptlinie (ist nur als Analogie zu verstehen, es gibt mit den "Zwillingen" keine Überschneidungen bzgl. Gruppenadressen o. ä.).

> Warum hat mein IP-Interface mehrere physikalische Adressen?

Es können sich mehrere Clients gleichzeitig verbinden, jeder muss dabei eine eigene Tunnel-Adresse bekommen

Mit Clients meinst du jetzt den Home Assistant, easyKNX und jedes weitere "Programm", das unabhängig von den anderen per IP auf den Bus will?
Falls ja, sucht die IP-Schnittstelle dann unter den vorhandenen physikalischen Adresse immer dyamisch eine aus für jede IP-Verbingung, die zugreifen möchte?

> Warum hat ein Linienkoppler nicht zwei physikalische Adressen: Eine auf der Haupt- und eine auf der Nebenlinie?

Warum sollte er, ist doch nur ein Gerät (ein Management-Server)

Ich stelle mir das vor wie einen IP-Router. Da geht ja auch eine Schnittstelle in das eine Netz, eine Schnittstelle in das andere Netz, und jede hat eine zum jeweiligen Netz passende IP, unter der sie erreichbar ist. Der Router setzt dann zwischen beiden um.

Wenn ein Linienkoppler nur die eine physikalische Adresse hat, wirkt das in diesem Bild auf mich, als würde man von der Hauptlinie den Koppler über die Addresse erreichen, die er auf der Nebenlinie hat. Deswegen versuche ich gerade, im Kopf das tatsächlich richtige Bild/Modell von der Situation zu entwickeln...

Viele Grüße
Carsten

[Klaus Gütter]

Was natürlich die Frage aufwirft, warum sie dort fehlt?

Hast du denn den Linienkoppler danach auch neu programmiert?

Falls ja, sucht die IP-Schnittstelle dann unter den vorhandenen physikalischen Adresse immer dyamisch eine aus für jede IP-Verbingung, die zugreifen möchte?

Der Client kann entweder einen bestimmten Tunnel anfordern oder die Auswahl der Schnittstelle überlassen, wenn es ihm egal ist.

wirkt das in diesem Bild auf mich, als würde man von der Hauptlinie den Koppler über die Addresse erreichen, die er auf der Nebenlinie hat.

Ja, genau so ist es auch. Der Koppler sitzt topologisch auf der Unterlinie.

[CarstenF]

Hast du denn den Linienkoppler danach auch neu programmiert?

Jepp, hatte ich. (Man kann sich doch darauf verlassen, dass wenn alle grünen Häkchen da sind, nichts neu zu programmieren ist?)

Jetzt habe ich sicherheitshalber folgendes gemacht:
1. "Vorschau Filtertabelle" aufgerufen --> beide Gruppen, Schalt- und Rückmelde-Gruppe, stehen drin.
2. Nochmals das Programmieren des Applikationsprogramms aufgerufen.
3. Danach nochmal "Geräteinfo mit Gruppenkommunikation" ausgelesen.

In letzterer steht, genau wie zuvor, nur die Schalt-, aber nicht die Rückmeldegruppe drin.
In der Vorschau der Filtertabelle stehen aber weiterhin beide ... 🤔

Der Client kann entweder einen bestimmten Tunnel anfordern oder die Auswahl der Schnittstelle überlassen, wenn es ihm egal ist.

Alles klar, diesen Punkt habe ich schonmal kapiert. Danke! :-)

Ja, genau so ist es auch. Der Koppler sitzt topologisch auf der Unterlinie.

Aber wie? Die Hauptlinie "endet" ja erstmal am Eingang des Kopplers. Von dort kommt man ja nur auf die Unterlinie, wenn der Koppler aktiv etwas dafür tut, also das Telegramm von der Hauptlinie dort neu auflegt.
Wenn der Koppler auf der Unterlinie sitzt, hört sich das wie ein Henne-Ei-Problem an: Von der Hauptlinie erreicht man den Koppler nur, nachdem dieser zuerst das Telegram von der Hauptlinie gelesen hat, auf der Unterlinie neu aufgespielt hat und dann (bildhaft gesprochen in einem anderen Hardware-Abschnitt, quasi der Management-Teil) sein eigenes Telegram wieder empfängt?

[Punker Deluxe]

SUFU Dummy...

Also Klaus Gütter so hab ich es hier im Forum gelernt das man so Filtertabellen anlegt und nicht über irgendwelche Sonderlocken direkt im IP Interface??? Hab ich was verpasst?

[CarstenF]

Guten Morgen,

das man so Filtertabellen anlegt und nicht über irgendwelche Sonderlocken direkt im IP Interface???

Das Problem ist, dass genau das ab der ETS 6.3 nicht mehr zu gehen scheint, siehe ETS 6 Dokumentation im Kapitel "Übersicht über Filtertabellen und bewährte Praktiken für eine effektive Visualisierung"

Dort wird zwar eine weitere Alternative mit Dummy Geräten genannt, aber ich würde gerne gleich lernen und anwenden, wie der zukünftig richtige Weg funktioniert.

Viele Grüße
Carsten

[CarstenF]

Ohhh!
Ein Update: Ich sehe gerade, dass ich plötzlich doch Rückmeldungen bekomme. Genaueres kann ich aber erst später sagen. Jedenfalls hat sich seit meiner letzten Meldung über Nacht eigentlich gar nichts mehr verändert …

[Klaus Gütter]

SUFU Dummy...

Also Klaus Gütter so hab ich es hier im Forum gelernt das man so Filtertabellen anlegt und nicht über irgendwelche Sonderlocken direkt im IP Interface??? Hab ich was verpasst?

Das eigentliche Problem ist ja, dass Gruppenadressen von einem Gerät/einer Software konsumiert werden, die nicht als ETS-Gerät (mit Kommunikationsobjekten) konfiguriert wird. Diese Software muss ja über irgendeine Schnittstelle (IP oder USB) auf den Bus kommen und benutzt dann deren phys. Adresse.
Bei modernen Schnittstellen-Produktdaten sind diese Tunneladressen (jetzt mal beispielhaft im Fall von IP) explizit modelliert und stehen zur Verlinkung der benutzten Gruppenadressen direkt zur Verfügung.

Einen Dummy braucht man nur, wenn die Schnittstellen-Produktdaten das nicht hergeben. Ansonsten ist die Lösung über diese sogenannten "BusInterfaces" besser weil ein Dummy zwangsweise eine falsche phys. Adresse hätte (die richtige ist ja schon von der Tunnelingadresse belegt) und damit:

• die Anzeige der Quelle im Monitor nicht stimmt
• das mit KNX Data Security nicht kompatibel ist.

[CarstenF]

Klaus Gütter, vielen Dank für deine Erläuterungen. Habe schon wieder viel gelernt.

Trotzdem noch Folgefragen:

Wie oben schon passiert, ist es reproduzierbar, dass die ETS Vorschau auf die Filtertabelle etwas anderes anzeigt als die – nach dem Programmieren – aus dem LK zurückgelesene Info inkl. Gruppenkommunikation. Dazu zwei Screenshot aus der ETS anbei (html kann man hier im Forum leider nicht anhängen). Beim MDT Support habe ich schon gefragt. Dort hat man bestätigt, das zwei Gruppenadressen zu fehlen scheinen, mich aber ansonsten freundlich an die KNX.org verwiesen.

• Weiß jemand, wie? Bzw. an wen man sich am besten wenden muss?
• Hast du / habt ihr eine Idee?

Hier die Vorschau:
grafik.png

Und hier die zurückgelesenen Werte:
grafik.png

[Klaus Gütter]

ETS 6.3.1? Wenn ja, bitte Ticket auf support.knx.org aufmachen.