Fehlermeldung in openhab logviewer

[SmartHomer]

Ich möchte ja nicht nur eine Vorhersage berechnen sondern ich möchte einen Vorhersagewert in Zeitabschnitten von 3 Stunden für die nächsten 5 Tage berechnen. Also insgesamt 40 Vorhersagewerte.

Wie schon im anderen Thread erwähnt, die ursprüngliche Rule läuft bei mir in weniger als einer halben Sekunde durch, wenn gültige Status vorhanden sind.

Auch diese Rule läuft bei mir nur sehr langsam ab. Ich kann gerne mal den Zeitstempel für den Start und für das Ende ausgeben lassen.

[SmartHomer]

Ich glaube wir haben die ganze Zeit aneinander vorbeigesprochen. Bei mir läuft die eigentliche Rechnung auch schnell durch.

Code: Alles auswählen

2018-08-18 19:04:00.701 [INFO ] [clipse.smarthome.model.script.pvcalc] - Rule Berechnung Cosinus Thetta getriggert
2018-08-18 19:04:01.634 [INFO ] [clipse.smarthome.model.script.pvcalc] - Rule Berechnung Cosinus Thetta durchgelaufen

Mein Problem ist nur, wenn ich über den Texteditor (VS Code) eine Änderung in meiner .rules Datei vornehme und diese dann speicher, dauert es sehr lange bis meine Rule getriggert wird und anfängt zu rechnen.

Wenn ich beispielsweise alle Dateien im Ordner Rules unter dem Pfad /etc/openhab2/rules ausschneide und im Anschluss über Putty mit dem Befehl sudo systemctl restart openhab2.service openHAB 2.3.0 neustarte und dann die rules-Dateien wieder in den Ordner einfüge kommt über den openHABlogviewer als erstes die Meldung

Code: Alles auswählen

2018-08-18 12:35:52.780 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Berechnung_Cosinus_Thetta.rules'
2018-08-18 12:36:35.275 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Berechnung_Sonnendeklination.rules'
2018-08-18 12:48:05.357 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Berechnung_Stundenwinkel.rules'
2018-08-18 12:51:06.027 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Berechnung_Zeitgleichung.rules'
2018-08-18 12:56:37.613 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Berechnung_Prognose_PV_Leistung.rules'
2018-08-18 12:56:40.524 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Umrechnung_Gradmaß_Bogenmaß.rules'
2018-08-18 12:56:51.829 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Abfrage_Datumswerte.rules'
.
.
.
2018-08-18 13:13:13.046 [INFO ] [eclipse.smarthome.model.script.pvcal] - Rule getriggert
2018-08-18 13:13:13.066 [INFO ] [clipse.smarthome.model.script.pvcalc] - Breitengrad_Grad: 48.8 °
2018-08-18 13:13:13.071 [vent.ItemStateChangedEvent] - numItem_Breitengrad_Grad changed from NULL to 48.8
2018-08-18 13:13:13.090 [INFO ] [clipse.smarthome.model.script.pvcalc] - Breitengrad_Bogen: 0.8517206749732888 rad
2018-08-18 13:13:13.092 [vent.ItemStateChangedEvent] - numItem_Breitengrad_Bogen changed from NULL to 0.8517206749732888
2018-08-18 13:13:13.152 [INFO ] [clipse.smarthome.model.script.pvcalc] - Azimutabweichung_Grad: 45.0 °
2018-08-18 13:13:13.172 [vent.ItemStateChangedEvent] - numItem_Azimutabweichung_Grad changed from NULL to 45.0
2018-08-18 13:13:24.417 [INFO ] [clipse.smarthome.model.script.pvcalc] - Azimutabweichung_Bogen: 0.7853981633975 rad
2018-08-18 13:13:24.426 [INFO ] [clipse.smarthome.model.script.pvcalc] - Aufstellwinkel_PV_Module_Grad: 30.0 °
2018-08-18 13:13:24.430 [vent.ItemStateChangedEvent] - numItem_Azimutabweichung_Bogen changed from NULL to 0.7853981633975
2018-08-18 13:13:24.434 [vent.ItemStateChangedEvent] - numItem_Aufstellwinkel_PV_Module_Grad changed from NULL to 30.0

Beachte ersten Zeitstempel (Loading model): 12:36:35 ==> Loading model 'Berechnung_Sonnendeklination.rules'
Beachte ersten Zeitstempel (Rule getriggert): 13:13:13 ==> Rule getriggert

Zu diesem Zeitpunkt sind aber noch immer nicht alle Regeln gestartet worden...

