neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

[Damian]

Vielleicht als Anlehnung an die Register von Home Matic U- davor Scheiben für user.

Das könnte man auch machen, dann liegen allerdings die Readings mittendrin und es ist ein Zeichen mehr. Die Frage ist, ob "Kompatibilität" zu Home Matic als wichtig angesehen wird oder nicht.

[igami]

Das könnte man auch machen, dann liegen allerdings die Readings mittendrin und es ist ein Zeichen mehr. Die Frage ist, ob "Kompatibilität" zu Home Matic als wichtig angesehen wird oder nicht.

Wo die readings stehen sollte doch egal sein. Bei HM steht halt das R- für Register, daher die Idee U- für user.

[Ellert]

Hallo Damian,

ich habe die Kurzreferenz ergänzt mit checkall und das Beispiel für setList, readingList mit Defaultwerten ausgestattet und notexist entfernt.

Basis ist Version 0.6, ohne Fehler mit commandref_join.pl

[Damian]

Hallo Damian,

ich habe die Kurzreferenz ergänzt mit checkall und das Beispiel für setList, readingList mit Defaultwerten ausgestattet und notexist entfernt.

Basis ist Version 0.6, ohne Fehler mit commandref_join.pl

ok.

Mir fehlt noch ein sinnvolles Beispiel für checkall.

Ich sollte noch erwähnen, dass nicht vorhandene Readings (ohne Ersatzwert) keine Fehlermeldung mehr bringen und intern statt undef ein Leerstring "" zurückgegeben wird. Das war aufgrund des neuen Features: Dafaultvalue erforderlich und sollte weniger zu Problemen führen.

timer-Readings werden jetzt zweistellig dargestellt, damit bleibt die Reihenfolge über 9 erhalten.

[Ellert]

Ehrlich gesagt, ich habe für mich noch nichts gefunden, um checkall einzusetzen.

[Damian]

Ehrlich gesagt, ich habe für mich noch nichts gefunden, um checkall einzusetzen.

Ich auch nicht, aber einige User erwarten dieses Verhalten, weil sie es so in einer sequenziellen Programmierung kennen.

[Ellert]

Nach dem heutigen FHEM Update wird FHEM beendet, wenn ich ein DOIF (version 0.6) definieren möchte, z.B. mit

Code Auswählen Erweitern

define Testgeraet DOIF ([18:00])

Fehlermeldung im Logfile beim Start:

2016.11.16 14:41:10 0: Featurelevel: 5.7
2016.11.16 14:41:10 0: Server started with 46 defined entities (fhem.pl:12564/2016-11-13 perl:5.020002 os:linux user:fhem pid:784)
Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/98_DOIF.pm line 61.
2016.11.16 14:50:21 1: Including fhem.cfg
2016.11.16 14:50:21 3: telnetPort: port 7072 opened
2016.11.16 14:50:22 3: WEB: port 8083 opened
2016.11.16 14:50:23 3: WEBphone: port 8084 opened
2016.11.16 14:50:23 3: WEBtablet: port 8085 opened
2016.11.16 14:50:23 2: eventTypes: loaded 381 events from ./log/eventTypes.txt
2016.11.16 14:50:24 1: PERL WARNING: keys on reference is experimental at ./FHEM/98_DOIF.pm line 61, <$fh> line 139.
2016.11.16 14:50:24 1: stacktrace:
2016.11.16 14:50:24 1:     main::__ANON__                      called by ./FHEM/98_DOIF.pm (61)
2016.11.16 14:50:24 1:     (eval)                              called by fhem.pl (2302)
2016.11.16 14:50:24 1:     (eval)                              called by fhem.pl (2301)
2016.11.16 14:50:24 1:     main::CommandReload                 called by fhem.pl (1725)
2016.11.16 14:50:24 1:     main::LoadModule                    called by fhem.pl (1787)
2016.11.16 14:50:24 1:     main::CommandDefine                 called by fhem.pl (1085)
2016.11.16 14:50:24 1:     main::AnalyzeCommand                called by fhem.pl (955)
2016.11.16 14:50:24 1:     main::AnalyzeCommandChain           called by fhem.pl (1219)
2016.11.16 14:50:24 1:     main::CommandInclude                called by fhem.pl (519)

