Time Rule in OH2 geht nicht

[icedeath82]

Hallo, ich habe mein Server jetzt auf Windows umgestellt und von openhab auf openhab2 gewechselt, soweit funktioniert alles nur rules mit time cron nicht... hier mal eine rule

rule "Luffeuchtigkeit" 

when 
    Time cron "0 */40 * * * ?" //alle 15 min. prüfen
then 
    if(Arduino2_hum1.state < 60) {
                sendCommand(Terra_1_Wasser, ON)


        }  
end

rule "Luffeuchtigkeit Warnung"
when 
    Time cron "0 */30 * * * ?" //alle 15 min. prüfen
then 
    if(Arduino2_hum1.state < 25) {
        pushover ("Achtung! Luft sehr trocken bei Spike: " + Arduino2_hum1.state.toString() + "%")

        }  
end


rule "Morgens Taglichter an"
when
    Time cron "0 0 9 * * ?"
then
    say("Schalte Beleuchtung der Terrarien nun Ein!")
    Thread::sleep(1000)
    sendCommand(Relay_1, ON)
    sendCommand(Relay_2, ON)
    sendCommand(Terra_2_Licht, ON)
    logInfo("terra spike", "licht aus")
    pushover("Terrarien Beleuchtung an!")
end

rule "Morgens Taglichter aus"
when
    Time cron "0 0 21 * * ?"
then
    say("Schalte Beleuchtung der Terrarien nun Aus!")
    Thread::sleep(1000)
    sendCommand(Relay_1, OFF)
    sendCommand(Relay_2, OFF)
    sendCommand(Terra_2_Licht, OFF)
    logInfo("terra spike", "licht aus")
    pushover("Terrarien Beleuchtung aus!")
end

was mache ich falsch?

[udo1toni]

Zumindest bei den ersten beiden Rules sieht die cron-Definition falsch aus. Ich bin mir nicht sicher, ob ein Trigger alle 40 Minuten überhaupt richtig funktionieren wird, aber zumindest behauptet CronMaker, die Definition müsste so aussehen:

"0 0/40 * * * ?"

Also kein Stern vor dem Slash. Der Grund hierfür ist auch klar, denn diese Stelle gibt an, wann das erste Ereignis stattfindet (also in diesem Fall zur vollen Stunde). Zumindest für einen 30-Minuten-Intervall wird das auch klappen, wenn nicht irgendetwas anderes kaputt ist. Die nächste Frage wäre, ob Du sicher bist, dass die Rules nicht getriggert werden. Arduino2_hum1 mag vom Typ Number sein, in der if-Clause musst Du ziemlich sicher ein Type Casting machen:

if (Arduino2_hum1.state as DecimalType < 25)

Zumindest die beiden letzten Rules sehen erstmal gut aus. Du könntest probieren, ob eine Umstellung von Action auf Methode funktioniert:

Relay_1.sendCommand(OFF)

