Timestamp bei unverändertem Reading behalten

[CoolTux]

Ich finde es ist verständlich genug.

[Loredo]

Habe readingsBulkUpdateIfChanged hinzugefuegt, bin ja schliesslich Dienstleister der Modulentwickler.

Als Dokumentationsdienstleister, habe ich die neue Funktion ebenfalls in die Wiki-Doku übernommen: http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#Erzeugen_von_Readings_.2F_Events

Vorbildlich, alle beide. Rühren.

[Loredo]

Das Attribute dem Anwender gehören ist ja glaube ich Konsens.
Ich denke, es ist aber auch nicht verboten Attribute mit Sinnvollen Defaults zu belegen.
Das geht bei Geräten, welche via Autocreate angelegt werden einfacher, als bei Geräten, welche mittels Define angelegt werden.
Vielleicht schafft man es ja, zu erkennen wann ein Gerät erstmalig angelegt wurde und kann dann Attribute einmalig vorbelegen.

So hat hat der Erfahrene Anwender die Möglichkeit alles zu ändern und der 0815 Anwender hat gleich ein Gerät, das gut funktioniert und muss sich nicht mit den Details beschäftigen.

Genau nach diesem Prinzip sind alle meine Module gestrickt.
Die Attribute werden initial in der define-Methode gesetzt und durch ein if($init_done){} abgesichert, damit sie anschließend nur vom Anwender verändert werden können.

[justme1968]

die meinung das attribute dem anwender gehören teile ich.

aber auch das ein modul beim ersten define sinnvolle vorgaben machen sollte damit alles funktioniert. damit der anwender die defaults sehen und verstehen kann reicht es nicht den default parameter von AttrVal zu verwenden. der ist von aussen unsichtbar.

ein beispiel bei dem es nützlich wäre die defaults bei attributen sichtbar zu machen ist übrigens webCmd. one das das attribut gesetzt ist erscheinen bei manchen devices on und off in der raum übersicht und einsteiger fragen sich wie sie das weg bekommen. das man webCmd auf : setzen muss erschliesst sich nicht. wenn das on off als voreingestellt default wert im device sichtbar wäre und nach dem löschen für immer weg ist wäre das logischer.

mit etwas aufwand kann man auch das setzen von default attributen so implementieren das der anwender danach attribute ändern und komplett löschen kann ohne das er durch immer neu angelegte defaults gegängelt wird. um das in allen fällen zu erreichen reicht es aber nicht auf $init_done zu prüfen. das deckt z.b. den modify fall nicht ab.

darum wäre es schön wenn es einen einfacheren weg gäbe das erste interaktive define eines neuen devices zur laufzeit vom define beim einlesen aus der config zu unterscheiden. damit könnte man es einsteigern erleichtern defaults vorzugeben ohne diese (unabsichtlich) aufzuzwingen.

[Loredo]

Dafür prüfst du zusätzlich auch das Vorhandensein von $hash->{OLDDEF}. Hab ich bisher aber auch noch nicht eingebaut und fürs TC Module vergessen...

[justme1968]

wie es geht weiss ich . ich sage ja nur das man es leicht vergisst .

[DeeSPe]

Ich habe heute mein Modul umgebaut von Hyperion_readingsBulkUpdateIfChanged auf nur readingsBulkUpdate da ich die allgemeine Meinung teile dass die Erstellung der Readings vom User über event-on-*-reading selbst beeinflussbar sein soll.

Des Weiteren habe ich meinem Modul ein neues Attribut hyperionAttrRestore spendiert. Im ungesetzten Zustand werden die Default Attribute immer wieder gesetzt wenn sie vom User gelöscht werden. Wird das Attribut auf 0 gesetzt unterbleibt die Erstellung der Default Attribute.
Ich denke das ist ein machbarer Weg. Man könnte die Funktion auch umdrehen.
Eventuell wäre was Ähnliches auch was für ein globales Attribut?

Gruß
Dan

[Loredo]

</Amen>

Bitte für diese Diskussion dann auch ein neues Thema öffnen, ist hier OT.


Gruß

Julian

[rudolfkoenig]

@justme1968:
- warum man default-Attribute bei einem modify setzen sollte, habe ich nicht verstanden.
- webCmd bei on/off/desired-temp im Modul zu setzen waere auch meiner Ansicht besser, allerdings muss das jedes Modul machen. Und webCmd betrifft nur FHEMWEB, d.h. die Module wuerden fuer einen der Frontends Attribute setzen, aber nicht fuer FLOORPLAN, etc.

@DeeSPe: ein Modul, was von mir geloeschte Attribute wieder anlegt, wuerde mich in Wahnsinn treiben. Hilfe mag nett sein, aber der Modulautor soll fuer mich bitte kein Erzieher sein.

[justme1968]

nein. man soll sie ja eben beim modify nicht setzen. das passiert aber wenn man nur $init_done prûft.

[DeeSPe]

</Amen>

Bitte für diese Diskussion dann auch ein neues Thema öffnen, ist hier OT.

Auch wenn OT fand ich die Diskussion sehr nützlich und hab mal geschaut wie Du es jetzt verbessert hast und es bei mir auch entsprechend angepasst.

Danke!!!

@DeeSPe: ein Modul, was von mir geloeschte Attribute wieder anlegt, wuerde mich in Wahnsinn treiben. Hilfe mag nett sein, aber der Modulautor soll fuer mich bitte kein Erzieher sein.

Du hast absolut Recht! Habe mein Modul angepasst und lasse (nach Vorlage von Loredo) die default Attribute nur noch beim define mit anlegen.

nein. man soll sie ja eben beim modify nicht setzen. das passiert aber wenn man nur $init_done prûft.

Ich hoffe das passt endgültig mit Loredo's Vorlage:

Code Auswählen Erweitern

if ($init_done && !defined $hash->{OLDDEF})

Habe es in allen möglichen Situationen getestet (define/modify/restart) und es macht was es soll.

Gruß
Dan