ElabNET Technik Forum

Hallo zusammen!

Ich überlege schon ein Weilchen, wie denn der Umstieg vom WG auf den TWS schrittweise für Sensoren, Visu, Logik, Datenerfassung etc. funktionieren könnte.
Angeregt durch die Diskussion hier (https://knx-user-forum.de/forum/support ... timberwolf), möchte ich mal meine Überlegungen teilen, vielleicht gibt es ja Anregungen von euch!

Folgendes Vorgehen schwebt mir im Moment vor:

PHASE 1: Sensoren migrieren
1) Migration des WG mittels der zur Verfügung gestellten Tools (damit werden Sensorbezeichnungen und die Historie der rrds der Sensoren übernommen).
2) Umstecken der 1-wire Sensorik auf den TWS.

Um den Parallelbetrieb zu ermöglichen, braucht es die folgenden Ergänzungen:
- Die rrd's der Sensoren werden am WG mittels plugin weiter befüllt. Ich schreibe die bisher übersiedelten Sensoren in eine neue RRD, ob man per plugin einfach in das bereits vom WG angelegte RRD schreiben kann, hab ich nicht getestet, könnte aber Probleme machen, wenn man einen Sensor wieder zurück umsteckt.
- Für die CometVisu habe ich das alte RRD des Sensors durch das neue ersetzt.
- Das die Sensorwerte über KNX-GA ausgetauscht werden, muss für die anderen Anzeigen in der Visu nichts gemacht werden.
- Auch die Logiken, die 1-wire Sensoren verwenden laufen weiter.

Das ist im Übrigen mein aktueller Status (derzeit nur Teile der Sensorik migriert).

PHASE 2: Logiken übersiedeln
Die Phase wird sicher länger dauern, da nicht alle Logiken mit den ersten Versionen des Logikmoduls abgelöst werden können.
1) Einfache Logiken ersetzen (Klassiker wie Typ-Umwandler 0/1 auf 0/100%, Nachsenden von Dimmwerten in der Nacht etc.). Dazu braucht es hauptsächlich UND/ODER Gatter.
2) Weitere Logiken, je nach Möglichkeiten am TWS.

Einige aufwendigere Dinge (Plugins mit Arrays, etc.) werden vermutlich länger im Plugin-Docker verbleiben müssen.

PHASE 3: CometVisu übersiedeln
Hier wird es für mich Stand heute etwas diffus.
1) Heute verwendet die CometVisu RRDs für Diagramme, ich vermute, dass die Unterstützung der CV für TimeSeries nicht ganz trivial zu implementieren ist.
2) Es braucht weiterhin das rrd-Schreiben plugin im Docker, wobei für mich unklar ist, wo die rrd dann liegen müssen, dass sowohl CV-Docker als auch plugin-Docker zugreifen können. Ideal wäre natürlich eine TWS Logik, die ein rrd befüllt.

Ab diesem Zeitpunkt könnte das WG entfallen, sofern alle Logiken im TWS plugin-Docker lauffähig sind.

PHASE 4: Vollständige RRD Ablöse durch TimeSeries
1) Sollte die CV irgendwann TimeSeries unterstützen, könnten die RRDs entfallen
2) Voraussetzung ist allerdings, dass der TWS eine Logik bereit stellt um eigene TimeSeries zu befüllen

Soweit meine Überlegungen, bin gespannt was ihr so an Gedanken zu diesem Thema habt!

lg
Robert

Robert_Mini hat geschrieben: ↑Fr Aug 24, 2018 9:07 pm PHASE 3: CometVisu übersiedeln
Hier wird es für mich Stand heute etwas diffus.
1) Heute verwendet die CometVisu RRDs für Diagramme, ich vermute, dass die Unterstützung der CV für TimeSeries nicht ganz trivial zu implementieren ist.
2) Es braucht weiterhin das rrd-Schreiben plugin im Docker, wobei für mich unklar ist, wo die rrd dann liegen müssen, dass sowohl CV-Docker als auch plugin-Docker zugreifen können. Ideal wäre natürlich eine TWS Logik, die ein rrd befüllt.

Ab diesem Zeitpunkt könnte das WG entfallen, sofern alle Logiken im TWS plugin-Docker lauffähig sind.

PHASE 4: Vollständige RRD Ablöse durch TimeSeries
1) Sollte die CV irgendwann TimeSeries unterstützen, könnten die RRDs entfallen
2) Voraussetzung ist allerdings, dass der TWS eine Logik bereit stellt um eigene TimeSeries zu befüllen

Wenn ich weiß wie ich "von außen" (also aus einem Docker Container) auf die InfluxDB zugreifen kann, kann ich auch das Diagram-Plugin erweitern, so dass es darauf aufbaut. Dies habe ich auch fest eingeplant, brauche es ja selber

Aber leider habe ich bisher keine Info bekommen, wie ich da drauf komme.

Zu Phase3:
Wenn man Abstriche bei der Funktionalität machen kann, dann dürfte das nicht so schwierig sein. Die bisherigen Miniaturbilder werden halt nicht so einfach gehen.
Für die gewünschten Time Series kannst du in Grafana jeweils Dashboards anlegen und deren Link dann wiederum in die CV per externem Link einbinden (so wie man es jetzt z.B. für Wetterdaten machen kann).
Von daher braucht man keine RRDs mehr für Daten, für die der TW schon Series unterstützt.

