Probleme mit der Migration einer rule [Umstieg von Openhab2 auf 3]

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
Eleven
Beiträge: 53
Registriert: 15. Okt 2018 10:27
Answers: 0

Probleme mit der Migration einer rule [Umstieg von Openhab2 auf 3]

Beitrag von Eleven »

Hallo liebes OpenHAB-Forum,

in OpenHAB 2.x wurde mittels einer rule einmal am Tag der Batteriezustand aller batteriebetriebenen Things überprüft und sobald ein Gerät bei 10% angekommen ist kam eine Pushover Nachricht. Leider funktioniert diese rule nach der Umstellung nicht mehr.
Da ich die rule nicht selbst geschrieben habe und mir bei so umfangreichen recht schwer tue, benötigt ich Eure Hilfe.
Wie ich in der Pushover Dokumentation entnommen habe ist die neue Schreibweise etwas anders. Leider habe ich bei der rule keine Ahnung wie diese dort einbauen soll.

Ich hoffe ihr könnt mir weiterhelfen.

Hier mal die Config:

Items (es sind natürlich mehrere, hier exemplarisch ein item)

Code: Alles auswählen

Group	gBatteryStatus			"Battery state"						<measure_battery_75>

Number 	WZKR_Heizung_Battery 	"HZ_Wohnzimmer klein rechts [%s %%]"	<battery>           		(gBatteryStatus)             

Code: Alles auswählen

rule "Publish Battery Status"
when

    Time cron "0 0 18 ? * * *"

then

    val String ruleIdentifier = "Publish Battery Status"

    val Integer batteryThreshold = 10 // %. This should be enough to change the battery within a few days
    val StringBuilder aMessage = new StringBuilder

    var Integer emptyBatteries = 0

    emptyBatteries = gBatteryStatus.members.filter[ i | ((i.state instanceof DecimalType) && (i.state < batteryThreshold)) || ((i.state instanceof OnOffType) && (i.state == ON)) ].size

    logInfo(ruleIdentifier, "Bei der täglichen Batterieprüfung wurden {} leere Batterien zum Melden gefunden!", emptyBatteries)

    if (emptyBatteries != 0) {

        aMessage.append("-> Batteriestatusreport <-\n")
        gBatteryStatus.members.filter[ i | ((i.state instanceof DecimalType) && (i.state < batteryThreshold)) || ((i.state instanceof OnOffType) && (i.state == ON)) ].forEach[ aBattery | 
            aMessage.append(aBattery.label+": Batt="+aBattery.state+"%\n")
        ]
        aMessage.append("-> Ende <-")

        sendPushoverMessage(pushoverBuilder(aMessage.toString).withDevice("iPhoneXR"))
        logInfo(ruleIdentifier, "Information zu {} leeren Batterien wurde veröffentlicht!", emptyBatteries)

    }

end

Benutzeravatar
udo1toni
Beiträge: 15249
Registriert: 11. Apr 2018 18:05
Answers: 242
Wohnort: Darmstadt

Re: Probleme mit der Migration einer rule [Umstieg von Openhab2 auf 3]

Beitrag von udo1toni »

Eigentlich sollte das keine große Sache sein. Zunächst brauchst Du ein Pushover Thing mit dem Account. Dieses Thing hat eine UID. In Textform definiert sieht das so aus:

Code: Alles auswählen

Thing pushover:pushover-account:account [ apikey="APP_TOKEN", user="USER_KEY" ]
Dann musst Du in der Rule einen Handle für den Account erzeugen. Ich habe die Rule nicht getestet, aber bis auf das geänderte pushover sollte sie ja eigentlich unverändert funktionieren, also unter OH3 so:

Code: Alles auswählen

rule "Publish Battery Status"
when
    Time cron "0 0 18 ? * * *"