Edit:
Zeile 61 geändert auf:

Code Auswählen Erweitern

foreach my $key (keys %{$defs{$hash->{NAME}}{READINGS}}) {

[Damian]

Ja, es fehlte die Referenz. Ich habe es angepasst.

[Damian]

Durch die Änderung der timer-Readings auf zweistellige Nummern (da wollen wir mal hoffen, dass keiner mehr als 99-Timer pro Modul definiert) verblieben die alten timer-Readings als Leichen nach einem Neustart. Erst nach einem manuellen def modify wären sie gelöscht.

In Version 0.8 werden jetzt beim Neustart immer alle timer-Readings gelöscht, weil Timer ohnehin immer neugesetzt werden müssen. Damit verschwinden auch alle Altlasten nach dem Neustart.

[Ellert]

Wenn man setList, readinglist zusammen mit dauerhaften Benutzer-Readings verwendet und diese Reading mit einer Vorgabe angegeben sind und Sie noch keinen Wert besitzen (""), wäre es dann nicht sinnvoll alle Benutzer-Readings auf den Vorgabewert zu setzen (ohne Event), bei Definition oder Modify?
Das könnte funktionieren, sofern der Readingname in der Bedingung vollständig angegeben ist und nicht als Regex, also wenn
[$SELF:_<readingname>,<default value>] oder [<eigener Name>:_<readingsname>,<default value>] benutzt wird.

Der Vorteil wäre, dass die Anzeige im Frontend dann den Vorgabewert enthält.

[Damian]

Wenn man setList, readinglist zusammen mit dauerhaften Benutzer-Readings verwendet und diese Reading mit einer Vorgabe angegeben sind und Sie noch keinen Wert besitzen (""), wäre es dann nicht sinnvoll alle Benutzer-Readings auf den Vorgabewert zu setzen (ohne Event), bei Definition oder Modify?
Das könnte funktionieren, sofern der Readingname in der Bedingung vollständig angegeben ist und nicht als Regex, also wenn
[$SELF:_<readingname>,<default value>] oder [<eigener Name>:_<readingsname>,<default value>] benutzt wird.

Der Vorteil wäre, dass die Anzeige im Frontend dann den Vorgabewert enthält.

ja, muss ich mir mal anschauen. Wird aber nicht einfach sein eine passende Stelle im Modul zu finden, wo die nötigen Informationen vorliegen. Andererseits muss der User ohnehin selbst das Reading anlegen und dann kann er es auch gleich vorbelegen.

[Yil]

Hi Damian,

ich habe folgende Definition für das Gartenlicht aufgebaut:

Code Auswählen Erweitern

([([{sunrise("HORIZON=-1.5",0,"05:20","08:14")}]) -
      ([09:00]+2700+int(rand(900)))|7] and [Garten.Bewegung:1.BRIGHTNESS] < 130 and [Sommerzeit] ne 'on')
      (({if (Value('Garten.Beleuchtung') eq 'off') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung Wochenende morgens: angeschaltet','Steph')}}),
      ({if (Value('Garten.Beleuchtung') eq 'off') {Log 3,"Gartenbeleuchtung Wochenende morgens: An"}}),
  (set Garten.Beleuchtung:FILTER=STATE!=on on))
DOELSEIF (
      [([{sunrise("HORIZON=-1.5",0,"05:20","06:30")}]+int(rand(900))) -
  ([{sunrise("HORIZON=-1.5",0,"05:20","08:14")}]+2700+int(rand(900)))|8] and [Garten.Bewegung:1.BRIGHTNESS] < 130 and [Sommerzeit] ne 'on')
      (({if (Value('Garten.Beleuchtung') eq 'off') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung Werktags morgens: angeschaltet','Steph')}}),
      ({if (Value('Garten.Beleuchtung') eq 'off') {Log 3,"Gartenbeleuchtung Werktags morgens: An"}}),
  (set Garten.Beleuchtung:FILTER=STATE!=on on))
DOELSEIF (
      [{sunset("HORIZON=-2.0",0,"16:28","21:29")} -
  ([21:45]+int(rand(900)))] and [Garten.Bewegung:1.BRIGHTNESS] < 130)
      (({if (Value('Garten.Beleuchtung') eq 'off') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung abends: angeschaltet','Steph')}}),
      ({if (Value('Garten.Beleuchtung') eq 'off') {Log 3,"Gartenbeleuchtung abends: An"}}),
  (set Garten.Beleuchtung:FILTER=STATE!=on on),
  (set Osram05:FILTER=STATE=off dim1%),(set Osram05 dim75% 900))
DOELSE (
      ({if (Value('Garten.Beleuchtung') eq 'on') {PushInfo('Gartenbeleuchtung','Gartenbeleuchtung: ausgeschaltet','Steph')}}),
  ({if (Value('Garten.Beleuchtung') eq 'on') {Log 3,"Gartenbeleuchtung: Aus"}}),
      (set Garten.Beleuchtung:FILTER=STATE!=off off),(set Osram05:FILTER=STATE!=off off))

Daraus werden folgende Zeiten errechnet:

Code Auswählen Erweitern

Readings:
     2016-11-17 10:29:40   Device          Garten.Bewegung
     2016-11-17 10:29:40   cmd             4
     2016-11-17 10:29:40   cmd_event       Garten.Bewegung
     2016-11-17 10:29:40   cmd_nr          4
     2016-11-17 10:29:40   e_Garten.Bewegung_1.BRIGHTNESS 181
     2016-11-17 05:06:00   e_Sommerzeit_STATE off
     2016-11-17 10:29:40   state           cmd_4
     2016-11-17 09:55:33   timer_1_c1      18.11.2016 07:32:24|7
     2016-11-17 09:55:33   timer_2_c1      18.11.2016 09:49:27|7
     2016-11-17 08:23:51   timer_3_c2      18.11.2016 06:35:09|8
     2016-11-17 08:23:51   timer_4_c2      18.11.2016 08:30:13|8
     2016-11-17 05:30:32   timer_5_c3      17.11.2016 16:48:58
     2016-11-17 05:30:32   timer_6_c3      17.11.2016 21:46:40

Folgende Log-Einträge werden geschrieben:

Code Auswählen Erweitern

2016.11.17 06:39:57 3: Gartenbeleuchtung Werktags morgens: An
2016.11.17 07:30:55 3: Gartenbeleuchtung: Aus
2016.11.17 07:39:13 3: Gartenbeleuchtung Werktags morgens: An
2016.11.17 08:23:51 3: Gartenbeleuchtung: Aus
2016.11.17 08:27:41 3: Gartenbeleuchtung Werktags morgens: An
2016.11.17 08:32:29 3: Gartenbeleuchtung: Aus

Kannst Du nachvollziehen, warum sich das Gartenlicht während des Zeitraumes aus CMD_2 mehrfach in CMD_4 wechselt? Würde das neue Attribut checkall hier etwas helfen?

VG Yil

[Damian]

Zufällige Intervalle sind immer kritisch zu sehen:

Beispiel:

[10:00-(sunset+rand(3600)]

gestern wurde z. B. die errechnete Zeit auf sunset+1000 errechnet, heute wird um diese Zeit getriggert - zu diesem Zeitpunkt ist das Intervall nicht mehr wahr und  DOELSE schlägt zu. Gleichzeitig wird die neue Endzeit berechnet z. b. sunset+3000. Damit verlängert sich das Intervall um ca. 2000 Sekunden und ist wieder wahr. In dieser Zeit kann wieder ein Trigger kommen, der zur erneuten Ausführung dieses Zweiges führt, da ein Zustandswechsel erfolgte. Ein checkall würde die Sache eher noch verschlimmern.

[Yil]

Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?

[Ellert]

Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?

Statt eine Zufallszahl bei der Zeitangabe zu verwenden könntest Du ein zufälliges wait verwenden.

Code Auswählen Erweitern

attr <name> wait rand(900):rand(900):rand(900)