[V1.6 RC8] Timberwolf schreibt falsche 1-Wire Werte auf den KNX-Bus

[cheater]

Der Wert in Der Timeseries ist identisch zu den anderen vorherigen und nachfolgenden. Also die Linie läuft durch.

Wenn man den Graph zur Table umfunktioniert sieht das so aus:
2021-01-05 04:15:56 29.25
2021-01-05 04:14:43 29.25
2021-01-05 04:13:26 29.25
2021-01-05 04:12:25 29.25

Und hier noch der Buslog:

[Marinux]

Ich dachte der Graph in Deinem Eingangspost reflektiert die Zeitserie und dort sieht man doch den Einbruch um 04:13:26?!

[cheater]

Achtung Verwchslungsgefahr. Im Eingangspost das ist der Grafana Graph für die KNX Werte und nicht der für die Timeseries. Aber Stefan ist ja Profi, dem ist das bewusst.

[Sensej]

Achtung Verwchslungsgefahr. Im Eingangspost das ist der Grafana Graph für die KNX Werte und nicht der für die Timeseries. Aber Stefan ist ja Profi, dem ist das bewusst.

so was(0 Werte) hätte ich beim Stromausfall.
Prüfe, ob der 0 Wert um gleiche Zeit bei den anderen Sensoren vorhanden ist bzw. in die Timeserie geschrieben wurde.

MfG Juri

[cheater]

Stromausfall war nicht, außerdem hängt der Timberwolf an einer USV.

Edit: 0 Werte sind weiter nicht aufgetreten.

[S. Kolbinger]

Hi Dominic,

ich hatte mich gerade auf deinem TWS126 eingeloggt und mir die Log-Dateien des KNX-Stacks angesehen.
Ich bin hier zwar nicht der KNX-Experte, aber es deutet für mich auf eine unerkannte Kollision am KNX-Bus hin:

Hier der Ausschnitt aus den Log:

Code: Alles auswählen

05.01.2021 04:13:26 Tracer-level 2 (TPUART (2+)): Write (raw)(011) -> BC 10 C8 31 0B E3 00 80 0D B7 78
05.01.2021 04:13:26 Tracer-level 2 (TPUART (2+)): Recv Busmonitor(010) -> BC 10 FA 07 18 E2 00 80 00 D4
05.01.2021 04:13:26 Tracer-level 2 (TPUART (2+)): Recv Busmonitor(011) -> BC 10 C8 31 0B E3 00 80 87 B7 F2

1. Schreibauftrag von 1.0.200 (10 C8) an 6/1/11 (31 0B) mit Wert "0D B7"
2. Telegramm empfangen von 1.0.250 (10 FA) an 0/7/24 (07 18) mit Wert "00"
3. Telegramm empfangen von 1.0.200 (10 C8) an 6/1/11 (31 0B) mit Wert "87 B7"

Eigentlich sollte die 3.Zeile das Bus-Echo zum Sendeauftrag der 1.Zeile sein.
Aber wie man sieht, entspricht der empfangene Wert (87 B7) nicht dem gesendeten (0D B7).
Was hier außerdem auffällt ist, dass sich das Telegramm von 1.0.250 (Loxone Miniserver) zwischen dem Sendeauftrag und Bus-Echo geschoben hat.

Zum Vergleich hierzu der letzte fehlerfreie Sendeauftrag davor:

Code: Alles auswählen

05.01.2021 04:12:25 Tracer-level 2 (TPUART (2+)): Recv Busmonitor(010) -> BC 10 FA 07 18 E2 00 80 00 D4
05.01.2021 04:12:25 Tracer-level 2 (TPUART (2+)): Write (raw)(011) -> BC 10 C8 31 0B E3 00 80 0D B7 78
05.01.2021 04:12:25 Tracer-level 2 (TPUART (2+)): Recv Busmonitor(011) -> BC 10 C8 31 0B E3 00 80 0D B7 78

Eventuell ein Hardware-Fehler in der KNX-Schnittstelle, entweder bei uns oder beim MIniserver.
Aber letztendlich muss sich das ganze unser KNX-Experte nochmal genauer ansehen.

@cheater Bitte eine wachsames Auge darauf haben und melden, falls das nochmals auftreten sollte.

[gbglace]

Ohne hier Polemik verbreiten zu wollen, das Telegramm von der grünen Wunderkiste ist mir auch direkt aufgefallen. Und da diese grüne Kiste die Sauberkeit der KNX-Standardimplementierung nicht so ernst nimmt ist ja allgemein bekannt, da denke ich mal das Ding ist da nicht ganz unschuldig. Programmierversuche des Busses bei laufender Loxone-Box führt immer mal wieder zu Abbrüchen des Selbigen. Entsprechende Beiträge im KNX-UF erscheinen dazu auch in gewisser Regelmäßigkeit, in den letzten 14 Tagen war da auch wieder einer frisch rein gekommen.

