neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

[Damian]

Hi,

wow, setList ist ein tolles Feature, vielen Dank! Das spart mir viele dummy-devices!!

Ein Wunsch jedoch:

Code Auswählen Erweitern

A-Z_<persistent user defined readingname>
ist für mich höchst unschön, wenn meine Heizungs-Anschaltzeit plötzlich einen Prefix bekommt.

Wie wärs, mit einem Attribute: "userStaticReadings" oder nur "staticReadings"?

Code Auswählen Erweitern

attr xx staticReadings on|off|Heizungsmodus
ich denke, das wäre nicht unlogischer und sowas wird ja an anderer Stelle auch schon verwendet.

Noch ein Punkt: Sollte nicht der State von "initialized" geändert werden, nachdem ein Reading per set aktualisiert wurde?
Ich nutze initialized, um bestimmte defaultwerte zu überprüfen, diese Überprüfung ist später nicht mehr notwendig, daher würde ich hier eine Änderung vorschlagen.


Edit 1: Rechtschreibfehler, format
Edit2: Nachtrag state

Tja, ist natürlich alles Ansichtssache. Dafür müsste der User für jedes Reading das Attribut pflegen. Warum kann deine Heizungsausschaltzeit nicht mit H_ (wie Heizung) oder A_ (wie Ausschaltzeit) beginnen?

Der Status Initialized ist gekoppelt an das cmd-Reading und das ist entscheidend für die Zustandsverwaltung des Moduls - daher schlecht realisierbar.

[JoeALLb]

Tja, ist natürlich alles Ansichtssache. Dafür müsste der User für jedes Reading das Attribut pflegen. Warum kann deine Heizungsausschaltzeit nicht mit H_ (wie Heizung) oder A_ (wie Ausschaltzeit) beginnen?

Kann.. schon, ist aber unlogisch und muss man ihn einem Jahr noch verstehen. Außerdem arbeite ich viel am Handy und "_" ist da ungünstig.
Sorry, aber das wirkt für mich zu sehr nach krücke, das andere wäre für mich die logischere Methode, die mich mehr an andere Module erinnert.
Ich würde viel lieber die Liste pflegen.... die ich für dblogexclude, event-on-.*, etc. auch schon pflegen muss....

Aber wie gesagt: Gesamt ist das ein tolles Feature, und wollte ich mir auch schon mehrmals wünschen!!

[Ellert]

Hi,

wow, setList ist ein tolles Feature, vielen Dank! Das spart mir viele dummy-devices!!

Ein Wunsch jedoch:

Code Auswählen Erweitern

A-Z_<persistent user defined readingname>
ist für mich höchst unschön, wenn meine Heizungs-Anschaltzeit plötzlich einen Prefix bekommt.

Wie wärs, mit einem Attribute: "userStaticReadings" oder nur "staticReadings"?

Code Auswählen Erweitern

attr xx staticReadings on|off|Heizungsmodus
ich denke, das wäre nicht unlogischer und sowas wird ja an anderer Stelle auch schon verwendet.

Noch ein Punkt: Sollte nicht der State von "initialized" geändert werden, nachdem ein Reading per set aktualisiert wurde?
Ich nutze initialized, um bestimmte defaultwerte zu überprüfen, diese Überprüfung ist später nicht mehr notwendig, daher würde ich hier eine Änderung vorschlagen.


Edit 1: Rechtschreibfehler, format
Edit2: Nachtrag state

Selbst erzeugte Readings werden bei einem Modfiy gelöscht, das kannst Du umgehen, in dem Du über "Raw definition" editierst, dabei werden die Readings wieder gesetzt, sind also quasi persistent.

[Damian]

Kann.. schon, ist aber unlogisch und muss man ihn einem Jahr noch verstehen. Außerdem arbeite ich viel am Handy und "_" ist da ungünstig.
Sorry, aber das wirkt für mich zu sehr nach krücke, das andere wäre für mich die logischere Methode, die mich mehr an andere Module erinnert.
Ich würde viel lieber die Liste pflegen.... die ich für dblogexclude, event-on-.*, etc. auch schon pflegen muss....

Aber wie gesagt: Gesamt ist das ein tolles Feature, und wollte ich mir auch schon mehrmals wünschen!!

Das könnte man als zusätzliches Feature einbauen - wenn ich wieder Zeit habe. Ansonsten kann sich das Ellert anschauen. Die Stelle zum Löschen der Readings ist eindeutig im Modul zu finden.

Gruß

Damian

[Ellert]

Hallo Damian,

a) Ich stelle gerade Dummys auf DOIF um. Dabei habe ich festgestellt, dass $SELF bei Berechnungen in den Attributen "wait" und "state" nicht funktioniert.
Das funktioniert in "state"

Code Auswählen Erweitern

{([TestStatus:cmd]*5)}
und dies nicht

Code Auswählen Erweitern

{([$SELF:cmd]*5)}

