attr <FHT> retrycount 3 (Feature Request)

[Zrrronggg!]

Also genau genommen habe ich keinen Feautere Request, sondern einen "unfeature"-Vorschlag.

Folgendes:

Soweit ich weiss wirkt das FHT attr  "retrycount" eigentlich nur, wenn man softbuffer verwendet.  Und softbuffer wiederum wirkt nur, wenn man eine FHZ1x00PCirgendwas verwendet.

Soweit richtig?

Selbst wenn man softbuffer einsetzen kann und tatsächlich einsetzt, will gut überlegt sein, ob man retrycount>1 verwendet, denn in vielen denkbaren Scenarien in der Kommunikation mit FHTs hilft das eher nicht, in Einzelfällen können Probleme sogar verschärft werden.
Weil das Attribute aber existiert und viele Anfänger die commandref nicht auswendig im Kopf haben, glauben sie, das wirkt/hilft auch in ihrem Fall, was überwiegend *nicht* der Fall ist.


Mein Vorschlag ist daher, bei der Anlage eines FHT mittels Autocreate

Code Auswählen Erweitern

attr <FHT> retrycount 3
durch

Code Auswählen Erweitern

attr <FHT> retrycount 1

zu ersetzen, oder sogar GANZ wegzulassen. Ich habe mit FHTs inzwischen einige Erfahrungen und  schätze, dass statistisch weniger Anfänger Probleme haben, wenn man den Retrycount auf 1 lässt.

Ich sage damit nicht, dass in einzelnen Fällen retrycount nicht doch sinnvoll ist, ich meine nur, das es in 80% aller Fälle NICHTS tut, in 15% der Fälle schädlich ist, bzw. Problem verdeckt oder gar selber erzeugt und nur in den restlichen 5% aller Fälle sinnvoll ist. (Zahlen natürlich frei abgeschätzt)

[rudolfkoenig]

Habs geaendert auf implizit 1 von explizit 3.

Dadurch dass es vorher explicit 3 war, haben die bisherigen FHEM-Anwender dieses Attribut in fhem.cfg abgespeichert, d.h. die Aenderung wird nur zukuenftige Anwender betreffen.

[Zrrronggg!]

Habs geaendert auf implizit 1 von explizit 3.

Danke.

Dadurch dass es vorher explicit 3 war, haben die bisherigen FHEM-Anwender dieses Attribut in fhem.cfg abgespeichert, d.h. die Aenderung wird nur zukuenftige Anwender betreffen.

Das ist klar.