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

Begonnen von Beta-User, 20 Januar 2021, 11:23:05

Vorheriges Thema - Nächstes Thema

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Zitat von: Beta-User am 20 Januar 2021, 11:23:05
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Aus gegebenem Anlass (https://forum.fhem.de/index.php?topic=139617.0) biete ich hier etwas Mais an, falls einer die Pfanne heiß hat...

Der Spur nach würde ich folgendes vorschlagen und bei Gelegenheit mal (unverbindlich!) nach https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings einpflegen:

Schaltbare Geräte (mehrkanalig=>erster Kanal, "Hauptschalter" oä.):
- "state" mit Werten "on" bzw. "off" (für laufende Schaltvorgänge auch "set_xx", s.u.)

Leuchtmittel:
- "state" wie "schaltbare Geräte"
- "pct" für Helligkeit (Wertebereich: 0-100), alternativ "dim" (Wertebereich: 0-99) oder "brightness" (Wertebereich: 0-255 (bzw. 254))
- "ct" (alternativ: "colorTemp") für die Farbtemperatur
- "hue" für den Farbwert (ohne Helligkeitsanteil)
- "rgb" (alternativ: "color" oder "hex") für Farbwerte mit Helligkeitsanteil (rrggbb)
- "sat" (oder "saturation") für die Farbsättigung

Rollladen- und Jalousieaktoren:
Wie Leuchtmittel, in der Regel sollte "offen" = "on" = "100" (pct) sein (komplett invertiert ist zulässig)
Falls drehbare Lamellen (direkt) im Device einstellbar sind: "posSlat" (0-100, 100= ganz nach oben gekippt) (to be verified!)


Thermostate (einstellbare Wunschtemperatur):
- "desired-temp" für die Wunschtemperatur (typischerweise in °C)
- "temperature" für die gemessene Temperatur, alternativ auch "measured-temp"
- "valve" (oder "level") für Stellgrößen (z.B. Ventilöffnung, "valve" typischerweise 0-100 (%))

Thermometer:
Temperatur in Reading "temperature" oder "state"

Feuchtigkeitsmesser:
Luftfeuchte in "humidity", Bodenfeuchte als "moisture"

Bewegungs- oder Präsenzmelder, Kontakte:
"motion" mit "on" oder "off" bzw. motion/noMotion
"presence" mit "on" oder "off" bzw. present/absent
"contact" mit "open" oder "closed" bzw. "on" oder "off"

Füllstandssensoren:
"pct" oder "level" (typischerweise in %), bei Koexistenz mit "pct" ggf. "level" als absoluter Messwert (Einheit nicht festgelegt)

Drucksensoren:
"pressure"

Schlösser:
"state" für den Haupt-Schließzustand (locked / unlocked?)
set-Befehle: "lock" und "unlock"

Geräte, die voreingestellte Szenarien einstellen können:
set-Befehl mit "scene"

Allgemeiner Gerätestatus
- "availability" ("online"/"offline" bzw. "present" / "absent") (Für MQTT alternativer Readingname: "LWT")
- "lastseen" (Zeitstempel in Sekunden)

Allgemeines:
Als "Transitstatus" darf (analog z.B. CUL_HM) auch ein "set_xx" in allen Readings stehen, bis (hoffentlich...) die Bestätigung vom Gerät zurückkommt, dass das ausgeführt wurde.

also Anweisung "set DEVICE brightness 77" ergibt übergangsweisen Readinginhalt für "brightness" mit "set_77".
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

erwin

Hi Beta-User,
genialer Ansatz, DANKE dafür!

Wenn ich mir noch was wünschen darf:
1) ein "generisches reading" - falls es nicht in dieser liste definiert ist.
z.B: desired-value, actual-value - wobei ich mich nicht auf die Worte festlege.

2)Jalousien/Rollläden: cmds: up/down/stop/desired-pos xx/desired-posSlat xx
                     status: moving/pos xx/posSlat xx/uppos/downpos
  so Dinge wie: z.B.: "um 10% up" muss man vmtl. in FHEM realisieren, das kann vmtl. kein Aktor direkt.

Und ja, grundsätzliche Unterscheidung für "setter" und "getter" (cmd /response aus Aktor sicht), wie ja schon bei etlichen der Fall: desired-temp, temperature, usw.

3)Das Thema Energie-erzeuger/-Zähler/-Speicher - ich kann mich erinneren, dazu gabs schon mal was, ich find es nur nicht mehr.

