ElabNET Technik Forum

gbglace hat geschrieben: ↑Di Feb 02, 2021 11:20 am Oder soll es zu jeder GA oder sonstige ID eine eigene CSV geben?

Ich bin mir da gerade nicht sicher, wie die Philosophie des TWS ist. Wenn ich mir die Zeitreihen anschaue, die ich mir über den Logikeditor selber angelegt habe oder durch eine Objektverknüfung, scheinen die mir alle einheitslose Floats zu sein. Die Zeitreihen, die sich aus 1-wire Regeln bilden, haben Einheiten. Vielleicht habe ich beim Anlegen der Zeitreihen im Logikeditor einfach auch nur was vergessen, aber ich glaube man kann aktuell (V1.6) keine Zeitreihen mit Einheiten manuell anlegen.

Daher: Ich plädiere dazu es gaaaanz einfach zu halten und lediglich eine Zeitreihe aus einer externen csv-Daten zu erzeugen, die dazu einheitslos ist.
Es wäre schön, wenn man mehrere csv-Dateien zum gleichen Zeitpunkt importieren kann - so wie beim Wiregate-Import z.B. indem ein USB-Stick mit einem speziellen Vereichnis zum Einsatz kommt. Alle csv Dateien in dem Verzeichnis werden eingelesen.

Wenn eine Einheitenvergabe leicht möglich ist, kann man diese vielleicht in Form von KNX DPTS (diese sind ja bereits im TWS sehr gut bekannt und Elabnet hat dazu die nötige Datenbank) als dritten semikolongetrennten Wert vorsehen (optional).

Zum Thema GA-Verknüfung: Eine Zeitreihe hat ja zunächst nicht zwingend etwas mit einer GA zutun und ich würde hier keine vorgegebene Möglichkeit berücksichtigen. Wenn man eine manuell hochgeladene Zeitreihe gerne z.B. aus einer GA heraus weiter beschreiben möchte, dann muss man das eben manuell im Objekteditor verknüpfen. Im Zweifel ist das Verknüpfen dann eine Fleißarbeit, wenn man wirklich unbedingt viele Daten übernehmen möchte. Aus meiner Sicht ist das doch eigentlich meist nur für Zählerwerte interessant. Von anderen Dingen braucht man doch eher selten die alten Werte von vor zwei Jahren...

Hallo Sven,

also hier wäre mal interessant wie das Datenbank Modell und die einzelnen Tabellen aussehen. Also wie das mit den Einheiten und soweiter gelöst ist, das könnte uns nur @StefanW und das Entwickler Team sagen.

Ganz klar zählen bei nem Import nur die Daten. Verbindungen der Quellen zu den TS ist ganz einfach über den Objekt Editor zu machen und zählt nicht hier rein.

@gbglace

Hier benötigt man eben das Datenbank Modell was hinter dem Ringspeicher und anderen TS die aus den diversen Welten (Z.B. KNX ; 1-Wire ; eKey ; Modbus ; ...) erstellt werden sich ergeben. Diese benötigt man um eine klare Aussage zu treffen.

Ja ohne datenbank-Modell werden wir nicht weiter kommen.

Entweder jede Timeseries eine Tabelle oder eben eine ID-Spalte zu den TWS-Objekten um die Werte decodieren zu können.

gbglace hat geschrieben: ↑Di Feb 02, 2021 11:20 am Drei Spalten müssen es schon sein, weil nur mit Zeit und einem Wert wie boolsches 0/1 gefolgt von 20°C ist es in Summe dann Datenschrott. Es braucht also noch einen Identifier wie z.B. eine GA über die dann der Wert decodiert werden kann.

Oder soll es zu jeder GA oder sonstige ID eine eigene CSV geben?

Hallo Göran,
so wie ich weiß haben alle TimeSeries in TWS, die mit "TS" beginnen, auch nur zwei Spalten time und Val.
Der Name der TimeSerie ist der Identifier.

TimeSerien: time, Val
Ringspeicher: time, GA, PA, Raw, Rcv, Val

MfG Juri

Hallo Juri,

hmm aber irgendwie muss die TS ja wissen welche Einheit der Wert hat. Daher denke ich auch das es 3 Spalten sind wobei die letzte eventuell eine Zahl von 001 bis 999 hat und der TWS dann die Einheit anhand dieser Zahl zuordnet. Aber alles nur Vermutungen. Genaueres gibts nur von Elabnet.

Sensej hat geschrieben: ↑Di Feb 02, 2021 12:06 pm
so wie ich weiß haben alle TimeSeries in TWS, die mit "TS" beginnen, auch nur zwei Spalten time und Val.
Der Name der TimeSerie ist der Identifier.

TimeSerien: time, Val
Ringspeicher: time, GA, PA, Raw, Rcv, Val

Dann wäre der Name der TS aber auch gleichzeitig jeweils eine eigene Tabelle in der Datenbank, weil dann genügen die zwei Spalten.

Sun1453 hat geschrieben: ↑Di Feb 02, 2021 12:12 pm Hallo Juri,

