Analysemöglichkeiten in HA

[henfri]

Hallo,

vorab: Ich weiß dass dies ein sehr großer Feature-Request ist. Aber der Mehrwert ist auch sehr groß, daher möchte ich ihn teilen.

Schritt 1:
HA hat ja die (Möglichkeit) Projektdatei eingelesen und stellt diese auch dar.
Zudem hat HA den Busverkehr. Jetzt wäre es total praktisch, wenn man in der Ansicht der GAs vier zusätzliche Spalten hätte:
- Aktueller Zustand
- Gesetzt durch
- Vorheriger Zustand
- Gesetzt durch

Das bei der Analyse sehr helfen. Noch besser, aber auch mehr Aufwand, da es diese Daten & Ansicht noch nicht gibt:

Schritt 2:
In der Projektdatei gibt es ja auch alle Geräte mit deren KOs und den Verknüpfungen ( meti thewhobox stimmt das, oder wird dafür die knxprod gebraucht)
Man könnte also möglicherweise jedes Gerät mit seinen KOs in HA darstellen und (wie bei Schritt 1) den Zustand darstellen.

Das wäre eigentlich ein Featurewunsch an die ETS. Habe ich auch schon dort geäußert.

[Träummodus]
Schritt 3:
Jetzt könnte man noch einen Slider/Timepicker einführen und schrittweise vor und zurück springen.


Gruß,
Hendrik

[gbglace]

Also in der ETS bringt es ja nur etwas wenn da einer der Monitore permanent läuft. So manches Telegramm gibt es ja nur alle Tage/Wochen/Monate mal. Will man da bei jedem Monitorstart erst einen massiven Rundruf auf dem Bus machen?

Und was ist mit denen Telegrammen die nie am HA vorbeikommen?
Alle Koppler auf Durchzug stellen ist ja auch Murks. Und so manche Aktoren haben dann ggf auch mehrere GA dran verbunden, also ggf auch jene die HA gar nicht sieht.
Und ob ein Telegramm auf einer anderen Linie überhaupt das eine Gerät erreicht hat ist auch nicht klar für HA.
Und was alles via Medium IP geflogen ist, ist auch komplett unklar wo da in der Infrastruktur was fehlen könnte.

Und dann alles was im Medium IP nur über Tunnel verbunden ist und gar keine KO hat und nur via einem Dummy abgebildet ist. Da die Zuordnung IP-Adresse zu Tunnel-PA und Dummy-PA nicht statisch ist nur wenige Interfaces das bieten, ist an der Stelle doch keinerlei valide Aussage zu Quelle/Ziel des Telegramms möglich.

Es ist eben Broadcast und nur weil theoretisch etwas ankommen müsste, bedeutet es ja noch lange nicht, dass es angekommen ist. Und wenn dem so ist, dann gibt es meist auch Fehler den man analysieren will und dann helfen so Tabellen mit Überschrift "das ist der letzte Wert der von da nach da unterwegs war" es real aber nur ein "es könnte das gewesen sein" repräsentiert, auch nicht hilfreich.

[Dampf]

Ein HA Feature request wäre wahrscheinlich an dee passenden Stelle in der HA Community besser platziert.
https://community.home-assistant.io/...re-requests/13

[henfri]

gbglace Gute Punkte.

Dass LK die Diagnose erschweren ist eine Tatsache die sich natürlich nicht ändern lässt - weder in HA noch in der ETS.

Und dann alles was im Medium IP nur über Tunnel verbunden ist und gar keine KO hat und nur via einem Dummy abgebildet ist. Da die Zuordnung IP-Adresse zu Tunnel-PA und Dummy-PA nicht statisch ist nur wenige Interfaces das bieten, ist an der Stelle doch keinerlei valide Aussage zu Quelle/Ziel des Telegramms möglich.

Das habe ich nicht verstanden.

so Tabellen mit Überschrift "das ist der letzte Wert der von da nach da unterwegs war" es real aber nur ein "es könnte das gewesen sein" repräsentiert, auch nicht hilfreich.

Es gibt Fälle in denen sie nicht hilfreich sind.
Aber in der großen Mehrheit der Fälle sind sie hilfreich.

Ich denke, unterschiedliche Personen sind da unterschiedlich geprägt. Wahrscheinlich sehr abhängig davon, was man beruflich macht.
Für mich ist eine 99% Lösung besser als keine. Für andere ist es nur eine Lösung wenn 100% abgedeckt werden.

Dampf dort gehen KNX Feature-Requests vermutlich unter. Selbst wenn nicht, hätte ich wahrscheinlich eine so relevante Antwort wie von gbglace nicht, oder viel später bekommen.
Abhängig vom Feedback hier werde ich den Feature-Request natürlich im passenden Github (knx-frontend (?)) stellen.