4)Bin nicht sicher, ob OT hier: wenns um Sprachsteuerung (ganz allgemein) geht:
eine Tabelle, ungefähr so:
Spachsteuerung        <<=>> FHEM
===================================================
gesprochenes Wort     ==>>  FHEM cmd xxx (template?)
bzw. Aktion auf GUI
---------------------------------------------------
Anzeige Wert xxx      <<==  FHEM reading od. event?
auf GUI
---------------------------------------------------     
Wäre sowas möglich / sinnvoll? - oder doch zu unterschiedlich zw den Implementierungen Rhasspy, Alexa,...
mich verwirrt momentan die Einschränkung die mit den profilen (=genericdevicetype) definiert ist: z.b. blinds können nur bestimmte cmds, usw. Aber hier bin ich absolut nicht mit der Materie vertraut....
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Beta-User

Danke für deine nette Rückmeldung!

ad 1)
Habe noch nicht so recht verstanden, was damit gemeint ist. Magst du es erläutern?

Meine Gedanken dazu:
Mit "desired-xx" verbinde ich nur desired-temp, und das ist die (ohne Drehen am Knopf) nicht vom Gerät her veränderliche Zieltemperatur, also in diesem Sinne ein "statischer Wert". Bei allen anderen "das will der User haben"-Dingen ist der Ablauf eher der, dass die Anweisung rausgeht, ggf. im "Original-Reading" (z.B. "pct") ein Übergangswert ("set_25") steht und dann nach Erreichen des Zielwerts eben die Bestätigung vom Gerät kommt und dann wieder der neue Wert (ohne den "set_"-Präfix) im Reading landet.
Wenn man das in 2 Readings auftrennt (war das gemeint? Nach meinem Verständnis des g1/g2-Threads scheint das das Vorgehen bei KNX zu sein?), kann man das zwar leichter per Grafik auswerten, nur sieht man an den Readings nicht mehr, ob es ein Kommunikationsproblem gab, wenn Soll- und Istwert unterschiedlich sind. (Es könnte ja sein, dass zwischenzeitlich jemand per klassischem Taster was anders wollte als FHEM weiß).     

ad 2)
a) Kommandos standen ursprünglich nicht auf meiner Liste, aber m.E. ist der Vorschlag valide!
Und wenn ein Aktor bestimmte Kommandos kann wie "10% heller", kann man die auch entsprechend benennen. HUEDevice scheint sowas zu kennen und hat es m.E. sinnvoll benannt (habe grade auf zigbee2mqtt umgestellt und kann daher nicht mehr testen):
dimUp [delta]
dimDown [delta]
ctUp [delta]
ctDown [delta]
hueUp [delta]
hueDown [delta]

b)
Das mit dem "status" finde ich einen guten Ansatz, CUL_HM verwendet an der Stelle "motor" (mit up/down/stop, afair). Finde sprachlich beide Varianten nicht allzu glücklich, aber "status" gefällt mir persönlich noch weniger. Ist mir zu "schillernd", man verwechselt es leicht mit "state" (oder "STATE"...)  und "motor" käme z.B. auch für Stellmotoren, Garagentore etc. in Frage. Mal sehen, was andere dazu meinen :) .

ad 3)
Guter Punkt. Müßte hier gewesen sein Frevel: Die Idee einheitlicher Devicenamen und Readings

ad 4)
Ist m.E. nicht komplett OT. Für RHASSPY kann ich sagen: Wenn ein Device einem bestimmten genericDeviceType zugewiesen ist, muss man nichts zusätzlich konfigurieren, wenn das Ding bestimmte set-Befehle kennt und/oder die abzufragenden Readings passend benannt sind. Die obige Liste ist genau so entstanden: Ich habe den RHASSPY-Code als Basis genommen und geschaut, was es "kennt". Dabei ist "brightness" z.B. schon ein Sonderfall, der afaik bei RHASSPY direkter abgehandelt wird wie bei allen/den meisten (?) anderen: RHASSPY kann den Wertebereich ermitteln und mappt das direkt passend, für die anderen muss man ein "homebridgeMapping" anlegen und explizit konfigurieren, wie zu rechnen ist (siehe die attrTemplate-File für Sprachsteuerung, die z.B. aus mqtt2.template heraus aufgerufen werden).

So ein xxxMapping muss man auch anlegen, sobald man die set- und Reading-Namen nicht "standardkonform" wählt. Kann man natürlich machen, ist aber (m.E. komplett unnötiger) Aufwand...

Die sprachliche Umsetzung (das "gesprochene Wort") ist dagegen etwas, das m.E. außerhalb dieses Threads anzusiedeln ist. Beginnt schon damit, dass z.B. RHASSPY parallel dieselbe FHEM-Installation in mehreren Sprachen steuern kann (via mehreren Rhasspy-Installationen und RHASSPY-Instanzen). Eine "gute" Sprachsteuerungslösung sollte auch erkennen, wie der Kontext aussieht. Beispiel: "Mach etwas heller" ist ja eigentlich für einen anwesenden Menschen eine halbwegs klare Ansage, aber eine Maschine wird daraus eher nicht den Schluss ziehen, dass es die Rollläden öffnen soll. RHASSPY zieht daraus immerhin den Schluss, dass angeschaltete dimmbare Leuchten in der Nähe des Sprechers etwas hochgedimmt werden.... 

