Rule triggert nicht mehr / sporadische Fehlermeldungen

[migal]

Hallo zusammen,

ich habe eine rule strom.rules unter Openhab 3.0.2 laufen, die zunächst funktioniert und macht, was sie soll, die aber nach nach einiger Zeit (Stunden, manchmal über Nacht) nicht mehr triggert. Der Trigger ist die Änderung der Wirkleistung eines Wechselrichters.
In den logs gibt es keine Fehlermeldung.

Nach editieren und upload des files kam vorhin dieser Fehler, wobei die rule dennoch funktioniert:

2021-06-11 11:54:55.036 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'strom.rules'
2021-06-11 11:54:55.694 [ERROR] [enhab.core.model.script.actions.HTTP] - Fatal transport error: java.lang.InterruptedException
2021-06-11 11:54:55.939 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'strom-1' failed: The name '<unkown>' cannot be resolved to an item or type; line 0, column 0 in strom

Eben nach edit/upload dieser Fehler, rule läuft dennoch:

2021-06-11 12:10:30.860 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'strom-1' failed: Script interpreter couldn't be obtain in strom

Diese Fehlermeldungen im log sind aber nicht reproduzierbar, meistens kommt gar keine.

Kann jemand mit den Fehlermeldungen was anfangen? Ich komme überhaupt nicht weiter ...

rule "Photovoltaik"

// gesamte Wirkleistung
// Poolheizung und Klimaanlage nach PV-Erzeugung steuern

when

Item SB30Wirkleistung changed

then
if ((TP20Wirkleistung.state instanceof Number) && (SB30Wirkleistung.state instanceof Number))

{
PVGesWirk.postUpdate(TP20Wirkleistung.state as Number + SB30Wirkleistung.state as Number)
}

else

{
PVGesWirk.postUpdate(0)
}


if (!(PoolHeizstatus.state instanceof Number))

{
PoolHeizstatus.postUpdate(0)
logInfo("PV", "Poolheizung Status auf 0 gesetzt")
}


if ( (PVGesWirk.state as Number) < 5000 && (PVGesWirk.state as Number) > 1000) // unter 1000 nicht mehr ausschalten

{

sendHttpGetRequest("http://192.168.1.117/modify?0003=1234")
sendHttpGetRequest("http://192.168.1.117/modify?0110=5")
sendHttpGetRequest("http://192.168.1.117/modify?0003=0000")
// logInfo("PV", "Poolheizung AUS")
PoolHeizstatus.postUpdate(0)

}


if ( (PVGesWirk.state as Number) > 7000)

{

sendHttpGetRequest("http://192.168.1.117/modify?0003=1234")
sendHttpGetRequest("http://192.168.1.117/modify?0110=32")
sendHttpGetRequest("http://192.168.1.117/modify?0003=0000")
// logInfo("PV", "Poolheizung AN")
PoolHeizstatus.postUpdate(1)

}


if ( (PVGesWirk.state as Number) > 12000)

{

// logInfo("PV", "Klimaanlage AN")
AirconPower.postUpdate(ON)

}


if ( (PVGesWirk.state as Number) < 9000 && (PVGesWirk.state as Number) > 5000) // unter 5000 nicht mehr ausschalten, damit man abends manuell schalten kann

{

// logInfo("PV", "Klimaanlage AUS")
AirconPower.postUpdate(OFF)

}


logInfo( "PV", "Poolheizung : {}", PoolHeizstatus.state.toString )
logInfo( "PV", "Klimaanlage : {}", AirconPower.state.toString )

end

[udo1toni]

Warum Deine Rule irgendwann aufhört, zu funktionieren, kann ich leider auch nicht beantworten.