Für

Code Auswählen Erweitern

wait 0,300,[$SELF:P_bmofrdur]*60
wird eine Fehlermeldung erzeugt

PERL WARNING: Argument "*main::60" isn't numeric in addition (+) at ./FHEM/98_DOIF.pm line 1733

Das ist nicht tragisch, da ich den Namen direkt angeben kann.

b) Wenn man Gerätenamen in der Definition des DOIF angibt, dann werden sie unter "Probably associated with" aufgelistet.
Das klappt für Gerätenamen, die im Attribut "state" verwendet werden nicht.

Es werden auch Gerätenamen aufgelistet, die als Kommentar angegeben sind.
Leider kann man keine Definition erstellen, die nur einen Kommentar enthält, weil eine Fehlermeldung erzeugt wird.

Code Auswählen Erweitern

define Test DOIF ## Geraet1 liefert

Test DOIF: no left bracket of condition:

Es gibt nur einen Fall, wo ich das nutzen würde, ist also auch nicht tragisch.

c)
Garantiert persistente Reading beginnen mit [A-Z]_.
Spricht etwas dagegen alle Readings nicht zu löschen, ausser die vom DOIF selbst erzeugten?
Also nur

Device
state
error
cmd.*
e_.*
timer_.*
wait_.*
matched_.*

und alle, die zukünftig dazu kommen oder die ich vergessen habe.

Wer dann die nicht garantiert persistenten Readings nutzt, muss das Risiko einer zukünftigen Verwendung durch DOIF in Kauf nehmen.
Dann könnte man sich ein weiteres Attribute sparen. Das Risiko bestünde dort auch.

[JoeALLb]

Dein Lösungsvorschlag für c) würde mir natürlich aus reichen!

   
Einen Wunsch den ich noch hätte, wäre folgender.
Ich kann aber verstehen, wenn du den nur auf sehr niedrige Priorität setzt::

Ich habe oft sehr lange DOIFs, mit über 20 DOELSE:
Dabei verschiebt sich immer mal wieder die Reihenfolge von "cmdState"-Einträgen,
was nicht sonderlich leicht ist, diese wieder korrekt herauszulesen.

Mein Wunsch wäre, diese Namen direkt in den Prüfungen selbst mit anzugeben

Code Auswählen Erweitern

([[Urlaubs:on:"(\d\d:\d\d)"]]  #DIname=Urlaubsprüfung)
((set telegram message xxxx))
DOELSEIF ([[Urlaubs:off:"(\d\d:\d\d)"]] #DIname=UrlaubEnde)


Natürlich wäre für mich auch die Regex-Schreibweise denkbar:

Code Auswählen Erweitern

(?<Urlaubsprüfung>)

[Muschelpuster]

Sorry, aber das wirkt für mich zu sehr nach krücke

Also da sehe ich im FHEM aber andere Baustellen, welche die Assoziation eher verdient haben. Aber hey, das steht ja jedem frei es besser zu programmieren 
Ich stimme Ellert zu: Man könnte ja auch sagen, dass nur die User-Readings nicht gelöscht werden, also nur die Standard-Readings. Aber vielleicht ist es auch cool, wenn man auch sagen kann, dass User-Readings gelöscht werden - auch wenn mir gerade die Idee dazu fehlt. OK, wenn ich ein Reading nicht mehr brauche, kann ich es in anderen Devices nicht löschen...
Aber wenn schon ein Attribut zum User Reading, dann würde ich dafür plädieren, dass man dieses nur für User-Readings setzt, welche gelöscht werden sollen und nicht umgekehrt.

entspannte Grüße
Niels

[JoeALLb]

[...] kann ich es in anderen Devices nicht löschen[...]

klar geht das!

Code Auswählen Erweitern


deletereading <DEVICE> <reading>


[Damian]

Hallo Damian,

a) Ich stelle gerade Dummys auf DOIF um. Dabei habe ich festgestellt, dass $SELF bei Berechnungen in den Attributen "wait" und "state" nicht funktioniert.
Das funktioniert in "state"

Code Auswählen Erweitern

{([TestStatus:cmd]*5)}
und dies nicht

Code Auswählen Erweitern

{([$SELF:cmd]*5)}

Für

Code Auswählen Erweitern

wait 0,300,[$SELF:P_bmofrdur]*60
wird eine Fehlermeldung erzeugt
Das ist nicht tragisch, da ich den Namen direkt angeben kann.

b) Wenn man Gerätenamen in der Definition des DOIF angibt, dann werden sie unter "Probably associated with" aufgelistet.
Das klappt für Gerätenamen, die im Attribut "state" verwendet werden nicht.

Es werden auch Gerätenamen aufgelistet, die als Kommentar angegeben sind.
Leider kann man keine Definition erstellen, die nur einen Kommentar enthält, weil eine Fehlermeldung erzeugt wird.

Code Auswählen Erweitern

define Test DOIF ## Geraet1 liefert Es gibt nur einen Fall, wo ich das nutzen würde, ist also auch nicht tragisch.

c)
Garantiert persistente Reading beginnen mit [A-Z]_.
Spricht etwas dagegen alle Readings nicht zu löschen, ausser die vom DOIF selbst erzeugten?
Also nurund alle, die zukünftig dazu kommen oder die ich vergessen habe.

Wer dann die nicht garantiert persistenten Readings nutzt, muss das Risiko einer zukünftigen Verwendung durch DOIF in Kauf nehmen.
Dann könnte man sich ein weiteres Attribute sparen. Das Risiko bestünde dort auch.

Ich denke alle drei Punkte ließen sich durchaus ohne großen Aufwand realisieren.

[Muschelpuster]

klar geht das!

Code Auswählen Erweitern


deletereading <DEVICE> <reading>


Und wieder was gelernt 

Dann gehen mir auch die Ideen 

lernfähige Grüße
Niels

[Per]

Mein Wunsch wäre, diese Namen direkt in den Prüfungen selbst mit anzugeben

Wie trennst du das bei Sub-States (cmd1_1)(cmd1_2) ab, wenn du z.B. wait einsetzt? Da hast du keine extra Bedingungen in Klammern.

[JoeALLb]

Wie trennst du das bei Sub-States (cmd1_1)(cmd1_2) ab, wenn du z.B. wait einsetzt?

Gleich wie bisher, also mit Trenner. Da es dann trotzdem nahe am Punkt mit dabei steht, wäre es meiner Meinung nach dennoch viel übersichtlicher.
wait wäre hier für mich übrigens auch viel übersichtlicher und vom Zusammenhang her besser platziert... Habe nur ich so große DOIFs?
Aber vermutlich wäre die neue Syntax vom bisherigen zu unterschiedlich...

beispiel:

Code Auswählen Erweitern

([[Urlaubs:on:"(\d\d:\d\d)"]]  #DIname=Urlaubsprüfung|Sub-States #DIwait=1,0,2)

[Per]

OK, so ergibt das Sinn. Gefällt mir, dabei fällt auch gleich der Mischmasch mit den Trennern (":" und "|") weg.
Aber: ich (!) möchte das nicht programmieren müssen Muss ich aber zum Glück auch nicht...

[Damian]

Gleich wie bisher, also mit Trenner. Da es dann trotzdem nahe am Punkt mit dabei steht, wäre es meiner Meinung nach dennoch viel übersichtlicher.
wait wäre hier für mich übrigens auch viel übersichtlicher und vom Zusammenhang her besser platziert... Habe nur ich so große DOIFs?
Aber vermutlich wäre die neue Syntax vom bisherigen zu unterschiedlich...

beispiel:

Code Auswählen Erweitern

([[Urlaubs:on:"(\d\d:\d\d)"]]  #DIname=Urlaubsprüfung|Sub-States #DIwait=1,0,2)

Man kann sicher Vieles anders und auch besser machen. Aber das Modul hat sich über zwei Jahre weiter entwickelt und hat inzwischen eine gewisse Komplexität erreicht, die jetzt schon einige erschlägt. Bei über 30.000 offiziell genutzten Modulen steht die Kompatibilität  und Stabilität an erster Stelle. Jede Änderung des Moduls kann diese zunichtemachen.

Das wären Änderungen, die stark das Modul verändern würden, aber keine echte neue Funktionalität mitbringen würden.

Es steht jedem offen ausgehend von der Idee des Moduls ein neues und besseres zu entwickeln.

Gruß

Damian

[JoeALLb]

Das wären Änderungen, die stark das Modul verändern würden, aber keine echte neue Funktionalität mitbringen würden.

Servus und danke fürs Feedback. Sorry, sollte ich dich damit "beleidigt" haben, das war natürlich keinesfalls mein Ansinnen.
Ich Gebe Dir völlig recht, dass es andere Prioritäten gibt, weshalb ich meinen Wunsch auch sehr vorsichtig fomuliert habe.
Gerade durch die häufige Nutzung und die universelle Einsetzbarkeit deines tollen Moduls bringt die Übersichtlichkeit eben manchmal an ihre Grenzen, weshalb
ich eben nur mitdenken wollte und einen sinnvollen Verbesserungsvorschlag zur weiteren Vereinfachung machen wollte. (Dein ganzes Modul bringt ja hauptsächlich kaum neue Funktionalität,
sondern eine massive Vereinfachung des bisher dagewesenem). Ich denke auch, dass dies die Supportanfragen reduzieren
würde, da mehr Anwender ihre Fehler selbst, bzw. früher erkennen könnten... (gerade mit waits, etc. lese ich des Öfteren von Fehlern)

... Ich hatte nur einen Traum, und wer weiß, vielleicht entwickelt sich in den nächsten Jahren doch etwas in diese Richtung...