then
    val actions = getActions("pushover", "pushover:pushover-account:account") // get handle for pushover account
    val String ruleIdentifier = "publishBatteryStatus"  // please no spaces!
    val Integer batteryThreshold = 10                        // %. This should be enough to change the battery within a few days
    val StringBuilder aMessage = new StringBuilder
    var Integer emptyBatteries = 0
    emptyBatteries = gBatteryStatus.members.filter[ i |
        ((i.state instanceof DecimalType) && (i.state < batteryThreshold)) || ((i.state instanceof OnOffType) && (i.state == ON)) ].size

    logInfo(ruleIdentifier, "Bei der täglichen Batterieprüfung wurden {} leere Batterien zum Melden gefunden!", emptyBatteries)
    if (emptyBatteries != 0) {
        aMessage.append("-> Batteriestatusreport <-\n")
        gBatteryStatus.members.filter[ i |
            ((i.state instanceof DecimalType) && (i.state < batteryThreshold)) || ((i.state instanceof OnOffType) && (i.state == ON)) ].forEach[ aBattery | 
            aMessage.append(aBattery.label+": Batt="+aBattery.state+"%\n")
        ]
        aMessage.append("-> Ende <-")
        actions.sendHtmlMessage(aMessage.toString,"openHAB")   // send Messge with handle
        logInfo(ruleIdentifier, "Information zu {} leeren Batterien wurde veröffentlicht!", emptyBatteries)
    }
end
In der ersten Codezeile wird der Handle geholt, in der viertletzten Zeile wird die Nachricht verschickt.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet

Eleven
Beiträge: 53
Registriert: 15. Okt 2018 10:27
Answers: 0

Re: Probleme mit der Migration einer rule [Umstieg von Openhab2 auf 3]

Beitrag von Eleven »

Hallo Udo1toni, hallo liebes Forum,

was soll man dazu noch sagen, es läuft wie gewünscht ohne irgendwelche Fehler!
Udo1toni, Du hast mir mittlerweile schon so oft bei Problemen geholfen, dafür möchte ich mich nochmal ganz herzlich bei Dir bedanken.
Gleiches gilt natürlich auch für das gesamte Forum. Ohne euch hätte ich mein Projekt "Hausautomatisierung" schon lange aufgegeben.
Vielen vielen Dank!!

Liebe Grüße

P.S.: Macht es bei OpenHAB 3 im allgemeinen überhaupt noch Sinn, rules in DSL zu schreiben? Ich finde mich nach der Umstellung von OpenHAB 2 auf 3 noch recht schwer zurecht. Ich habe mir schon so viele Videos bzgl. Erstellung von Models, Pages und Rules, etc. angesehen, es fühlt sich alles einfach noch fremd an. Aktuell arbeite ich noch sehr "klassisch" also mit VScode und einer Basic ui, möchte mich aber in Zukunft mehr damit beschäftigen.

Benutzeravatar
udo1toni
Beiträge: 15249
Registriert: 11. Apr 2018 18:05
Answers: 242
Wohnort: Darmstadt

Re: Probleme mit der Migration einer rule [Umstieg von Openhab2 auf 3]

Beitrag von udo1toni »

Das schöne an openHAB3 ist ja, dass Du es von openHAB2 kommend zu 99 % so bedienen kannst, wie unter openHAB2 gewohnt (also bis auf Paper UI, welches durch Main UI abgelöst wurde). Wenn Du direkt von openHAB1 kommst (nun ja, etwas aus der Zeit gefallen...) musst Du "nur" lernen, dass Du die Hardware nicht mehr innerhalb des Items programmierst, sondern ausschließlich über Things und Channels. Wenn Du von openHAB2 kommst, kennst Du die Things und Channels mit hoher Wahrscheinlichkeit schon, so dass Du maximal ein paar Bindings umstellen musst, die unter openHAB2 nie offiziell mit einem OH2-Binding ersetzt wurden (z.B. http... gab es auch für OH2, aber nie offiziell über das Repository, nur über manuelle Installation).