[cheater]

@S. Kolbinger
Vielen Dank fürs Nachsehen zu so später Stunde und danke für die Analyse.

Aber letztendlich muss sich das ganze unser KNX-Experte nochmal genauer ansehen.

Das wäre natürlich Top.

Ich gebe mein Bestes das weiter zu beobachten, aber diese Fehler werden sich gut verstecken. Zoomt man ein bisschen raus in Grafana werden sie schon nicht mehr angezeigt.

@gbglace
Ja das ist mir durchaus bekannt. Aber bisher hatte ich mit dem Grünen beim Programmieren nie Problemme. Die vertragen sich hier alle ziemlich gut.

[Sensej]

Zoomt man ein bisschen raus in Grafana werden sie schon nicht mehr angezeigt.

Ich überprüfe auch manchmal die Protokollierung auf verdächtige Werte.
Da nehme ich als Zeitraum das ganze Jahr.
Bei diesem Zeitraum sieht man alle Ausreißer

MfG Juri

[StefanW]

Hallo zusammen,

die vielfältigen Probleme mit dem grünen kleinen Server hinsichtlich KNX sind allgemein und schon seit fast einem Jahrzehnt bekannt.


Ich habe Bilder gemacht von dem Inneren eines kleinen grünen Servers der Generation 1 mit KNX-Schnittstelle

Die Bauelemente, die nach erstem Anschein für KNX zuständig sind, habe ich rot markiert.

2021-01-06_Lox-KNX_Vorderseite.jpg

2021-01-06_Lox-KNX_Unterseite.jpg

Interessanter ist, was man nicht sieht: Eben keinen der üblichen zertifizierten KNX Chips.

Technisch ist das ein Bitbang-Interface das komplett vom einzigen Hauptprozessor (ein relativ schwacher Atmel mit einem ARM Kern, geschätzt 1/80 der Leistungskraft eines Timberwolf Servers Hutschiene) bedient wird. Dieser eine Prozessor führt das Busprotokoll mit allen Schichten ab dem Link Layer selbst aus. Das ist der selbe eine Prozessor und die selbe Firmware, die auch alle anderen Prozesse und Abfragen im System steuern muss. Wenn die Software während eines KNX Telegramms womöglich nur mal ein paar µs aufgehalten wird (weil auch Abfragen der IOs, Lesen / Schreiben auf SD-Karte, Kommunikation mit den 30 Extensions, Netzwerktelegramme usw. ausgeführt werden müssen) dann könnte man sich unter Umständen vorstellen, dass das mit dem Timing schonmal - hust - eventuell schief geht.


Wie ist das beim Timberwolf Server gelöst?

1. Wir verwenden einen zugelassen, zertifizierten KNX Chip in der Referenzschaltung von Infineon / Siemens.

2. Obwohl dieser KNX Chip schon ganz alleine das ganze Low-Level Protokoll selbständig handelt, haben wir noch einen eigenen CoProzessor zwischen Stack und diesen Chip geschaltet, damit das Handling der PAs und die Ansteuerung des Chips unabhängig von der Haupt-CPU auch in Echtzeit erfolgt.

3. Auf dem Hauptprozessor des TWS mit seinen vier Kernen läuft dann der KNX Stack, der - weil es vier Kerne sind - ungebremst laufen kann, weil sich die gesamte Last des Servers - ohnehin verringert durch KNX Chip und CoProzessor (solche CoProzessoren haben wir auch bei DMX und 1-Wire) - gleichmäßig auf die vier Kerne verteilen kann. Da blockiert nichts mehr.

==> Alles drei, die Hardware, CoProzessor und Stack wurden im zertifizierten KNX Labor (bei DIAL) überprüft und zertifiziert.

Die Bewertung, welche der beiden Lösungskonzepte nun das die technisch bessere ist, überlasse ich Euch.

Aber letztendlich muss sich das ganze unser KNX-Experte nochmal genauer ansehen.

Das wäre natürlich Top.

Wir werden das intern noch besprechen. Meine Neigung, meine Spezialisten für kalkulatorisch 1000 bis 2000 EUR die Sache untersuchen zu lassen, nur um Herauszufinden was wir schon über den kleinen grünen Server wissen, ist nicht sehr ausgeprägt.

Ich denke, wir sollten mit Hochdruck an den wichtigen Themen arbeiten.

Ein Hinweis noch: Der Busmonitor zeichnet nicht auf, was der Timberwolf Server zum Chip gesendet hat, sondern was der KNX-Chip auf dem TP-empfangen hat.


lg

Stefan