Die eigentliche Berechnung der Rule passiert dann relativ zügig nur bis die Rule zum Rechnen kommt dauert es sehr lange. Ich hoffe dadurch ist mein Problem vielleicht etwas klarer geworden?

[udo1toni]

Ah. ja, das ist ein anderes Problem. Leider kann ich das bei mir auch beobachten.
Man muss dazu verstehen, wie openHAB und VSCode zusammenspielen.

Wenn man in VSCode Eingaben macht, werden diese laufend in die Syntaxprüfung in openHAB geladen, und zwar, bevor man eine Datei abspeichert. Damit bekommt man unmittelbar Tippfehler angezeigt und die Anzeige möglicher Ergänzungen zum Getippten läuft natürlich auch darüber.
Leider ist der Code an dieser Stelle wohl suboptimal, so dass bei jedem einzelnen Buchstaben (Leerzeichen, das auch immer) das gesamte File übertragen wird. Das führt dazu, dass die Syntaxprüfung in openHAB extrem gefordert wird, darüberhinaus dauert die Prüfung immer länger, je größer das File wird.
Deshalb gehe ich davon aus, dass die Syntaxprüfung schneller funktioniert, wenn das Rules-File kurz ist, welches man bearbeitet. Während der Entwicklung sollte man also versuchen, die Rule am besten als einzelne Datei zu entwickeln. Wenn openHAB auf einem Raspberry läuft, kommt natürlich noch der eine oder andere Flaschenhals dazu, die langsame Netzanbinduung, der langsame Flashspeicher, die vergleichsweise starke Auslastung des Systems in Ruhe...
Man könnte versuchen, die Syntaxprüfung in VSCode abzuschalten (API-igendwas in den openHAB-Plugin-Einstellungen), womit man dann aber den wichtigsten Grund für VSCode verliert.
Da ich pragmatisch bin, wäre für mich ein gangbarer Weg, ein Entwicklungssystem hochzuziehen, und zwar in einer virtuellen Maschine, die direkt auf meinem Desktop läuft. Ist bei mir aber auch kein Problem, weil ich 8GByte Arbeitsspeicher habe, da flutscht der VMWare-Player mit einer headless-debian-Installation. So ein System ist in überschaubarer Zeit installiert:

1. VMWare Player runterladen
2. VMWare Player installieren
3. aktuelles debian-netinstall image runterladen
4. in VMWare Player eine virtuelle Maschine mit 1GByte Ram und 10GByte Plattenplatz anlegen, das debian-iso-image als Installationsmedium auswählen, für Netzwerk auf bridge-Modus umschalten, NAT macht nur Probleme.
5. Die Installation startet automatisch mit Start der virtuellen Maschine
6. debian mit Standard-Werten über Textinstallation einrichten, ohne Desktop
7. sobald debian läuft, mit root anmelden und ein

   Code: Alles auswählen

   apt update && apt full-upgrade

   ausführen
8. sudo installieren und einen User für Remotezugriff mit sudo-Rechten versehen:

   Code: Alles auswählen

   apt install sudo
   adduser <meinusername> sudo

9. ausloggen, die Konsole klein machen und stattdessen über ssh (z.B. putty) auf der virtuellen Maschine anmelden. Ab hier verhält sich debian exakt so, wie der Pi über ssh!
10. oracle oder zulu java von debian aus herunter laden und einrichten (von webupd8team gibt es ein Script, welches oracle in die Paketverwaltung integriert, so dass auch Updates einfach über apt update && apt full-upgrade installiert werden)
11. openHAB-Quellen einrichten und openHAB über

    Code: Alles auswählen

    sudo apt update && sudo apt install openhab2

    installieren
12. openHAB2 mit

    Code: Alles auswählen

    sudo systemctl enable openhab2.service

    im Autostart einbinden
13. samba installieren und Freigabe einrichten (siehe Doku von openHAB)
14. VSCode so konfigurieren, dass es auf die VM zugreift.

Das Ganze sollte nicht wesentlich länger als eine Stunde dauern, eine gewisse Computer-Affinität vorausgesetzt. Da Raspbian von debian abgeleitet ist, läuft der Teil exakt so wie auf dem Pi, also keine Umgewöhnung.
Lohn der Mühen ist ein autarkes openHAB-System, welches auf Anforderung innerhalb weniger Minuten auf dem Desktop-PC gestartet wird, wenn man etwas entwickeln oder ausprobieren möchte. Die fertigen Rules kopiert man dann in das echte System. Im Entwicklungssystem sollten natürlich nur jeweils die Dinge vorgehalten werden, die für die jeweilige Entwicklung unverzichtbar sind, also nur wenige Addons, nur die nötigen Things, nur die benötigten Items, keine überflüssigen Rules.

