openhabforum.de

Der entscheidende Teil ist hier das Number:Temperature. Das bedeutet, es handelt sich um ein UoM (Units of Measurement) Item. Anders gesagt, es liefert keine gewöhnliche Zahl, sondern eine Zahl mitsamt Einheit, in diesem Fall gewöhnlich °C, aber Du könntest die Anzeige auch auf K oder F umstellen (und Du musst Dir dabei keine Gedanken um die Umrechnung machen, das übernimmt openHAB).
Wenn Du allerdings in einer Rule mit diesen Werten rechnen willst (auch ein Vergleich ist eine Rechnung), dann musst Du darauf Rücksicht nehmen. Es gibt hier zwei Möglichkeiten.
Entweder, Du sorgst dafür, dass die zu vergleichende Zahl auch eine Einheit hat (und auch dann kannst Du ohne Probleme mit einer anderen Einheit arbeiten, also z.B.: ist 0°C größer, kleiner oder gleich 32°F?)
Die Alternative ist, die Einheit zu entfernen. Dabei wird immer die default Einheit verwendet (imperial oder metrisch, metrisch ist vorausgewählt, in diesem Fall also °C (obwohl strenggenommen K korrekt wäre

)

Variante eins:

Code: Alles auswählen

if(LocalWeatherAndForecast_ForecastHours24_MaximaleTemperatur.state > 15 | °C)

Variante zwei:

Code: Alles auswählen

if((LocalWeatherAndForecast_ForecastHours24_MaximaleTemperatur.state as QuantityType<Number>).floatValue > 15)

Eigentlich müsste man bei Variante eins auch nach Number casten, aber openHAB erledigt das selbst.

udo1toni hat geschrieben: ↑13. Jun 2020 23:31 Der entscheidende Teil ist hier das Number:Temperature. Das bedeutet, es handelt sich um ein UoM (Units of Measurement) Item. Anders gesagt, es liefert keine gewöhnliche Zahl, sondern eine Zahl mitsamt Einheit, in diesem Fall gewöhnlich °C, aber Du könntest die Anzeige auch auf K oder F umstellen (und Du musst Dir dabei keine Gedanken um die Umrechnung machen, das übernimmt openHAB).
Wenn Du allerdings in einer Rule mit diesen Werten rechnen willst (auch ein Vergleich ist eine Rechnung), dann musst Du darauf Rücksicht nehmen. Es gibt hier zwei Möglichkeiten.
Entweder, Du sorgst dafür, dass die zu vergleichende Zahl auch eine Einheit hat (und auch dann kannst Du ohne Probleme mit einer anderen Einheit arbeiten, also z.B.: ist 0°C größer, kleiner oder gleich 32°F?)
Die Alternative ist, die Einheit zu entfernen. Dabei wird immer die default Einheit verwendet (imperial oder metrisch, metrisch ist vorausgewählt, in diesem Fall also °C (obwohl strenggenommen K korrekt wäre )

Variante eins:
Code: Alles auswählen
if(LocalWeatherAndForecast_ForecastHours24_MaximaleTemperatur.state > 15 | °C)
Variante zwei:
Code: Alles auswählen
if((LocalWeatherAndForecast_ForecastHours24_MaximaleTemperatur.state as QuantityType<Number>).floatValue > 15)
Eigentlich müsste man bei Variante eins auch nach Number casten, aber openHAB erledigt das selbst.

Habe mich für Variante 1 entschieden und es hat super funktioniert.
Vielen Dank.

Kann man Time cron, und die 2 verschiedenen Timer in der Rule noch irgendwie in der Sitemap ändern?

Die Time cron Trigger kannst Du nur über das Rules-File ändern, die verwendeten Timer kannst Du selbstverständlich mit Variablen steuern. Es gibt verschiedene mehr oder weniger komplexe Codebeispiele für "Wecker", mit denen die Funktion Zeitschaltuhr nachgerüstet wird.
In meinen Augen ist das alles aber eher umständlich. Es gibt drei verschiedene Bindings (gcal - nur für Google Calendar; caldav - allgemein für alle möglichen Kalender im iCal Format; iCalendar, ebenfalls für iCal Kalender, aber V2 Addon, mit zurzeit noch reduziertem Funktionsumfang gegenüber caldav) um eine Terminsteuerung zu realisieren. Nein, die Kalender lassen sich nicht direkt aus des UI heraus konfigurieren, aber das ist auch nicht sinnvoll. Es handelt sich hier um eine Automation, und die sollte über die UI höchstens abschaltbar sein (damit der Rasensprenger nicht die Party sprengt), aber eine Festlegung von Schaltzeiten ist eine administrative Aufgabe und gehört nicht in die tägliche Übersicht.

Das ist natürlich Ansichtssache

aber es ist nun mal so, dass es in der UI seit 10 Jahren kein Steuerelement für Datums- oder Zeitwahl gibt, trotz vieler Nachfragen.

Hier spielt natürlich mit rein, dass es schon sehr gute Lösungen für das Problem gibt (also außer die Einbindung in die UI), und die Philosophie hinter openHAB ist an der Stelle einfach eine andere.

Irgendwie klappt das mit meiner rrd4j persist leider nicht. im Graph bleibt der Wert auf 0.
rrd4j.persist

Code: Alles auswählen

Strategies 
{
   everyMinute	: "15 * * * * ?"
   everyHour    : "0 0 * * * ?"
   everyDay     : "0 0 0 * * ?"
   default = everyUpdate
}
 
 
Items
    {
	LocalWeatherAndForecast_Current_Regen : strategy = everyUpdate, restoreOnStartup       
    }

Item
wurde über things automatisch erzeugt als Länge und Number der Name ist LocalWeatherAndForecast_Current_Regen

Code: Alles auswählen

Number Chart_Zeitraum_D_W_M_Y

Sitemap auszug

Code: Alles auswählen

Frame label="Regen" { Switch item=Chart_Zeitraum_D_W_M_Y label=""
                                        mappings=[0="Tag", 1="Woche",
                                        2="Monat", 3="Jahr"] Chart
                                        item=LocalWeatherAndForecast_Current_Regen
                                        period=D refresh=60000
                                        visibility=[Chart_Zeitraum_D_W_M_Y==0,
                                        Chart_Zeitraum_D_W_M_Y=="Uninitialized"]
                                        Chart
                                        item=LocalWeatherAndForecast_Current_Regen
                                        period=W refresh=60000
                                        visibility=[Chart_Zeitraum_D_W_M_Y==1]
                                        Chart
                                        item=LocalWeatherAndForecast_Current_Regen
                                        period=M refresh=60000
                                        visibility=[Chart_Zeitraum_D_W_M_Y==2]
                                        Chart
                                        item=LocalWeatherAndForecast_Current_Regen
                                        period=Y refresh=60000
                                        visibility=[Chart_Zeitraum_D_W_M_Y==3]
}

Wo liegt der Fehler?

Würde auch gerne um 23:59 alles speichern und als Item in der SItemap den gesamten Niederschlag als Item sehen um ihn auch in einer Regel für die automatische Bewässerung nutzen zu können.

Bei rrd4j muss zwingend everyMinute als Strategie angegeben werden, damit die Graphen berechnet werden.

Formatierung der Sitemap eher so:

Code: Alles auswählen

Frame label="Regen" { 
    Switch item=Chart_Zeitraum_D_W_M_Y label="" mappings=[0="Tag", 1="Woche",2="Monat", 3="Jahr"] 
    Chart item=LocalWeatherAndForecast_Current_Regen period=D refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==0,Chart_Zeitraum_D_W_M_Y=="Uninitialized"]
    Chart item=LocalWeatherAndForecast_Current_Regen period=W refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==1]
    Chart item=LocalWeatherAndForecast_Current_Regen period=M refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==2]
    Chart item=LocalWeatherAndForecast_Current_Regen period=Y refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==3]
}