Was Speicherorte bzgl. Docker betrifft: mehrere Docker-Container können sich sogenannte Volumes teilen und darüber Daten austauschen. Ein Volume ist ein ins Dateisystem des Containers reingemappter Speicherort. Die Frage ist nur, wo das dann im TW liegt/liegen kann.

Cepheus73 hat geschrieben: ↑Fr Aug 24, 2018 10:11 pm Wenn man Abstriche bei der Funktionalität machen kann, dann dürfte das nicht so schwierig sein. Die bisherigen Miniaturbilder werden halt nicht so einfach gehen.
Für die gewünschten Time Series kannst du in Grafana jeweils Dashboards anlegen und deren Link dann wiederum in die CV per externem Link einbinden (so wie man es jetzt z.B. für Wetterdaten machen kann).
Von daher braucht man keine RRDs mehr für Daten, für die der TW schon Series unterstützt.

Klar, das geht jetzt schon. Hat halt nicht die Features die die direkte Darstellung hat (z.B. scrollen, zoomen, einzelne Werte anzeigen, Popup)

Cepheus73 hat geschrieben: ↑Fr Aug 24, 2018 10:11 pm Was Speicherorte bzgl. Docker betrifft: mehrere Docker-Container können sich sogenannte Volumes teilen und darüber Daten austauschen. Ein Volume ist ein ins Dateisystem des Containers reingemappter Speicherort. Die Frage ist nur, wo das dann im TW liegt/liegen kann.

Das nützt nichts - InfluxDB ist eine richtige Datenbank. D.h. da musst Du per Client und API mit sprechen und nicht nur blind auf eine Datei zugreifen.
=> Ich brauche Adresse mit Port und Credentials so wie den Datenbanknamen.

Klar, das geht jetzt schon. Hat halt nicht die Features die die direkte Darstellung hat (z.B. scrollen, zoomen, einzelne Werte anzeigen, Popup)

Im openHAB Forum gibt es einen langen Thread zur Einbindung von Grafana, da ist ein html Wrapper mit etwas Jacascript gepostet mit dem das problemlos funktioniert. Hier der Thread: https://community.openhab.org/t/influxd ... hing/13761

Chris M. hat geschrieben: ↑Fr Aug 24, 2018 10:05 pmWenn ich weiß wie ich "von außen" (also aus einem Docker Container) auf die InfluxDB zugreifen kann, kann ich auch das Diagram-Plugin erweitern, so dass es darauf aufbaut. Dies habe ich auch fest eingeplant, brauche es ja selber

Hast Du uns das schon gefragt? ich mache da mal ein ticket auf und bringe Dich mit allen Entwicklern zusammen.

Du frägst einfach per SQL ab. Ich sorge dass Du Zugangsdaten und Port bekommst.

lg

Stefan

Hinzugefügt nach 2 Minuten 6 Sekunden:

Cepheus73 hat geschrieben: ↑Fr Aug 24, 2018 10:11 pmWas Speicherorte bzgl. Docker betrifft: mehrere Docker-Container können sich sogenannte Volumes teilen und darüber Daten austauschen. Ein Volume ist ein ins Dateisystem des Containers reingemappter Speicherort. Die Frage ist nur, wo das dann im TW liegt/liegen kann.

Ein solches Volume, das ihr zum Austausch zwischen den Containern nehmen könnt, existiert auch bereits. Ich lasse mit die Daten geben und poste das dann (kommt auch in das Video zu der Sache) und Anleitung machen wir auch noch. Dieses Volume sollte auch Bestandteil der Sicherung sein.

lg

Stefan

StefanW hat geschrieben: ↑Sa Aug 25, 2018 12:05 am

Chris M. hat geschrieben: ↑Fr Aug 24, 2018 10:05 pmWenn ich weiß wie ich "von außen" (also aus einem Docker Container) auf die InfluxDB zugreifen kann, kann ich auch das Diagram-Plugin erweitern, so dass es darauf aufbaut. Dies habe ich auch fest eingeplant, brauche es ja selber

Hast Du uns das schon gefragt? ich mache da mal ein ticket auf und bringe Dich mit allen Entwicklern zusammen.

Ja, in einem der Beta-Feedback Mails (glaube ich). Ist halt wahrscheinlich im Stress untergegangen

jockel hat geschrieben: ↑Fr Aug 24, 2018 10:43 pmIm openHAB Forum gibt es einen langen Thread zur Einbindung von Grafana, da ist ein html Wrapper mit etwas Jacascript gepostet mit dem das problemlos funktioniert. Hier der Thread: https://community.openhab.org/t/influxd ... hing/13761

Wir verwenden z.B. DyGraphs im Timberwolf Server (auf der Seite mit den Zeitserien). Das könnte man auch in die CV integrieren. Es gibt aber zig Bibliotheken die das können.

Chris: Wenn Du hier CodeSnipplets brauchst, dann lasse ich Dir diese zur Verfügung stellen. Ich mail dir mal eine Liste der Ansprechpartner, dann kannst Du das direkt mit Ihnen klären.

lg

Stefan

Noch ein Hinweis:

Liste der vorgeschlagenen Vorgehensweise für die Migration von WireGate nach Timberwolf Server unter viewtopic.php?p=682#p682 veröffentlicht