Hallo,
bin neu hier und steige gerade in die fhem-Welt ein.
Dachte mir, ich fange mal "ganz leicht" an und scheitere schon kläglich.
Die Idee war, eine YeeLight nur durch einen Aqara Motion Sensor zu schalten, wenn es tatsächlich dunkel ist. Den ursprünglichen Gedanken, hierfür den im Sensor integrierten Helligkeitssensor zu nutzen, habe ich erstmal begraben, da das Ding auch schon bei eigentlich noch brauchbaren Lichtverhältnissen 0 Lux "misst". Außerdem aktualisiert sich der Messwert extrem selten. Ich habe noch keine Möglichkeit gefunden, da eine gewisse Regelmäßigkeit bzw. Steigerung der Häufigkeit der Messungen reinzubringen.
Also nächster Gedanke: twilight. Recht naheliegend.
Ich habe bislang allerdings noch nicht begriffen, wie ich die Zeit auf den Zeitraum zwischen sunset und unrise begrenze. Ggf. macht es auch Sinn, da einen zeitlichen Offset reinzubasteln.
Da ich ja "Vor dem ersten Post unbedingt lesen" gelesen habe, hier noch alles, was das System ausspuckt
Der Sensor
Internals:
DEF 158d0001e522d9 sensor_motion.aq2 XiaomiGW
IODev XiaomiGW
LASTInputDev XiaomiGW
MODEL sensor_motion.aq2
MSGCNT 24
NAME Motion_Garderobe
NR 46
SID 158d0001e522d9
STATE motion
TYPE XiaomiSmartHome_Device
VERSION 1.20
XiaomiGW_MSGCNT 24
XiaomiGW_TIME 2018-04-14 14:38:53
READINGS:
2018-04-14 14:26:51 battery ok
2018-04-14 14:26:51 battery_level 3
2018-04-14 14:26:51 heartbeat 158d0001e522d9
2018-04-14 14:33:54 lux 0
2018-04-14 14:38:53 no_motion 300
2018-04-14 14:33:54 state motion
Attributes:
IODev XiaomiGW
devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green
icon message_presence
room MiSmartHome
twilight 'device' heißt bei mir geo
Internals:
CONDITION 26
CONDITION_TXT Cloudy
DEF 52.6XXXXX 13.5XXXXX 1 693XXX
INDOOR_HORIZON 1
LATITUDE 52.6XXXXX
LONGITUDE 13.5XXXX
NAME geo
NR 51
STATE 6
SUNPOS_OFFSET 300
SWIP 0
TEMPERATUR 14
TYPE Twilight
VERSUCHE 0
WEATHER 69XXXX
WEATHER_CORRECTION 1.6
WEATHER_HORIZON 2.6
READINGS:
2018-04-14 12:55:31 aktEvent sr_weather
2018-04-14 14:50:22 azimuth 216.51
2018-04-14 14:50:22 compasspoint south-southwest
2018-04-14 12:55:28 condition 26
2018-04-14 12:55:28 condition_txt Cloudy
2018-04-14 14:50:22 elevation 43.1
2018-04-14 12:55:31 horizon 2.6
2018-04-14 12:55:31 light 6
2018-04-14 12:55:31 nextEvent ss_weather
2018-04-14 12:55:31 nextEventTime 19:38:45
2018-04-14 12:55:28 sr 06:17:33
2018-04-14 12:55:28 sr_astro 03:59:54
2018-04-14 12:55:28 sr_civil 05:35:37
2018-04-14 12:55:28 sr_indoor 06:24:22
2018-04-14 12:55:28 sr_naut 04:50:39
2018-04-14 12:55:28 sr_weather 06:35:10
2018-04-14 12:55:28 ss 19:56:26
2018-04-14 12:55:28 ss_astro 22:15:17
2018-04-14 12:55:28 ss_civil 20:38:36
2018-04-14 12:55:28 ss_indoor 19:49:36
2018-04-14 12:55:28 ss_naut 21:23:54
2018-04-14 12:55:28 ss_weather 19:38:45
2018-04-14 12:55:31 state 6
2018-04-14 14:50:22 twilight 100
2018-04-14 14:50:22 twilight_weather 100
TIMER:
geo_Midnight:
HASH geo
MODIFIER Midnight
NAME geo_Midnight
geo_sr:
DEG 0
HASH geo
LIGHT 4
MODIFIER sr
NAME geo_sr
NAMENEXT sr_indoor
STATE 4
SWIP 0
TIME 1523679453.03
geo_sr_astro:
DEG -18
HASH geo
LIGHT 1
MODIFIER sr_astro
NAME geo_sr_astro
NAMENEXT sr_naut
STATE 1
SWIP 0
TIME 1523671194
geo_sr_civil:
DEG -6
HASH geo
LIGHT 3
MODIFIER sr_civil
NAME geo_sr_civil
NAMENEXT sr
STATE 3
SWIP 0
TIME 1523676937.02
geo_sr_indoor:
DEG 1
HASH geo
LIGHT 5
MODIFIER sr_indoor
NAME geo_sr_indoor
NAMENEXT sr_weather
STATE 5
SWIP 0
TIME 1523679862.04
geo_sr_naut:
DEG -12
HASH geo
LIGHT 2
MODIFIER sr_naut
NAME geo_sr_naut
NAMENEXT sr_civil
STATE 2
SWIP 0
TIME 1523674239.01
geo_sr_weather:
DEG 2.6
HASH geo
LIGHT 6
MODIFIER sr_weather
NAME geo_sr_weather
NAMENEXT ss_weather
STATE 6
SWIP 0
TIME 1523680510.05
geo_ss:
DEG 0
HASH geo
LIGHT 3
MODIFIER ss
NAME geo_ss
NAMENEXT ss_civil
STATE 9
SWIP 0
TIME 1523728586.97
geo_ss_astro:
DEG -18
HASH geo
LIGHT 0
MODIFIER ss_astro
NAME geo_ss_astro
NAMENEXT sr_astro
STATE 12
SWIP 0
TIME 1523736917
geo_ss_civil:
DEG -6
HASH geo
LIGHT 2
MODIFIER ss_civil
NAME geo_ss_civil
NAMENEXT ss_naut
STATE 10
SWIP 0
TIME 1523731116.98
geo_ss_indoor:
DEG 1
HASH geo
LIGHT 4
MODIFIER ss_indoor
NAME geo_ss_indoor
NAMENEXT ss
STATE 8
SWIP 0
TIME 1523728176.96
geo_ss_naut:
DEG -12
HASH geo
LIGHT 1
MODIFIER ss_naut
NAME geo_ss_naut
NAMENEXT ss_astro
STATE 11
SWIP 0
TIME 1523733834.99
geo_ss_weather:
DEG 2.6
HASH geo
LIGHT 5
MODIFIER ss_weather
NAME geo_ss_weather
NAMENEXT ss_indoor
STATE 7
SWIP 0
TIME 1523727525.95
geo_sunpos:
HASH geo
MODIFIER sunpos
NAME geo_sunpos
geo_weather:
HASH geo
MODIFIER weather
NAME geo_weather
TW:
sr:
DEG 0
LIGHT 4
NAME sr
NAMENEXT sr_indoor
STATE 4
SWIP 0
TIME 1523679453.03
sr_astro:
DEG -18
LIGHT 1
NAME sr_astro
NAMENEXT sr_naut
STATE 1
SWIP 0
TIME 1523671194
sr_civil:
DEG -6
LIGHT 3
NAME sr_civil
NAMENEXT sr
STATE 3
SWIP 0
TIME 1523676937.02
sr_indoor:
DEG 1
LIGHT 5
NAME sr_indoor
NAMENEXT sr_weather
STATE 5
SWIP 0
TIME 1523679862.04
sr_naut:
DEG -12
LIGHT 2
NAME sr_naut
NAMENEXT sr_civil
STATE 2
SWIP 0
TIME 1523674239.01
sr_weather:
DEG 2.6
LIGHT 6
NAME sr_weather
NAMENEXT ss_weather
STATE 6
SWIP 0
TIME 1523680510.05
ss:
DEG 0
LIGHT 3
NAME ss
NAMENEXT ss_civil
STATE 9
SWIP 0
TIME 1523728586.97
ss_astro:
DEG -18
LIGHT 0
NAME ss_astro
NAMENEXT sr_astro
STATE 12
SWIP 0
TIME 1523736917
ss_civil:
DEG -6
LIGHT 2
NAME ss_civil
NAMENEXT ss_naut
STATE 10
SWIP 0
TIME 1523731116.98
ss_indoor:
DEG 1
LIGHT 4
NAME ss_indoor
NAMENEXT ss
STATE 8
SWIP 0
TIME 1523728176.96
ss_naut:
DEG -12
LIGHT 1
NAME ss_naut
NAMENEXT ss_astro
STATE 11
SWIP 0
TIME 1523733834.99
ss_weather:
DEG 2.6
LIGHT 5
NAME ss_weather
NAMENEXT ss_indoor
STATE 7
SWIP 0
TIME 1523727525.95
Attributes:
und zu guter letzt die DOIF Regel, von der ich natürlich weiß, dass sie nicht richtig sein kann
define Garderoben_Licht DOIF (([Motion_Garderobe:"motion"]) and ([[geo:ss_civil]])) (set Garderobenlicht on-for-timer 61)
Nichts einfacher als das.
define Garderoben_Licht notify Motion_Garderobe:motion { fhem('set Garderobenlicht on-for-timer 61') unless isday('CIVIL')) }
bewirkt: "Mach das Licht für 61 Sekunden an, ausser tagsüber"
Die regexp für den Bewegungsmelder musst Du ggf. noch anpassen.
ok... Da wäre ich so schnell nicht drauf gekommen...
eben hatte ich noch überlegt, ob das mit DOIF so funktioniert hätte:
define Garderoben_Licht DOIF (([Motion_Garderobe:"motion"]) and ([[geo:ss_civil]-[geo:sr_civil]])) (set Garderobenlicht on-for-timer 61)
ich bin bekennender DOIF Verweigerer und bevorzuges pures FHEM bzw. pures perl 8)
Und grundsätzlich kennt FHEM die Daten für Sonnenauf- und Untergang auch völlig ohne TWILIGHT device. Die Zeitpunkte ergeben sich eindeutig aus der geografischen Lage, die man über globale Attribute definiert.
Verstehe. Dennoch erstmal danke.
Ich habs jetzt erstmal mit meiner DOIF Variante probiert. 20:38 bin ich schlauer.
Wenn´s nicht geht, schieß' ich mich gern auf Deinen Vorschlag ein ;-)
Deine DOIF Variante ist einfach aus Performancegründen eine ziemliche Katastrophe (wofür Du als Anwender nichts kannst, das ist einfach technisch bedingt). Wenn man nur 5 devices in seinem FHEM hat, fällt das nicht auf. Aber bei mir sind inzwischen mehrere Hundert devices vorhanden.
Zitat von: betateilchen am 14 April 2018, 17:03:21
Deine DOIF Variante ist einfach aus Performancegründen eine ziemliche Katastrophe (wofür Du als Anwender nichts kannst, das ist einfach technisch bedingt). Wenn man nur 5 devices in seinem FHEM hat, fällt das nicht auf. Aber bei mir sind inzwischen mehrere Hundert devices vorhanden.
Das behaupten Leute, die nicht wissen, wie ein Modul intern funktioniert. Dein definiertes Moduls ist vergleichbar performant, wie das notify. Die DOIF-Definition ist nämlich bereits nach der Definition weitgehend in Perl übersetzt worden. Die meiste Performance dürfte hier der set-Befehl verbrauchen, denn dieser wird in beiden Varianten jedes Mal über die gleiche Routine in Perl übersetzt. Würde ich auch den set-Befehl bereits zum Definitionszeitpunkt in den internen Funktionsaufruf übersetzen, dürfe DOIF sogar performanter sein als ein notify ;)
und bevor die Diskussion hier weiter geht:
defmod di_test6 DOIF ([di_trigger])(set bla on)
vs.
defmod n_test6 notify di_trigger set bla on
Ergebnis:
name function max count total average maxDly avgDly TS Max call param Max call
di_test6 DOIF_Notify 18 3360 5605.11 1.67 0.00 0.00 14.04. 19:29:19 HASH(di_test6);
n_test6 notify_Exec 29 3360 8867.35 2.64 0.00 0.00 14.04. 19:36:55 HASH(n_test6);
Hier also der Nachweis, dass selbst im einfachsten Fall DOIF um ca. 60% performanter ist als ein notify: beide Module wurden 3360 mal getriggert und haben 3360 mal "set bla on" ausgeführt.
Beim nächsten Mal bitte vorher informieren, bevor man hier unqualifizierte und vor allem falsche Behauptungen aufstellt ;)
PS: DOIF-Perl mit Perl-FHEM-Funktionsaufrufen ist noch mal um einiges performanter
Wo soll das jetzt hinführen?
Ganz im Ernst! Das hat doch nunmehr nichts mehr mit meinem Anliegen zu tun.
Btw: Mein fhem läuft auf einem i5. Denke nicht, dass ich mir um Performance großartig Gedanken machen muss.
Es ist auch nicht so, dass ich gestern erst vom Baum gestiegen bin. Bin nur eben neu in Sachen fhem. Perl ist nicht so meins. Python auch nicht. Bei php oder n bissl Shell-Scripten sieht die Sache schon anders aus.
Will die Hardware, die da ist, nur halbwegs sinnfüllend nutzen. In 40min weiß ich wenigstens, ob meine define Line funktioniert. Evtl. habt Ihr Euch bis dahin wieder eingekriegt.
Zitat von: sh4 am 14 April 2018, 19:59:17
Wo soll das jetzt hinführen?
Ganz im Ernst! Das hat doch nunmehr nichts mehr mit meinem Anliegen zu tun.
Btw: Mein fhem läuft auf einem i5. Denke nicht, dass ich mir um Performance großartig Gedanken machen muss.
Es ist auch nicht so, dass ich gestern erst vom Baum gestiegen bin. Bin nur eben neu in Sachen fhem. Perl ist nicht so meins. Python auch nicht. Bei php oder n bissl Shell-Scripten sieht die Sache schon anders aus.
Will die Hardware, die da ist, nur halbwegs sinnfüllend nutzen. In 40min weiß ich wenigstens, ob meine define Line funktioniert. Evtl. habt Ihr Euch bis dahin wieder eingekriegt.
Es gibt auch viele Leute, die FHEM auf einem Raspi laufen haben und hunderte von DOIFs bzw. notifys definiert haben.
Hier lesen viele Leute, es gibt auch viele Diskussionen zu diesem Thema z. B. hier: https://forum.fhem.de/index.php/topic,66830.0.html.
Was würdest du tun, wenn Fake-News über dein Modul verbreitet würden?
Zitat von: Damian am 14 April 2018, 20:10:08
Was würdest du tun, wenn Fake-News über dein Modul verbreitet würden?
Popcorn holen. Vor allem, wenn in der Diskussion Äpfel mit Birnen verglichen werden.