Insider Preview IP 1 zur V 4.8 - veröffentlicht
Verehrte Nutzer des Timberwolf Servers. Wir haben die IP1 zur nächsten Hauptversion 4.8 für alle Modelle des Timberwolf Servers freigegeben.

Diese neue Version enthält eine neue Funktion zum selektiven Löschen von Datenpunkten in ein oder mehreren Zeitserien sowie 16 Verbesserungen und wichtige Fehlerkorrekturen
Insbesondere die neuen Funktionen zum selektiven Löschen in Zeitserien sind sehr wichtig, weil damit erstmals ein Bereinigen sowie ein Kürzen von Zeitserien möglich wird. Damit kann massiv Speicherplatz reduziert werden, womit auch Backup / Restore kürzer wird. Zudem können damit Datenschutzanforderungen umgesetzt werden.
Foren Diskussion: viewtopic.php?t=6070
Release Notes im Wiki: https://elabnet.atlassian.net/wiki/x/AYCEyw
WICHTIG: Dies ist die eine neue Insider Preview im Zyklus 4.8. Mit Installation der letzten Hauptversion 4.5 wurde der Bezug für Insider Versionen zurückgesetzt. Mitglieder im Insider Club müssen daher in der Systemaktualisierung erst den Bezug von Insider Versionen wieder freischalten, damit das Update angezeigt wird.
[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
-
- Beiträge: 716
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 485 Mal
- Danksagung erhalten: 326 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
-
- Beiträge: 716
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 485 Mal
- Danksagung erhalten: 326 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
-
- Beiträge: 918
- Registriert: So Aug 12, 2018 9:12 am
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 251 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
-
- Beiträge: 716
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 485 Mal
- Danksagung erhalten: 326 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
- Beiträge: 588
- Registriert: Mi Aug 15, 2018 11:34 am
- Hat sich bedankt: 82 Mal
- Danksagung erhalten: 560 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.
-
- Beiträge: 4141
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1452 Mal
- Danksagung erhalten: 1943 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
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
-
- Beiträge: 716
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 485 Mal
- Danksagung erhalten: 326 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
-
- Beiträge: 918
- Registriert: So Aug 12, 2018 9:12 am
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 251 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
- Beiträge: 10890
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5368 Mal
- Danksagung erhalten: 9099 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.