Damit wird dann klar, was da passiert.

Was die Tagessumme betrifft, so musst Du die über eine Rule berechnen. Aber ob Mitternacht als Grenze da sinnvoll ist?

udo1toni hat geschrieben: ↑16. Jun 2020 22:09 Bei rrd4j muss zwingend everyMinute als Strategie angegeben werden, damit die Graphen berechnet werden.

Formatierung der Sitemap eher so:
Code: Alles auswählen
Frame label="Regen" { 
    Switch item=Chart_Zeitraum_D_W_M_Y label="" mappings=[0="Tag", 1="Woche",2="Monat", 3="Jahr"] 
    Chart item=LocalWeatherAndForecast_Current_Regen period=D refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==0,Chart_Zeitraum_D_W_M_Y=="Uninitialized"]
    Chart item=LocalWeatherAndForecast_Current_Regen period=W refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==1]
    Chart item=LocalWeatherAndForecast_Current_Regen period=M refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==2]
    Chart item=LocalWeatherAndForecast_Current_Regen period=Y refresh=60000 visibility=[Chart_Zeitraum_D_W_M_Y==3]
}
Damit wird dann klar, was da passiert.

Was die Tagessumme betrifft, so musst Du die über eine Rule berechnen. Aber ob Mitternacht als Grenze da sinnvoll ist?

[/quote]
Wann würden Sie denn die Daten speichern?
Und warum ist es nicht sinnvoll bzw weniger sinnvoll?
Könnte sinnvoller sein den Time cron 5min vor der geplanten Bewässerung zu setzten, damit die Beregnung aktuelle Werte hat zum rechnen, oder?
Vielen Dank werde es gleich morgen ausprobieren

Darauf wollte ich hinaus. Bei der Beregnung ist es ja eher interessant, ob es innerhalb der letzten Stunden genügend geregnet hat, dass nicht bewässert werden muss.

Wetter.items

Code: Alles auswählen

Number:Temperature  	localCurrentTemperature        "Aktuelle Temperatur [%.1f %unit%]"	   	<temperature> (gWetter) 
Number:Length      		localCurrentRainVolume          "Aktueller Niederschlag [%.1f %unit%]"  	<rain>        	(gWetter) 
Group               		gWetter		  	              "Grafik Wetter"
Number		        	RainYesterday

