WERBUNG: Erfahrungsbericht Timberwolf Server 950Q

[gbglace]

Eine Datenbevorratung der letzten 3 Jahre halte ich für ausreichend.

Das denke ich auch. Ausnahme der Mensch mit reichlich Datenfetischismus gesegnet.

Noch sind wir ja auch nicht soweit das wir alle unsere Jahrzenhnte an Telegrammen per KI im Zusammenhang mit weiteren Datensammlungen auswerten. Wenn wir das dann zur Verfügung haben sollten dann wird es nochmal richtig spannend, weil man dann noch mehr in Richtung smart-home und nicht nur relativ einfaches Wenn-Dann abarbeiten kommt.

[ewfwd]

Eine normale (mechanische) HDD ist genau genommen ebenso ungeeignet für Archivierung, wie ein Flash-Speicher.

Sie ist besser dafür geeignet, vorallem weil Flash auch ein Problem mit der "Haltbarkeit" der Daten hat über lange Zeiten ohne Strom. Eine einzelne HDD ist nicht ideal, dennoch ist die Warscheinlichkeit höher dass du aus dieser noch deine Daten heraus bekommst bei einem Defekt als bei diesen Flashzellen.
Je nach Fehlerart ist das bei ner HDD relativ simpel für das Labor. Und bei der Frage nach Archivierung spielt in meinen Augen es eben auch ne Rolle ob und wie du auch deine Daten noch aus der defekten SSD/SD/HDD herausbekommst.

Ideal wäre natürlich eine Art Speicher der nur einmal beschrieben werden kann. Flashspeicher würde ich nicht blind mehr vertrauen als einer HDD nur weil man keine beweglichen Teile mehr hat. Nen Backup brauchste bei Flash genauso.
Von daher find ich es eher wenig ideal wenn man nun die ganzen Daten der letzten 5Jahre auf ner SD Karte aufzeichnet und dort lässt. Kommt aber auch drauf an wie wichtig sind einem die aufgezeichneten Daten nun.
Aber rumzujammern dass Daten wegwären wenn der Server crasht oder neu aufgesetzt werden muss, aber einer SD Karte vertrauen können finde ich etwas merkwürdig.

[Gast1961]

Der Spruch passt sehr gut zum TWS. Irgendwie scheinen die Nutzer eine ganz besondere Sicht auf die Welt zu haben.

[773H]

Ich wohne jetzt fast 18 Jahre in meinem smarthome und ich habe die letzten 16 Jahre keinen Busmonitor mehr gebraucht.

Genau das ist der Knackpunkt fuer alle, die sich im Bereich Jahr 0 bis Jahr 2(...) nach Erstbezug befinden. Und damit sind wir auch wieder beim hiesigen Hauptproblem hier: natuerlich gibt es massenweise etablierte Projekte, die auch ohne TWS auskommen und Nutzer, die mit seiner Menge an Faehigkeiten nichts anzufangen wissen, da ja alles (irgenwie) schon seit Jahren laeuft. Aber es gibt sicherlich sehr viele neue Projekte, die sich fertigentwickeln / optimiert werden muessen und fuer die ist halt doch sehr grosser Bedarf an sehr effektiv analysierbaren Bustelegrammen!

Speziell hier in dieser TWS-Diskussion faellt mir immer wieder das Zitat ein: "Der Horizont vieler Menschen ein Kreis mit dem Radius null - und den nennen sie dann ihren Standpunkt"
Ich weiss gar nicht, warum ...

Gruss
Stephan

[Dragonos2000]

Eine normale (mechanische) HDD ist genau genommen ebenso ungeeignet für Archivierung, wie ein Flash-Speicher. Wenn es wirklich um richtige Archivierung geht, musst Du Dir erstmal Gedanken machen, vor welchen Szenarien Du Dich schützen willst, um welche Datenmengen-/typ (Klassifizierung) und welchen zeitlichen Horizont es geht. Danach triffst Du dann die Entscheidung zur Technologie. Aber das geht jetzt hier am Thema vorbei.
Einigen wir und darauf, dass Daten auf internem Speicher (egal welcher) einem höheren Verlustrisiko unterliegen, als auf externen Medien...

[ewfwd]

Das gilt nur für mehrmaliges Beschreiben ein und derselben Speicherbereiche. Die Daten werden hier aber nur alle 3 - 20 Jahre überschrieben.

