DOIF: Brightness-Mittelwertberechnung in "state"

Begonnen von FunkOdyssey, 23 November 2015, 12:53:10

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Hallo miteinander,

in der CommandRef ist ein Beispiel aufgeführt, wie man im DOIF-state direkt Berechnungen durchführen kann:
define di_average DOIF
attr di_average state Average of the two rooms is {([room1:temperature]+[room2:temperature])/2}


Dies nutze ich auch bereits für die Mittlerwertberechnung der Helligkeit von zwei Bewegungsmelder.

Nun will ich aber mittels Perl einen if-Vergleich dort durchführen und bekomme das nicht hin. Geht das überhaupt?

Beispiel:

{
if ([lampe_bei_bm] eq "on")
     {(([bm1:brightness]-100+[bm2:brightness])/2)}
else
     {(([bm1:brightness]+[bm2:brightness])/2)}
}


Der if-Vergleich scheint nicht zu funktionieren. Im "state" steht nachher folgender Inhalt:

{if (off eq "on") {((212-100+206)/2)} else {((212+206)/2)}}

Habt ihr eine Idee? Vielen Dank.

Damian

Zitat von: FunkOdyssey am 23 November 2015, 12:53:10
Hallo miteinander,

in der CommandRef ist ein Beispiel aufgeführt, wie man im DOIF-state direkt Berechnungen durchführen kann:
define di_average DOIF
attr di_average state Average of the two rooms is {([room1:temperature]+[room2:temperature])/2}


Dies nutze ich auch bereits für die Mittlerwertberechnung der Helligkeit von zwei Bewegungsmelder.

Nun will ich aber mittels Perl einen if-Vergleich dort durchführen und bekomme das nicht hin. Geht das überhaupt?

Beispiel:

{
if ([lampe_bei_bm] eq "on")
     {(([bm1:brightness]-100+[bm2:brightness])/2)}
else
     {(([bm1:brightness]+[bm2:brightness])/2)}
}


Der if-Vergleich scheint nicht zu funktionieren. Im "state" steht nachher folgender Inhalt:

{if (off eq "on") {((212-100+206)/2)} else {((212+206)/2)}}

Habt ihr eine Idee? Vielen Dank.

Das wird wohl nicht funktionieren. Da wirst du wohl mit einem Dummy arbeiten müssen

DOIF ([lampe_bei_bm] eq "on") (set mein_dummy {([bm1:brightness]-100+[bm2:brightness])/2}) DOELSE (set mein_dummy {([bm1:brightness]+[bm2:brightness])/2})

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FunkOdyssey

#2
Danke für deine Antwort.
Schade eigentlich. Ich hatte mich gerade an die Kurzvariante gewöhnt. :-)

Ein kleines Problem bleibt dann aber noch. Das Triggern durch die Bewegungsmelder finde nicht statt, wenn diese nicht im Condition-Teil stehen. Ich finde folgenden Code zwar nicht elegant, aber es scheint zu funktionieren. Und ich spare mir einen Dummy, wenn ich die Readings einfach direkt im DOIF speichere. Keine Ahnung, ob mich das nachher noch irgendwie einholen wird. :-)

(
[lampe_bei_bm] eq "on" and
[bm1:brightness] and
[bm2:brightness]
)
(
setreading di_bright_average brightness_terasse [bm1:brightness],
setreading di_bright_average brightness_gartentor [bm2:brightness],
setreading di_bright_average brightness_average {([bm1:brightness]-100+[bm2:brightness])/2}
)
DOELSEIF
(
[lampe_bei_bm] eq "off" and
[bm1:brightness] and
[bm2:brightness]
)
(
setreading di_bright_average brightness_terasse [bm1:brightness],
setreading di_bright_average brightness_gartentor [bm2:brightness],
setreading di_bright_average brightness_average {([bm1:brightness]+[bm2:brightness])/2}
)



Nachtrag 1:
Natürlich darf "do always" nicht fehlen.
Und richtig viel Sinn macht das Berechnen des Durchschnitts in Abhängigkeit von einer unmittelbaren Lichtquelle nur, wenn das brightFilter-Register in den Bewegungsmeldern auf "0" gesetzt wird.

Nachtrag 2:
Ein Dummy macht doch wirklich mehr Sinn. Das DOIF verliert nach dem Bearbeiten des DEFs die vorherigen Readings. Somit könnten abhängige Geräte falsch reagieren oder einen Fehler auswerfen, wenn die Readings für kurze Zeit fehlen.

Damian

Zitat von: FunkOdyssey am 23 November 2015, 15:21:33
Danke für deine Antwort.
Schade eigentlich. Ich hatte mich gerade an die Kurzvariante gewöhnt. :-)

Ein kleines Problem bleibt dann aber noch. Das Triggern durch die Bewegungsmelder finde nicht statt, wenn diese nicht im Condition-Teil stehen. Ich finde folgenden Code zwar nicht elegant, aber es scheint zu funktionieren. Und ich spare mir einen Dummy, wenn ich die Readings einfach direkt im DOIF speichere. Keine Ahnung, ob mich das nachher noch irgendwie einholen wird. :-)

(
[lampe_bei_bm] eq "on" and
[bm1:brightness] and
[bm2:brightness]
)
(
setreading di_bright_average brightness_terasse [bm1:brightness],
setreading di_bright_average brightness_gartentor [bm2:brightness],
setreading di_bright_average brightness_average {([bm1:brightness]-100+[bm2:brightness])/2}
)
DOELSEIF
(
[lampe_bei_bm] eq "off" and
[bm1:brightness] and
[bm2:brightness]
)
(
setreading di_bright_average brightness_terasse [bm1:brightness],
setreading di_bright_average brightness_gartentor [bm2:brightness],
setreading di_bright_average brightness_average {([bm1:brightness]+[bm2:brightness])/2}
)