rrd4j.persist

Code: Alles auswählen

Strategies {
        everyMinute : "0 * * * * ?"
        everyHour   : "0 0 * * * ?"
        everyDay    : "0 0 0 * * ?"
        default = everyChange
}

Items {
        LocalWeatherAndForecast_Current_Regen : strategy = everyUpdate, restoreOnStartup
        gWetter* : strategy = everyMinute, everyChange, restoreOnStartup    
}

regen.rule

Code: Alles auswählen

rule "Update rain yesterday"
when
   		Time cron "0 59 20 * * ?" //20:59:00
then
	if (localCurrentRainVolume.state !== null)
		rainYesterday.postUpdate(localCurrentRainVolume.state as Number)
        logInfo("FILE","Beregnung: Regendaten erfasst" + localCurrentRainVolume.state + ">" + rainYesterday.state)
end

beregnung.rules

Code: Alles auswählen

rule "Beregnung"
when Time cron "0 0 21 * * ?"
then if (beregnung.state == ON && LocalWeatherAndForecast_ForecastHours24_MaximaleTemperatur.state > 15 | °C && rainYesterday.state < 10 | mm){
                    channel1.sendCommand(ON)
                    channel2.sendCommand(ON)
                    channel3.sendCommand(ON)
                    channel5.sendCommand(OFF)
                    teich.sendCommand(OFF)
                    createTimer(now.plusMinutes(1)) [| channel1.sendCommand(OFF); channel3.sendCommand(OFF)]
                    createTimer(now.plusMinutes(1)) [| channel2.sendCommand(OFF)]
                    }
end

Kann ich irgendwie in beregnung.rule reinnehmen dass alle Timer beendet werden zum start. sonst könnte es passieren dass der Timer der Teichbefüllung die Brunnenpumpe ausschaltet, wenn die sich in die Quere kommen?

Kann es sein, dass ich das mal in einem anderen Thread erläutert habe? Die Timer in dieser Form zu verwenden ist Mist.
Wenn Du mit zwei Timern arbeiten willst, ist das ok (obwohl unnötig), aber zumindest solltest Du die Kontrolle über die Timer behalten:

Code: Alles auswählen

var Timer tEins = null
var Timer tZwei = null

rule "Beregnung"
when 
    Time cron "0 0 21 * * ?"
then
    logInfo("watering","Es ist 21 Uhr. Zeit für Bewässrung.")
    if (beregnung.state != ON) {
        logInfo("watering","Aber Beregnungsautomatik abgeschaltet.")
        return;
    }
    if (LocalWeatherAndForecast_ForecastHours24_MaximaleTemperatur.state < 15 | °C ){
        logInfo("watering","Aber zu kalt.")
        return;
    }
    if (rainYesterday.state > 10 | mm){
        logInfo("watering","Aber es hat ausreichend geregnet.")
        return;
    }
    channel1.sendCommand(ON)
    channel2.sendCommand(ON)
    channel3.sendCommand(ON)
    channel5.sendCommand(OFF)
    teich.sendCommand(OFF)
    tEins?.cancel
    tEins = createTimer(now.plusMinutes(1), [|
        channel1.sendCommand(OFF)
        channel3.sendCommand(OFF)
        tEins = null
    ])
    tZwei?.cancel
    tZwei = createTimer(now.plusMinutes(1), [| 
        channel2.sendCommand(OFF)
        tZwei = null
    ])
end

Die Rule macht weitgehend das gleiche, nur ein wenig anders

Natürlich kannst Du alle Bedingungen in ein if-Statement schreiben, aber Du sieht hoffentlich den Vorteil des Codes, nämlich, dass es immer genau definierte Umstände gibt, warum die Rule etwas tut (oder nicht). Ob Du die logMeldungen ausgeben lässt, ist natürlich ebenso Geschmacksache. Durch den Abbruch mittels return; bleibst Du im Code aber in der ersten Ebene, was einfach übersichtlicher ist.

Die Schreibweise des Timers, so wie hier gezeigt, verdeutlicht, dass das Lambda (der Teil zwischen [ und ]) Teil der Funktion ist. Die andere Schreibweise funktioniert ohne Frage auch, aber der Zusammenhang kann verloren gehen.
Die Zuweisung des Timers zu einer Variablen hat nun den Vorteil, dass Du den Timer abbrechen kannst (habe ich hier jeweils vor dem Timer-Aufruf implementiert; falls der Timer existiert, wird er gecancelt)
Das Canceln kannst Du auch aus beliebigen anderen Rules heraus erledigen, vorausgesetzt, sie sind in der gleichen Datei gespeichert (wegen der globalen Definition der Variablen)
Genauso kannst Du einen Timer, der so definiert ist, auch erneut zur Ausführung bringen, um z.B. im ersten Durchlauf zwei Regner abzuschalten und den dritten Regner erst im zweiten Durchlauf. dazu braucht es dann aber einen Zähler

zum Abfragen.

openhabforum.de

Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer

Re: Beregnung Timer