Zyklisch in einer rule prüfen

[JoergA]

Hallo zusammen,

folgende Überlegung.

Ich habe eine rule (die seltsamerweise nicht immer in die cron Prüfung läuft, aber das ist ein anderes Problem) mit der ich die Rollladen fahren lasse.

rule Rollladen_Task
when
    Time cron "0 30 08 ? * MON-SAT" or
    Time cron "0 30 17 ? * MON-SAT" or
    Time cron "0 00 09 ? * SUN"
then
 pushNotification(tempmax + " Grad", "Rollladen sollten fahren: " + now)
 if (Holiday.state == OFF && Night.state == OFF && tempmax < 40) {
  pushNotification("Information", "Rollladen fahren auf: " + now)

  Rollos.sendCommand(UP)

 } else if (Holiday.state == OFF && Night.state == OFF && tempmax >= 40) {
  SunProtection.postUpdate(ON)
  pushNotification("Information", "Sonnenschutz aktiviert.")

 } else if (Holiday.state == ON) {
  pushNotification("" + SpecialDay + "", "Rollladen bleiben unten.")

 } else if (Holiday.state == OFF && Night.state == ON) {
  pushNotification("Information", "Es ist noch Nacht, Rollladen bleiben unten.")
 }
end

Seltsamerweise wird die Regel derzeit nicht Mo-Fr um 8:30 (1te Regel) aber Mo-Fr (17:30) durchlaufen?!?!?

Aber zu meiner Frage: Ich würde gerne bei der letzten Prüfung (wenn es draussen noch zu dunkel ist) eine zyklische Schleife einbauen, in der immer mal wieder (alle 15 Min) geprüft wird, ob eine gewisse Helligkeit erreicht ist und wenn ja, dann hochfahren.

Irgendwie habe ich grad keine Idee, wie ich dies umsetzen kann.

Viele Grüße,
Jörg

PS: Die 40 als Temperatur sind noch Werte in der test-Phase um sicherzustellen, dass die Rollladen fahren und nicht die Sonnenautomatik (ist eine andere Rule) eingeschaltet wird.

[Brain0verflow]

Hallo,

mehrere time cron Bedingungen funktionieren nicht, das ist ein Bug. Als workaround für jede Bedienung eine rule erstellen.

Für dein Anliegen mit den Rollladen würde ich eventuell eine eigene Rule erstellen welche über das Astro Binding bei Sonnenaufgang bzw. 20 Minuten danach triggered.

[udo1toni]

Welche openHAB-Version setzt Du ein? Was die Kombination mehrerer Time cron Trigger betrifft, gibt es mannigfaltige Meldungen und mehrere Threads, in der aktuellen OH2-Version sollte das eigentlich gefixt sein, da ich momentan noch nicht produktiv bin, kann ich dazu aber nichts aus eigener Erfahrung beitragen.
Für das Zeitproblem könntest Du einen Timer verwenden:

var Timer t_night = null

rule ...
...
else if (Holiday.state == OFF && Night.state == ON) {
    pushNotification("Information", "Es ist noch Nacht, Rollladen bleiben unten.")
    if (t_night != null)
        t_night = createTimer(now.plusMinutes(5))[|
            if (Night.state == ON) {
                pushNotification("Information", "Es ist immer noch Nacht, Rollladen bleiben unten.")
                t_night.reschedule(now.plusMinutes(5))
            }
            else {
                pushNotification("Information", "Rollladen fahren auf: " + now)
                Rollos.sendCommand(UP)
                t_night.cancel
                t_night = null
            }
        ]
    }

Strenggenommen müsste noch die Temperaturprüfung mit rein...

[JoergA]

Derzeit bin ich wieder zurück auf die 1.7.1, da die 1.8.3 mit den nur noch verfügbaren 1.9.0 Add Ons den "Fehler" im Designer hatte, dass diverse Befehle als fehlerhaft angezeigt wurde. (Hatte ich in einem anderen Threat thematisiert)

Mit der 1.8.3 liefen die mehrfachen cron im Test auch gut, daher hatte ich einige Rules zusammen gefasst.
a) Um die Rules (wie ich finde) übersichtlicher zu haben
b) weniger rules laufen auch schneller durch (hatte da auf dem Rasp Pi Performance Probleme)

Auch wenn ich keinen Rasp Pi mehr einsetze, versuche ich die Regeln schlank und anzahlmäßig gering zu halten.

