RR727 hat geschrieben: ↑5. Dez 2023 12:29
Ich habe jetzt bedenken, ob die Geschichte meinen Rasp-Pi gut tut, da ich bedenken habe, dass damit der Speicher schneller beschädigt werden könnte, ist da etwas dran?
Definitiv nicht von dem einen Item
und wenn Du das offizielle Image für den Pi verwendest (openHABian), dann sollte ZRAM aktiv sein, welches sämtliche Schreibzugriffe ohnehin ins RAM umleitet - eben um vorzeitiges Wearout der SD-Karte zu verhindern.
Fronius_Symo_Inverter_AC_Power ist vom Typ
Number:Power? Dann ist schon die Annahme verkehrt, dass Du aus dem Mittelwert eine vernünftige Aussage über die Energiemenge treffen könntest
Deine Rule kann so nicht funktionieren, denn Du vermischst DSL und JavaScript.
Korrekt wäre die Rule so:
Code: Alles auswählen
configuration: {}
triggers:
- id: "1"
configuration:
cronExpression: 0 * 9-18 * * ?
type: timer.GenericCronTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/vnd.openhab.dsl.rule
script: >
var mittelwert = Fronius_Symo_Inverter_AC_Power.averageSince(now.minusMinutes(15))
logInfo("mittelwert", "Mittelwert der letzten 15 Minuten: {}", mittelwert)
PVMittelwert.postUpdate(mittelwert)
type: script.ScriptAction
Wobei es noch ein paar Dinge zu beachten gibt...
Erstmal die offensichtlichen Unterschiede DSL<->JavaScript:
Grundsätzlich gibt es kein Semikolon am Ende eines Befehls. Die einzige Ausnahme zum Grundsatz: mit dem Befehl
return; kann man die Rule frühzeitig abbrechen. return liefert gewöhnlich immer einen Rückgabewert, was aber im Zusammenhang mit Rules nicht funktioniert, da es keine aufrufende Funktion gibt, der ein Wert übergeben werden könnte. Deshalb muss dediziert
null als Rückgabewert gesetzt werden, was mit dem Semikolon erreicht wird.
Items stehen direkt als Objekte zur Verfügung, man greift niemals indirekt auf Items zu (also
Fronius_Symo_Inverter_AC_Power.state statt
Items.getItem("Fronius_Symo_Inverter_AC_Power").getState)
.sendCommand() tut genau das: es sendet ein Kommando. Du möchtest den Status eines Items setzen, dazu wird
.postUpdate() verwendet. Es mag auf den ersten Blick nicht auffallen, weil openHAB (default) für jedes
.sendCommand() ein passendes
.postUpdate() erzeugt, aber zum Einen kann man diese Funktion abschalten (
autoupdate=false), zum Anderen kann das schief gehen und ist mindestens langsamer als das
.postUpdate()
Zum Befehl
logInfo(): Der erste der zwei Strings ist der letzte Teil des Loggernamens, der erste Teil lautet immer
org.openhab.core.model.script., und der Loggername wird genutzt, um das Verhalten des Loggers zu steuern (ob die
logInfo() Befehle beachtet werden oder nicht) rules ist kein guter Loggername (und der erste Teil des vollständigen Loggernamens ist ohnehin fix und verweist auf scripts)
Außerdem beherrscht logInfo Substitution, jedes Klammerpaar {} wird durch den Inhalt der nachfolgenden Variablen ersetzt (das ist wichtig, weil die Substitution auch Typumwandlung beherrscht, im Gegensatz zum verknüpfen von Strings (und im Gegensatz zum Schreiben in das Item braucht es hier zwingend das .toString, nur ist openHAB hier sehr gnädig und setzt .toString automatisch.
Wie gesagt, beim
.postUpdate() (und auch bei
.sendCommand()) braucht es kein .toString.
Es kann allerdings gut sein, dass die Umwandlung der Units Probleme macht, je nachdem, ob die Persistence die Unit mit ausliefert oder nicht. Im Zweifel kannst Du die Unit so loswerden:
Code: Alles auswählen
var mittelwert = (Fronius_Symo_Inverter_AC_Power.averageSince(now.minusMinutes(15)) as Number).floatValue
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
