[DISKUSSION] manueller Eintrag in Time Series

[jockele]

Hallo zusammen,

ich wünsche allen ein gutes Neues!

Pünktlich zum Jahresbeginn habe ich einige TimeSeries (täglich, wöchentlich, monatlich und jährlich) angelegt zur Erfassung diverser Verbräuche (Wärmepumpe, Gesamtstrom, Wasserzähler) . Diese will ich ab sofort mit Grafana anstatt bisher mit Edomi visualisieren.

Die Auswertung läuft teilweise noch in Edomi, ich schicke dann einfach die entsprechenden Stände als GA auf den Bus.

Nun aber zur eigentlichen Frage: Für das vergangene Jahr kann ich aus Edomi noch einige Daten rausholen, kann ich diese irgenwie händisch in die neu erstellten TimeSeries eintragen?

Danke für einen Tipp und beste Grüße

[blaubaerli]

Hi @jockele,

irgendwo hatten wir das schon mal....

Was einfaches OutOfTheBox gibt es nicht. Es gibt aber einen Mechanismus, mit dem Daten aus dem vom wiregate genutzten RRD-Format auf den Wolf umziehen konnten.

Wenn du dich da geschickt einklinkst, dann geht das.

Also aus Edomi die Daten in dem Format exportieren, so migrieren, dass sie dem RRD-Migrationsverfahren-Format entsprechen. Dann darüber eine neue Zeitserie initial erstellen und dann genau in diese Serie weiterschreiben.

Beste Grüße
Jens

[blaubaerli]

So, Einstieg gefunden.... viewtopic.php?f=26&t=2321

und hier: viewtopic.php?f=26&t=2532

[Robosoc]

Yeah, endlich ein Mitstreiter, der die Gleiche Aufgabe für sich definiert hat, wenn auch aus anderem Grunde:-)

[tger977]

diesselbe Fragestellung stellt sich bei mir auch schon länger... Wie bekomme ich einfach die Daten die bisher in EDOMI gesammelt wurden in timeseries auf dem TW... Wenn da jemand was hat wäre ich auch dankbar. Ausserdem fände ich es gut wenn man in der timeseries auch einzelne Datenpunkte rausnehmen könnte, da ich leider in einem Zählerarchiv aufgrund eines Logikfehlers auch mal kurzzeitig falsche Daten reingeschrieben hatte und diese nun zu komplett wirren auswertungen / Grafana Darstellungen führen.

Da das Thema natürlich "heikel" ist für den Support wenn die DB frei zugänglich wäre, wäre auch ein einfaches komplett Exportieren der Timeserie über das UI, dann ein Löschen durch den User (geht ja heute schon) und ein Komplettimport der geänderten Daten über die UI eine feine Sache. Wenn dann das Format nicht stimmt darf auch gerne ein Import abgebrochen werden und von mir aus auch der Support für die Im/Exportfunktion kostenpflichtig sein.

[Robosoc]

Ein paar erste Erfolge hatte ich schon, ich denke wir bekommen das selbst schon bald auf die Beine gestellt.

Es wäre aber echt gut, wenn ihr (Elabnet) uns ein paar Info geben könnte, die jemand von Euch vermutlich aus dem Ärmel schüttelt.

Z. B. Würde mich interessieren, ob ich richtig liege, wenn ich denke, dass Ihr beim Wiregate RRD Import
A) Ausschließlich die AVG Werte importiert und
B) die verdichteteren Daten nur dann nutzt, wenn im gleichen Zeitraum keine Daten mit weniger Verdichtung vorliegen.

So habe ich die eine bisherige Beispieldatei interpretiert.

Auch wäre es interessant zu wissen ob überhaupt irgendwelche Kopf Daten aus den XML Dateien des Wiregateserveres genutzt werden, oder nur die Massendaten aus den Databasezeilen...

[StefanW]

Hallo Andi,

Da das Thema natürlich "heikel" ist für den Support wenn die DB frei zugänglich wäre, wäre auch ein einfaches komplett Exportieren der Timeserie über das UI, dann ein Löschen durch den User (geht ja heute schon) und ein Komplettimport der geänderten Daten über die UI eine feine Sache.

Richtig, das wäre zunächst der am einfachsten realisierbare Weg.

Wenn dann das Format nicht stimmt darf auch gerne ein Import abgebrochen werden und von mir aus auch der Support für die Im/Exportfunktion kostenpflichtig sein.

Die Erfahrung zeigt, dass Vereinbarungen mit den Nutzern, dass womöglich etwas zu Extrakosten führen könnte, unbeliebt und auch im Detail schwierig sind. Nicht dass dies nicht gesetzlich völlig klar geregelt wäre (nach dem Gesetz gibt es keinen kostenlosen Support, zumindest bislang, man arbeitet derzeit an einer Initiative für ein Recht auf Reparatur und Support, was ich im Kern wegen der Nachhaltigkeit begrüße, dürfte aber die Preise für komplexe Geräte deutlich anheben) aber die Erwartungshaltung ist bei Teilen der Kundschaft eine andere.

Es wird stellenweise eher zwei Stunden diskutiert, anstatt für die eine halbe Stunde Support zu bezahlen. Wir können uns diese Diskussion nicht leisten. Daher legen wir das Produkt so aus, dass möglichst kein Support entsteht. Dies entspricht auch der Erwartungshaltung der Nutzer: "Ich erwarte, dass das Produkt mich vor jeder Fehlbedienung schützt". Dies hat durchaus Konsequenzen für das Produktdesign, weil manche Ideen (wie z.B. solche Schreib / Importrechte) nicht ohne beträchtlichen Aufwand realisiert werden können.


Beispiel zu solchem Import / Export Leistungsmerkmerkmalen aus der derzeitigen Modbus Implementierung:

Bei 1-Wire und KNX war die Sache noch einfach, der TWS bzw. die ETS kennt ALLE angeschlossenen Geräte und deren Schnittstellendefinition (welche Daten kommen wie). Bei 1-Wire ist das eingebaut und in die ETS lädt man die Applikation.

Abgesehen von DALI und BACNET gibt es keine klaren Gerätedefinitionen für andere Protokolle. Bei Modbus, MQTT, UDP, Rest-API sind fast alle Parameter der Datenkommunikation frei - und die Hersteller nutzen das auch. Die Datenblätter sind teils mangelhaft und so dürfte es schon eine Herausforderung sein, die jeweiligen Geräte zu definieren.

Um dem zu begegnen, weil wir wollen die Integration mit dem Timberwolf Server ja wirklich einfach machen, haben wir die Möglichkeit implementiert, dass man Geräteprofile selbst definieren kann. Im KNX System nennt man dies das "Manufacturer Tool", das ist die Software, mit der die Entwickler eines KNX Gerätes die Applikation erzeugen, die dann von der KNX Association später signiert wird. Wir nennen das Tool im TWS-Sprech einen "Profileditor" und die Verwaltung wird vorgenommen mit dem "Profil-Manager". Mit dem Editor kann man - übrigens sehr komfortabel und höchst interaktiv (das ist unser Meisterstück geworden) - das Geräteprofil definieren.

Weil das nur Sinn macht, wenn die Nutzer das untereinander teilen können, haben wir entsprechende Export- und Import-Funktionen eingebaut.

Das Austauschformat ist eine lesbare XML-Datei die auch den Vorteil bietet, dass mancher es auch dort editieren oder erweitern kann (oder sich mit Excel was baut) - wie auch immer. Die Freiheit ist vollständig aber kann zu schweren Supportproblemen führen, weil hier nicht nur Fehler passieren können sondern weil nun zig verschiedene Versionen eines Profiles in Umlauf geraten können.

Beispiel: Nutzer K (der Kreative) hat ein Profil angelegt für seinen Wechselrichter. Nutzer N (der Nerd) hat zwar den gleichen Wechselrichter, aber in der vollen Ausbaustufe mit noch drei Modulen dran, weil er will alles nutzen, was technisch möglich ist. Der K teilt nun sein Profil mit der Community. N freut sich, lädt das Profil und stellt dann fest, dass es die Definitionen für seine Extra-Module nicht enthält, außerdem ist er mit manchen Einstellungen nicht zufrieden, er würde das ein oder andere anders machen - und schreibt das Profil um. Das teilt er dann auch, dummerweise beide unter dem gleichen Namen des Wechselrichters. Der Nutzer D (für Durchschnitt) hat auch den Wechselrichter und möchte sich nicht in die Profildefinition einlesen. Er hat sich den Timberwolf Server gekauft, weil damit alles einfach ist. Er schließt also seinen Wechselrichter an den TWS an und nutzt dazu eines der fertigen Profile.
Leider geht irgendwas schief, die Werte passen irgendwie nicht. Er schreibt ins Forum "Modbus Timberwolf funktioniert nicht". Andere Nutzer schreiben jedoch, das bei Ihnen alles mit dem Wechselrichter und dessen Profil funktioniert. Nutzer D beklagt nun, dass er sich das alles viel einfacher vorgestellt hätte und beteuert, dass er es ganz genauso gemacht hat wie alle anderen und dass der Fehler am Timberwolf Server liegen muss. Womöglich wird nun eskaliert, weil der Wechselrichter - oder was auch immer mit den Daten daraus angesteuert wird - nun richtig Mist macht. Wir lesen mit und der Vorgang hat das Potential, gerade am Anfang wenn man ein neues Leistungsmerkmal herausbringt, dass die neue Funktion "ins Gerede" kommt. Weil wenn sich erst einmal der Ruf manifestiert hat "geht nicht richtig" ist es schwer davon wieder weg zukommen in der Rezeption.

Das leider oft vorzufindende einseitige öffentliche Bewertungsverhalten (manchmal in Kombination ohne Sachkenntnis) in Verbindung mit einer hohen Erwartungshaltung macht es uns oft schwer. Das Modbus Thema leidet darunter, weil wir den Profileditor nun ein zweites Mal geschrieben haben, weil wir in Sorge waren, dass die erste Version womöglich zuviel von der Lernkurve des Nutzers abverlangt hätte. Wir sehen einfach zu oft, dass der Frust, sich nun in etwas einarbeiten zu müssen, bei manchen zu Kritik führt. Weil es ist eben erst mal das Produkt schuld oder dessen Dokumentation oder der Support oder das wurde ja alles ganz anders versprochen.

Also werden wir uns um solche Probleme kümmern müssen, womit wir in die Installation vor Ort eintauchen müssen und zum Integrator des Kunden werden - unbezahlt. Nach mehreren Stunden der Fehlersuche und Beschäftigung mit dem uns völlig unbekannten Modbus Gerät bei mehreren Nutzer stellen wir fest, dass Nutzer D wohl die spezielle Profildatei des N erwischt hat, anstatt die von allen anderen Nutzern im Forum genutzte Version des K. Es war also ein wenig Zufall, ob der D die für ihn funktionierende und in allen Threads beschriebene Version des K oder die speziell angepasste und getunte Version des N erwischt.

Exportieren, Bearbeiten und Importieren bedeutet die Möglichkeit, dass unzählige Derivate mit der gleichen Bezeichnung entstehen können, die sich beliebig verbreiten können und womöglich den gleichen Namen tragen - aber letztlich verschieden funktionieren.

