neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

Begonnen von Damian, 05 Oktober 2016, 19:58:14

Vorheriges Thema - Nächstes Thema

Damian

Zitat von: igami am 15 November 2016, 05:50:56
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

igami

Zitat von: Damian am 15 November 2016, 08:46:05
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.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

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

Zitat von: Ellert am 15 November 2016, 19:14:03
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

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

Damian

Zitat von: Ellert am 15 November 2016, 22:54:29
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

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

define Testgeraet DOIF ([18:00])

Fehlermeldung im Logfile beim Start:
Zitat2016.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: foreach my $key (keys %{$defs{$hash->{NAME}}{READINGS}}) {


Damian

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

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.

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

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

Zitat von: Ellert am 17 November 2016, 08:11:38
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Yil

Hi Damian,

ich habe folgende Definition für das Gartenlicht aufgebaut:
([([{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:
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:
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
HM CCU2 mit ca. 35 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth
Osram Lightify

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.





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

Yil

Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?
HM CCU2 mit ca. 35 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth
Osram Lightify

Ellert

Zitat von: Yil am 17 November 2016, 12:13:49
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.

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