UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Beantwortet] [V3.5] erhöhte KNX Buslast durch unbekannten Fehler - Funktionsprobleme

Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
cheater
Reactions:
Beiträge: 610
Registriert: Sa Aug 11, 2018 11:16 pm
Hat sich bedankt: 381 Mal
Danksagung erhalten: 274 Mal

[V3.5] erhöhte KNX Buslast durch unbekannten Fehler - Funktionsprobleme

#1

Beitrag von cheater »

Hallo Leute,
ich bräuchte bitte mal Beistand. Kurz und knapp, da ich eigentlich schon auf der Arbeit sein müsste.

Heute Nacht ist irgendwas passiert auf meinem KNX Bus passiert. Im Busmonitor sehe ich das seitdem viele Telegramme 4-fach aufgezeichnet werden. Timberwolf und Loxone habe ich schon mal neu gestartet.

KNX Taster scheinen zu funktionieren.

Befehle die man mit dem KNX Busmonitor (über die KNX Schnittstelle des TWS) sendet, bewirken auch nichts.

Wo könnte ich noch den Fehler suchen? Evtl. kann Elabnet mal einen kurzen Blick drauf werfen, das wäre sehr nett und ich bin gerade völlig ratlos.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von cheater am Fr Okt 21, 2022 8:38 am, insgesamt 1-mal geändert.
Grüße, Dominic

Timberwolf 2400 #126, VPN offen, Reboot nach Absprache

Ersteller
cheater
Reactions:
Beiträge: 610
Registriert: Sa Aug 11, 2018 11:16 pm
Hat sich bedankt: 381 Mal
Danksagung erhalten: 274 Mal

#2

Beitrag von cheater »

Erster Verdacht, die Wetterstation könnte kaputt sein und stört den Bus!

