Seite 1 von 1

Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 15. Nov 2020 21:45
von Alex_K
Hallo zusammen

Ich möchte gerne meine Weihnachtsbeleuchtung einschalten, wenn die Wetterstation das Signal für Dämmerung sendet, aber nur im November, Dezember, Januar und Februar.
Bei “when” scheint man die Trigger aber nur mit “or” verknüpfen zu können und nicht mit “and”.
Auch ohne die Zeitabhängigkeit scheint es nicht zu funktionieren.
Das habe ich bisher (der Time teil auskommentiert da ich nicht weiss wie verknüpfen):

Code: Alles auswählen

rule “Weihnachtsbeleuchtung Ein”
when
Item dawn2 received command
// Time cron “* * * ? 1,2,11,12 *”
then {
if(dawn2.state == OPEN
sendCommand(TE_Garage_Steckdose, ON)
}
end
Vielleicht habt Ihr ja eine Idee woran es liegen könnte.

dawn2 ist vom Typ contact:

Code: Alles auswählen

Contact dawn2 “Dämmerung 2 [MAP(alarm.map):%s]” (WG_Wiga,TE_Garage,TE_Wiga,Aussen) { knx = “<5/3/0" }
TE_Garage_Steckdose ist ein Switch:

Code: Alles auswählen

Switch TE_Garage_Steckdose "Steckdose Terrasse Garage" (TE_Garage,Steckdose) [“Lighting”] { knx = “3/1/2+<3/1/102" }
Danke für die Unterstützung
Alexander

Re: Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 16. Nov 2020 13:26
von imhofa
Kann es sein, dass Du die Klammern nicht richtig gesetzt hast?

Code: Alles auswählen

rule “Weihnachtsbeleuchtung Ein”
when
  Item dawn2 received command
  // Time cron “* * * ? 1,2,11,12 *”
then
  if(dawn2.state == OPEN)
  {
    TE_Garage_Steckdose.sendCommand(ON)
  }
end
Am besten immer die Fehlermeldungen im LOG anschauen...

Re: Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 16. Nov 2020 14:17
von udo1toni
Immer wieder gern genommen...

Also, der erste Punkt ist das mit dem and im when-Teil... Rules sind Event gesteuert. Im when-Teil der Rule-Definition sind die Trigger gelistet, welche zur Ausführung der Rule führen (auf deutsch die Ereignisse).
Stelle Dir vor, man könnte hier ein and einsetzen, dann wäre die Bedeutung: Nur wenn diese beiden Ereignisse absolut zeitgleich eintreten die Rule auslösen. Das ist also Quatsch.
Was Du wirklich willst, ist, wenn ein Ereignis eintritt, prüfen, welchen Zustand ein Item hat (oder hier welchen Zustand das Datum hat).

Der zweite Punkt: dawn2 ist logisch kein Kontakt, sondern ein Switch. Vermutlich hast Du hier Contact gewählt, weil in der Sitemap ein Schalter gezeichnet wird. Das liegt aber daran, dass Du den falschen Widget Typ verwendet hast. Nutze einfach Text (also Text item=dawn2).
Der dritte Punkt wäre eigentlich die Anbindung über knx1. Das solltest Du dringend mal auf knx2 umstellen...
Der vierte Punkt: Wenn Du die Rule auf received command triggern lässt, ist die Chance groß, dass der Status des Items nicht den erwarteten Inhalt hat. Das hat mit Laufzeiten im System zu tun. Es ist aber ohnehin besser, hier changed zu verwenden.
das ergibt dann zusammen folgende Rule:

Code: Alles auswählen

rule "Weihnachtsbeleuchtung Ein"
when
    Item dawn2 changed to ON // Dämmerung aktiv
then
    if(now.getMonth < 3 || now.getMonth > 10)
        TE_Garage_Steckdose.sendCommand(ON)
end
now ist der Datums- und Zeitstempel "jetzt", getMonth liefert den Monat als Integer Wert von 1 bis 12. || ist das logische ODER.
Ich empfehle grundsätzlich, die Methode sendCommand der Action sendCommand vorzuziehen. :)

Re: Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 17. Nov 2020 22:44
von Alex_K
Vielen Dank, das hat mir schon mal ein grosses Stück weiter geholfen. :D Der Time cron Ansatz funktioniert also nicht.
Mit now.getMonth funktioniert es bei mir allerdings auch nicht, ich muss now.getMonthOfYear schreiben, dann geht es.
Gibt es eigentlich einen Unterschied zwischen <3 und <= 2? In den meisten Beispielen ist jedenfalls <n+1 benutzt statt <=n.

Zum ersten Punkt: Sehe ich ein. Die Time cron Formulierung wäre in dem Sinne auch kein Event sondern ein Zeitraum von 4 Monaten.

Zum zweiten Punkt: Ein Switch ist für mich etwas das ich aktiv schalten kann, Contact habe ich für Sensorwerte benutzt, wie z.B. Fenstersensoren, Windalarme oder eben Dämmerung aktiv/inaktiv. Sollte aber ja ausser, dass man OPEN statt ON schreiben muss keinen Unterschied machen, oder? Angezeigt in der Sitemap wird bei mir eine Sonne wegen <sun>.

Code: Alles auswählen

Contact dawn2 "Dämmerung 2 [MAP(alarm.map):%s]" <sun> (WG_Wiga,TE_Garage,TE_Wiga,Aussen) { knx = "<5/3/0" }
Zum dritten Punkt: Stimmt schon, aber da bisher alles auch mit dem knx1 Binding funktioniert inkl. HueEmulation und Sprachsteuerung mit Alexa und ich doch einige items habe, hatte ich noch keine Motivation und Zeit das alles auf Things umzuschreiben. Aktuell nutze ich OpenHAB 2.3.0.005 auf einer Synology Diskstation.

Zum vierten Punkt: Triggern auf received command statt changed to habe ich genommen, weil ich dawn2 zyklisch alle 10 Minuten senden lasse und ich eigentlich will, dass jedes Mal das ON bzw. OFF Kommando gesendet wird und nicht nur einmal Abends und einmal Morgens. Hintergrund, falls jemand am Schalter die Steckdose ein- oder ausschaltet, soll das wieder rückgängig gemacht werden und noch wichtiger, wenn wir das Haus verlassen und auf abwesend drücken, geht automatisch die Steckdose auch aus, soll dann aber kurz danach, wenn die Weihnachtsbeleuchtung dran hängt wieder an gehen. Von März bis September soll sie dann aber aus bleiben, daher möchte ich das nicht in der knx Programmierung ändern. Von daher wäre es aber auch nicht so schlimm, wenn dawn2.state erst verzögert aktualisiert wird, dann geht es halt erst 10 Minuten später an oder aus.
Könnte ich das dann so machen?:

Code: Alles auswählen

rule "Weihnachtsbeleuchtung Ein"
when
Item dawn2 received command

then 
	if (dawn2.state == OPEN && (now.getMonthOfYear < 3 || now.getMonthOfYear > 10))
	{
	TE_Garage_Steckdose.sendCommand(ON)
	}
end
Brauch es die { und }?
sendCommand (xy, ON) funktioniert in meinen anderen rules eigentlich bisher zuverlässig, aber xy.sendCommand (ON) kann ich natürlich auch nehmen, wenn das robuster ist.

Dein Code mit changed to funktioniert auch mit einem Contact, meiner mit received command bisher leider nicht. :(
Habe das mal testweise mit einem Fenstersensor statt mit dawn2 gemacht, damit ich das aktiv beeinflussen kann. Damit geht immer beim Öffnen des bodentiefen Fensters / der Türe das Licht an und beim Schliessen wieder aus: :D

Code: Alles auswählen

rule "Weihnachtsbeleuchtung Ein Test Tuere"
when
    Item Fenster_GF_Kueche_Ost changed to OPEN // Türe offen (Dämmerung aktiv)
then
    if(now.getMonthOfYear < 3 || now.getMonthOfYear > 10)
        TE_Garage_Steckdose.sendCommand(ON)
end

rule "Weihnachtsbeleuchtung Aus Test Tuere"
when
    Item Fenster_GF_Kueche_Ost changed to CLOSED // Türe zu (Dämmerung inaktiv)
then
    if(now.getMonthOfYear < 3 || now.getMonthOfYear > 10)
        TE_Garage_Steckdose.sendCommand(OFF)
end

Re: Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 18. Nov 2020 22:30
von udo1toni
Alex_K hat geschrieben: 17. Nov 2020 22:44 Vielen Dank, das hat mir schon mal ein grosses Stück weiter geholfen. :D Der Time cron Ansatz funktioniert also nicht.
Mit now.getMonth funktioniert es bei mir allerdings auch nicht, ich muss now.getMonthOfYear schreiben, dann geht es.
Gibt es eigentlich einen Unterschied zwischen <3 und <= 2? In den meisten Beispielen ist jedenfalls <n+1 benutzt statt <=n.
Es kam mir beim Schreiben schon komisch vor, aber ich hatte gerade kein openHAB zur Hand... getMonthOfYear ist natürlich die richtige Funktion..
Zum ersten Punkt: Sehe ich ein. Die Time cron Formulierung wäre in dem Sinne auch kein Event sondern ein Zeitraum von 4 Monaten.
Nein, Time cron beschreibt immer Zeitpunkte, niemals Zeiträume. Time cron sind immer Ereignisse. Der * bedeutet lediglich, das jeder mögliche Wert gemeint ist, entsprechend "zündet" das Ereignis eben mehrfach.
Zum zweiten Punkt: Ein Switch ist für mich etwas das ich aktiv schalten kann, Contact habe ich für Sensorwerte benutzt, wie z.B. Fenstersensoren, Windalarme oder eben Dämmerung aktiv/inaktiv. Sollte aber ja ausser, dass man OPEN statt ON schreiben muss keinen Unterschied machen, oder?
Ein Contact ist eben ein Kontakt, z.B. ein Türkontakt oder ein Fensterkontakt. Ein Regensensor liefert ja streng genommen Regen/kein Regen, also Regen ON oder Regen OFF. Letztlich ist das aber egal.
Angezeigt in der Sitemap wird bei mir eine Sonne wegen <sun>.

Code: Alles auswählen

Contact dawn2 "Dämmerung 2 [MAP(alarm.map):%s]" <sun> (WG_Wiga,TE_Garage,TE_Wiga,Aussen) { knx = "<5/3/0" }
Das ist ja nur das Icon. Wenn Du das Item auf die Sitemap bringst, wird das Widget ja irgendwie dargestellt. Und wenn Du nun ein Switch Item nimmst, dann wird eben default ein Schalter gezeichnet, den Du nicht möchtest, da das ja ein "read only" Item ist.
Zum dritten Punkt: Stimmt schon, aber da bisher alles auch mit dem knx1 Binding funktioniert inkl. HueEmulation und Sprachsteuerung mit Alexa und ich doch einige items habe, hatte ich noch keine Motivation und Zeit das alles auf Things umzuschreiben. Aktuell nutze ich OpenHAB 2.3.0.005 auf einer Synology Diskstation.

Zum vierten Punkt: Triggern auf received command statt changed to habe ich genommen, weil ich dawn2 zyklisch alle 10 Minuten senden lasse und ich eigentlich will, dass jedes Mal das ON bzw. OFF Kommando gesendet wird und nicht nur einmal Abends und einmal Morgens. Hintergrund, falls jemand am Schalter die Steckdose ein- oder ausschaltet, soll das wieder rückgängig gemacht werden und noch wichtiger, wenn wir das Haus verlassen und auf abwesend drücken, geht automatisch die Steckdose auch aus, soll dann aber kurz danach, wenn die Weihnachtsbeleuchtung dran hängt wieder an gehen. Von März bis September soll sie dann aber aus bleiben, daher möchte ich das nicht in der knx Programmierung ändern. Von daher wäre es aber auch nicht so schlimm, wenn dawn2.state erst verzögert aktualisiert wird, dann geht es halt erst 10 Minuten später an oder aus.
Könnte ich das dann so machen?:

Code: Alles auswählen

rule "Weihnachtsbeleuchtung Ein"
when
Item dawn2 received command

then 
	if (dawn2.state == OPEN && (now.getMonthOfYear < 3 || now.getMonthOfYear > 10))
	{
	TE_Garage_Steckdose.sendCommand(ON)
	}
end
Brauch es die { und }?
sendCommand (xy, ON) funktioniert in meinen anderen rules eigentlich bisher zuverlässig, aber xy.sendCommand (ON) kann ich natürlich auch nehmen, wenn das robuster ist.

Dein Code mit changed to funktioniert auch mit einem Contact, meiner mit received command bisher leider nicht. :(
Habe das mal testweise mit einem Fenstersensor statt mit dawn2 gemacht, damit ich das aktiv beeinflussen kann. Damit geht immer beim Öffnen des bodentiefen Fensters / der Türe das Licht an und beim Schliessen wieder aus: :D

Code: Alles auswählen

rule "Weihnachtsbeleuchtung Ein Test Tuere"
when
    Item Fenster_GF_Kueche_Ost changed to OPEN // Türe offen (Dämmerung aktiv)
then
    if(now.getMonthOfYear < 3 || now.getMonthOfYear > 10)
        TE_Garage_Steckdose.sendCommand(ON)
end

rule "Weihnachtsbeleuchtung Aus Test Tuere"
when
    Item Fenster_GF_Kueche_Ost changed to CLOSED // Türe zu (Dämmerung inaktiv)
then
    if(now.getMonthOfYear < 3 || now.getMonthOfYear > 10)
        TE_Garage_Steckdose.sendCommand(OFF)
end
Wenn Du die Rule mit received command triggern lassen willst, muss das Item auch ein command senden. (sendCommand oder Schalter über UI betätigen) Ob der Contact überhaupt ein command triggert, weiß ich nicht. knx nutze ich schon lange nicht mehr, ich meine mich aber zu erinnern, dass knx immer commands getriggert hat. Allerdings ist weder OPEN noch CLOSED ein zulässiges Command. Nimm lieber ein Switch Item...

Wenn Du received command als Trigger verwendest, steht übrigens auch die implizite Variable receivedCommand zur Verfügung, die dann das empfangene Command (ON, OFF, INCREASE, DECREASE, UP, DOWN, STOP, PLAY usw. ... 0 bis 100...) enthält. Das wäre besser als dawn2.state...

Die geschweiften Klammern fassen alle enthaltenen Anweisungen zu einem Block zusammen. Wenn man eine bedingte Verzweigunf wie if() verwendet, betrifft die immer nur den nachfolgenden Befehl. Mit den Klammern sorgt man also dafür , dass der gesamte Block als "einzelner Befehl" betrachtet wird. Hat man ohnehin nur einen einzelnen Befehl, so kann man die {} einfach weg lassen.

Re: Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 19. Nov 2020 23:17
von Alex_K
Ja beim Contact wird in der Sitemap einfach Open und Closed dargestellt, bzw. mit meiner "map" dann Aktiv und Aus, oder für Regen "Es regnet" "Es regnet nicht", kann man ja beliebig definieren. Ein "klassischer" Contact ist es schon nicht, aber auf knx Ebene ist es vermutlich wie beim Switch 0 und 1 und OpenHAB macht daraus eben den Schalter oder Open und Closed per "default map".
Eine Möglichkeit wäre dawn2 bzw. dann dawn3 zusätzlich als Switch zu definieren, der aber auf keiner Sitemap dargestellt wird und dann mit received command und dawn3.receivedCommand == ON / OFF zu arbeiten.
Ich habe es zuerst mal mit received update versucht und das scheint tatsächlich zu funktionieren. :D :D :D
Wenn ich nachts händisch ausschalte, geht es nach ein paar Minuten wieder an. Mal sehen ob es morgen früh auch aus geht.

Code: Alles auswählen

rule "Weihnachtsbeleuchtung Ein_Aus bei Daemmerung"
when
Item dawn2 received update
 
then 
 	if (dawn2.state == OPEN && (now.getMonthOfYear < 3 || now.getMonthOfYear > 10))
 	{
 	sendCommand(TE_Garage_Steckdose, ON)
	}
	else if (dawn2.state == CLOSED && (now.getMonthOfYear < 3 || now.getMonthOfYear > 10))
	{
 	sendCommand(TE_Garage_Steckdose, OFF)
	}
end
Nochmals vielen Dank für die Unterstützung. Jetzt muss ich nicht mehr im November und Februar mittels ETS direkt die knx Steuerung umprogrammieren.

Re: Weihnachtsbeleuchtung bei Dämmerung einschalten aber nur im Winter

Verfasst: 20. Nov 2020 01:09
von udo1toni
Ich verstehe ehrlich gesagt nicht, warum Du auf eine m Contact Item bestehst... Warum willst Du partout Contact verwenden? Bau es einfach auf Switch um, Switch kann genauso ein Mapping verwenden (welches dann natürlich mit ON und OFF statt CLOSED und OPEN läuft). Die über knx gelieferten Werte sind selbstverständlich reine Binärdaten, eben 1 oder 0, die nur abhängig vom verwendeten Channel Type einmal als ON/OFF und im anderen Fall als CLOSED/OPEN interpretiert werden. Sie haben aber ohnehin nichts mit den dargestellten Werten zu tun, also mach Dir bitte das Leben leichter, statt es noch weiter zu verkomplizieren. ;)