neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

[Ellert]

selftrigger all hat auch nichts gebracht.
Wenn ich bei {([$SELF:my] + [LUM] + 3)} LUM ändere bleibt state initialized, da triggert doch LUM.

Ein anderes Beispiel für Raw definition

So funktioniert es

Code Auswählen Erweitern

defmod errorTest DOIF ([$SELF:my])
attr errorTest do always
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest state {([errorTest:my] * 5)}
attr errorTest webCmd my

setstate errorTest 2016-11-29 20:43:58 my 1


so funktionert es nicht und ergibt den Fehler "state *main::5"

Code Auswählen Erweitern


defmod errorTest DOIF ([$SELF:my])
attr errorTest do always
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest state {([$SELF:my] * 5)}
attr errorTest webCmd my

setstate errorTest 2016-11-29 20:47:38 my 0


[Damian]

War etwas tricky.

Jetzt noch gut testen.

[JoeALLb]

Nett!!

Mit diesem Konstrukt löse ich damit übrigens auch im Moment mein cmdState-Problem
in meinem größten Doif (über 34 DOELSE)

Code Auswählen Erweitern


define myDOIF (XX)
(setreading $SELF statDOIF CommandDescription)
(...)

und

Code Auswählen Erweitern

attr myDOIF [$SELF:statDOIF]

[Ellert]

War etwas tricky.

Jetzt noch gut testen.

Folgendes DOIF und Dummy für Raw-definition:

Code Auswählen Erweitern


defmod LUM dummy
attr LUM group 0SELF
attr LUM readingList humidity
attr LUM room 0_Test
attr LUM setList state:0,1,2,3
attr LUM webCmd state

setstate LUM 1
setstate LUM 2016-11-30 00:04:03 state 1

defmod errorTest DOIF (## [LUM] or [$SELF:my])
attr errorTest do always
attr errorTest group 0SELF
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest state {([$SELF:my] + [errorTest:my] + [LUM])}
attr errorTest webCmd my
setstate errorTest 2016-11-30 09:58:53 my 1

Das funktioniert.

DOIF mit wait

Code Auswählen Erweitern

defmod errorTest DOIF ([LUM])
attr errorTest do always
attr errorTest group 0SELF
attr errorTest readingList my
attr errorTest room 0_Test
attr errorTest setList my:0,1,2
attr errorTest wait {([$SELF:my] + [errorTest:my] + [LUM])}
attr errorTest webCmd my

Wenn state initialized ist und my geändert wird, dann wird state auf "" gesetzt/aktualisiert.
Wenn state initialized ist und das Attribut wait übers Frontend geändert/aktualisiert wird, dann wird state auf ""/aktualisiert gesetzt.

In der Releaseversion wird state durch my nicht beeinflusst, das sollte auch so bleiben.

[JoeALLb]

Nur nochmal zur Nachfrage:

"state" kann im DOIF nicht wie im dummy genutzt werden, es müssen andere Readings verwendet werden, oder?

Mit

Code Auswählen Erweitern

attr errorTest readingList state
zum oberen Beispiel habe ich Schwierigkeiten....

[Ellert]

habe ich Schwierigkeiten....

Und die wären?

[JoeALLb]

Und die wären?

Code Auswählen Erweitern

unknown argument 2 for errorTest, choose one of disable initialize enable state:0,1,2

[JoeALLb]

Noch ein hoffentlich kleiner Wunsch:
Wäre es möglich, bei setList zusätzlich noch ein Linebreak als Trenner zu akzeptieren?
Meine setList wird immer recht lange und das Space als Trenner ist da sehr ungünstig.

[Ellert]

Code Auswählen Erweitern

unknown argument 2 for errorTest, choose one of disable initialize enable state:0,1,2

readingList state versuchen Hattest Du ja schon probiert.

[Ellert]

Noch ein hoffentlich kleiner Wunsch:
Wäre es möglich, bei setList zusätzlich noch ein Linebreak als Trenner zu akzeptieren?
Meine setList wird immer recht lange und das Space als Trenner ist da sehr ungünstig.

Dies ist dafür der falsche Forumsbereich, setList ist vom Dummy adaptiert.

Aber wo ist das Problem?

[Ellert]

Ich schon

Punkt a), b) eingebaut, Eintrag A_Z... zu UserReadings aus der Doku entfernt.

Bitte testen.

Wäre es nicht trotzdem sinnvol einen Namensraum für Benutzerreadings zu definieren?

[JoeALLb]

Aber wo ist das Problem?

Der erste Eintrag funktioniert, die anderen haben solche Artefakte.
Ich dachte, setList sei hier eventuell "eigens" umgesetzt und hat mit dem Dummy-setList nichts gemeinsam

[JoeALLb]

Wäre es nicht trotzdem sinnvol einen Namensraum für Benutzerreadings zu definieren?

Wozu? Ich kann mir keinen sinnvollen Grund dafür vorstellen...
Einzig wenn state (wie oben beschrieben) tatsächlich nicht funktioniert, sollte das in der Doku erwähnt werden...

[Ellert]

Wozu? Ich kann mir keinen sinnvollen Grund dafür vorstellen...
Einzig wenn state (wie oben beschrieben) tatsächlich nicht funktioniert, sollte das in der Doku erwähnt werden...

Um hier vor geschützt zu sein: https://forum.fhem.de/index.php/topic,58556.msg530754.html#msg530754 .
Es könnte auch sein, dass DOIF plötzlich eigene Inhalte in Deine Readings schreibt.

[JoeALLb]

Dieses "Problem" besteht heute mit userReadings auch schon... ich denke das kann hier vernachlässigt werden, aber gut... ist nur meine Meinung
Vielleicht reicht ein Hinweis dazu in der commandref, dass dies sein kann.