Imports der Grundfunktionen sollten unnötig sein (siehe http://docs.openhab.org/features/aut...n/ruledsl.html)
Aber vielleicht ist auch etwas anderes im Argen, eigentlich sollten Time cron Trigger funktionieren.

[AingTii]

Hallo,

irgendwie funktionieren die Rules die ich in OH2 aus OH1 übernommen habe bei mir auch nicht.
habe sowohl Action als auch Methode probiert und auch extra noch mit cronMaker probiert....

Oder muss man noch extra was in OH2 einstellen, dass er das .rules file nimmt?

Danke

Gruß jens

[udo1toni]

Nein, man muss nichts extra installieren.

Wie lauten denn die Rules? Gibt es im log eventuell eine Meldung, dass das Rulefile Fehler enthält und deshalb vielleicht gar ignoriert wird?

[AingTii]

ah, im log schön versteckt ist zu lesen:

Configuration model 'Haus.rules' is either empty or cannot be parsed correctly!
Configuration model 'Haus.rules' has errors, therefore ignoring it: [453,1]: missing EOF at 'var'

also stimmt etwas nicht....

aber was ist EOF und warum im var (ich denke mal der Ordneer ist damit gemeint?) ?

ansonsten sind es ganz normale standard Rules, die unter OH1 liefen, meine time cron, teileweise noch mit if
und einige Stati der Rollladen icon setzen...
Kann ich nachher mal posten....

Danke

[udo1toni]

EOF steht vermutlich für End Of File, und es geht um Zeile 453 in der Datei Haus.rules. Dort stößt der Interpreter auf das Wort var, was dort so nicht stehen darf.

Ohne den Code gesehen zu haben, tippe ich auf eine fehlende Klammer oder z.B. ein falsches Anführungszeichen. Auch ein falscher Zeilenumbruch (statt <cr> ein <lf><cr>) könnte Ärger machen.

EOF ist natürlich irreführend, vermutlich ist der Fehler auch nicht unmittelbar an der angegebenen Stelle zu finden. Nutzt Du den Smarthome Designer?

[AingTii]

ah, nun könnte ich erahnen, was da hakt...
evtl. ist es wirklich nur eine fehlende Klammer etc...
ich glaube da ist noch die variable mit drin die ich mal getestet hatte bezüglich übber die gui einstellbare Zeiten für die Rolläden,
das probier eich nachher mal....

Smarthome designer, am Anfang ja, nun nicht mehr, da ich die files meist direkt im Raspberry bearbeite...
vielleicht sinnvoll den zu nutzen?!?!?!

[udo1toni]

Smarthome designer, am Anfang ja, nun nicht mehr, da ich die files meist direkt im Raspberry bearbeite...
vielleicht sinnvoll den zu nutzen?!?!?!

Auf jeden Fall, wenn nicht regulär, dann zumindest, wenn es Probleme gibt, denn viele (nicht alle...) Fehler werden vom Smarthome Designer erkannt. Leider erkennt der Smarthome Designer auch einige Fehler, die keine sind, weil z.B. Schlüsselwörter hinzugekommen sind, aber gerade Klammer- und Anführungszeichenfehler findet der Designer zuverlässig.

Wem das Teil zu langsam ist, der sollte mal einen Blick auf VS Code werfen, es gibt ein Plugin für diesen Editor, der viele der Funktionen vom Designer nachrüstet, Syntax Highlighting, Auto completion live Vorschau der Items, um nur einige zu nennen. VS Code ist von Microsoft, aber komplett frei und Open Source.

[AingTii]

Hallo,

also der Smarthome Designer zeigt keinen Fehler, habe den überflüssigen kram mit der Variablen rausgeschmissen.
Allerdings muss ich feststellen, dass nach dem Speichern der .rules Datei der RP bestimmt einen Minute mit ca 30%
ausgelastet ist.
Und wenn die Zeit für meine Testrule 16:30:00 erreicht ist, wird diese erst 16:30:20 ausgeführt und mit ca 30% Auslastung
in den ca 20 Sekunden.
die 2. rule allerdings dann pünktlich... 16:31:00 ohne Verzögerung ohne viel Auslastung
die 3. 16:32:00 auch pünktlich ohne viel Auslastung

ist das nur eine Start-Erscheinung oder kann das öfter vorkommen oder ist etwas komplett falsch?

Welche Form in den Rules ist denn besser?
Shutter_GF_Arbeit.sendCommand(STOP)
oder
sendCommand(Shutter_GF_Arbeit, STOP)

Danke

Gruß Jens

[udo1toni]

Das erste ist besser

Item.sendCommand(Wert): Dies ist eine Methode des Items. Damit werden die Eingaben (also der Wert) vom Item ausgewertet.
sendCommand(Item,Wert): Dies ist eine Action. Die Action weiß nichts von Vererbung. Es gibt nur eine Möglichkeit, die Aufgabe zu erledigen.

Konkretes Beispiel:

rule "testrule 1"
when
    Item MyTestItem changed
then
    var int myInt= MyTestItem.state as DecimalType
    logInfo ("testrule","Wert: {}",myInt)             // klappt
    MyTestItem.sendCommand(myInt + 1)                 // klappt
    sendCommand(MyTestItem,myInt + 1)                 // geht schief
end

rule "testrule 2"
when
    Item MyTestItem changed
then
    var Int myInt= MyTestItem.state as DecimalType
    logInfo ("testrule","Wert: {}",myInt)             // klappt
    MyTestItem.sendCommand(myInt + 1)                 // klappt
    sendCommand(MyTestItem,myInt + 1)                 // klappt!!!
end

Warum geht es in der 1. Rule schief, in der 2. aber nicht?
Dazu muss man verstehen, dass es einen Unterschied zwischen Objekten var Int myInt und Primitives var int myInt gibt.
Das Objekt hat seine Eigenschaften vom Elternteil geerbt (Int), zu diesen Eigenschaften gehört als Minimalausstattung die Methode .toString.
Das Primitive ist hingegen einfach nur eine dumme Integervariable ohne Methoden.

Entsprechend kann die Action sendCommand(), die zwei Strings als Parameter erwartet, das Objekt erfolgreich automatisch in einen String wandeln, beim Primitive geht das aber schief, denn es gibt die Methode .toString gar nicht.

Aber warum klappt es dann mit der Methode Item.sendCommand()?
Weil die Methode eben nicht zwingend einen String als Eingabe erwartet, die Methode hat stattdessen für jeden zu erwartenden Eingangstyp eine eigene Routine, also eine für String, eine für State, eine für Integer, eine für Float...

Es gibt also beim Einsatz der Methode einfach weniger Stolperfallen.

[AingTii]

OK, danke.

das Beispiel in der Erklärung evtl. noch etwas fortgeschritten für mich, aber wird sicherlich bald kommen und dann
weiß ich wo ich es nachschauen kann...

Danke

[udo1toni]

Na ja, die Beispielrule ist fast die kleinste vorstellbare Rule... Die Rule wird von der Änderung eines Items getriggert, lädt den Status des Items als Zahl in eine Integer Variable und schreibt anschließend den Inhalt der Variablen, um eins erhöht zweimal in das Item zurück. Vorher gibt es den alten Wert noch im Log aus.

Abgesehen davon, dass die Rule sich selbst triggern wird (das kommt davon, wenn man ein Beispiel einfach ma lso runter schreibt, ohne groß darüber nachzudenken...) ging es mir darum zu zeigen, dass schon ein einzelner Buchstabe, der groß statt klein geschrieben wird ausreicht, um die Rule zu "reparieren". Oder man verwendet einfach die Methode und muss sich keinen Kopf machen...