Der "wahre Mehrwert" "etwas einheitlicherer" Reading-Namen (usw.) liegt m.E. darin, dass man eher mit devspec arbeiten kann, den (eigenen oder fremden!) Code leichter versteht ("set xx g2 25" vs. "set xx desired-temp 25", "set xx volume 25", "set xx pct 25" oder "set xx brightness 25"?), und sich allgemein beim Konfigurieren nicht unnötig den Wolf schreiben muss...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

erwin

ad generisches reading:
Egal wie ausgefeilt diese Liste von "einheitlichen reading namen" mal sein wird, "super-spezial-blabla Fälle" werden dort nicht zu finden sein, daher die Idee "generisch"...

ad desired-xxx

das versteh ich etwas anders:
desired... ist für mich eine Zielvorgabe, das will der Anwender haben. Ob die Zielvorgabe statisch, durch ein FHEM-set-cmd oder von einem anderen Gerät von extern kommt, spielt erstmal keine Rolle. Wichtig ist allerdings, dass FHEM das mitbekommt!
Um jetzt ein extremes/weit hergeholtes Beispiel zu nennen: "Ich will viel Strom verbrauchen, wenn er gerade billig ist".:
1) Was kostet Strom jetzt?
2) Davon abhängig-dynamisch Ziel "Maximalverbrauch".
3) Falls Max.Verbrauch überschritten, wird bei unkritischen Verbrauchern "eingespart"..., wenn zuwenig Verbrauch, werden zus. Verbraucher eingeschaltet...

Beispiel Jalousie: Ziel könnte eine von Sonnenstand/Tageszeit abhängige Jalousiestellung sein. Das ist dzt. via FHEM-ASC-Modul unterstützt. Das ist recht cool, ASC erzeugt generische cmds, die man mittels cmd-templates auf den cmd eines FHEM devices mappen kann.

konkreter:
Im Fall einer KNX-Jalousie läufts etwa so:
cmd up/state=moving/cmd stop/position=xxx/state=stopped, oder alternativ:
cmd desired-pct 66/state=moving/pct=66/state=stopped/
Ich hoffe, damit habe ich deine Bedenken bez. Kommunikationsproblem-readings ändern sich nicht mehr, beantwortet.

ad: Auftrennen in 2 Kanäle: (cmd / status) Ja, das ist im KNX von der Hardware/Firmware lt. Standard so vorgegeben. Bedeutet, es gibt immer ein aktives Feedback von Gerät ob der cmd ausgeführt wurde! Vergleiche das mit 2 unterschiedlichen topics bei MQTT2. (Im KNX-system sind das Gruppenadressen)... und daher kommt meine Überlegung, das auch in den reading-namen abzubilden.
Dazu kommt in einem KNX system noch, dass der cmd nicht nur von FHEM gesendet werden kann, sondern auch von einem/mehreren externen Geräten. (Beispiel: Thermostat - desired-temp).

Bei deinem stmt: Der wahre Mehrwert.... stimmen wir absolut überein.
Als Konsequenz dieser Diskussion werde ich in den nächsten ?Tagen? versuchen das wiki entsprechend anzupassen.
l.g. Erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Beta-User

Zitat von: erwin am 28 Oktober 2024, 23:24:07ad generisches reading:
[...] "super-spezial-blabla Fälle"
Die sind speziell und werden es vermutlich auch bleiben ("es gibt nichts neues unter der Sonne"), von daher stellt sich die Frage, wie da eine sinnvolle "Vorgabe" sein sollte.

Zitatad desired-xxx

das versteh ich etwas anders:
Hmm, deine Beispiele sind da m.E. etwas speziell und stehen nicht unbedingt mit "Hardwaremodulen" in Verbindung. Ob wir gleich für Logikbausteine auch was vorschlagen wollen? Würde das ggf. auf einen 2. Schritt verlagern (falls es sich nicht doch direkt mit ergibt).

