Ich arbeite halt nicht mit Blockly, ich bin es gewohnt, Code hinzuschreiben. Das Blöcke Schubsen ist für mich immer ein Stück weit Rätsel Raten.
Was die "Datenbanken" betrifft: Default erzeugt openHAB3 für jedes Item eine rrd-Datei. Allerdings kann rrd4j gar nicht mit allen Itemtypen umgehen, andererseits sind die Dateien nicht so wahnsinnig groß (also für 2023er Verhältnisse).
Legt man eine externe Datenbank an, so wird für jedes Item eine Tabelle angelegt. Will man bestimmte Items nicht persistieren lassen, so muss man eine passende *.persist Datei für den Service anlegen, also z.B. rrd4j.persist für die rrd4j Persistence. Dort kann man genau defnieren, welche Items persistiert werden sollen. Wichtig ist aber, dass rrd4j mindestens einen Wert pro Minute persistieren muss, weshalb für diese Persistence eine minütliche Time cron Strategy zwingend gesetzt werden muss. Da rrd eine statische Dateigröße hat, die sich niemals ändert, hat das Speichern ohne Wertänderung aber keinen negativen Effekt.
Was die Group zum summieren betrifft: Du kannst selbstverständlich machen, was Du willst
und solange es sich nur um zwei Items handelt wird es auch keine Rolle spielen, ob ich ein Group Item zum Rechnen verwende oder in einer Rule beide Status auslese und addiere.
Aber stelle Dir bitte mal vor, Du hast im eine Doppelhaushälfte und dort in jedem Zimmer einen Temperatursenor. Du möchtest nun zusätzlich zu allen Raumtemperaturen auch noch die hausweite Durchschnittstemperatur wissen. Da die Haushälfte über zehn Räume verfügt, musst Du zehn Items innerhalb der Rule benennen, um sie miteinander zu addieren. Außerdem musst Du die Items von Hand zählen und durch die Anzahl teilen.
Und nun kaufst Du andere Hälfte auch noch und hast plötzlich 20 Räume (Junge, Du scheinst Geld zu haben...
) Und jetzt musst Du Deine Rule anpassen und um weitere zehn Items ergänzen. Außerdem musst Du den Divisor anpassen.
Meine Zeilen dazu:
Code: Alles auswählen
var nTemp = 0
gTemp.members.forEach[i|nTemp += (i.state as Number).floatValue]
Durchschnitt.postUpdate(nTemp/gTemp.members.size)
Es ist egal, wieviele Räume das Haus hat, zwei, zwanzig, fünfhundert... allenfalls braucht die Rule bei fünfhundert Räumen zwei Sekunden länger, als bei zwei Räumen.
Natürlich ist das Beispiel mit der Durchschnittstemperatur sehr konstruiert (also der Teil mit der Änderung der Anzahl der Items innerhalb der Gruppe), bei WLAN Steckdosen und dem gemessenen Stromverbrauch pro Steckdose sieht das aber schon anders aus, vielleicht kauft man da nach und nach immer mal wieder ein weiteres Gerät dazu. Über Gruppe und Rule legt man lediglich jeweils ein Item für die neue Steckdose an (vielleicht gar halbautomatisch mittels Autodiscovery) und packt es in die Gruppe, der Rest bleibt gleich.