Anderen Herstellern wäre das egal, weil das Risiko für die Implementierung trägt der Integrator. Er ist der Handwerker, der das gelieferte Werkzeug eben richtig bedienen muss. Aber für uns, die alles öffentlich in einem Forum abhandeln und nicht mit ganzseitigen Anzeigen und tausend Vertriebsleuten vor Ort alle bequatschen können, geht das nicht. Wir müssen stets auf die Stimmung im Forum achten und zusehen, wie wir alle allseits zufrieden stellen und Probleme zügig erledigen.

Damit sind aber alle Funktionen schwierig, wo der Nutzer einen Fehler machen kann. Während bei den Containern der Nutzer nun verstanden wurde, dass dies alleine in der Hand der Nutzer liegt, wäre das bei Grundfunktionen des Timberwolf Servers schwierig.


Wie haben wir das oben beschriebene Problem nun bei Modbus gelöst?

1. Alle angelegten Profile bekommen eine weltweit eindeutige Nummer (aus TWS-SN und forlaufendem Index).

2. Es werden auch Kopfdaten exportiert, welche diese Nummer beinhalten

3. Sobald ein Profil einmal exportiert wurde, kann es nicht mehr geändert werden am Server (diese Version wird ab Export fixiert).

4. Wenn das Profil geteilt und von einem anderen Nutzer an dessen TWS importiert wird, dann wird es die SELBE ID anzeigen wie auf dem TWS auf dem es exportiert wurde.

5. Die Profile werden beim Export signiert. Jede Veränderung an der Datei wird beim Import festgestellt und es wird ein Derivat angelegt.

6. In den Kopfdaten ist auch ein Changelog, aus dem der Werdegang eines solchen Profils ersichtlich ist (wann wurde welche Kopie, welcher Export usw. gemacht). Zwecks der Nachvollziehbarkeit.

==> Die Nutzer (und unser Support) sollen sich darauf verlassen können, dass die einmalige ID eines Profiles auch einen dazugehörigen einmaligen Inhalt hat.

Diese Import- / Export-Möglichkeit war am Ende sehr aufwändig und hat locker - mit allen hier noch nicht aufgeführten Details - locker ein viertel Mannjahr an Arbeit gemacht. Weil man muss das richtig machen, sonst gibt es schnell ein Chaos im Support.


Zurück zu Import / Veränderung / Export von Zeitserien:

Man wird das hier ähnlich machen müssen. Da müssen Kopfdaten angelegt werden, damit man weiß von welchem TWS das kam und man wird es signieren müssen, damit man Änderungen der Nutzer auch erkennt. Damit man das dann auch klar anzeigen kann, ob eine Zeitserie "jungfäulich" ist oder von einem Nutzer manipuliert wurde, muss man ein weiteres Datenbankfeld einführen und eine Markierung in der Verwaltung. Bedeutet eine anstrengende Schema-Erweiterung und ein komplexes Update deswegen.

Selbstredend muss man das Format korrekt erkennen und vor allem validieren. Da es mit der Zeit (immer 15 Jahre im voraus denken) auch mehrere solcher Exportformate geben kann, muss man auch eine Formatversionierung einbauen. Wieder ein Kopffeld mehr, dass bestimmt, exportiert, importiert, validiert werden muss.

Was ich damit sagen will: Es ist nicht so einfach. Nicht weil man die Basisfunktion nicht einfach schaffen könnte, sondern weil wir auch immer die Fehlbedienungen und die Anspruchshaltung das es eine solche nicht geben kann, mit adressieren müssen.

Deshalb können wir ein solches wünschenswertes Feature erst einbauen, wenn wir das auch ordentlich umsetzen können.


Hallo Sven,

Auch wäre es interessant zu wissen ob überhaupt irgendwelche Kopf Daten aus den XML Dateien des Wiregateserveres genutzt werden, oder nur die Massendaten aus den Databasezeilen...

ich muss das erst mit dem speziellen Entwickler besprechen, der das vor drei Jahren programmiert hat.

Ich meine mich zu erinnern (ohne Gewähr) dass nur de AVG Daten importiert wurden, weil beim RRD hat man diese mit Minima und Maxima in einer Datenbank, während man bei der Influx dafür einzelne Zeitserien anlegt.

