ElabNET Technik Forum

Hallo Forum,

ich kann es nicht besser beschreiben. Meine Frau sagte mir gerade, dass die Heizung im Bad (am KNX-Aktor) eingeschaltet sei und der zugehörige Taster aber nicht leuchtet. Also habe ich mal Comet Visu (0.11.0) gestartet, um zu sehen, was denn der digitale Zwilling sagt. Doch CometVisu zeigte nichts an. Ich bin dann in den KNX-Busmonitor gegangen und habe "Additional individual Address" durchrattern sehen (13/x/x, die nutze ich nicht bewusst). So ein "durchrattern" hatte ich wohl schonmal beim Start vom Timberwolf gesehen, also habe ich geschaut, ob er oder ein Prozess neu gestartet wurde, läuft aber alles seit 2 Tagen durch (hab ihn vor 2 Tagen mal vom Strom genommen, also ok). Es ist Mega, wie sehr man da debuggen kann, ich komme allerdings nun nicht drauf, was da passiert sein kann. Hat hier jemand eine Idee? Ich denke, das wird sich nun alles beruhigen und der Fehler verschwinden, ich wäre nur gern schlauer für ein mögliches nächstes Mal.

Was habe ich die letzte Zeit am Timberwolf geändert: Ich habe Modbus/RTU eingerichtet (danke nochmal an alle!) und mir eben im Monitor über sicherlich zwei Stunden etwa 5 Werte angesehen, die jeweils ca. alle 5 Sekunden neu gelesen wurden. Ob das eine Ursache war?

Beste Grüße,
Rolf

Hallo Rolf,

die Adresse die du dort siehst wird wohl die der CV sein. Um das zu verifizieren, schau mal bitte hier (ganz unten auf der Seite findest du eine Tabelle):



Die CV löst Lesetelegramme "r" (Read) aus und sendet diese an den Bus. Aber dort antwortet niemand.

Das sieht danach aus, als hättest du auf dem Aktor deine entsprechenden KNX-Flags nicht korrekt gesetzt.

Beste Grüße
Jens

Hallo Rolf,

Nachtrag: Die 1.1.201 ist die wohl die von der CV vom Wolf bezogene Adresse.
Wenn in der Konfigurationsdatei der CV irgendwo die GA 13/1/1 auftaucht, dann bekommst du auch den Effekt...

Beste Grüße
Jens

Hallo Rolf,

ich habe mir erlaubt, den Betreff des Threads zu ändern, weil ich hier noch kein "seltsames" Verhalten des TWS erkannen kann .

Beste Grüße
Jens

Danke Jens,

womöglich sollte man den Thread dann noch nach KNX verschieben... oder CometVisu.

Diese Lesetelegrammfluten sind typisch für KNX Visualisierungen, wenn diese neu gestartet werden. Wenn dann noch die Flags falsch gesetzt sind kann beides zusammen den Bus auch für längere Zeit so belasten, dass anderes blockiert wird und ggfls. im Timeout der Devices "verschwindet".

[Werbeeinlendung] Das ist übrigens auch ein großer Vorteil mit der Timberwolf VISU, weil diese keine Lesetelegramme verursacht, da alle letzten Werte von jedwedem Subsystem komplett gecached werden (eigentlich schon immer durch den Dispatcher, auch über Reboots hinweg) und bei einem evt. Restart der VISU (damit vor allem bei Neuboot des Servers oder Upgrade der VISU-Software) wird dieser Cache gelesen. Das spart insbesondere beim Start des Servers tausende Lesetelegramme ein.[/Werbeeinlendung]


lg

Stefan

Hi zusammen,

liegt jetzt im KNX-Bereich.

Beste Grüße
Jens

Habt vielen Dank! (Mal wieder). Nun verstehe ich das Verhalten etwas besser. Ja, die 13er Adressen sind noch irgendein Rest, der aber nicht aktiv genutzt wird, den muss ich mal rausnehmen. Wenn CometVisu eine KNX-Flut ausgelöst hat, weil ich da mal wieder mit einem Browser-Tab drauf war, ja, das mag gut möglich sein. Und auch hier in diesem Thread freue ich mich wieder auf die neue Visu, nun aber nochmal mit einem anderen Hintergrund .

Beste Grüße,
Rolf

StefanW hat geschrieben: ↑Mo Okt 16, 2023 12:59 pm Diese Lesetelegrammfluten sind typisch für KNX Visualisierungen, wenn diese neu gestartet werden. Wenn dann noch die Flags falsch gesetzt sind kann beides zusammen den Bus auch für längere Zeit so belasten, dass anderes blockiert wird und ggfls. im Timeout der Devices "verschwindet".

Bei der CometVisu muss man zwischen dem "Backend", also dem Teil auf dem Server, und dem "Client", also das was der Browser anzeigt, trennen.
Das Backend speichert ab dem Start für jede GA den letzten Wert zwischen, der auf dem KNX gesendet wurde. Hier werden keine Lese-Telegramme versendet. Und das ist der Grund warum das Backend auf einem System laufen sollte, dass dauerhaft läuft.
Der Client fragt dann beim Laden (oder ggf. nach einem Timeout, z.B. weil der Rechner schlafen war) beim Backend für alle verwendeten GAs den letzten Wert ab. Alles was das Backend schon kennt wird direkt angezeigt, der Rest wird am Bus gelesen.

Eine "Lesetelegrammflut" kann folglich nur passieren, wenn man den Server frisch startet und sofort die Visu im Browser öffnet. Also eigentlich nur beim Testen.
Im Normalfall läuft der Server schon lange und kennt alles.
Und im seltenen Fall der der Server neu gestartet wurde (z.B. nach einem Stromausfall) lädt der im Hintergrund genüsslich alle Daten, rein durch zuhören, bis das nächste mal die Visu im Browser geöffnet wird.
Außerdem ist so sichergestellt, dass niemals ein veralteter Wert angezeigt wird, z.B. weil der Server vor dem Restart sich einen Wert gemerkt hat, in der Zwischenzeit aber ein neuer am Bus gesendet wurde, den der Server durch seinen Restart nicht mitbekommen hat.

Danke Chris,

meine Anmerkung war nicht (alleine) auf die CV bezogen, danke für die Komplettierung.

lg

Stefan