Der erste Fehler deutet auf einen Lesefehler hin (The name '<unkown>' cannot be resolved to an item or type;)
Der zweite Fehler ist auch ziemlich obskur. (Script interpreter couldn't be obtain in strom) Ich denke, das ist nicht die vollständige Fehlermeldung).

Allgemein wäre es vermutlich besser, mindestens eine lokale Variable zu verwenden (Laufzeitoptimierung):

rule "Photovoltaik"                                                 // Poolheizung und Klimaanlage nach PV-Erzeugung steuern, gesamte Wirkleistung
 when
    Item SB30Wirkleistung changed
 then
    var Number nWirk = 0
    if((TP20Wirkleistung.state instanceof Number) && (SB30Wirkleistung.state instanceof Number))
        nWirk = (TP20Wirkleistung.state as Number) + (SB30Wirkleistung.state as Number)

    PVGesWirk.postUpdate(nWirk)

    var Number nPool = 0
    if(PoolHeizstatus.state instanceof Number)
        nPool = (PoolHeizstatus.state as Number)

    if(nWirk < 5000 && nWirk > 1000) {                              // unter 1000 nicht mehr ausschalten
        sendHttpGetRequest("http://192.168.1.117/modify?0003=1234")
        sendHttpGetRequest("http://192.168.1.117/modify?0110=5")
        sendHttpGetRequest("http://192.168.1.117/modify?0003=0000")
        // logInfo("PV", "Poolheizung AUS")
        nPool = 0
    }
    if(nWirk > 7000) {
        sendHttpGetRequest("http://192.168.1.117/modify?0003=1234")
        sendHttpGetRequest("http://192.168.1.117/modify?0110=32")
        sendHttpGetRequest("http://192.168.1.117/modify?0003=0000")
        // logInfo("PV", "Poolheizung AN")
        nPool = 1
    }
    if(PoolHeizstatus.state != nPool)
        PoolHeizstatus.postUpdate(nPool)

    if(nWirk > 12000) {
        // logInfo("PV", "Klimaanlage AN")
        AirconPower.postUpdate(ON)
    }
    if(nWirk < 9000 && nWirk > 5000) {                              // unter 5000 nicht mehr ausschalten, damit man abends manuell schalten kann
        // logInfo("PV", "Klimaanlage AUS")
        AirconPower.postUpdate(OFF)
    }
    logInfo( "PV", "Klimaanlage : {}", AirconPower.state)
    logInfo( "PV", "Poolheizung : {}", nPool)
 end

Die Wirkung sollte (bis auf die eine fehlende Logmeldung) identisch sein. Es wird aber nur einmal die Wirkleistung berechnet und in das Item geschrieben (für die UI), lokal wird auf die Variable zugegriffen, womit der openHAB Bus nicht mehr abgefragt werden muss. Es geht hier immerhin um sechs Abfragen, und es ist noch nicht mal klar, ob der oben geschriebene Wert auch tatsächlich unmittelbar geliefert wird. Im Fall der Poolheizung ist die Verwendung der Variablen eher kosmetisch.

[migal]

Vielen Dank für Deine Hinweise! Auf einen Lesefehler als Ursache für den ersten komischen Fehler wäre ich gar nicht gekommen.
Ich werde dann mal als erstes ein neues Openhabian auf einer neuen SD Karte aufsetzen.

[udo1toni]

Ja, das ist natürlich nicht sicher, wäre abeer mein erster Tipp.

[migal]

Die Neuinstallation auf eine andere SD Karte könnte geholfen haben. Ich habe auch Deinen code mit den beiden Variablen übernommen.
Die rule läuft momentan ohne Fehlermeldungen, Klimaanlage und die Heizanforderung werden bei jeder Änderung der Leistung des Wechselrichters geschaltet.

Da der Wechselrichter oft, teilweise mehrfach die Minute seinen Status ändert wäre es gut, wenn die Befehle an Heizung und Klima nur abgeschickt werden, wenn sich deren Status ändern müsste. Wenn Klima bzw Heizung bereits an ist, müsste ja nicht erneut der Befehl "an" gesendet werden. Das würde den Bus nochmals entlasten.

rule "Photovoltaik" // Poolheizung und Klimaanlage nach PV-Erzeugung steuern, gesamte Wirkleistung
when
Item SB30Wirkleistung changed
then
var Number nWirk = 0
if((TP20Wirkleistung.state instanceof Number) && (SB30Wirkleistung.state instanceof Number))
nWirk = (TP20Wirkleistung.state as Number) + (SB30Wirkleistung.state as Number)

PVGesWirk.postUpdate(nWirk)

var Number nPool = 0
if(PoolHeizstatus.state instanceof Number)
nPool = (PoolHeizstatus.state as Number)

if(nWirk < 5000 && nPool == 1) {
sendHttpGetRequest("http://192.168.1.117/modify?0003=1234")
sendHttpGetRequest("http://192.168.1.117/modify?0110=5")
sendHttpGetRequest("http://192.168.1.117/modify?0003=0000")
nPool = 0
logInfo( "PV", "Poolheizung : {}", nPool)
}

if(nWirk > 7000 && nPool == 0) {
sendHttpGetRequest("http://192.168.1.117/modify?0003=1234")
sendHttpGetRequest("http://192.168.1.117/modify?0110=32")
sendHttpGetRequest("http://192.168.1.117/modify?0003=0000")
nPool = 1
logInfo( "PV", "Poolheizung : {}", nPool)
}

if(PoolHeizstatus.state != nPool)
PoolHeizstatus.postUpdate(nPool)




if(nWirk > 12000) {
if (AirconPower.state != ON) {
AirconPower.sendCommand(ON)
logInfo( "PV", "Klimaanlage : {}", AirconPower.state)
}
}

if(nWirk < 9000 && nWirk > 5000) { // unter 5000 nicht mehr ausschalten, damit man abends manuell schalten kann
if (AirconPower.state != OFF) {
AirconPower.sendCommand(OFF)
logInfo( "PV", "Klimaanlage : {}", AirconPower.state)
}
}

end

[migal]

Nach einem Tag funktioniert die rule problemlos, ich denke, das Problem ist beseitigt.

Bei der Neuinstallation bin ich auf ein neues Problem gestoßen: ich nutze Grafana mit InfluxDB seit längerer Zeit unter OH2.5 und auch unter OH3.
Die Installation über das config-tool von openhab hatte funktioniert, und Grafana auch. Nach jedem reboot der RPi ist jedoch das Verzeichnis var/log/grafana weg und der grafana Dienst ist auch nicht gestartet. Ich habe in der englischen community etwas dazu gefunden, nämlich das Verzeichnis neu anzulegen, die Rechte zu setzen und den Dienst zu starten, allerdings ist bei mir auch dann nach reboot wieder das Verzeichnis var/log/grafana weg.

Hat jemand eine Idee hierzu?

[udo1toni]

Mit dem "config-tool" meinst Du vermutlich openhabian-config?

Nutzt Du ZRAM? Dann müsstest Du den RPi mal korrekt runterfahren, damit ZRAM die Änderungen (eben das Anlegen und Befüllen des Verzeichnisses /var/log/grafana) einmal auf ide Karte speichert.

Korrekt herunterfahren:

Eigentlich sollte sowohl sudo poweroff als auch sudo shutdown -h now zum Ziel führen.

Nach dem erneuten Hochfahren müsste das Verzeichnis da sein und Grafana starten. Falls das Verzeichnis da ist, aber Grafana immer noch nicht startet, prüfe noch, ob der Dienst enabled ist: systemctl status grafana.service sollte darüber Auskunft geben. Steht da was von disabled, rufe einmalig sudo systemctl enable grafana.service auf.

[migal]

Ja, openhabian-config war gemeint. Ich bin gestern auch noch auf das Thema ZRAM gestossen. Das ist bei openhabian-Installation per default aktiviert, das war mir so gar nicht klar. Jedenfalls war das das Problem.
Genau wie Du sagst muss man shutdown -h nutzen, was ich nicht oder nicht immer gemacht habe. Auch hatte ich den Befehl reboot genutzt, und dabei schreibt ZRAM auch nicht mehr auf die Karte.

Ich habe dann nochmals neu installiert und als erstes in openhabian-config ZRAM deaktiviert. Danach lief die Installation problemlos weiter, Grafana läuft, alle Verzeichnisse sind da und auch die rules sind in Ordnung.

Ich weiß jetzt nicht, wie stark die SD Karte nun ohne ZRAM jetzt belastet ist - ich habe schon viele Items in der persistence, so dass es eher viele Zugriffe auf die Karte gibt. Also mehr Backups machen ...

[udo1toni]

ZRAM ist grundsätzlich eine gute Sache, damit ist Wearout eigentlich kein Thema mehr. Man muss es halt im Hinterkopf behalten, dass man das System (mindestens zwischendurch, wenn man neue Sachen installiert hat) sauber herunterfährt und neu startet (Reboot ginge mit shutdown -r now ebenfalls), um ZRAM die Chance zu geben, die geforderten Daten einmalig auf die Karte zu schreiben. Ansonsten sollte man ZRAM im täglichen Betrieb nicht bemerken (insbesondere nicht negativ).
Da die MicroSD-Karten wegen des intensiven Loggings sehr stark belastet werden, sollte man da schon sehr gute Gründe haben, ZRAM nicht einzusetzen.

Für den Hinterkopf: eine SD-Karte hat keinen SSD-Controller, das heißt, die Mechanismen, die in SSDs eingebaut sind, um das Wearout möglichst gleichmäßig zu verteilen (indem stark beanspruchte Bereiche bevorzugt mit statischen Daten beschrieben werden), gibt es in der Form für SD-Karten nicht. Wobei ich irgendwo mal davon gelesen habe, dass es doch solche Karten gibt, die dann aber vielfach teurer sind als gleichgroße "gewöhnliche" Modelle.
Man kann den Raspberry auch direkt von einer SSD booten (mit entsprechender Firmware, die es für alle aktuellen Modelle gibt) oder alternativ von SD-Karte booten (die ro eingebunden ist), das eigentliche Betriebssystem aber auf der SSD parken. Das ist natürlich beides nur mit einem Raspberry 4 sinnvoll, da nur der echtes USB3 mit entsprechender Geschwindigkeit bietet.

[nipponichi]

Bis auf die SmartMedia und xD Karten, die um die Jahrtausendwende gängig waren, haben alle Flash-Karten einen eingebauten Controller.
(Die CompactFlash-Beführworter aus dem Fotobereich haben oft behauptet, SD-Karten hätten keinen, aber das ist quatsch, und CF spielt heute keine Rolle mehr.)

Es wird tatsächlich ernsthaft diskutiert, ob SD-Karten wear leveling verwenden, mich hat das überrascht. Aber die Markenhersteller sagen selbst, es wäre implementiert.
Bei wenigen tausend Zyklen pro Sektor würde mich alles andere aber auch überraschen.

[migal]

Ich werde ZRAM wieder aktivieren, wenn ich den Umzug auf OH3 abgeschlossen habe. Im Prinzip startet man ja den RPi selten neu, aber im Rahmen des Umzugs kam es halt doch vor. Jetzt bin ich entsprechend sensibilisiert. Wahrscheinlich war das neu starten mit aktivem ZRAM auch der Grund für die komischen Fehler, wegen derer ich den Thread hier überhaupt gestartet hatte.

Das Betriebssystem auf SSD auszulagern wäre sicher eine gute Sache, wobei ich gerade mit dem Linux Filesystem ein wenig auf Kriegsfuß stehe. RPi4 ist vorhanden.

[nipponichi]

Bei ZRAM fehlt mir ein sync-Mechanismus, dass man die aktuellen Daten im ZRAM gezielt ins Flash speichern kann. Stürzt das System ab, ist alles seit dem letzten ordnungsgemäßen Herunterfahren weg. Neulich hat mir ein USB-Seriell-Wandler das System einmal täglich zum Absturz gebracht (vermute kernel panic, aber nichts in den Logs zu finden), da wäre ZRAM schon nachteilig (im Moment ist es abgestellt).
Im Verzeichnisbaum sind die Dateien ja sowohl im Flash als auch im ZRAM zugreifbar. Ob man die einfach zu Fuß gelegentlich kopieren kann? Erhält man korrupierte Dateien, wenn eine Datei beim Kopieren gleichzeitig geschrieben wird?

[migal]

Ich hatte den Diskussionen in der englischen community entnommen, dass ZRAM zu Schwierigkeiten führen kann und wohl auch nicht besonders gut/verständlich dokumentiert ist: https://community.openhab.org/t/zram-status/80996/119
Daher habe ich es als Direktmaßnahme auch erstmal abgestellt.