Wenn Du natürlich neue Features nutzen willst (also über die reine Verwaltung per Main UI hinaus), musst Du auch neue oder zusätzliche Methoden der Konfiguration erlernen.
Das Semantic Model z.B. lässt sich zu 100 % über ganz normale Items abbilden, mittels Textdatei. Dabei müssen die Tags halt mit angegeben werden, das Semantic Model ist auch nichts anderes als Group Items, welche getaggt sind.
Das Schicke daran: man kann sich automatisiert Übersichten für Geräte, Topologie und Eigenschaften erzeugen lassen (und man kann diese zusätzlich noch manipulieren).
Will man die Main UI auch zum Steuern verwenden, so muss man diese aber über die UI selbst programmieren oder zumindest den Code in yaml ins System schmuggeln (mir wäre jetzt kein direkter Import per Textdatei bekannt).

Was die DSL betrifft, so gab es lange Zeit von den Entwicklern die Aussage, dass diese abgeschafft würde. Das hat mit den dafür verwendeten Techniken zu tun, XTend stellt die DSL zur Verfügung und man wollte das los werden. Es hat sich aber rausgestellt, dass es nicht so wild ist, das zu integrieren (wie auch immer... ich bin kein Entwickler...) und jetzt gibt es keine Ansage mehr, dass die DSL raus fliegt.
Noch wichtiger: Es gibt bis zum heutigen Tag (!) keinen offiziellen Nachfolger. Die DSL ist die einzige Konstante in openHAB (wenn man es so ausdrücken möchte). Man kann eine OH1 Rule ohne Probleme in OH3 laufen lassen - wurden Bezüge zu Joda Time verwendet, sind natürlich Anpassungen nötig, die aber, wenn man mal den Bogen raus hat, fast als trivial zu bezeichnen sind.

Man kann also über die UI Rules anlegen, welche ohne Code auskommen (so triviale Rules, wenn a passiert, schalte b), oder man programmiert in Blockly (wer grafisch programmieren mag, freut sich). Man kann ECMA programmieren (das ist letztlich an Bord, weil Blockly an Bord ist), mit der Gefahr, dass man Code anpassen muss, weil Blockly die EMCA Version wechselt. Außerdem ist ECMA bisher nicht für openHAB optimiert, man kann nicht einfach MeinItem.sendCommand() schreiben, nein, man muss sich zunächst ein Handle aus der Item Registry besorgen, was den Code enorm aufbläht.
Oder Man nimmt den DSL Code und nutzt ihn über die UI. Nur kann man dann eigentlich auch gleich vollständig in der DSL bleiben, zumal es in der UI Einschränkungen wegen der fehlenden globalen Variablen gibt.

Unterm Strich möchte ich empfehlen, wenn Du nicht dringend weg von der DSL willst, lass einfach alles so wie es ist. Wenn die DSL irgendwann mal raus fliegen sollte, dann wird es bis dahin noch genug Zeit geben, um Rules in die dann etablierte bessere Alternative zu überführen, von der heute noch Niemand weiß, welche das überhaupt ist.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet

Eleven
Beiträge: 53
Registriert: 15. Okt 2018 10:27
Answers: 0

Re: Probleme mit der Migration einer rule [Umstieg von Openhab2 auf 3]

Beitrag von Eleven »

Ich habe mich tatsächlich noch ein paar Monate mit OpenHAB1 versucht. Kurze Zeit später kam dann OpenHAB2, was nach einer kurzen Eingewöhnungsphase dann auch super von der Hand ging. Ich handhabe es so das ich neue Things über die "WebUi" inkludieren und die items, etc. dann mittels VS-Code weiter einrichte. Dies werde ich dann auch erstmal weiter so handhaben.

Wie schon im Beitrag zuvor erwähnt vielen vielen Dank für den Support!

Grüße Eleven

Antworten