NEU! UPGRADE IP 11 verfügbar!
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[V1.6 RC8] Timberwolf schreibt falsche 1-Wire Werte auf den KNX-Bus
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
-
- Reactions:
- Beiträge: 613
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 384 Mal
- Danksagung erhalten: 274 Mal
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:
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:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Grüße, Dominic
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
-
- Reactions:
- Beiträge: 125
- Registriert: Fr Apr 12, 2019 3:04 pm
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 51 Mal
Ich dachte der Graph in Deinem Eingangspost reflektiert die Zeitserie und dort sieht man doch den Einbruch um 04:13:26?!
Gruß Markus
TWS 960Q #360, VPN geschlossen, Reboot verboten
TWS 960Q #360, VPN geschlossen, Reboot verboten
-
- Reactions:
- Beiträge: 613
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 384 Mal
- Danksagung erhalten: 274 Mal
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.
Grüße, Dominic
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
-
- Reactions:
- Beiträge: 901
- Registriert: So Aug 12, 2018 9:12 am
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 240 Mal
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
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt
-
- Reactions:
- Beiträge: 613
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 384 Mal
- Danksagung erhalten: 274 Mal
Stromausfall war nicht, außerdem hängt der Timberwolf an einer USV.
Edit: 0 Werte sind weiter nicht aufgetreten.
Edit: 0 Werte sind weiter nicht aufgetreten.
Zuletzt geändert von cheater am Di Jan 05, 2021 8:55 pm, insgesamt 1-mal geändert.
Grüße, Dominic
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
-
- Elaborated Networks
- Reactions:
- Beiträge: 588
- Registriert: Mi Aug 15, 2018 11:34 am
- Hat sich bedankt: 82 Mal
- Danksagung erhalten: 559 Mal
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:
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:
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.
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
- Schreibauftrag von 1.0.200 (10 C8) an 6/1/11 (31 0B) mit Wert "0D B7"
- Telegramm empfangen von 1.0.250 (10 FA) an 0/7/24 (07 18) mit Wert "00"
- Telegramm empfangen von 1.0.200 (10 C8) an 6/1/11 (31 0B) mit Wert "87 B7"
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
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.
Gruß,
Stefan K.
Stefan K.
-
- Reactions:
- Beiträge: 3614
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1272 Mal
- Danksagung erhalten: 1674 Mal
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.
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
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
-
- Reactions:
- Beiträge: 613
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 384 Mal
- Danksagung erhalten: 274 Mal
@S. Kolbinger
Vielen Dank fürs Nachsehen zu so später Stunde und danke für die Analyse.
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.
Vielen Dank fürs Nachsehen zu so später Stunde und danke für die Analyse.
Das wäre natürlich Top.Aber letztendlich muss sich das ganze unser KNX-Experte nochmal genauer ansehen.
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.
Zuletzt geändert von cheater am Di Jan 05, 2021 9:30 pm, insgesamt 1-mal geändert.
Grüße, Dominic
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
-
- Reactions:
- Beiträge: 901
- Registriert: So Aug 12, 2018 9:12 am
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 240 Mal
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
Zuletzt geändert von Sensej am Di Jan 05, 2021 10:01 pm, insgesamt 1-mal geändert.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt
-
- Elaborated Networks
- Reactions:
- Beiträge: 9775
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7820 Mal
- Kontaktdaten:
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.
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.
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
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.
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.
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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von StefanW am Mi Jan 06, 2021 11:14 am, insgesamt 4-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.
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.