Die Wetterstation sollte abgeklemmt sein, bin mir gerade aber nicht sicher. Dennoch habe ich weiterhin 4-fach Telegramme auf dem Bus :-(.
Zuletzt geändert von cheater am Fr Okt 21, 2022 8:51 am, insgesamt 1-mal geändert.
Grüße, Dominic

Timberwolf 2400 #126, VPN offen, Reboot nach Absprache

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#3

Beitrag von gbglace »

4-fach Telegramm bedeutet, der Sender des Telegramm bekommt kein ACK und wiederholt daher das Ganze.

Ab 22:16 ist da also irgendetwas kaputt, allerdings finde ich auch die Grundeinstellung, den Messwert alle 30-Sekunfen auf den KNX zu senden mehr als übertrieben. Kein Regler der Welt benötigt so häufig den Messwert, geschweige das er sich so schnell ändert im Heizungssystem. Sich den Messwert in der Zyklizität in eine Timesries zu schreiben kann ja jeder für sich entscheiden, der Mehrwert an Informtionsgewinn bleibt aber auch dort gering. Und im TWS lässt sich das ja getrennt gestalten, oft in die Timesries aber nur selten auf den Bus, das solltest.grundsätzlich Mal korrigieren.

Zur weiteren Analyse Mal bitte auch die weiteren Häkchen im Busmonitor aktivieren.

Welches Gerät müsste denn das ACK senden? Wenn in der gleichen Linie halt ein Taster oder Regler, wenn in einer anderen Linie ggf der LK. Ist ein solcher LK ggf Busy? Was sagen Diagnoseangaben der Spannungsversorgung des Busses?

Wie hoch war die allgemeine Buslast bis 22:16?
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

Ersteller
cheater
Reactions:
Beiträge: 610
Registriert: Sa Aug 11, 2018 11:16 pm
Hat sich bedankt: 381 Mal
Danksagung erhalten: 274 Mal

#4

Beitrag von cheater »

Hallo Göran,
wenn ich ACK im Busmonitor aktiviere wird nichts weiter angezeigt, sonst war alles angehakt. (Ich nutze den 8-fach TP-UART).

Die 1.0.200 ist der Timberwolf selbst. Die 6/1/16 (nur exemplarisch gewählt) ist eigentlich erstmal mit nichts weiter verbunden (höchstens die Loxone fragt den noch ab).

Die Buslast war davor immer so 1.200 bis 1.300 Telegramme.

Edit: Loxone mal vom Bus genommen. Immer noch 4-fach Telegramme.

Spannungsversorgungen hatte ich gecheckt, keine Auffälligkeiten!
Zuletzt geändert von cheater am Fr Okt 21, 2022 9:10 am, insgesamt 2-mal geändert.
Grüße, Dominic

Timberwolf 2400 #126, VPN offen, Reboot nach Absprache

eib-eg
Reactions:
Beiträge: 442
Registriert: Fr Sep 14, 2018 5:03 pm
Hat sich bedankt: 1457 Mal
Danksagung erhalten: 235 Mal

#5

Beitrag von eib-eg »

ich würde in der ETS mal nachschauen wer das ACK senden soll
und den mal versuchen neu über die ETS zu programmiren
hatte bei mir 1998 einen ähnlichen fall
ein versuch ists alle mal wert
TW 2600_99 seit 1.1.2018 / VPN zu

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#6

Beitrag von StefanW »

Hallo Dominik,

Ein Ack wird geschickt von allen Geräten, die mit einem TP-Uart 2 Chip ausgestattet sind, sowie allen Segment und bereichskopplern. Also von allen moderneren Geräten, damit auch vom TWS. Es sollte also am Bus nicht an Acks mangeln.

Ein solches ACK kann man im Bus Monitor nur dann sehen, wenn dieser im Real Bus Monitor Mode arbeitet, was nicht möglich ist, wenn das KNX Interface gleichzeitig auch für die Kommunikation mit dem Bus genutzt wird. Du müsstest also entweder den Applikationsmodus von der KNX Schnittstelle abschalten , wodurch der Server dann nicht mehr mit dem Bus kommuniziert (nur noch aufzeichnet), oder eine zweite Schnittstelle bei uns kaufen und anschließen.

Liebe Grüße
Zuletzt geändert von StefanW am Fr Okt 21, 2022 9:54 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#7

Beitrag von gbglace »

Aha, die GA 6/1/16 hat auf dem TP Medium keinen Empfänger, warum sendet man einen solchen Sensorwert dann auf den Bus und dann auch noch in solcher Telegrammdichte?

Bitte tut sowas nicht. Was nicht auf dem Bus benötigt wird gehört da auch nicht drauf gesendet, der KNX ist gut und stabil aber er ist kein Reservespeichermedium.

1200-1300 in welchem Zeitraum? Tag Stunde Minute?
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

zaphood
Reactions:
Beiträge: 90
Registriert: Sa Mai 14, 2022 10:15 am
Hat sich bedankt: 38 Mal
Danksagung erhalten: 79 Mal

#8

Beitrag von zaphood »

Schau doch mal unter KNX - Physikalische Objekte - und da auf PA Statistiken. Da siehst du links in der Liste, welche Geräte was auf dem Bus treiben, sollte dir die Top Talker zeigen um die du dich ggf. mal näher kümmern kannst?
Timberwolf 3500L #950 - VPN geschlossen - Reboot nach Absprache

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#9

Beitrag von gbglace »

Und diese Statistiken mit Scope auf GA absteigend sortiert, dazu einen Abgleich mit dem ETS Projekt wo es nur einseitig verbundene GA gibt.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#10

Beitrag von StefanW »

Hallo Dominic,

1. Im KNX Standard ist festgelegt, dass jedes Telegramm dreimal zu wiederholen ist (mit dem ersten Aussenden sind es dann vier Telegramme), wenn ein LL_NACK empfangen wird oder KEIN LL_ACK empfangen wird

2. LL_ACK (für LinkLayer_Acknowledge = Bestätigung der Datensicherungsschicht) werden von den Systemgeräten "Linienkoppler" oder "Bereichskoppler" gesendet UND seit einigen Jahren von JEDEM ANDEREN GERÄT in der jeweiligen Linie auf jedes Telegramm gesendet, das vom Buskoppler empfangen wird, soweit das Gerät dazu fähig ist. Das LL_ACK auf jedes empfangende Gerät wird hierbei unabhängig davon gesendet, ob das empfangende Telegramm überhaupt für das eigene Gerät gedacht ist (auswertung von Ziel-PA oder Ziel-GA, weil das passiert erst in höheren Schichten).

3. Ein solches LL_ACK darf nicht vom eigenen Gerät auf eigene Telegramme gesendet werden

4. Der TWS ist ein solches modernes Gerät, das LL_ACK auf jedes Telegramm sendet, das von ihm empfangen wird (unabhängig ob das Telegramm für den TWS "adressiert" ist).

5. Der Auszug aus dem Busmonitor zeigt, dass der TWS jedes Paket viermal sendet. Dies ist dann konform zum KNX Standard, wenn der TWS kein LL-ACK empfangen hat. Es erscheint mir unwahrscheinlich, dass der TWS ohne Probleme an der Buskommunikation teilnimmt, jedoch ausgerechnet LL_ACK nicht erhalten sollte.

6. Der Busmonitor kann diese LL-Telegramme der Sicherungsschicht im Busmonitor nur dann anzeigen, wenn der KNX Busankoppler im "Real-Busmonitor-Mode" befindet. Das geht nur dann, wenn dieser KNX Busankoppler sich nicht gleichzeitig im Applikationsmodus befindet. Wenn man an einem Timberwolf Server "nur" einen KNX Busankoppler angeschlossen hat und diesen auch für die Kommunikation über Gruppenadressen nutzt, dann ist dieser TWS im Applikationsmodus (das ist der betriebliche Standard) und dann befindet sich der KNX Busankoppler nur noch im "Virtual-Busmonitor-Modus" und hierbei werden die LL nicht vom CHip hochgereicht und sind damit nicht im Busmonitor sichtbar. Wenn man LL Pakete messen möchte, dann muss man den Applikationsmodus abschalten bzw. einen weiteren KNX Busankoppler bei uns kaufen.

7. Weitere Interpretationen und Annahmen zu Deinem Problem sind uns nicht möglich, wenn wir die Topologie Deiner Installation nicht kennen. Es wäre also wichtig zu wissen, wie die Linie aufgebaut ist, an welcher der Timberwolf Server installiert ist.


Vorschläge:

A: KNX Busankoppler des TWS vom Bus trennen und wieder anschließen (damit der aus dem KNX Bus versorgte Chip "gebootet" wird)

B: Alle anderen Geräte am Bus einzeln vom Bus trennen und wieder anschließen (und nach jedem Gerät prüfen, wann der Fehler weg ist, damit man das Gerät kennt, welches die ACKs hätte senden sollen und es nicht getan hat).

In einer KNX Linie mit modernen Geräten sollte eigentlich JEDES Gerät ein LL_ACK senden. Ich vermute, dass entweder der Busankoppler vom TWS defekt ist oder es nicht sehr viele moderne Geräte in der gleichen Linie gibt, welche kein ACK mehr senden. Alternativ kann auch ein Gerät zu Busfehlern führen, so dass NACK erzeugt werden.


Wir wünschen viel Glück bei der Fehlersuche


lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Antworten

Zurück zu „KNX“