[der_pman]

Ich würde das Thema noch einmal hochholen wollen
Ich habe am Wochenende mein System neu aufgesetzt (odroidM1, Ubuntu22.04 und openhab 3.4.4) und jetzt tauchen in bisher funktionierenden Rules folgende Fehler auf.
Das alte System war ein openhabian auf einem raspi4 und per Update auf einem aktuellen Stand (3.4.4).

Code: Alles auswählen

2023-07-24 23:58:49.903 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'wama-1' failed: Could not cast NULL to java.lang.Number; line 16, column 23, length 28 in wama
2023-07-24 23:59:00.641 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'Stromverbrauch-1' failed: Could not cast NULL to java.lang.Number; line 5, column 38, length 31 in Stromverbrauch
2023-07-24 23:59:00.641 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'Einspeisung-1' failed: Could not cast NULL to java.lang.Number; line 5, column 39, length 33 in Einspeisung

Es handelt sich um folgende Rules:

wama.rules

Code: Alles auswählen

rule "Waschmaschine Verbrauch Status"
when
    Item WAMA_Verbrauch changed
then
    val power = ((WAMA_Verbrauch.state as Number).floatValue)
    var newMode = 0
    var message = "Waschmaschine: "
    if (power < 0.2) {
        message = message + "MODE_OFF"
    }
    else if (power > 5) {
        newMode = 2
        message = message + "MODE_ACTIVE"
    }
    else {         // zwischen 0.2 und 5
        val opState = ((WAMA_OPSTATE.state as Number).floatValue)
        if (opState == 0) {
            newMode = 1
            message = message + "MODE_STANDBY"
        }
        else if (opState == 2) {
            newMode = 3
            message = message + "MODE_FINISHED"
        }
    }
    if((WAMA_OPSTATE.state as Number) != newMode) {
        WAMA_OPSTATE.postUpdate(newMode)
    } else
        message = "Waschmaschine: Keine Änderung"
    logInfo("washer",message)
end

Einspeisung.rules

Code: Alles auswählen

rule "Letzter tägliche Einspeisung"
when
   		Time cron "0 59 23 * * ?"
then
	var Number letzteTageseinspeisung = (Strom_Eingespeist.state as Number) - (Strom_Eingespeist.historicState(now.minusMinutes(5)).state as Number)
	if(Strom_Eingespeist.state != letzteTageseinspeisung)
	logInfo("Einspeisung.rules", "Zahlenkontrolle Stand: {}, DB:{}", Strom_Eingespeist.state, Strom_Eingespeist.historicState(now.minusMinutes(5)).state)
	{
		Strom_letzte_Tageseinspeisung.postUpdate(letzteTageseinspeisung)
	}
end

Stromverbrauch.rules

Code: Alles auswählen

rule "Letzter täglicher Stromverbrauch"
when
   		Time cron "0 59 23 * * ?"
then
	var Number letzterTagesverbrauch = (Strom_Verbrauch.state as Number) - (Strom_Verbrauch.historicState(now.minusMinutes(5)).state as Number)
	if(Strom_Letzter_Tagesverbrauch.state != letzterTagesverbrauch)
	logInfo("Stromverbrauch.rules", "Zahlenkontrolle Stand: {}, DB:{}", Strom_Verbrauch.state, Strom_Verbrauch.historicState(now.minusMinutes(5)).state)
	{
		Strom_Letzter_Tagesverbrauch.postUpdate(letzterTagesverbrauch)
	}
end

wama soll prüfen ob die Waschmaschine noch Strom verbraucht und eine Meldung senden wenn sie fertig ist.
Einspeisung und Stromverbrauch berechnen Werte aus der influxdb und schreiben die Ergebnisse wieder in die Items und die Datenbank zurück.

Habt Ihr eventuell eine Idee?

Gruß Bernd

[udo1toni]

Na ja, steht eigentlich ganz eindeutig da...
openHAB kann aus NULL keine gültige Zahl ableiten (Could not cast NULL to java.lang.Number)
Wie immer ist es ratsam, vor einem myItem.state as Number zu prüfen, ob myItem.state überhaupt vom Typ Number ist if(myItem.state instanceof Number)
Insbesondere bei persistierten Items und dem Bezug eines historischen Wertes aus der Persistence ist hier Vorsicht geboten. MAn tut gut daran, hier mit Variablen zu arbeiten, die zur Not einen Default Wert erhalten, falls die Rule keinen gültigen Wert ermitteln kann (alternativ lässt man die Rule an dieser Stelle abbrechen, falls ein Default Wert nicht hilfreich ist)