Kernteil der Commandref

Begonnen von Prof. Dr. Peter Henning, 19 März 2017, 10:45:43

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Gerade beim Stöbern darüber gestolpert, dass in der Commandref (deutsche und englische Version) unter dem Link https://fhem.de/commandref.html#attributes bzw. https://fhem.de/commandref_DE.html#attributes (und natürlich auf jedem einzelnen FHEM-Rechner ebenfalls in der Commandref) ein Attribut

genericDisplayType mit den möglichen Werten switch,outlet,light,blind,speaker,thermostat

genannt wird. Tatsächlich verwenden wir aber bei homebridge und Alexa das Attribut

genericDeviceType

mit ähnlichen (allerdings auch weiteren) Werten. Das erstgenannte Attribut habe ich noch nirgendwo gebraucht, und die Beschreibung ist mehr als vage. Bitte um Überprüfung, ob das wirklich genericDisplayType heißt, oder ob sich hier an zentraler Stelle ein Fehler in der Dokumentation eingeschlichen hat.

LG

pah


Christian Uhlmann

Hallo,

bin über das Attribut genericDeviceType auch schon gestolpert und habe bemerkt das es nirgendwo exakt definiert wird.
Wenn es eine Lösung für die Commandref gibt, dann könnte ich das gerne in einem Wiki-Eintrag mal zusammen fassen und genauer erklären, was welcher Wert in welchem Modul zu bedeuten hat.
Leider fehlen mir aber Infos, wo dieses Attribut bisher zu welchen Zwecken verwendet wird (außer natürlich homebridge bzw. alexa).

Grüße
Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

DeeSPe

#2
Irgendwie glaube ich mich daran zu erinnern dass bei genericDisplayType statt switch,outlet,light,blind,speaker,thermostat mal andere Auswahlen zur Verfügung standen.
Sowas wie "CSS Media Types" ala all,print,screen,speech.
Bin mir aber gerade nicht sicher!
Vor Allem würde das ja auch in global keinen Sinn ergeben, sondern eher in WEB.
Bin da auch etwas ratlos! Da muss wohl Rudi ran... ;)


Gruß
Dan

EDIT: Okay, der Beitrag unter mir belehrt uns eines Besseren.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

KernSani

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

justme1968

das ist noch ein fehler in der doku.

genericDisplayType war der ursprüngliche vorschlag der dann im laufe der diskussion in genericDeviceType geändert wurde. das hat sich inzwischen auch als richtig erwiesen. siri und alexa z.b. haben kein display. zumindest nicht um das device anzuzeigen.

die aktuell von alexa-fhem und homebridge-fhem in userattr eingetragenen werte sind: security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock


ich bin mir nicht ganz sicher wie wir das attribut dokumentieren sollen. in die allgemeine doku ist es gewandert weil es damals noch kein siri und alexa device gab. die gibt es inzwischen und man könnte es dort dokumentieren.

ich möchte aber eigentlich gerne das dieses attribut nicht nur von siri und alexa verwendet und verstanden wird. d.h. eine zentrale stelle wäre besser. dann gehört aber neben den typen noch eine empfehlung dazu wie die wichtigsten readings dieser devices heissen sollten damit man kein homebridgeMapping verwenden muss.

den sinn dieser art meta information sehen aber die meisten nicht. ebenso wie den des units konzepts. es ist sogar schwer verständlich zu machen wozu und weshalb wir so etwas brauchen. so ziemlich jeder der ein neues frontend baut fängt wieder und wieder damit an device typen fest einzubauen oder überlässt es komplett dem endanwender.

siri und alexa sind in dieser hinsicht als frontend ausnahmen weil es keine grafische repräsentation gibt die ein anwender wie z.b. in fhemweb direkt interaktiv bedient. fhemweb muss nicht wissen was ein kommando tut oder ein reading bedeutet. siri und alexa müssen es. sonst funktioniert die umsetzung der sprache auf ein kommando oder reading nicht sinnvoll und automatisch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Prof. Dr. Peter Henning

Na ja.

Ich habe mir vor 5 Jahren (oder so...) den Mund fusselig geredet ob der Einheiten. Ebenfalls ohne Erfolg - so sind wir halt.

Deinen Wunsch kann ich verstehen, er führt aber ins Leere. Nicht einmal innerhalb eines Programms - HomeMatic - gelingt es, die Geräteklassen konsistent zu halten.

Wer bereinigt denn nun die zentrale Doku ?

LG

pah