So oder so gehen SD Karten irgendwann kaputt. Es muss nicht nur ein totgeschriebener Block sein. Seine ganzen Archivdaten auf einer SD Karte zu haben und darauf zu hoffen dass diese nicht von heute auf morgen einfach mal nicht mehr will empfinde ich schon eher als riskant.
Als Archiv ist ne HDD (besser mehrere) nach wie vor das beste Medium in meinen Augen. Da kann im Worst Case selbst nen Datenrettungslabor noch Dinge von auslesen. Bei Flash ist das in der Regel einiges schwieriger vorallem auch weil spezielle Algos zum Einsatz kommen welche Bytes wohin geschrieben werden. Ergo sind deine Daten dann mal gern verteilt über zig Flash Chips und wollen wieder zusammengesetzt werden. Hinzu kommt dann oft auch nochmal die interne Verschlüsselung. Sprich den internen Key musste dann auch mit auslesen und das ganze wird meist vom hersteller ja grade so gebaut dass genau dies maximal schwierig bis unmöglich ist.
Aber zumindest Verschlüsselung auf Hardwareebene ist bei SD Karten noch kein Thema. Würde dennoch eine SD Karte nur als temporären Speicher sehen wo nur Daten drauf sind mit dessen Verlust man leben kann.

[evolution]

Eine SD Karte ist da aber alles andere als ein ideales Ziel, die sind zu schnell kaputt geschrieben.

Das gilt nur für mehrmaliges Beschreiben ein und derselben Speicherbereiche. Die Daten werden hier aber nur alle 3 - 20 Jahre überschrieben.

[evolution]

Welche Zeiträume siehst Du als sinnvoll?

Eine Datenbevorratung der letzten 3 Jahre halte ich für ausreichend.

[Jockel]

Deswegen halte ich nichts von Loggingdaten, die lokal auf einem Rechner (hier TWS) abgelegt sind. Hier ist ein separates Speichermedium, das unabhängig vom Gesamtsystem ist, immer die bessere Wahl.

Eine SD Karte ist da aber alles andere als ein ideales Ziel, die sind zu schnell kaputt geschrieben. Wenn man die Daten lange verfügbar haben will kommt man um ein Backup nicht herum, egal wo sie gespeichert sind.

Gegenüber der ETS hat der TW den Vorteil, dass er eben ständig aufzeichnet und nicht extra gestartet werden muss. Wenn meine Frau sich über Fehler in der Logik beschwert, kann ich irgendwann entspannt schauen was zu diesem Zeitpunkt genau passiert ist. Damit habe ich z.B. auch schon merkwürdiges Verhalten von openHAB gefunden, was sonst nur schwer möglich gewesen wäre.

[Dragonos2000]

Beim TWS können ja weitere Schnittstellen angehängt werden (je nach Modell), um mehrere Linien gleichzeitig zu loggen. Da relativiert sich dann die Größe des Speichers in Bezug auf den Zeitraum bei großen Anlagen, wobei auch dann noch sicherlich mehr als ausreichend dimensioniert.
Der Busmonitor ist ein gutes, hilfreiches und erwähnenswertes Feature. Bei der ETS ist's dagegen schon sehr nervig und eingeschränkt. Aber ja: Sollte eher selten (im Fehlerfall) gebraucht werden.

evolution : Welche Zeiträume siehst Du als sinnvoll?

[MatthiasS]

für den sprunghaften Wassermehrverbrauch, seit die Schwiegermutter eingezogen ist

Zum Glück endlich mal ein Beispiel, das mir den Sinn der unendlichen Aufzeichnung von KNX-Telegrammen verdeutlicht. Ich wohne jetzt fast 18 Jahre in meinem smarthome und ich habe die letzten 16 Jahre keinen Busmonitor mehr gebraucht. Wozu auch? Um den Lamellen datenmäßig bei der Sonnennachführung zuzusehen?

In allen Objekten, die ich ich der Vergangenheit projektiert habe, hat nei einer der Bauherren nach einer Telegrammhistorie gefragt. Wir haben idR Diagramme für die RTR über 48h, das ist alles. Ich frage mich, was man mit den ganzen Daten macht, außer man ist

Datenfetischist

.

Gleiches gilt für den Busmonitor. Ein Tool, für den (hoffentlich) seltenen Fehlerfall. Aber als Killer-Feature eines smarthome-Servers?

[evolution]

Naja Bestandteil der Backups ist der Datenspeicher im TWS schon.

Deswegen halte ich nichts von Loggingdaten, die lokal auf einem Rechner (hier TWS) abgelegt sind. Hier ist ein separates Speichermedium, das unabhängig vom Gesamtsystem ist, immer die bessere Wahl. Aber wie Du schon sagtest ist das hier "nur" ein Zusatzfeature.

Nicht jeder Privatanwender ist dazu in der Lage, weil er entweder gar keine ETS hat oder nicht eigene weitere Serverlandschaften und Datenbanken administrieren kann/will.

Auch das spricht für meinen Ansatz. Und die ETS kostet jeden 0,00€, wenn er nur das Telegrammlogging ansehen und auswerten will. Nur frage ich mich, was ein unbedarfter Privatanwender ohne KNX- und Serverkenntnissen mit den Daten überhaupt anfangen soll...

