[FINR] CometVisu - kein KNX-Zugriff

[Jürgen]

Hallo zusammen,

nachdem ich letzte Woche meinen Timberwolf erhalten habe, wurde dieser in den letzten Tagen produktiv gesetzt.
Die Migration vom wiregate auf den Timberwolf hat hervorragend funktioniert - alle Sensoren wurden erkannt, RRDs alle übernommen, etc.

Auch habe ich es geschafft, die Visualisierung im entsprechenden Docker-Container nach der Anleitung zu installieren und die Konfiguration vom wiregate zu übertragen.
Aber die Visualisierung erhält keine Daten vom KNX, auch können keine Daten an den KNX-Bus gesendet werden.
Sollte dies nicht bereits mit dem Container funktionieren?
Fehlt mir hier noch etwas, wenn ich die Anleitung Anleitung CometVisu exakt abgearbeitet habe??

Viele Grüße
Jürgen

[blaubaerli]

Hi Jürgen,

mehr habe ich eigentlich auch nicht gemacht und bin damit zum Ziel gekommen.

Was mir auf die Schnelle einfällt: Hast du eventuell eine Kollision der defaultmäßig in Visu-Container genutzten PA?

Dazu gibt es eine Variable die du über die Portainer-Oberfläche anpassen kannst. Ich weiß nicht woher die Defaultmäßige kommt, kann natürlich auch sein, dass solche Themen womöglich durch schlaue Automatismen verhindert werden und man da gar nichts machen muss.

Gruß
Jens

[StefanW]

Es gibt wohl noch bei einigen das Problem, dass der eibd im Docker Container (manchmal) nicht mit dem IP-Tunnel unseres KNX-Stacks spricht.

Das ist ein Problem mit dem Treiber der Netzwerkkarte und dem macVlan im Docker. Wir arbeiten daran.

Workaround: Wenn eine andere IP-Schnittstelle (z.b. ein WireGate Server) verfügbar sind, dann den lokalen eibd darauf umstellen


lg

Stefan

[Chris M.]

Grundsätzlich ist die Anleitung vollständig und auf aktuellem Stand, Fehler sind mir aktuell auch keine bekannt.

Was mir auf die Schnelle einfällt: Hast du eventuell eine Kollision der defaultmäßig in Visu-Container genutzten PA?

Dazu gibt es eine Variable die du über die Portainer-Oberfläche anpassen kannst. Ich weiß nicht woher die Defaultmäßige kommt, kann natürlich auch sein, dass solche Themen womöglich durch schlaue Automatismen verhindert werden und man da gar nichts machen muss.

Das kann grundsätzlich sein. Die Default-PA (1.1.238) ist reiner Zufall und bewusst etwas größer um die Wahrscheinlichkeit einer Kollision zu verringern.
Ich werde das Handbuch entsprechend anpassen, da richtig ist, dass dort momentan nicht steht, dass dieser Wert auf die eigenen Bedürfnisse hin anzupassen ist.
(Meine Vermutung ist allerdings, dass auch eine Kollision zwar nicht konform, aber trotzdem erst mal unproblematisch ist)

Was ich mir eher vorstellen kann, ist, dass der knxd des Containers nicht auf die KNX-Schnittstelle des Timberwolfs kommt. Hierzu wird eine Verbindung zur "iptn:172.17.0.1:3700" aufgebaut.
=> @Jürgen: Stellt der Timberwolf unter dieser Adresse sein Interface bereit?
Bzw. welchen Timberwolf hast Du (2500 oder nur 2400?)? Wie ist dieser an den KNX angeschlossen?

[Jürgen]

Hallo Chris,
Hallo Stefan,

erst mal danke für die Lösungsansätze.

Der Timberwolf ist ein 2600, dieser ist über die integrierte KNX-Schnittstelle an den Bus angebunden.
Der TW befindet sich in der Linie 1.0 und hat die physikalischen Adressen 1.0.10 - 1.0.35 zugewiesen bekommen.
Die PA 1.1.238 ist im gesamten Bus nicht verwendet.
Von daher schließt sich eine Kollision aus.
Kann es sein, dass ich diese Adresse auf eine der Linie 1.0 umstellen muss??
Wo ist das möglich?

Wie kann ich feststellen, ob der TW unter der 172.17.0.1:3700 sein Interface bereitstellt??
Port 3700 ist eingestellt:


Ping an 172.17.0.1 hat funktioniert, aber ein anderer Server antwortet:


Die ETS stellt den Timberwolf auch als Schnittstelle dar, programmieren darüber funktioniert.
Adresse ist hier 192.168.255.235:3700
Muss ich hier vielleicht den knxd an die IP 192.168.255.235:3700 verweisen?
Wenn ja, wie?

Es stehen als alternative Schnittstellen noch ein IP-Router sowie das wiregate zur Verfügung. Wie kann ich den knxd darauf umstellen?

Vielen Dank schon mal für die Ansätze
Jürgen

[blaubaerli]

Hallo Jürgen,

ich vermute, dass das mit der PA aus der Linie 1.0 zwingend ist. Wie von mir angedeutet, geh mal in die Portainer-Admin-Oberfläche, editiere die Settings vom Visu-Container. Dort gehst du unten auf die Registerzunge ENV. Darin editierst du den Eintrag „KNX_PA“ und trägst hinten als Value eine freie Adresse aus deiner Linie ein. Danach den Container einfach mal neu deployen. Fertig.

Gruß

Jens

[Chris M.]

2600 sollte wie 2500 funktionieren, d.h. mit den internen Tunneln sollte das schon gehen. (Ich hätte mehr Sorge beim 2400).

Ich bin jetzt kein KNX Spek Profi - aber kann es sein, dass es die 1.0.xxx gar nicht als Linie zur freien Verwendung geben darf? Die "0" war da immer für irgend was wichtiges reserviert...
Wie auf https://www.cometvisu.org/CometVisu/de/ ... nvironment dokumentiert, muss der Parameter KNX_PA halt nun auf irgend etwas 1.0.xxx (z.B. 1.0.238) gestellt werden was noch frei ist, dann wäre dieses Thema sauber (außer s.o.)

Der Port 3700 passt schon mal, dann das ist der, der bei Dir horcht.

Die IP 172.17.0.1 ist nun die, die der Docker-Server als Gateway im Netzwerk bereit stellt. Wenn Du da nichts verstellt hast, dann wird die auch passen.

[gbglace]

Die 0 in einer PA ist nur in der letzten Stelle reserviert für die Koppler in die nächst höhere Ebene. 1.1.0 Linien Koppler in die Hauptlinie mit 1.0.x und 1.0.0 als Koppler in die Bereichslinie.

Das passt schon so eine PA einem KNX-Device ungleich Koppler / Router zu vergeben.

[Jürgen]

Hallo zusammen,

ich habe nun der Reihe nach die Einstellungen geprüft:

1. Netzwerke:

Hier sind nach wie vor die Standard-Einstellungen drin. Sollte daher passen.

2. physikalische Adresse:
Die physikalische Adresse habe ich wie in der Anleitung genannt (danke dafür, ich habe nur die für den Timberwolf gelesen) geändert auf eine freie Adresse der Linie des Timberwolf geändert.

Danach habe ich den Container neu deployed.

Damit sollte dies auch passen. Die Adresse 1.0.62 ist bisher nicht belegt.
Beim folgenden Test habe ich in der ETS festgestellt, dass der Timberwolf nun sehr wohl auf den KNX schreibt. Allerdings mit einer der Adressen, die ich dem Timberwolf zugewiesen habe.


Folglich ist das Problem, soweit ich es erkennen kann, dass die Visualisierung keine Werte vom KNX lesen kann bzw. die Buskommunikation nicht mitbekommt.
Denn ein Switch-Element sendet immer nur aus, statt abwechselnd ein und aus-Befehle, wie das ganze programmiert ist.
Hier noch ein Ausschnitt aus der Konfig-Datei der Visualisierung, der diese Steckdose schaltet:

3011:           <switch mapping="OnOff" styling="GreyGreen">
3012:             <layout colspan="4"/>
3013:             <label><icon name="message_socket"/>Kniestock Mitte (13.8 sw)</label>
3014:             <address transform="DPT:1.001">5/3/15</address>
3015:             <address transform="DPT:1.001" mode="read">5/3/16</address>
3016:           </switch>

Welche Lösungsansätze gibt es hier noch?
Viele Grüße
Jürgen

[gbglace]

Hilft Dir sicher nicht bei Deinem Problem aber hast auch das ETS Projekt sauber in den TWS geladen? Unter Quellname hätte ich da ja jetzt auch irgendwie "TWS-Tunnel xy" statt "-" erwartet. Oder hast das in der ETS nicht gepflegt?