DevelopmentGuidelinesReadings - weitere Vorschläge für künftige Module

[Beta-User]

Hallo zusammen,

aus Anlass der Frage einer möglichen Standardisierung der Anbindung von extern via MQTT möchte ich zumindest Teilaspekte aus battery / batteryLevel / ... -> Vereinheitlichen wieder aufgreifen. Bislang hat jedenfalls keiner, der ggf. dazu in der Lage wäre, eine Art Vorschlag zu einer "großen Lösung" gemacht, von daher bleibt für den Moment eigentlich nur, weiter "Stückwerk" zu machen, so dass es bislang "nur" Vorschläge zum Thema "battery" gibt sowie für AV-Geräte eine etwas umfangreichere Zusammenstellung in https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (Readings und Kommandos).
Weiter gibt es noch https://wiki.fhem.de/wiki/DevelopmentGuidelines#Bezeichnungen, das aber "Archive"-Status hat.

Bereits beim Thema attrTemplate für MQTT2_DEVICE hatte ich das "Vergnügen", hin und wieder entscheiden zu dürfen, ob die vom Gerät "vorgegebenen" Readingnamen oder andere verwendet werden sollen. Im Ergebnis scheint es an der Stelle halbwegs konsistent zu sein, aber befriedigend ist das nicht, denn eigentlich stellt sich die Frage:

Wo wollen wir hin?

Um es vorneweg zu sagen: Es geht hier NICHT darum, den IST-Zustand an irgendeinem Modul zu ändern!
Das gäbe nur Ärger mit den Usern und entsprechende Irritationen und Supportanfragen. Wer bestehende Module umstellen will, darf das gerne tun, aber auch da stellt sich ja die Frage, wo "man" eigentlich hin will.
Diese Vorfrage zu klären, ist daher Anliegen dieses Threads, und eigentlich ist das auch nicht unbedingt nur eine Developer-Frage, sondern auch eine nach den Wünschen der User.

Klar ist: Bestimmte Reading-Namen sind (in FHEM) auf spezielle Weise implementiert und werden von diversen Hilfsfunktionen automatisch entsprechend behandelt. Einfaches Beispiel: Wenn "desired-temp" als setter da ist, weiß afaik nicht nur WeekdayTimer, dass das ein Heizungsgerät ist, auch in der Sprachsteuerung scheint sich sowas (ggf. in Verbindung mit genericDeviceType) durch "funktioniert einfach" bemerkbar zu machen etc. pp..

Langer Rede kurzer Sinn:

Ausgehend von dem Thread MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen wäre meine Idee, zusammenzutragen, wie denn bei bestimmten, bislang noch nicht standardisierten Readings denn eigentlich die "optimale Zukunft" aussehen könnte, an der sich dann zumindest der Developer orientieren kann, der grade vor dem Problem steht, sich einen "guten Reading"- oder Setter-Namen überlegen zu dürfen (und ggf. dann zwischen motion/nomotion, 1/0, true/false, Motion/noMotion etc. als Reading-Wert wählen zu können...).

Eventuell könnte (!) es sinnvoll sein, sich bei den Sprachsteuerungs-Lösungen Anleihen zu holen, evtl. reicht es "schon", sich (teilweise?) an sowas wie https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-property-schemas.html#thermostat-mode-values zu orientieren? 

Es gibt ein paar "Standards", die z.B. bei den MQTT2-attrTemplate eingehalten sein sollten; die orientieren sich überwiegend an CUL_HM, und ja, zugegebenermaßen auch eher an in zentraleuropäischen Gefielden gängigen Maßssystemen.... Ein weites Feld also, ja, aber irgendwo muss man m.E. mal mit dem Thema anfangen, und einfach ist es sicher auch nicht, weil eben v.a. manche Hardwaresysteme so ihre Eigenheiten haben.

Falls ich bisher was übersehen haben sollte, bitte ich um Rückmeldung, wo es dazu Guidelines gibt, ansonsten würde ich mich freuen, wenn sich jemand mal die Mühe machen würde, da eine Art Vorschlag auszuarbeiten, evtl. erst mal mit Heizungsgeräten als Anfang?

Ansonsten würde ich das hier einfach zu gegebener Zeit wieder aufgreifen und mal das eine oder andere, das bei der Entwicklung von attrTemplate für MQTT_GENERIC_BRIDGE jetzt dann so hochpoppt hier zur Diskussion stellen, aber das betrifft eigentlich einen etwas anderen Teilaspekt, nämlich der Frage der Belabelung von Infos nach außen und von außen. Das muss nicht zwingend in allen Punkten dasselbe sein.

Ein Beispiel: In FHEM scheint "desired-temp" für die Wunsch- oder Zieltemperatur eine häufige Benennung zu sein, die sich am einfachsten in das Ökosystem einfügt. In FHEM würde ich das nicht ändern wollen, aber (willkürliches Beispiel) zigbee2Tasmota scheint für sowas "CurrentTemperatureSetPoint" zu verwenden, was ggf. überall auf der Welt gut verstanden wird? Also stellt sich die Frage, ob man die betreffende Info unter diesem Label dann versendet und empfängt?

Na ja, bin mal gespannt, ob wir da was hinbekommen oder ob jemand einen anderen, zielführenden Angang für diese Themen hat.

Grüße, Beta-User

[betateilchen]

oh, ein Popcorn-Thread...

[Beta-User]

oh, ein Popcorn-Thread...

"altersmilde", ja?!?

[Wzut]

Es geht hier NICHT darum, den IST-Zustand an irgendeinem Modul zu ändern!
Das gäbe nur Ärger mit den Usern und entsprechende Irritationen und Supportanfragen.

Das ich dir da voll zustimme dürfte aus dem bereits erwähntem MAX Thread schon klar sein, aber das Batterie Thema hat es quasi vorgemacht.
Es kam einfach ein zusätzliches Reading mit "neuem" Namen dazu. Wieder als Beipiel MAX : battery und batteryState und in Zukunft halt auch noch desiredTemperature & desired-temp.

[Beta-User]

Gegen Änderungen an den bestehenden Modulen wollte ich mich auch ausdrücklich nicht aussprechen!

Wenn ich betr. MAX an die Sache herangehen würde: es gibt diesen "Referenzierungs-Vorschlag" in dem "battery"-Thread für fhem.pl. Als "Totschlaglösung" finde ich das nicht user-freundlich, aber man könnte ggf. ein "entweder-oder" in das betreffende Modul einbauen, das
- vorrangig Attributgesteuert und
- nachrangig $feature_level-gesteuert "gute" Readingnamen ermöglicht.
Doppelungen halte ich für nicht zielführend, aber das ist ausdrücklich nur meine Meinung.

Dann kann der User entscheiden, ob er in der "alten Welt" bleiben will (z.B. ab 6.1 über das Attribut) oder schon jetzt umstellen. Wer dann ab 6.1. neu beginnt, ist automatisch in der "neuen Welt" und muss aktiv werden, wenn er das alte haben will?

Wir können das gerne noch kurz hier weiter diskutieren, aber das ist hier eigentlich nicht so sehr das Thema; es geht mir in diesem Thread hier eher darum:
Wenn man heute ein Modul (z.B. für HK-Thermostate) neu erstellt, was sollte man dann für die diversen Readings an Namen vergeben?