hmm aber irgendwie muss die TS ja wissen welche Einheit der Wert hat. Daher denke ich auch das es 3 Spalten sind wobei die letzte eventuell eine Zahl von 001 bis 999 hat und der TWS dann die Einheit anhand dieser Zahl zuordnet. Aber alles nur Vermutungen. Genaueres gibts nur von Elabnet.

Hallo Michael,

In der Daten-DB(Timeseries und Ringspeicher) sollen keine Einheiten, sondern nur rohe Daten stehen.
Die Zuweisung der Einheiten im TWS findet wahrscheinlich im Geräte-Manager, wenn einem Gerät die TS zugewiesen wird.
Es ist aber bestimmt schon eine andere DB, Konfig-Datenbank.
Es gibt im TWS bestimmt noch mehr DB-Tabellen, die für normale Anwender nicht sichtbar sind

MfG Juri

Robosoc hat geschrieben: ↑Di Feb 02, 2021 11:51 am Daher: Ich plädiere dazu es gaaaanz einfach zu halten und lediglich eine Zeitreihe aus einer externen csv-Daten zu erzeugen, die dazu einheitslos ist.
Es wäre schön, wenn man mehrere csv-Dateien zum gleichen Zeitpunkt importieren kann - so wie beim Wiregate-Import z.B. indem ein USB-Stick mit einem speziellen Vereichnis zum Einsatz kommt. Alle csv Dateien in dem Verzeichnis werden eingelesen.

Dem kann ich nur zustimmen, wäre vermutlich das einfachste und damit auch zusätzlichen Supportaufwand von elabnet erheblich reduzieren.

HIer mal die unterschiedlichen Varianten
https://www.influxdata.com/blog/getting ... -influxdb/

Habe selber überhaupt keine Erfahrungen mit InfluxDB.

Hallo,

ich fürchte ihr stellt Euch das sehr einfach vor.

Wir haben am Export aus dem WireGate und dem Import im Timberwolf-Server mit einem Aufwand von 1,5 Mannjahren gearbeitet.

So ein CSV-Export & Import mit allen Bedienungsfehlderm Hinweis-Anzeigen und Fehlermeldungen, Logs für Fehlersuche, Validierungen usw. würde uns vermutlich ein viertel bis ein halbes Mannjahr beschäftigen.

Es ist durchaus mehr Aufwand, als das auf den ersten Blick erscheinen mag.

Wir haben das durchaus auf der Liste, einen Termin kann ich nicht versprechen.


lg

Stefan

Hallo zusammen,

ich denke das Ganze muss man in zwei Bereiche aufteilen.

1: TS-CSV-Export/Import/Massenänderungen der Daten

2: Bearbeiten einzelner Werte der TS(Werte löschen bzw. ändern)

Mein Vorschlag zum Punkt 1:

• Neue Datenbank "csv" erstellen, die man nur für diese Zwecke nutzt.

• Einen Neuen Benutzer "csv_user" mit Schreibrechten nur für die csv-Datenbank anlegen.

• Eine Möglichkeit schaffen im TWS die Time-Series X aus der DB "timeseries_db" nach DB "CSV" zu kopieren und umgekehrt.

• Der Name der TS wird beim Kopiervorgang nach DB "csv" geändert, z.B TSX wird zu TSX_COPY

Hinweis: Für DM kann man bereits bestehende interne/externe Tools(InfluxDB-Funktionen, Python-Skripte, Telegraf usw.) verwenden.
Dies kann der Benutzer selber übernehmen, weil er dafür Rechte(csv_user) hat.

Anwendungsfall 1: Externe Daten in eine neue TS kopieren

• Neue TS "TSX" in DB "csv" anlegen

• Daten in die "TSX" kopieren

• Daten mit Grafana prüfen

• TSX nach DB "timeseries_db" kopieren

• TSX einbinden

Anwendungsfall 2: Daten in der bestehenden TS bearbeiten -> z.B Löschen/Ändern

• TSX aus der DB "timeseries_db" nach "csv" als "TSX_COPY" kopieren

• Daten in der "TSX_COPY" bearbeiten

• Daten mit Grafana prüfen

• "TSX_COPY" wieder nach DB "timeseries_db" kopieren

• Original TS "TSX" löschen

• "TSX_COPY" nach "TSX" umbenennen

• TS "X" einbinden

Anwendungsfall 3: Daten in einer bestehenden "TSX" um externe Daten erweitern

• TSX aus der DB "timeseries_db" nach "csv" als "TSX_COPY" kopieren

• Daten in die "TSX_COPY" importieren, bearbeiten/mergen

• Daten mit Grafana prüfen

• "TSX_COPY" wieder nach DB "timeseries_db" kopieren

• Original TS "TSX" löschen

• "TSX_COPY" nach "TSX" umbenennen

• TS "X" einbinden

Vorteile:

• Änderungen finden nicht direkt an der produktiven DB statt

• Der Anwender kann selber die Datenänderungen in der DB "csv" durchführen -> Weniger Entwicklungsaufwand

• Weitere Tools können später an die bestehende Funktionalitäten(DB-Datenänderung) angebunden werden

Zum Punkt 2: Habe ich noch keinen Vorschlag

MfG Juri