Wie schaut der Zugriff auf diese extern gerouteten Datenspeicher für einen SI aus, der die Anlage mal nach berichteten Auffälligkeiten analysieren soll?

Die Loggingdaten sind doch bei Gira und ise einfach von der Gerätewebseite herunterladbar und dezentral analysierbar. Das funktioniert mit jedem Rechner ohne TWS!

[Gast1961]

Es ist eine interessante Komponente mit interessanten Analysetools.

Ich denke der Vorteil ist auch weitgehend akzeptiert. Das mit der InfluxDB zu loggen ist eine gute Lösung, Grafana zur Auswertung auch, und im Paket mit dem Rest scheint das für Datenlogging und Datenauswertung eine runde Lösung zu sein.

Edit: Mit fällt gerade ein, daß irgendwo stand, daß beim TWS ein *.CSV-Export der Werte noch fehlt. Der wäre schon noch wichtig, um Meßwerte genauer analysieren zu können.

[gbglace]

o wie ich das sehe, sind diese Daten beim TWS (wie bei nahezu jedem serverbasierten System) hingegen verloren, wenn das System komplett neu aufgesetzt oder wiederhergestellt werden muss.

Naja Bestandteil der Backups ist der Datenspeicher im TWS schon. Das die Backups noch ein externes Ziel als Option erhalten ist in der ToDo-Liste.

Sollte der Totale Systemabsturz /Verlust in einem gebäudeweitem physischen Schaden verursacht sein, denke ich das auch mehr als 90% aller anderen Systeme vernichtet sind, die externe Speicher / Backups verwenden. Denn nicht alle die Backups machen machen die auch in Richtung getrennte Standorte. Bei hoch professionellen Anlagen schaut das natürlich auch wieder anders aus. Aber wir reden ja hier wohl nicht über die Kundschaft die auch eigene Rechenzentren betreiben / mieten. Backup in Richtung Cloud ist natürlich auch immer eine Option.

Ein Restore der Anlage aus einem Backup funktioniert daher inkl. der TWS-Datenspeicher. Und solange die Speicher nicht gänzlich zerbrutzelt sind, wäre wahrscheinlich auch noch der Support in der Lage die DB vom Speicher zu separieren.

Den Server selbst im Frontend mal eben auf Zustand Werksreset zu bringen kann natürlich ungesund für den Datenspeicher werden. Das sollte aber immer auch die letzte Option sein.

Letztendlich ist dieser Datenspeicher des TWS aber eben ein integriertes Angebot, da man sich nicht darum kümmern muss erst mit einem Analysetool den Speicher aus einem ISE / Gira IP-Router zu lesen. Nicht jeder Privatanwender ist dazu in der Lage, weil er entweder gar keine ETS hat oder nicht eigene weitere Serverlandschaften und Datenbanken administrieren kann/will.

Wie schaut der Zugriff auf diese extern gerouteten Datenspeicher für einen SI aus, der die Anlage mal nach berichteten Auffälligkeiten analysieren soll? Im TWS hat er den Zugriff via der passenden Analysewerkzeuge ohne erst das NAS vom Kunden durchsuchen zu müssen, bzw. der Kunde kann sich das auch anschauen ohne Zugriff auf das NAS vom SI haben zu müssen, sind ja schließlich seine Daten.

Es ist eine interessante Komponente mit interessanten Analysetools.

Jetzt könnte man ja mal eine Anlage aufsetzen mit ISE-Logger / EIBPORT / TWS und dann nach 3 Monaten Laufzeit nach einem bestimmten Phänomen suchen lassen.

[evolution]

Data-Logger über 100mio-1mrd Telegramm Ringspeicher

Hallo Robert, bei uns Zuhause würde das die Daten für 1,5 - 15 Jahre speichern können. Im Vergleich hierzu speichere ich bspw. mit einem ise Remote Access oder Gira IP-Router unsere Telegrammkolonnen für knapp 3 Jahre weg und mit einem Arcus IP-Gateway für knapp 20 Jahre. Jeweils mit einer 32GB Speicherkarte. Das ist privat meines Erachtens sicherlich ausreichend. Aber für eine "richtige" Anlage und dem gleichzeitigen Telegramm-Logging von mehreren Bereichen (was der TWS theoretisch könnte) wird es dann zu eng.
Und aus meiner Erfahrung mit anderen Datenloggern liegt ein großes Problem in der Speicherung selbst. So speichern die Datenlogger von Arcus, ise oder Gira die Telegramme explizit auf ein externes Speichermedium (SD-Karte). Diese Daten bleiben somit bei einem Systemupdate und selbst bei einem kapitalen Systemabsturz vollumfänglich erhalten. Und das auch ohne ein Backup. So wie ich das sehe, sind diese Daten beim TWS (wie bei nahezu jedem serverbasierten System) hingegen verloren, wenn das System komplett neu aufgesetzt oder wiederhergestellt werden muss.