Nachtrag
Natürlich darf "do always" nicht fehlen.
Und richtig viel Sinn macht das Berechnen des Durchschnitts in Abhängigkeit von einer unmittelbaren Lichtquelle nur, wenn das brightFilter-Register in den Bewegungsmeldern auf "0" gesetzt wird.

Ich würde die Abfrage dann aber so definieren:

[lampe_bei_bm] eq "on" and ([bm1:?brightness] or [bm2:?brightness])

damit es auch dann funktioniert, wenn brightness Null liefert.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FunkOdyssey

Danke. Probiere ich direkt mal aus.
Ich habe meinen vorherigen Post auch schon wieder ein wenig überarbeitet.
Ein Dummy macht doch mehr Sinn. :-)

Offtopic, aber schade eigentlich, dass bei mir eine Lampe direkt in der Nähe eines Bewegungsmelder hängt und ich hier nun tricksen muss. Mit einem "brightFilter"-Register von 7 müsste ich 42 Minuten warten, bis sich die Lichtveränderung am brightness-Wert auswirkt. Das ist einerseits gut, um kurzzeitige Schwankungen (ähnlich Flurlicht) herauszufiltern. Aber wenn man mal eine Lampe länger als 42 Minuten aktiviert, so spielt bei mir alles verrückt. Ich habe zig DOIFs, die in Abhängigkeit vom Helligkeitswert die Lampen ein- und ausschalten wie auch die Jalousien steuern. Und plötzlich gehen Jalousien wieder hoch/runter und Lampen aus- und wieder an. :-) Man kann dann von Glück reden, wenn geschlossene Jalousien NUR noch einmal geschlossen werden. Aber wenn plötzlich die Haustürbeleuchtung ausgeht, nur weil man an eine Lampe in der Nähe eines BM eingeschaltet hat, dann ist das schon doof. :-)

Damian

Zitat von: FunkOdyssey am 23 November 2015, 16:15:40
Danke. Probiere ich direkt mal aus.
Ich habe meinen vorherigen Post auch schon wieder ein wenig überarbeitet.
Ein Dummy macht doch mehr Sinn. :-)

Offtopic, aber schade eigentlich, dass bei mir eine Lampe direkt in der Nähe eines Bewegungsmelder hängt und ich hier nun tricksen muss. Mit einem "brightFilter"-Register von 7 müsste ich 42 Minuten warten, bis sich die Lichtveränderung am brightness-Wert auswirkt. Das ist einerseits gut, um kurzzeitige Schwankungen (ähnlich Flurlicht) herauszufiltern. Aber wenn man mal eine Lampe länger als 42 Minuten aktiviert, so spielt bei mir alles verrückt. Ich habe zig DOIFs, die in Abhängigkeit vom Helligkeitswert die Lampen ein- und ausschalten wie auch die Jalousien steuern. Und plötzlich gehen Jalousien wieder hoch/runter und Lampen aus- und wieder an. :-) Man kann dann von Glück reden, wenn geschlossene Jalousien NUR noch einmal geschlossen werden. Aber wenn plötzlich die Haustürbeleuchtung ausgeht, nur weil man an eine Lampe in der Nähe eines BM eingeschaltet hat, dann ist das schon doof. :-)

Mit Tricks geht auch das State-Attribut:

{();if ("[lampe_bei_bm]" eq "on")
     {([bm1:brightness]-100+[bm2:brightness])/2}
else
     {([bm1:brightness]+[bm2:brightness])/2}
}


Ist zwar nicht die eleganteste Lösung, aber sie funktioniert. :)

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FunkOdyssey

Ey, jetzt habe ich gerade mein komplettes Fhem umgeräumt. :-)
Trotzdem danke.

FunkOdyssey

Ich merke gerade, dass das alles eine doofe Idee war.
Egal welche Berechnungen ich durchführe, es bringt nichts, wenn die Bewegungsmelder nicht schneller die neuen Werte übertragen. Beim Trigger (Cond-Teil) habe ich schon den zweiten BM entfernt, da nur der BM in der Nähe der Lampe triggern darf.
[lampe_bei_bm] eq "on" and [bm_bei_lampe:?brightness]

Problem Nummer 1:
Schalte ich um 16:00 Uhr die Lampe ein und um 16:01 Uhr triggert der BM zyklisch, so enthält der brightness-Wert noch nicht die neue "Erleuchtung". :-) Eine Minute ist zu wenig für die Berechnung des brightness-Wertes im BM. Bei nächsten Zyklus passt es dann einigermaßen.

Problem Nummer 2:
Die Berechnung "-100" ist nicht für den ganzen Tag gültig. Bei Dunkelheit liegt das Delta (Lampe an|aus) bei ca. 100. Je heller es wird, umso kleiner ist das Delta.
Ich habe versucht, das Delta mit steigender Dunkelheit "mitwachsen" zu lassen, indem ich nicht immer 100 Einheiten substrahiere, sondern mit Formeln arbeite wie bspw.
{([bm1:brightness]-(100-[twilight:twilight])+[bm2:brightness])/2}
Das macht aber alles keinen Sinn, wenn Problem Nummer 1 nicht behoben werden kann.

Schade eigentlich.

Das ist zwar alles nicht DOIF-spezifisch, aber ich wollte meine Erfahrung hier trotzdem posten.