Der Umstieg auf 2.0 soll ja nicht so trivial sein? Einige Regeln müssen angepasst werden etc`?
Dies hatte mich bisher abgeschreckt.
Funktioniert denn meine Berechnung der Feiertage dann noch??

[JoergA]

Strenggenommen müsste noch die Temperaturprüfung mit rein...

Das es morgens noch nach 8:30 sooo dunkel ist, ist ja meist im Winter der Fall, da ist mir die Temperatur als Parameter nicht wichtig

[udo1toni]

Bezüglich Designer: Eigentlich sollte es "relativ" egal sein, welche OH1 Version Du laufen lässt, und welche OH1-Designer Version Du laufen lässt. Natürlich gibt es eventuell ein oder zwei Befehle, die OH1.9 unterstützt, und die dann vom Designer 1.7 angemeckert werden, weil die noch nicht bekannt sind, umgekehrt sollte es aber keine Dinge geben, die der Designer nicht anmeckert, die aber unter OH1.9 nicht laufen, und das ist ja die wichtigere Sache. Den Designer habe ich seit "Ewigkeiten" nicht mehr aktualisiert, vermutlich auch 1.7, müsste ich nachschauen, bei mir läuft aber aktuell OH1.8.0, weil ich zwingend auf Schiebesteller für Dimmer angewiesen bin, die eine kurze Zeit im Classic UI zur Verfügung standen, dann aber wegen Problemen wieder entfernt wurden, die bei mir nicht zum Tragen kommen. Der Designer hat ja mit der Runtime nichts zu tun und liefert nur die Konfigurationsoberfläche.

Umstieg auf OH2 zieht sich bei mir auch schon eine gefühlte Ewigkeit in die Länge, zum einen besteht bei mir kaum Leidensdruck, zum anderen stoße ich immer wieder bei der Konfiguration an Punkte, wo etwas nicht auf Anhieb klappt. Zur Zeit läuft bei mir parallel ein OH2, allerdings nur mit einem kleinen Ausschnitt der Dinge, die ich in OH1 produktiv nutze - knx z.B. kommt mit zwei OH Instanzen nicht zurecht, wobei es einfach an der Buslast liegt, die enorm ansteigt, das werde ich also sicher als letztes umheben, und dann erst werde ich auch überblicken können, ob noch weitere böse Fallen auf mich warten.

[JoergA]

Ich habe gestern Abend dann mal wieder auf die 1.8.x umgestellt, geht ja "klicki-klacki" und heute Morgen ist dann zumindest bereits wieder eine der mehrfach geschachtelten crons wieder gelaufen. Mal sehen, was gleich die anderen machen

Parallel habe ich mir auch mal OH2 - unter Windows 7 - installiert. Ist ja schon nett, mit der GUI zur Installation, auch wenn dies in OH1 mit - rüberkopieren und fertig - noch einfacher war. Da ich mit den ganzen rules und Items nicht von Scratch starten möchte, habe ich schon ein wenig gegoogelt und den einen oder anderen Bericht zum Umstieg gefunden. Ist ja leider nicht soo trivial, da die Configuration auseinander gerissen wurde Wird sicher einen guten Grund dafür gegeben haben, aber erschwert Dummies wie mir den Umstieg.

Derzeit habe ich die PaperUI laufen und einige der AddOn bereits installiert. Einige sind aber auch nicht verfügbar, die ich ggfs auch Unwissenheit noch mitziehe?!

Ich nutze unter OH1.x die folgenden Persistence
- org.openhab.persistence.db4o-1.9.0.jar
- org.openhab.persistence.exec-1.9.0.jar
- org.openhab.persistence.logging-1.9.0.jar
- org.openhab.persistence.mapdb-1.9.0.jar
- org.openhab.persistence.rrd4j-1.9.0.jar

Dies sind aber nicht alle unter OH2 vorhanden?!

[udo1toni]

Die einzige Persistence, die tatsächlich überhaupt nicht verfügbar ist, ist die logging persistence, was daran liegt, dass jetzt die karaf engine verwendet wird und das logging komplett anders funktioniert.
Andererseits stellt dieses logging ja nur eine eine-Richtung-Persistence zur Verfügung, die Daten können nur noch händisch verwendet werden.
db4o kannst Du notfalls manuell installieren. Die Frage ist aber, ob Du diese Art Persistence mit gutem Grund so gewählt hast, oder nur "weil es halt da und bequem war".

Es gibt einige OH1-Addons, die bisher nicht offiziell unter openHAB1 nutzbar sind, konkret gibt es aber, soweit ich weiß, nur ein oder zwei Bindings, die tatsächlich nicht unter openHAB2 laufen.
Alle anderen (z.B. Asterisk und VDR, um mal zwei zu nennen, die ich "vermisse"), kannst Du installieren, indem Du die .jar Datei in den Ordner /usr/share/openhab2/addons/ legst - openHAB2 wird diese umgehend bereitstellen, sofern das OH1 Compability Pack installiert ist - das sollte man als Umsteiger mit Auswahl des Expert Mode aber ohnehin aktiv haben - siehe http://docs.openhab.org/tutorials/migration.html

Das "Auseinanderreißen" der openhab.cfg sieht erstmal nach "komplizierter" aus, in Wirklichkeit werden die Konfigurationsdateien übersichtlicher, weil jeweils nur die Konfiguration eines Bindings aufgeführt wird. Nicht installierte Bindings tauchen gar nicht mehr auf (wenn man from Scratch anfängt, war es unter OH1 ja üblich, die openhab_default.cfg zu kopieren - damit hatte man dann potentiell jede Menge Müll, den man aber auch nur ungern wegwerfen wollte - könnte ja mal irgendwann... - andererseits musste man aber, wenn neue Bindings dazu kamen, trotzdem manuell den entsprechenden Teil zur eigenen openhab.cfg dazu kopieren)
Normal reicht es aus, den entsprechenden Teil der openhab.cfg in einer entsprechenden Datei abzuspeichern und das Schlüsselwort für das Binding, also z.B. knx: zu Beginn jedes Parameters zu entfernen - dies ist ja eine unnötige Information, die Zuordnung zum Binding erfolgt schon über den Dateinamen.

Es ist damit zu rechnen, dass im Laufe der Zeit jetzt noch fehlende Bindings entweder als kompatibel deklariert und in die Installation mit eingebaut, oder gleich komplett für OH2 neu entwickelt werden - natürlich dauert das.
Leider ist es auch nicht mit dem Setzen von zwei Haken auf einer Website getan, das muss also jemand machen, der zumindest halbwegs vertraut mit der Entwicklungsumgebung ist.

[JoergA]

Seit dem Umstieg auf 1.8.3 laufen meine Cron-Rules bisher , scheint als bereits dort gefixed zu sein.

Dennoch würde ich mal den Versuch mit OH2 starten und kann die "Entzerrung" der cfg nachvollziehen. Sicher hätte man auch eine zentrale cfg verschlanken können, aber wie so häufig führen viele Wege nach Rom und jeder Programmierer hat seine eigenen Vorlieben

Was ich aus OH1 an DBs nutze ist eigentlich überschaubar, da ich kein DB Spezi bin.

1. Ich schreibe die Werte meines Helligkeit/Temperatur Sensors in eine Datenbank um mir einen Graphen der letzten Stunden anzeigen zu lassen.
2. Ich speichere den Wert von einigen Items, die nur logisch existieren oder ich nicht abfragen kann/möchte

Ich finde in meiner OH2 Installation derzeit "nur":

1. org.openhab.persistence.mapdb-1.9.0.jar
2. org.openhab.persistence.rrd4j-1.9.0.jar

Es fehlen

• org.openhab.persistence.db4o-1.9.0.jar
• org.openhab.persistence.exec-1.9.0.jar
• org.openhab.persistence.logging-1.9.0.jar

OK, "logging" wurde ersetzt und funktioniert dann automatisch. Aber wozu werden die beiden anderen benötigt und wodurch könnte ich diese ersetzen??

Viele Grüße,
Jörg

[JoergA]

Der erste Schritt in die (so hoffe ich) richtige Richtung => Ich habe über den Designer die knx.cfg angepasst und unverzüglich kam:

10:53:05.687 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.xxx.yyy.zzz:3671 in mode TUNNEL.

[Jockel]

Aber zu meiner Frage: Ich würde gerne bei der letzten Prüfung (wenn es draussen noch zu dunkel ist) eine zyklische Schleife einbauen, in der immer mal wieder (alle 15 Min) geprüft wird, ob eine gewisse Helligkeit erreicht ist und wenn ja, dann hochfahren.

Ich löse das so, dass ich vom Astro Binding alle paar Minuten den Sonnenstand berechnen lasse. In einer Regel triggere ich dann auf den Sonnenstand und prüfe, ob die Sonne hoch genug steht. Zusätzlich einen einzigen Cron-Trigger zur spätesten Zeit an der die Rolläden,unabhängig vom Sonnenstand, verfahren werden sollen.

[udo1toni]

Was ich aus OH1 an DBs nutze ist eigentlich überschaubar, da ich kein DB Spezi bin.

1. Ich schreibe die Werte meines Helligkeit/Temperatur Sensors in eine Datenbank um mir einen Graphen der letzten Stunden anzeigen zu lassen.
2. Ich speichere den Wert von einigen Items, die nur logisch existieren oder ich nicht abfragen kann/möchte

Ich finde in meiner OH2 Installation derzeit "nur":

1. org.openhab.persistence.mapdb-1.9.0.jar
2. org.openhab.persistence.rrd4j-1.9.0.jar

Es fehlen

• org.openhab.persistence.db4o-1.9.0.jar
• org.openhab.persistence.exec-1.9.0.jar
• org.openhab.persistence.logging-1.9.0.jar

OK, "logging" wurde ersetzt und funktioniert dann automatisch. Aber wozu werden die beiden anderen benötigt und wodurch könnte ich diese ersetzen??

Für Graphen kannst Du weiterhin rrd4j verwenden, alles mit on Board, allerdings sind die Graphen nicht sonderlich hübsch. Grafana ist als Erweiterung sehr nett, leider ist es aber nicht ganz trivial, das Ganze so in openHAB einzubinden, dass es sich nahtlos einfügt. Gafana in Kombination mit InfluxDB ist dafür weitaus mächtiger als rrd4j mit dem Graphentool.

MapDB ist interessant für Restore On Startup, weil die Dateien nicht wachsen. Man kann aber nur den letzten Wert auslesen (und, wann dieser geschrieben wurde)

db4o ist eine "richtige" Datenbank, Vorteil war, dass der Anwender sich um nichts kümmern musste, nachteilig war aber, dass es eben db4o ist, man ist auf passende Werkzeuge angewiesen, falls man mehr mit den Daten anfangen will. Z.B. MySQL aufzusetzen ist ähnlich leicht wie openHAB aufzusetzen (also nur so, dass openHAB startet), aber anschließend kann man mit verschiedenen Werkzeugen bequem auf die Daten zugreifen. Ich nutze z.B. HeidiSQL um mir Daten rauszusuchen, und es gibt massig Visualisierungstools (wohlgemerkt: alles kostenlos) - SQL als Abfragesprache ist Standard und weltweit verbreitet, es gibt Backuplösungen,...

exec-Persistence hab ich nie benutzt, vermutlich kann man damit ziemlich mächtige Dinge tun, bisher hab ich das nicht gebraucht

logging: letztlich konnte man darüber zusätzliche Logdateien schreiben, aber wofür? Wenn man nicht konkret ganz bestimmte Daten isoliert als Textdatei benötigt, ist das eher unnötig. Es ist also die Frage, was Du mit den Persistence Daten überhaupt anstellst, Graphen sind, wie gesagt, kein Problem, und ansonsten gibt es mächtige Alternativen.

[JoergA]

Logging => habe ich nie aktiv genutzt, kann ich also ähnlich Default lassen wie bei OH1
db4o => habe ich auch nie aktiv genutzt war in OH1 standardmäßig installiert. Scheine ich auch nicht zu brauchen, oder wird dies by Default für etwas genutzt?
exec => habe ich auch nie aktiv genutzt, war also ein Restant

mapdb werde ich dann mal beobachten, scheint bei mir - auch unter OH1 - noch nicht rund zu laufen. habe dies konfiguriert, hat aber ähnliches Verhalten wie in OH1 => Werte sind nicht immer gespeichert
rrd4 => Finde ich ganz interessant (z.B. wie war der Temp-Verlauf in der Nacht, bzw. Helligkeit am Tag)

Gafan/InfluxDB werde ich dann mal bei Zeiten anschauen, ob ich dies hinbekomme.

Aber: Erst mal muss so weit alles andere laufen, bevor ich mit neuem anfange ;-)

[udo1toni]

Was installiert ist, ist ja "egal" (also abgesehen davon, dass ungenutzte aber installierte bundles Rechenleistung binden), wichtig ist, welche Items in der Persistence konfiguriert wurden. Wenn Du mit den persistierten Daten nichts anfängst, kann eine fehlende Persistence kein Showstopper sein rrd4j als Speicher für die integrierten Graphen ist ja dabei...