Gruß,
Hendrik

[meti]

Schritt 1: gibts bereits. Ohne vorherigen Zustand allerdings - den könnte man über den Monitor nachschauen.
Siehe https://github.com/XKNX/knx-frontend/pull/181

In der Projektdatei gibt es ja auch alle Geräte mit deren KOs und den Verknüpfungen (stimmt das, oder wird dafür die knxprod gebraucht)

Ja. Die Applikationen sind ja im Projekt enthalten. KOs werden ja beim UI-Entity-Konfigurator auch angezeigt.

dort gehen KNX Feature-Requests vermutlich unter.

Hier doch genauso. Dafür gibts GitHub.

[gbglace]

Das habe ich nicht verstanden.

Eine Tunnelverbindung auf den Bus ist meist keine statische Gerätezuordnung. Du kannst also an Hand der im Buslog auftauchenden sendenden PA nicht erkennen wer das Telegramm wirklich gesendet hat. Das könnte jemand mit einer ETS im Gruppenmonitor gewesen sein oder eben der HA oder ein NodeRed oder irgendetwas anderes an Software was sich per Tunneling auf dem Bus verbindet. Man sieht nur es kam via dem einen IP-Interface und einem dortigen Tunnel.

Es gibt nur wenige Interfaces die eine spezifische Zuordnung IP-Adresse zu Tunnel-PA erlauben.


Ansonsten ja bei 99% wäre ich auch schon zufrieden.


Ich komme bisher mit dem 24/7 laufen Monitor und Ringspeicher des TWS sehr gut zurecht. Alles was der TWS selbst direkt mit dem Bus interagiert, hat echte eigene KO in der ETS und ist damit auch sauber im Busmonitor ersichtlich (Aktionen aus Logiken/Visu/MQTT-angebundene Taster usw.).

Und für die Überwachung der anderen Linien hat der TWS jeweils weitere aktive KNX-Interfaces, via denen er auf diesen Linien lauscht und den Busmonitor im Ringspeicher füllt.

[meti]

Eine Tunnelverbindung auf den Bus ist meist keine statische Gerätezuordnung. (...) Es gibt nur wenige Interfaces die eine spezifische Zuordnung IP-Adresse zu Tunnel-PA erlauben.

Die neuen brauchen das auch nicht. Bei IP Secure kann man das ganz einfach über das User-Key-Paar zuordnen. Bei Tunnelling v2 (TCP) gehts auch ganz einfach, dass sich der Client eine Tunneladresse aussucht.
Theoretisch würds auch bei den Alten gehen, aber die Prozedur macht wohl kaum einer.

[gbglace]

Das mit dem Client seitigen Auswählen ist mir da auch suspekt.
Wer sich da dann auf der Clientseite vertippt hat dann Doppelvergaben wo dann das interface entweder auf die nächste freie wechselt oder den ersten gar disconnected?

Für nicht Secure ist es offensichtlich nix was in der ETS wirklich gepflegt wird und somit bleibt es für eine Busanalyse auf Basis der ETS-Daten random.

Ich kannte das feature nur von Enertex und glaube von Arcus

[meti]

Doppelvergaben wo dann das interface entweder auf die nächste freie wechselt oder den ersten gar disconnected?

Weder noch - der Client kann dann einfach nicht connecten wenn der Tunnel schon vergeben ist.

Für nicht Secure ist es offensichtlich nix was in der ETS wirklich gepflegt wird

Du kannst deinen Tunneln ja Namen geben wenn du möchtest. Da nimmt sichs nicht viel ob es Secure oder non-Secure ist.
Das mit den IP Adressen ist im Grunde das Gleiche - die können sich auch unabhängig von ETS ändern.

Aber mal ehrlich - das alles hat ja in der Praxis keine wirkliche Relevanz. Jede IA gibts nur 1x (korrekte Implementierung von Client und Server vorausgesetzt) und die 1-4 Programme die da hin tunneln sollen wird man schon zu identifizieren im Stande sein. Bzw. es schaffen sich da halt nicht zu vertippen wenn man das zum ersten Mal einstellt ... und dann wird das eh in der Regel nie wieder angegriffen.

Ich bin aber jetzt garnicht sicher ob es in HA überhaupt eine Auswahl für den Tunnel bei non-Secure TCP gibt. xknx könnte es auf jeden Fall.

[gbglace]

Im Nodered KNX-Ultimate kann man zwar die Tunnel-PA angeben mit der er sich auf dem KNX zeigen soll ob es aber eine effektive Auswirkung hat entscheidet dann wieder erst die verwendete Schnittstelle. Bei den mir vorliegenden Schnittstellen wird das ignoriert.

[henfri]

Hier doch genauso. Dafür gibts GitHub.

Jetzt hier:
https://github.com/XKNX/knx-integration/discussions/13