Es werden schon Kopfdaten benutzt. Beim "Import vom Wiregate Server" werden schließlich auch die 1-Wire Sensoren passend zu den vormaligen Einstellungen konfiguriert und mit den richtigen KNX Objekten (die mit dem "Timberwolf Importer" zuvor in der ETS angelegt wurden) sowie mit den importierten Zeitserien verknüpft. Dazu dienen die Kopfdaten, auch zur Benennung.

lg

Stefan

[Eraser]

Während dem Lesen wollte ich eine eigene Seriennummer des Exports vorschlagen, damit man Ändrungen erkennen kann

Meiner Meinung nach ist das so toll gelöst und man kann schnell und einfach Veränderungen an der Konfiguration erkennen

[StefanW]

Hallo Wolfgang,

Während dem Lesen wollte ich eine eigene Seriennummer des Exports vorschlagen, damit man Ändrungen erkennen kann

Das hätte nicht gereicht.

Weil dann hätte der Autor eine Version X bei sich in der Datenbank gehabt (und womöglich fortlaufend verändert) und die exportierte Version wäre ein früheres Derivat (Fork) davon. Das bekommt man nie wieder zusammen und womöglich erkennt selbst der Autor später nicht mehr, schon gar nicht bei mehreren Exports, was eigentlich wo in welcher Version er definiert hatte.

Darum haben wir ab auch Export eine Veränderungssperre im originären Profil, das sich in der DB befindet, drin. Wird auch entsprechend angezeigt.

Meiner Meinung nach ist das so toll gelöst und man kann schnell und einfach Veränderungen an der Konfiguration erkennen

Jep. Wir mussten das im Prinzip so lösen wie bei der ETS auch. Die Applikation (= das Geräte Profil) ist wirklich eindeutig. Eine Bezeichnung - hier die ID - ist eindeutig und Verlässlich.

lg

Stefan

[Robosoc]

Ich meine mich zu erinnern (ohne Gewähr) dass nur de AVG Daten importiert wurden, weil beim RRD hat man diese mit Minima und Maxima in einer Datenbank, während man bei der Influx dafür einzelne Zeitserien anlegt.

Jo, ich denke ich konnte das inzwischen so auch belegen.
Habe die RRD von dieser Diskussion Link importiert (ohne Änderung ausser Dateiname) und mit diversen Änderungen (z.B. vorheriges Löschen aller MIN und MAX databases).

Es werden schon Kopfdaten benutzt. Beim "Import vom Wiregate Server" werden schließlich auch die 1-Wire Sensoren passend zu den vormaligen Einstellungen konfiguriert und mit den richtigen KNX Objekten (die mit dem "Timberwolf Importer" zuvor in der ETS angelegt wurden) sowie mit den importierten Zeitserien verknüpft. Dazu dienen die Kopfdaten, auch zur Benennung.

Ich konnte es zumindest inzwischen (leider etwas schmerzvoll) bestätigen, dass Kopfdaten verwendet werden. Habe durch das Importieren von um Kopfdaten reduzierte RRD's meinen Zeitreihen Datenbank so zerschossen, dass A) die SSD von 42% Füllgrad auf 78% hochging (wegen einer einzigen RRD mit 8829 Einträgen ) und B) die Zeitreihen Datenbank sich nicht mehr aktivieren ließ... Ich musste meinen TWS komplett wiederherstellen, hatte aber ein Backup vorher gemacht. Ein Löschen der neu angelegten Zeitreihen war zwar möglich, aber hat das Problem nicht gelöst.

Beim Import der manipulierten RRD hat das Importtool aber keinen Fehler ausgeworfen und OK gemeldet - also vorsicht damit!

Ich werde heute noch ein zwei Tests mit vollständigen Kopfdaten, aber manipulierten Databases machen... Mal sehen, was das Ergebnis ist.