Autor Thema: Kernteil der Commandref  (Gelesen 544 mal)

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4375
Kernteil der Commandref
« am: 19 März 2017, 10:45:43 »
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


Offline Christian Uhlmann

  • Full Member
  • ***
  • Beiträge: 134
Antw:Kernteil der Commandref
« Antwort #1 am: 20 März 2017, 21:03:06 »
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 Stretch als XEN Guest
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, CUL FS20, CUL HM, HMLan, HM-USB 2, JeeLink LaCrosse
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, FS20 und andere

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2893
  • Wer anderen eine Bratwurst brät...
Antw:Kernteil der Commandref
« Antwort #2 am: 20 März 2017, 21:21:21 »
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.
« Letzte Änderung: 20 März 2017, 21:57:09 von DeeSPe »
FHEM 5.8, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert

Online KernSani

  • Hero Member
  • *****
  • Beiträge: 1295
Antw:Kernteil der Commandref
« Antwort #3 am: 20 März 2017, 21:43:43 »
RasPi: RFXTRX, HM, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16220
Antw:Kernteil der Commandref
« Antwort #4 am: 20 März 2017, 22:40:47 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4375
Antw:Kernteil der Commandref
« Antwort #5 am: 28 März 2017, 16:33:53 »
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

 

decade-submarginal