Probleme mit erster Rule

[oli1]

Hallo,
ich versuche mich mit der Erstellung meiner ersten Regel und scheitere leider kläglich :-( , hoffe aber, dass mir die Spezialisten hier im Forum weiterhelfen können.

Ich habe meine FritzBox DECT COMETHeizungthermostate schön mit openHAB verbinden können.
Auch die Things und Channels zu den einzelnen Thermostaten wurden automatisch erstellt.

Jetzt möchte ich gerne Regeln erstellen und dachte mit folgender Syntax kann ich eine einfache Temperaturänderung herbeiführen:

rule "Arbeitszimmer"
when
Item avmfritz_Comet_DECT_192_168_1_1_119600204408_tempe rature changed
then
logInfo("Rule: Arbeitszimmer", "Starting Rule Arbeitszimmer")
avmfritz_Comet_DECT_192_168_1_1_119600204408_set_t emp.postUpdate(28)
logInfo("Rule: Arbeitszimmer", "Temp Arbeitszimmer auf 28 Grad erhoeht")
end

Leider erhalte ich im openhab.log dazu nur folgenden output:
2018-02-10 17:23:47.972 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'heizung.rules'
2018-02-10 17:23:47.972 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'heizung.rules' is either empty or cannot be parsed correctly!
2018-02-10 17:23:48.003 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'heizung.rules'

Könnt Ihr mir hier bitte weiterhelfen?

VG,
Oli

[desidia]

du musst dafür Items erzeugen, mit denen du in den Rules arbeitest.

du kannst in dne Rules nicht mit dem "Absoluten Pfad" des things arbeiten sondern nur mit items. (oder heißt dein Item wirklich so "kryptisch?"
Ließ dir dazu nochmal den Items Teil in der Doku durch.

Nichtsdestotrotz, was soll die Rule bewirken?
Bisher ist wenn die Temperatur sich ändert, soll die Soll-Temperatur 28° gesetzt werden?

[Höhlenbär]

Hallo ich stehe auch gerade vor einigen Problem mit den Regeln,

gibt es die Möglichkeit, locale Items also solche die keinem Binding zugeordnet sind, zu erstellen. Zum Beispiel um einen Sollwert aus der Visu zu übergeben oder eine Rule zu aktiviren und eine andere zu deaktiviren.Und können diese dann Remanent gespeichert werden?
Stehen die Variablen in der der Regel nur der Regel zur Verfügung oder auch in anderen Regeln ? In welcher Sprache werden die Regeln denn geschrieben ist das Java oder Pyton oder ...... und gibt es soetwas wie eine Befehlsreferenz?

[udo1toni]

Was Du haben möchtest, ist ein ungebundenes Item (also eines ohne Binding Teil).

Switch MyUnboundSwitch "Mein Switch [%s]"

Fertig! Remanent wird es, wenn Du das Item persistierst und in der Persistence restoreOnStartup für dieses Item setzt. Dafür eignet sich besonders die mapdb Persistence, die speichert nur den aktuellen Zustand, braucht also nur minimalen Platz pro Item, der sich auch nicht ändert (Ausnahme vielleicht das String Item, weil die Länge sed Strings ja variieren kann) und kann mit allen Itemtypen umgehen.

Variablen, die außerhalb von Rules definiert sind, stehen allen Rules in dieser Datei zur Verfügung. Variablen, die innerhalb einer Rule definiert werden, leben nur zur Laufzeit der Rule und stehen damit auch nur dieser Rule zur Verfügung. Insbesondere muss man das berücksichtigen, wenn man Lambdas verwendet, z.B. einen Timer: Die Rule wird gestartet, eine Variable wird in der Rule definiert, ein Timer wird gestartet, die Rule wird beendet. Wenn nun der Timer abläuft und versucht, auf die Variable zuzugreifen, ist diese nicht mehr existent.
Auch wenn die Variablen nur innerhalb des Rulefiles Gültigkeit besitzen, sollte man Namensdoppelungen vermeiden.
Variablen innerhalb einer Rule dürfen einen beliebigen (global nicht verwendeten) Namen verwenden.

Die Rules der Standard Rule Engine sind in einer DSL zu programmieren (DomainSpecificLanguage). Man kann viele Parallelen zu Java finden, aber es ist kein Java. Die Engine arbeitet mit xtend und xtext.

[oli1]

du musst dafür Items erzeugen, mit denen du in den Rules arbeitest.

du kannst in dne Rules nicht mit dem "Absoluten Pfad" des things arbeiten sondern nur mit items. (oder heißt dein Item wirklich so "kryptisch?"
Ließ dir dazu nochmal den Items Teil in der Doku durch.

Nichtsdestotrotz, was soll die Rule bewirken?
Bisher ist wenn die Temperatur sich ändert, soll die Soll-Temperatur 28° gesetzt werden?

Danke für den Hinweis. Ich bin jetzt wohl dank Deiner Hilfe einen Schritt weitergekommen und habe folgende items datei erstellt die auch sauber verarbeitet wurde:
Group gCOMETDECT_Office "Comet DECT heating thermostat" <temperature>
Number COMETDECT_ActualTemp "Actual measured temperature [%.1f °C]" (gCOMETDECT_Office) { channel="avmfritz:Comet_DECT:1:119600204408:actual _temp" }
Number COMETDECT_Temperature "Actual measured temperature [%.1f °C]" (gCOMETDECT_Office) { channel="avmfritz:Comet_DECT:1:119600204408:temper ature" }
Number COMETDECT_SetTemp "Thermostat temperature set point [%.1f °C]" (gCOMETDECT_Office) { channel="avmfritz:Comet_DECT:1:119600204408:set_te mp" }
String COMETDECT_RadiatorMode "Radiator mode [%s]" (gCOMETDECT_Office) { channel="avmfritz:Comet_DECT:1:119600204408:radiat or_mode" }
Switch COMETDECT_Battery "Battery low" (gCOMETDECT_Office) { channel="avmfritz:Comet_DECT:1:119600204408:batter y_low" }

danach habe ich folgende rule erstellt:
rule "Office"
when
COMETDECT_ActualTemp changed from 23
then
logInfo("Rule: Office", "Starting Rule Office")
COMETDECT_SetTemp.sendCommand(26)
logInfo("Rule: Office", "Temp Office auf 26 Grad erhoeht")
end

Dazu bekomme ich openhab.log folgende fehlermeldung:
2018-02-11 12:04:46.801 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'heizung.rules'
2018-02-11 12:04:46.801 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'heizung.rules' is either empty or cannot be parsed correctly!
2018-02-11 12:04:46.816 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'heizung.rules' has errors, therefore ignoring it: [3,5]: no viable alternative at input 'COMETDECT_ActualTemp'

Eigentlich möchte ich nur mal erreichen, dass eine Regel verarbeitet wird - auch wenn die Funtkion an sich noch nicht wirklich Sinn macht

Bin für jeden Hinweis dankbar ... Vielen Dank!

[udo1toni]

Es fehlt das Schlüsselwort Item im when-Teil der Rule. Richtig muss die Rule also so aussehen:

rule "Office"
when
    Item COMETDECT_ActualTemp changed from 23
then
    logInfo("Rule: Office", "Starting Rule Office")
    COMETDECT_SetTemp.sendCommand(26)
    logInfo("Rule: Office", "Temp Office auf 26 Grad erhoeht")
end

Wobei ich mir nicht sicher bin, ob changed from 23 funktioniert (23 ist eine Zahl, im Triggerbereich sind eigentlich nur States erlaubt), aber probiere es mal.

[oli1]

Vielen Dank für den Hinweis. Ich habe "Item" nun eingefügt und "changed" statt "changed from 23" in der when klausel verwendet.
Trotzdem bekomme ich die Fehlermeldung im openhab.log:

2018-02-11 13:32:41.283 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'heizung.rules'
2018-02-11 13:32:41.283 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'heizung.rules' is either empty or cannot be parsed correctly!
2018-02-11 13:32:41.315 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'heizung.rules'

Hier der aktuelle Code in der Datei heizung.rules:

 [COLOR=#000080]rule"office"
  when
  ItemCOMETDECT_ActualTemp changed
  then
  COMETDECT_SetTemp.sendCommand(26)
  end[/COLOR]

[udo1toni]

Nein, das ist keine Fehlermeldung, sondern eine Warnung, und sie unterscheidet sich in der dritten Zeile (dort steht nur [INFO], nicht [WARN])

Der Grund für die erste [WARN] Zeile hängt mit dem Zugriff über Samba zusammen, weil openHAB bemerkt, dass sich der Zeitstempel der Datei geändert hat, der erste Lesezugriff aber scheitert, weil die Datei durch Samba noch gesperrt ist. Diese Meldung ist also normal und unbedenklich.

Ich hoffe mal, dass da in Wirklichkeit ein Leerzeichen zwischen Item und COMETDECT_ActualTemp steht...

[oli1]

Alles klar ... die Rule läuft jetzt erstmal soweit.
Vielen Dank an alle !!!

[Höhlenbär]

Was Du haben möchtest, ist ein ungebundenes Item (also eines ohne Binding Teil).

Switch MyUnboundSwitch "Mein Switch [%s]"

Fertig! Remanent wird es, wenn Du das Item persistierst und in der Persistence restoreOnStartup für dieses Item setzt. Dafür eignet sich besonders die mapdb Persistence, die speichert nur den aktuellen Zustand, braucht also nur minimalen Platz pro Item, der sich auch nicht ändert (Ausnahme vielleicht das String Item, weil die Länge sed Strings ja variieren kann) und kann mit allen Itemtypen umgehen.

Variablen, die außerhalb von Rules definiert sind, stehen allen Rules in dieser Datei zur Verfügung. Variablen, die innerhalb einer Rule definiert werden, leben nur zur Laufzeit der Rule und stehen damit auch nur dieser Rule zur Verfügung. Insbesondere muss man das berücksichtigen, wenn man Lambdas verwendet, z.B. einen Timer: Die Rule wird gestartet, eine Variable wird in der Rule definiert, ein Timer wird gestartet, die Rule wird beendet. Wenn nun der Timer abläuft und versucht, auf die Variable zuzugreifen, ist diese nicht mehr existent.
Auch wenn die Variablen nur innerhalb des Rulefiles Gültigkeit besitzen, sollte man Namensdoppelungen vermeiden.
Variablen innerhalb einer Rule dürfen einen beliebigen (global nicht verwendeten) Namen verwenden.

Die Rules der Standard Rule Engine sind in einer DSL zu programmieren (DomainSpecificLanguage). Man kann viele Parallelen zu Java finden, aber es ist kein Java. Die Engine arbeitet mit xtend und xtext.

Hallo Udo1Toni

danke zunächst für deine Antwort.. das muss ich noch eimal in Ruhe überdenken. (ich habs noch nicht wirklich kapiert). Zu der Items definition habe ich eine Datei local.item angelegt. Ein Item definiert als Switch deffiniert und versucht aus einer Regel mit .sendCommand(ON) zu beschreiben allerdings endete das immer mit der Fehlermeldung "is either empty or cannot be parsed correctly!" Ich versuche es einfach noch einmal.

[Höhlenbär]

Kannst Du mir das mit den Pesistence noch einmal erklären? Wenn ich ein Ungebundenes Item (Typ Real ) ich glaube das ist hier ein Number persitant Speichern möchte. wie Funktioniert das?
Im "Normalfall" programmiere ich Codesys. Da brauch der Wert nur als retain persistent angelegt werden. Ich verstehe zwar die Logik aber noch nicht die Syntax oder den Aufbau. der Struktur. der Regeln.

[udo1toni]

Wenn es um eine Zahl geht, muss das Item vom Typ Number sein.
openHAB ist vom Design stateless. Allerdings gibt es den openHAB bus, auf den man über die Items zugreift.
Grundsätzlich kennt openHAB nur den aktuellen Status eines Items, als Ausnahme könnte man noch erwähnen, wenn ein Item seinen Status ändert, wird der alte Status in den Rules bereitgestellt, die auf changed triggern (previousState ohne irgendwas), diese information ist aber nur im Moment des changes vorhanden.
Wenn man nun historische Daten braucht, muss man den Item Status persistieren. Dabei gibt es verschiedene Backends, die alle ihre Vor- und Nachteile haben. Jedes Backend muss getrennt bereit gestellt und konfiguriert werden, zum einen mit dem entsprechenden Persistence Service, zum anderen (bei den Varianten, die externe Backends verwenden) muss das Backend selbst eingerichtet sein. Ohne weiteres sind rrd4j und mapdb verwendbar, beide haben statischen Speicherbedarf, rrd4j kann nur Number Items speichern, mapdb speichert nur den aktuellen Status, ist also nur zum wiederherstellen des letzten Status beim Neustart zu gebrauchen, dafür ist der Speicherbedarf minimal. Wenn der Service installiert ist, muss eine passende Datei <service>.persist im Konfigurationszweig ./persistence/ angelegt werden.
Z.B. rrd4j wird über die Datei rrd4j.persist konfiguriert:

Strategies {        // for rrd4j, we need a cron strategy

    everyMinute : "0 * * * * ?"

}
Items {             // let's store Wheater_Chart values in rrd4j

    Weather_Chart* : strategy = everyMinute, everyUpdate
    MyItem : strategy = everyChange, restoreOnStartup
}

Die Dateien sind für alle Services gleich aufgebaut, es gibt also einen Teil Strategies, in dem man cron Trigger definieren kann, also Zeitpunkte, zu denen Items gespeichert werden sollen, gleich ob es Änderungen gab oder nicht. Dabei wird jedesmal ein Zeitstempel gesetzt.
Im unteren Teil werden die Items angegeben, die der Service persistieren soll. Im Beispiel werden alle Items minütlich und bei Updates persistiert, die zur Gruppe Weather_Chart gehören. Das Item MyItem hingegen wird nur bei Änderung persistiert, dafür aber beim Neustart des Systems aus dem Speicher dieses Persistence Services wiederhergestellt. Dies entspricht dann dem retain bei Codesys oder dem Remanentspeicher beim Gira HS.
Dass dies in einer separaten Datei konfiguriert wird, liegt daran, dass es verschiedene Services gibt. Das hat den Vorteil, dass man sich aussuchen kann, in welchem Format die Daten vorliegen, wenn man sie selbst extern weiter verarbeiten will (MySQL, PostgreSQL...) InfluxDB z.B. wurde "mal eben" nachgerüstet, damit Grafana zum Erstellen von Graphen verwendet werden konnte (das war zu einem Zeitpunkt, als SQL noch nicht von Grafana unterstützt wurde). Jedes Item kann individuell von einem oder auch mehreren Services persistiert werden.

[udo1toni]

Glatt vergessen: Die Fehlermeldung "is either empty or cannot be parsed correctly!" kann aus verschiedenen Gründen auftreten, entweder, weil es einen Fehler in einer Rules Datei gibt (dann sollte aber auch eine Information geliefert werden, wo der erste Fehler steht). Es kann aber auch sein, dass openhAB versucht, die rules Datei neu einzulesen, weil sich der Zeitstempel geändert hat, aber der Zugriff klappt nicht auf Anhieb, dann kommt auch diese Meldung, anschließend wird die Datei aber trotzdem gelesen und verarbeitet.

[Höhlenbär]

Hallo udo1toni

Danke für Deine Antwort ich werde es mal probieren und melde mich dann ob es funktioniert.

[Höhlenbär]

Hallo

hier die Rückmeldung wie versprochen. Die Ersten Regel laufen und auch das mit der persistenten Variable scheint zu funktionieren. Vielen Dank vorerst auch wenn noch 1000 Fragen folgen werden.