ZitatIm Fall einer KNX-Jalousie läufts etwa so:
cmd up/state=moving/cmd stop/position=xxx/state=stopped, oder alternativ:
cmd desired-pct 66/state=moving/pct=66/state=stopped/
Ich hoffe, damit habe ich deine Bedenken bez. Kommunikationsproblem-readings ändern sich nicht mehr, beantwortet.
Weiß nicht recht, das Beispiel wirft bei mir einige Fragen auf:
- "state" ist ein "schillerndes" Reading. Manche Module (im default!) verwenden "state" für alle Arten von Anweisungen von FHEM aus (insbes. ZWave und MQTT2_DEVICE) und ZWave bildet dann uU. den kompletten Gerätezustand in "state" ab (FRG-222: dim/Behanghöhe und posSlat), und ob der Motor läuft, kann man am Energieverbrauch erkennen. Ich persönlich finde das nicht so gelungen (was bei beiden Modulen dazu geführt hat, dass Rudi meiner Bitte entsprochen hat, das (soweit erforderlich) anders konfigurieren zu können...).
- Bei Jalousien/Rollläden sollte m.E. der Motor-Zustand (up/down/stop) in ein gesondertes Reading, "state" sollte imo immer für die "wichtigste" Information reserviert bleiben, und da sehe ich die (ggf. künftige) Behanghöhe. Kann man anders sehen, aber deswegen diskutieren wir ja. Bei Jalousien ist das übrigens nicht ganz so einleuchtend wie bei Leuchten: Wenn da in "state" "set_50" steht, weiß man eben gerade nicht, ob das Ding nun gerade an oder aus ist, von daher gehört die Helligkeitsvorgabe imo in "pct" (oder "brightness")...

Zitatad: Auftrennen in 2 Kanäle: (cmd / status) Ja, das ist im KNX von der Hardware/Firmware lt. Standard so vorgegeben. Bedeutet, es gibt immer ein aktives Feedback von Gerät ob der cmd ausgeführt wurde!
Das mit dem feedback ist bei allen "besseren" Systemen so. Das bedeutet aber imo (deutlich!) nicht, dass es getrennte Reading-Namen für den Hin- und Rückweg geben müßte, die KNX-Lösung ist hier die Ausnahme (und das darf gerne auch so bleiben, wenn es da sinnvoll ist!).
"Best practice" ist imo an der Stelle CUL_HM, das eben direkt alles in den passenden Readings abbildet, bis es bestätigt ist ("set nn desired-temp 22" ergibt also in "desired-temp set_22", bis die Bestätigung kommt (was bei den RT-DN schon mal 2,5 Minuten dauern kann). Wenn man es am Drehrad (oder an einem verbundenen Wandthermostat) ändert, kommt die Info selbstredend auch.

ZitatAls Konsequenz dieser Diskussion werde ich in den nächsten ?Tagen? versuchen das wiki entsprechend anzupassen.
Thx! Eine Anmerkung noch: wie erwähnt, hatte ich bei "Schritt für Schritt" zu MQTT2_DEVICE dann auch im Wiki geschaut, was dazu zu finden war - mit dem Ergebnis, dass ich den Vorschlag hier gepostet habe zwecks Übernahme in die Guidelines. Am Ausgangsort habe ich dann "nur" die Verweise auf die Guidelines eingepflegt - für "best practice" hat man für MQTT2_DEVICE dann ja einen umfänglichen Satz attrTemplate, der das schon einigermaßen umsetzt. Sowas "fehlt" halt für KNX, aber da würde es imo reichen, neben derselben Info-Box ein paar wenige "gute" Beispiele (einfacher on/off-Aktor, Dimmer, Thermostat) ins Wiki aufzunehmen?


Da wir auch bei der "set"-Nomenklatur waren: Für Messenger-Type Devices gäbe es noch msgConfig, das auch gewisse "Standards" voraussetzt, damit ein solches Gerät sich "reibungslos" in das FHEM-Ökosystem einfügt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

erwin

ad im Falls einer KNX-Jalousie:
sorry das Beispiel hab ich verkürzt dargestellt, komplett wäre:
cmd up /r:moving=on/state=moving/cmd stop/r:moving=off/r:state=stopped
cmd desired-pct 66/r:moving=on/state=moving/r:pct=66/state=stopped...
Grundsätzlich gilt: jeder ankommende KNX-event updated ein reading, readingName ist abgeleitet von der definition der Gruppenadresse, Das reading state enthält (default !) eine Kopie des letzten upgedateten reading Werts. Dieses Verhalten kann mittels KNX attr. beeinflusst werden, sodass nur die "wichtigen" Werte im reading state landen.
Meine best practice für Jalousien ist derzeit: Jalousie ist gestoppt - state zeigt aktuelle Position, in Bewegung - state zeigt "moving". Damit wird ein devicestateicon einfach...ob man das mittels grafic oder per %-Zahlen darstellt, ist Geschmackssache. Das ist auch die relevante Information, falls man die Jal aus der "Ferne" steuern will. Das die KNX-attr Funktionalität in eine 99_myUtils.pm ausgelagert werden kann, und somit allen JAL zur Verfügung steht, ist ein zusätzlicher Benefit.
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...