Weihnachtsangebot 2025! 🎄

[Stabilostick]

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. :D

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... ;)

[apollon77]

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.

[Stabilostick]

Ich sag ja: "Ich lass das mal auf mich einige Zeit wirken…" :lol: