Analytics-Adapter / DB-Harmonisierung
-
Jupp. Adapter finde ich auch gut. Ist universell. Wollte auf die Antwort von apollon77 eingehen.
-
Das Adapter System ist simpel und gut verständlich. `
und soll vor allem das große Problem von ccu.io vermeiden.Jeder Adapter soll nur so viel wie unbedingt nötig machen, für jede Funktion ein anderer (in Grenzen natürlich!).
Wenn dann eine Funktion Probleme hat ist nicht der Multi-Mega-Adapter mit 100 Funktionen komplett down, sondern nur einer von 100.
Gruß
Rainer
-
Nehmen wir mal als hypothetisches Beispiel für A den History-Adapter… Und den SQL-Adapter. Und den Influx-DB-Adapter. Deine Kids, apollon77.
Alle drei machen prinzipiell das Gleiche. Der SQL-Adapter hat schon die Möglichkeit verschiedene Backend-DBs einzubinden. Warum nicht auch für File und influx? ...-> Entwickung hin zu einer zentralen Datenschnittstelle für ioBroker. -> Dafür ein zentraler Adapter.
Vereinfachung für die Anwender.
Möglichkeit dort das Backend auszutauschen.
Datenmigration. Backup. Alles an einer Stelle.
Aggregatoren.
Abstraktion, Möglichkeit, Text-Files mit SQL abzufragen,…
...
Ich finde, das ioBroker von Entwicker für Entwickler geschrieben ist. Nichts schlechtes dabei. Doch was ist mit den Anwendern, die froh sind, dass der ioBroker überhaupt installiert ist... Abstraktion der Komplexität statt immer komplexer zu werden. `
Hm … also gerade aus Anwendersicht ist diese Trennung super (finde ich)!
Was will ich? File oder SQL oder InfluxDB? Dann installiere ich den Adapter und er macht genau das was er soll. Wenn ich nicht weiss was SQL oder InfluxDB ist nehme ich "History" und habe Diagramme. Cool.
Ich gebe Dir recht, der "Migrationspfad" von einem zu einem der anderen Adapter ist nicht ganz so simpel aus Usersicht - aber auch in einem Adapter wäre eine automatisierte Datenmigration nahezu unmöglich bzw. eeeeeecht umfangreich! Und genau bei sowas will dann jeder was anderes und es entsteht ein Mega-Monster was niemand mehr (weder User noch Entwickler) unter Kontrolle hat. Allein SQL ist schon so ein halbes Monster
Je mehr man in eine Software (und das ist jetzt ganz allgemein gesprochen) reinpackt umso komplexer, fehleranfälliger, schlechter wartbarer und und und wird das ganze. Auch wenn das Featureset der 3 History-Adapter nach aussen hin "identisch" ist, ist unter der Haube einiges anders.
Irgendwo muss man Grenzen ziehen zwischen "für den User einfach" und "noch wartbar" und aus diesen Gesichtspunkten finde ich die Auftrennung genau hier passend.
Das ioBroker "von Entwicklern für Entwickler" ist möchte ich aber nicht unterschreiben. ioBroker ist eins der wenigen Systeme wo man ohne Kommandozeile auskommt und im ersten Schritt sehr viel tun kann ohne "Entwickeln" zu müssen. Ja, um das Ziel echt erreicht zu haben fehlt noch ein guter grafischer/UI "Wenn-Dann-Sonst"-Regeleditor, aber sonst ist genau das Ziel sich nicht nur an "Techniker" zu richten.
Die Thematik an "Smart-Home" ist das man viel mit wenig Wissen tun kann, aber wenn man mal Blut geleckt hat und mehr will, dann muss man sich auch damit beschäftigen.
Und ja wenn jemand mal soweit ich das wegen I/O-Problemen History nicht mehr die Wahl ist oder man jetzt weiss was SQL ist und ne NAS hat wo man das mit einem Klick installieren kann, dann stellt man "einfach" alle Datenpunkte auf SQL um und gut ist. Der Aufwand kommt nur wenn man die alten Daten migrieren will ... aber so gesehen gabs dazu 2-3 Thraeds im ganzen Forum bisher ... Ich denke die meisten stellen einfach um und gut ist
ALso wie Du siehst habe ich/wir das gleiche Interesse ... es gibt nur verschiedene Sichtweisen auf das ganze Thema ... (und ich will Deine in keinem Fall hier wegdiskutieren!) ... gib gern Feedback
-
Ich lass das mal auf mich einige Zeit wirken… Ich komme eher von der DB-Seite und bin Konzepte wie OLEDB u.ä. gewohnt. Da ist es dann z.B. für Abfragen (nahezu) egal, welche DB darunter steckt. Das vermisse ich.
-
Also Javascriopt-Seitig gibt es die einheitliche "getHostory"-Message die alle 3 Adapter (und seit neuestem auch Homee) implementieren. Da kannst du die gleichen Abfragen (ja, kein SQL …) auf alle 3-4 Adapter loslassen - so machen es die Diagramm-Adapter z.B. flot.
https://github.com/ioBroker/ioBroker.hi ... pt-adapter
Also das haben wir hier schon. Nur keine echte Abfragesprache.
Dann viel Spass beim wirken lassen
-
Ja, "getHistory" mit den lustigen Aggregaten kenne ich. Das ist nicht das Problem. Aber z.B. Statistikwerte über den Datenbankzugriff/die Datenhaltung selbst, ohne dass ich mich als Anwender darum kümmern muss?
-
Usecase?
-
Bin vor allem an analytischen- und ranking-Funktionen unabhängig von der zugrunde liegenden Datenhaltung interessiert.
-
Also weit weg von Normal-User Interessen
Sorry aber die ANtwort ist mir gerade zu abstrakt (oder mein Kopf zu weit weg) … Was ?
-
Na, wenn man sieht, wie da(s) in Scripts "getrickst", ähm, gelöst wird. Da werde munter ioBroker-Objekte zur temporären Datenhaltung angelegt und vorberechnet. Nichts schlimmes, aber was hat das mit Smart Home zu tun? Das sind reguläre Anforderungen an die zugrunde liegende Datenhaltung und -aufbereitung.
Da baut sich jetzt halt jeder seine eigene Lösung, weil die minimale Basis der history-Adapter ist. Oder weil nicht jeder auf die 'query'-Funktion bei SQL stößt. Und der Anwender hofft auf Script-Sammlungen und das Forum.
Ich sag nur:
Letzter Datensatz
Letzte Woche
Top 10
Aggregationen über beliebige Zeiträume
Vergleich von Zeiträumen
Tendenzen
Gezielter Werte-Zugriff auf Zeitpunkte in der Vergangenheit
Parsen von JSON-Objekten aus der DB
…
Sag jetzt nicht SQL. Welcher Smart Home-Anwender will das freiwillig auch noch lernen...
-> Ironie:
Juhu, ein Analyse-Adapter muss her. Und der darf dann sich wieder mit den verschiedenen Datensenken herumschlagen, weil die nicht über eine zentrale Harmonisierungsschicht laufen...
-
Da ist schon was wahres dran.
Für die meisten User ist das nicht so ein Thema … sobald man tiefer rein geht will man sowas haben und ja, aktuell SQL bzw Abfragen je nach verwendetem History Adapter. Einiges geht per getHistory, anderes macht nur bei einer DB Sinn und dann ist man bei SQL/InfluxQL ...
Was das "cachen der Werte in eigenen States" angeht ist das mal wieder so ne Sache. Man will Die Daten ggf übergreifend in Skripten verwenden aber auch (egal über welchen Weg) nicht jedes mal neu abfragen. Auch berücksichtigt auf was für Systemen wir hier üblicherweise unterwegs sind ... Raspis & Friends
und SD Karten 
Da ist die temporäre Datenhaltung als States (vor allem bei Nutzung von Redis) ideal und "billig" und performant.
Bei einem Industie-System hat man auch oft den Trade-off zwischen "Aktuellsten Daten per direkter DB Abfrage" und "Performance durch Caching" ...
Naja die Optionen an dfer Stelle sind wieder vielfältig:
-
Erweitern der History-Adapter individuell um diese Art von Datenabfragen bereitstellen zu können. Einheitliche API sodass es trotz Unterschieden unter der Haube einheitlich ist
-
Ein Analyse adapter der die besonderheiten der History Adapter kennt oder die verfügbaren/erweiteren Schnittstellen nutzt um das zu tun was er braucht und die Daten bereitzustellen, ggf zu cachen (vllt ja auch selbst im Speicher und gar nicht in states) und so
-
Ein Statistic/Aggregator Adapter (ja da hat ein Entwickler schon angefangen um einfache Standardaggregationen wie Zähler oder min/Max anzubieten und in eigenen States abzulegen und so der aber gar nicht die History Adapter nutzt sondern slebst alle State-Änderungen subscribed und das komplett selbst ermittelt
-
...
Das coole an ioBroker ist ... jede Zielgruppe kann sich auf Ihre Art verwirklichen. Wenn Entwickler coole Ideen haben um regelmäßige Probleme der User so zu lösen das es einen Mehrwert gibt, geben diese Entwickler durchaus die Richtung des Projektes mit an. Jeder im Rahmen seiner Möglichkeiten.
-
-
Ich sag ja: "Ich lass das mal auf mich einige Zeit wirken…" :lol:
