Re-Read config/readings

[A.Harrenberg]

Hallo Rudi,

was hälst Du davon wenigstens für die Configregister und Assoziationen "re-read" Befehle einzubauen die bei einem set automatisch das dazu passende get absetzen damit zumindest bei diesen vitalen Readings immer der aktuelle Inhalt steht?

Für Config und Assoziation dürfte das nicht so kompliziert sein, für die normalen Klassenbefehle könnte das an der einen oder anderen Stelle jedoch kompliziert bis unmöglich werden...

Steuern könnte man das über ein Attribut re-read das man dann z.B. mit 0 ausschalten kann, mit 1 config+assoziation und mit 2 alles zurückliest.

Gerade Einsteiger haben damit ja meist ein Verständnisproblem das dort auch veraltete Informationen stehen können.

Gruß,
Andreas.

[krikan]

Hallo Andreas!

Zu dieser Problematik gibt es in https://forum.fhem.de/index.php/topic,39810.0.html von Deinem Namenskollegen eine simple Lösung, die ich aber nicht getestet habe. Und als Spielverderber und Zweifler bin ich nicht wirklich überzeugt von einer solchen Automatik im Modul, die die Modulkomplexität erhöht. Ich glaube zudem nicht, dass es das Verstehen bei den Einsteigern fördert. Man kann das Alter einfach am Zeitstempel erkennen, wenn man es nicht in der Doku erkannt hat. Aber Rudis Entscheidung.. 

Welche Module haben eigentlich eine solche Automatik? Von EnOcean kenne ich das auch nicht.

Gruß, Christian

[mahowi]

Es geht ja wohl um dieses Notify:

Code Auswählen Erweitern

define configGet notify .*:config[^:]* get $NAME $EVTPART0

Wenn ich das richtig sehe, funktioniert das ja nur, wenn ich direkt über die Klasse Configuration Parameter ändere. Ansonsten müsste ich ja alle möglichen Parameter wie z.B. ccsOverride bei Thermostaten ins Notify mit aufnehmen.

[krikan]

Ja.

Bei den normalen Classes abseits von CONFIGURATION und ASSOCIATION, halte ich eine Automatik letztlich für undurchführbar: Viel zu großer Aufwand für manuelle Pflege. Und wenn es dann bei einem Befehl geht und beim anderen nicht, ist die Verwirrung noch größer/perfekt.

Andreas schrieb es etwas vorsichtiger:

für die normalen Klassenbefehle könnte das an der einen oder anderen Stelle jedoch kompliziert bis unmöglich werden...

Aber ich muss/darf nichts entscheiden... 

[A.Harrenberg]

Hi Christian,

Zu dieser Problematik gibt es in https://forum.fhem.de/index.php/topic,39810.0.html von Deinem Namenskollegen eine simple Lösung, die ich aber nicht getestet habe. Und als Spielverderber und Zweifler bin ich nicht wirklich überzeugt von einer solchen Automatik im Modul, die die Modulkomplexität erhöht. Ich glaube zudem nicht, dass es das Verstehen bei den Einsteigern fördert. Man kann das Alter einfach am Zeitstempel erkennen, wenn man es nicht in der Doku erkannt hat. Aber Rudis Entscheidung.. 

also die Lösung ist für Einsteiger aber sicherlich nicht geeignet...

Welche Module haben eigentlich eine solche Automatik? Von EnOcean kenne ich das auch nicht.

Unter Homematic gibt es so ein autoreadreg der die Register von den Geräte (in verschiendenen Abstufungen) zurückliest. Da ist es aber vielleicht auch einfacher, da es dort nicht so eine Gerätevielfalt gibt und die Register auch ein wenig strukturiert sind.

Problem sehe ich aber auch dabei das man bei den Befehlen nicht alle eingefangen bekommt und es dann zu noch mehr Verwirrung führt. Vor allem die Vielfalt an Klassen/Versionen/Gerätebesonderheiten ist hier nicht zu unterschätzen.

Gruß,
Andreas.

[krikan]

Hi Christian,also die Lösung ist für Einsteiger aber sicherlich nicht geeignet...

Warum nicht? notify und RegEx gehören doch zu den Grundlagen, oder?

[rudolfkoenig]

Wir koennten ohne weiteres beim Setzen eines Parameters ein Reading erzeugen, das ist aber irrefuehrend, wenn die Befehle nicht beim Geraet angekommen sind.

Zuruecklesen ist fein, wenn es bei der Kommunikation keine Probleme gibt, und macht alles Fehleranfaelliger, wenn schon Fehler da sind. Ich tendiere eher zum lassen wie es ist, habe aber wirklich kein Problem damit, wenn ich ueberstimmt werde. Z.Zt. schaut es eher nach unentschieden aus

[mahowi]

Rein aus Anwendersicht wäre es ein "nice to have". Ich kann auch gut mit dem Ist-Zustand leben. Vielleicht könnte man aber in der commandref darauf hinweisen, daß sich die Readings erst nach einem get ändern. Mich hat es anfangs auch verwirrt, daß sich scheinbar nichts geändert hat nach einem set. Zumal es auch Geräte gibt, die manche Einstellungen von selbst zurückmelden.

[A.Harrenberg]

Hi,

Warum nicht? notify und RegEx gehören doch zu den Grundlagen, oder?

Ja ja...

Wir koennten ohne weiteres beim Setzen eines Parameters ein Reading erzeugen, das ist aber irrefuehrend, wenn die Befehle nicht beim Geraet angekommen sind.

Nee, das sollten wir auf keinen Fall machen. Das ist dann wirklich irreführend wenn beim senden dann was schief geht.

Zuruecklesen ist fein, wenn es bei der Kommunikation keine Probleme gibt, und macht alles Fehleranfaelliger, wenn schon Fehler da sind. Ich tendiere eher zum lassen wie es ist, habe aber wirklich kein Problem damit, wenn ich ueberstimmt werde. Z.Zt. schaut es eher nach unentschieden aus

Ja momentan ist es wohl unentschieden und in Anbetracht des Aufwands würde ich es dann wohl auch eher nicht machen.

Gruß,
Andreas.

[rudolfkoenig]

Vielleicht könnte man aber in der commandref darauf hinweisen, daß sich die Readings erst nach einem get ändern.

Erledigt