abstrakte device beschreibung / generische anbindung an 'fremd' systeme

Begonnen von justme1968, 17 Juli 2015, 11:34:38

Vorheriges Thema - Nächstes Thema

justme1968

ich bin gerade dabei für homebridge (https://github.com/nfarina/homebridge) ein platform shim zu entwickeln das es ermöglicht fhem direkt an apples homekit anzubinden. ein netter nebeneffekt ist das sich einzelne geräte, räume, und device typen dann über siri auch per sprache steuern lassen und den status abfragen kann. mit einem appletv geht das automatisch auch über das internet.

um solche generische anbindungen so einfach wie möglich zu realisieren wäre es hilfreich über die bisher angesprochenen themen wie einheiten und formatierung noch folgende funktionalitäten zur verfügung zu haben:


  • abstrakter geräte typ
    um  fhem devices korrekt auf die zur verfügung stehenden device typen und gui elemente zu mappen ist es nötig etwas über den (abstrakten) geräte typ zu wissen. der lässt sich nur beschränkt aus dem zur verfügung stehen kommandos ableiten. die alten interfaces waren ein schritt in diese richtung. sie sind aber nie wirklich verwendet worden und hätten auch nicht ausgereicht da sie z.b. keine unterscheidung zu lassen ob ein switch eine lampe oder ein anderes gerät ist. 
    deshalb schlage ich ein neues attribut fhemDeviceTYPE vor. dieses kann im define vom modul gesetzt werden und vom anwender überschrieben werden. da ich denke das es wichtiger ist einen kleinen aber konsistenten satz an möglichkeiten zu haben schlage ich zunächst outlet, light, blind, speaker, thermostat vor.
  • standard device kommandos
    um möglichst device unabhängig kommandos aus einem anderen system auf ein fhem device zu mappen schlage ich vor eine (kleine) anzahl an kommandos zu definieren die ein fhem modul unterstützen sollte. ich denke hiervon ist das meisten schon so vorhanden, es schadet aber nichts es auch mal hin zu schreiben. eventuell ähnlich wie wir es für die av geräte gemacht haben. also etwas in der art: on/off für schalter, steckdosen und lampen, pct für dimmer, hue/sat für farbige lampen (rgb auch?), pct für rolläden (welche richtung sollten wir festlegen?), desiredTemperature für thermostate. die jeweils gültigen werftenbereiche lassen sich aus der set list des devices extrahieren.
  • eindeutige geräte id
    um ein fhem device eindeutig wieder zu erkennen ist eine eindeutige device id nötig.
    diese könnte man im define erzeugen und über die gesamte lebensdauer (rename, modify) unverändert lassen. optional kann das device modul diese durch eine tatsächlich aus dem device ausgelesene id oder einem haus code oder ähnlichem ersetzen.
    eigentlich würden sich die internals anbieten um diese id abzulegen, diese werden aber nicht mit gespeichert. deshalb schlage ich ein neues attribut fhemDeviceID vor.

frage: brauchen wir attribute die vom endanwender nicht änderbar sind? z.b. durch ein nachgestelltes :nonModifiable in der attribut liste? oder ist es besser einen mechanismus zu bauen mit dem ein modul key/value paare (aus den internals?) genau so wie attribute persistent speichern kann statt attribute dafür zu verwenden?

ich schreibe das gerade aus dem blickwinkel der homekit anbindung, ich denke aber das mit den im folgenden vorgeschlagenen festlegungen auch anderen interfaces wie den diversen mobile apps oder alternativen frontends in einem gewissen umfang geholfen wird. selbst wenn das ganze noch lange nicht vollständig ist. ein einziger einfacher standard der erweiterbar ist ist sicher besser als in jedem frontend immer wieder von neuem das problem der unterschiedlichen device typen zu lösen. selbst wenn das ganze (noch) nicht vollständig ist.

gibt es hierzu noch weitere meinungen und vorschläge?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Zusammenfassung: Ein Typ erschwert einfaches/vollstaendiges Einbinden von Geraeten, wenn man nicht in einem vereinfachten "Apple-Welt" lebt, und ich will FHEM nicht dahingehend umbauen. Ein Frontend kann das Benoetigte aus den vorhandenen Infos ableiten, falls nicht, dann muss der Benutzer per FHEM-Attribut bestimmen, was gewuenscht ist.

Details:
----------------
_Ein_ abstrakter Gerate Typ ist ein Problem, da man haeufig einem Geraet nicht ein einziges "Frontend"-Typ zuordnen kann.

EM1000EM kann Strom messen, FS20 ST kann schalten, ein ZWave AN158 oder ein AVM Dect200 beides.
Letzteres kann auch Temperatur messen, laut Geruechten hat es sogar ein Mikrofon on-board, die anderen nicht.
D.h. entweder definieren wir alle moeglichen Typ-Kombinationen, oder das Geraete-Typ muss eine Liste sein, was de-Facto dem Interface-Konzept entspricht, was wiederum weniger flexibel ist, als die Liste aller set Befehle, ergaenzt mit der Liste aller Readings/Events.
Oder das Frontend ignoriert bestimmte Features, und der Dect200 ist nur noch ein Schalter. Fuer Homekit wuerde das reichen, mit den Strom- oder Temperaturdaten kann es ja im Moment eh noch nichts anfangen.

Noch ein Beispiel: Das FHEM Zwave-Modul implementiert z.Zt. ca 40 Klassen aus ueber 100 spezifizierten, jedem Hersteller steht es frei ZWave Geraete mit beliebiger Kombination dieser Klassen zu bauen. Wie soll ich das pro Geraet in einem einzelnen Typ abbilden? Ich kann hoechstens jede Klasse einem FHEM-Interface/Typ zuordnen, allerdings werden diese nie eine 100%-ige Entsprechung sein. Wahrscheinlich wird es fuer viele gar kein FHEM-Equivalent geben, d.h. diese Features sind fuer die FHEM-Frontends die auf Interface/Typliste aufbauen erstmal verloren.

Meiner Ansicht nach sollte das Frontend den Typ (wenn sowas unbedingt sein muss) anhand der verfuegbaren Befehle/Readings raten, oder der Benutzer muss per Attribut spezifizieren, wie es dargestellt werden soll.

----------------
Gegen standardisierte Kommandos habe ich nichts einzuwenden, aber selbst hier muss der Benutzer eingreifen koennen, z.Bsp. gibt es beim ZWave mehrere Moeglichkeiten ein Geraet einzuschalten (on / basicSet ff / dim 100 / usw), und je nach Hersteller/Geraet ist mal das eine mal das andere richtig. Apropos dim: FS20/EnOcean/ZWave verwenden dim fuer dimmen, und nicht pct.

----------------
Eindeutige Geraete-Id: das ist noetig, weil du Informationen zu FHEM Geraeten ausserhalb von FHEM speichern willst. Ich bin noch nicht sicher, ob das eine gute Idee ist. FHEM muesste die ID so speichern, dass es nicht verlorengeht, und ich habe bisher nur halbgare Ideen dazu. ":nonModifiable" ist nur fuers Frontend relevant, die "richtigen" Experten juckt das nicht, weil sie fhem.cfg direkt aendern. Eigentlich waere READINGS oder gar die Definition das richtige dafuer.

Mein Vorschlag: Alle notwendigen Daten in FHEM zu speichern.


Das ist hier alles meine Meinung zur Zeit. Nicht mehr aber auch nicht weniger.

justme1968

der abstrakte typ ist nicht nur für eine 'einfache apple welt' nützlich :). und eine einfache bedienung setzt unter der haube durch aus eine bestimmte art der komplexität voraus.

das betrifft im prinzip alle anderen frontends auch. die kranken immer wieder an dem problem das sie alle möglichen devices durch irgendwelche sonderbehandlungen einbinden. manchmal ist das einfach nur ungeschicktes design an einer ganze menge stellen ist es aber tatsächlich nur deshalb nötig weil es diese abstrakte beschreibung nicht gibt.

das zwave beispiel ist in so fern nicht optimal als das es hier auch in fhem schon probleme gibt und es unter umständen besser wäre für die unterschiedlichen funktionalitäten auch unterschiedliche fhem devices zu verwenden.

es steht auch nirgends geschrieben das es nur ein typ pro fhem device sein muss.

das problem am raten an hand der sets ist das es nicht möglich ist automatisch zu entscheiden ob das ding eine lampe ist oder der schalter für ein anderes gerät. an hand von pct kann ich nicht sehen ob es ein dimmer oder ein rolladen ist. das zu wissen ist aber wichtig weil man lampen mit siri anders anspricht als andere geräte. wenn ich sage mach den rollladen zu sollen nicht die lampen gedimmt werden. bei schalte das licht an sollen nur lampen an gehen. usw.

die abstrakten device typen sollen auch nicht alles erschlagen sondern in verbindung mit der set liste funktionieren. mit beidem zusammen habe ich (und andere frontends) alle möglichkeiten. ich denke eine lösung zumindest die häufigsten fälle automatisch abdeckt und dem anwender die möglichkeit gibt zur not von hand einzugreifen ist besser als so wie jetzt nichts zu haben. lieber jetzt ein bisschen (oder auch ein bisschen mehr) als alles dafür dann aber nie.

(ein anderes anwendungsbeispiel: in fhemweb sollen alle lampen automatisch ein anderes icon als alle steckdosen haben. das geht zur zeit nur in dem ein anwender von hand für jedes gerät das icon setzt. ich denke es wäre für viele schön das auch pro device typ zu machen. das geht nicht immer automatisch. aber oft eben schon. und zur not in dem ein mal von hand gesetzt wird du bist eine lampe und du bist ein steckdose.)

ich kann das ohne probleme durch ein (halb-) automatisch gesetztes user attr lösen das der anwender dann noch anpassen kann. eine lösung die auch anderen frontends und anwendungsfällen hilft wäre aber schöner.

---

zu den kommandos: das es den unterschied zwischen dim und pct gibt ist klar. aber auch der ist eher historisch und es wäre an vielen stellen einfacher wenn es überall ein pct gäbe und dieses zur not ein mal an zentraler stelle durch eine übersetzung von pct auf dim zu machen wäre besser als das in jedem frontend für jeden device typ wieder neu zu machen.

vielleicht könnte hier ein cmdalias mit dynamischem device helfen.

---

die eindeutige id ist nicht notwendig weil ich information ausserhalb speichern will sondern um das gerät schlicht und einfach wieder zu finden. auch nach einem rename. den aktuellen status hole ich live bzw. per longpoll.

es gibt diverse geräte die eine eindeutige id haben, leider wird dies unter x bezeichnungen and y stellen gespeichert.

readings sind nicht besser geeignet als attribute da sie genau so vom anwender geändert werden können. die definition ist ungeeignet weil die id ja automatisch (vom modul und wenn das nicht möglich ist von fhem) vergeben werden soll.

die frage ist ob man zusätzlich zu readings und attributen nicht noch einen dritte art daten haben sollte. die modul intern aber persistent sind. das wäre aufwändiger und ein findiger anwender kann sowieso alles was irgendwo gespeichert wird potentiell ändern. das ist also nichtunbedingt besser als :nonModifiable aber mehr aufwand.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Talkabout

Hallo zusammen,

ich möchte mich auch zu diesem Thema äußern.

Die grundsätzliche Idee Devices besser identifizieren zu können, finde ich gut. Für mich war es z.B. sehr schwierig über die JSON-Schnittstelle genau zu bestimmten, um was für ein Device es sich gerade handelt. Ich hätte tatsächlich erwartet, dass es dort einen abstrakten Device-Typ gibt, wie Andre ihn erwähnt hat. Wenn ich also z.b. eine Lampe abfrage, dann sollte dort nicht der Modul-spezifische Typ ausgegeben werden (oder zumindest nicht nur), sondern auch ein abstrakter FHEM-Typ mit dem ich Devices gruppieren kann. Das Problem, welches ich hier aber ganz klar sehe, ist das, was der Rudi erwähnt hat. Wenn ein Gerät mehrere Funktionen hat, welchen abstrakten Typ weiss man dann zu? Vielleicht wäre hier auch eine mehrstufige Typ-Definition sinnvoll. Also so etwas wie:

Lampe => lamp

Wettersensor => sensor : {'tempSensor', 'humiditySensor'...}

die Identifikation (Definition) welches Device welchem Typ entspricht, muss natürlich das Modul selber übernehmen. Ich könnte mir hier vorstellen, dass jedes Modul eine Methode zu implementieren hat, welche das Device übergeben bekommt und auf Basis dessen es dann den abstrakten Typ zurück gibt. Die Typen sollte man in FHEM dann global in Konstanten definieren:

$DEVICE_TYPE_LAMP
$DEVICE_TYPE_SENSOR
$DEVICE_TYPE_THERMOSTAT
...

Gibt das Modul für ein Device einen Hash zurück, ist klar, dass dieses mehrere Devices vereint (siehe Wettersensor). Auf diese Art und Weise ist es auf jeden Fall schon mal einfacher herauszufinden, um was für ein Gerät es sich handelt, ohne die Befehle prüfen zu müssen, was ja häufig in raten ausartet.

Standard-Commandos sind hier noch mal eine Ecke härter, da sich meiner Ansicht nach diese nicht unbedingt immer auf den Standard runter brechen lassen. Vielleicht kann man sich hier aber zumindest auf bestimmte Kommandos einigen.

Für die eindeutige ID sollte meiner Ansicht nach ebenfalls das Modul verantwortlich sin. Dieses weiss nämlich, was ein Device eindeutig identifiziert. Bei einem Homematic-Gerät ist es z.B. immer die Seriennummer. Bei einem Intertechno Gerät kann man das allerdings nur am Code festmachen. Auch hier wäre eine Methode im Modul notwendig, die zu einer ID ein Gerät, und zu einem Gerät die eindeutige ID zurück liefert.

Das alles ist deshalb schwer umzusetzen, weil dies erfordern würde, dass praktisch alle Module erweitert werden. Aber vielleicht kann man dies auch Schritt für Schritt aufbauen, und bei Modulen, die diese Methoden nicht implementieren, davon ausgehen, dass diese Architektur nicht unterstützt wird.

Only my 2 cents...

rudolfkoenig

@andre:
Die zwave Bemerkungen ignoriere ich erstmal, die Diskussion waere nicht sachlich.

Ich sehe ein, dass Siri ein Typ braucht, und deswegen ein FHEM Attribut eingefuehrt werden soll. Und wenn schon Attribut, dann wieso nicht so generisch, dass andere Frontends das auch nutzen koennen. Soweit, sogut,
ich hadere nur damit, dass das von den Modulen automatisch gesetzt werden soll, weil ich zu viele Ausnahmen sehe, z.Bsp. in den Modulen, die ich betreue (FS20/ZWave) kann ich als Modulautor zu keinem Geraet sagen, was es nach deiner Klassifizierung ist, das muss der Benutzer uebernehmen. Aber vlt. koennen andere Module sowas eher, also wieso nicht, die koennten das selbst setzen, fuer die anderen Module muss der Benutzer das machen.

D.h. ich fuehre ein fuer alle Geraete gueltiges Attribut ein mit dem von dir unten erwaehnten moeglichen Werten. Als Namen haette ich gerne genericDisplayType, um zu zeigen dass es sich um eine grobe Klassifizierung fuer die Anzeige handelt. Zu den Typ/Interface gehoert auch eine definierte Liste an Befehlen und Readings/Events, die das Geraet/Modul erfuellen muss. Idealerweise von sich aus, schlimmstenfall durch Benutzermapping. Bitte diese Daten auch spezifizieren. Ich vermute in diesem Zusammenhang wird auch das pct/dim Problem geloest.

Zitatdas gerät schlicht und einfach wieder zu finden
Ja, aber das impliziert, dass du etwas Altes kennst, ergo Daten gespeichert hast, was meiner Ansicht nach nicht der Fall sein sollte.

Was ich nicht verstanden habe: wer soll fhemDeviceId setzen? der Benutzer, fhem.pl oder das Modul? Soll das FHEM-Weit eindeutig sein, oder Device-Weit?

@Talkabout:
eine genaue Typ-Spezifikation ist mAn sinnlos, weil die Geraete sich stark unterscheiden, da waere man staendig mit anpassen/verfeinern der Interface-Definitionen beschaeftigt, und das hilft dann auch den Frontend-Leuten wenig.

justme1968

rudi: der zwave kommentar war nicht als kritik gedacht sondern sollte nur den unterschied zwischen der technischen sicht (viele funktionen in einem gerät) und der sicht eines endanwenders aufzeigen der schon probleme hat das ein serienschalter in fhem nicht als zwei geräte auftaucht mit deiner er seine beiden lampen die an ganz unterschiedlichen ecken des zimmers hängen schalten kann. ganz zu schweigen von seltsamen ABI0 zeichen. aber darum geht es hier tatsächlich nicht.


ich finde genericDisplayType so ok.

auch bei fs20 gibt es manche geräte bei denen sich automatisch (vorher) sagen lässt ob es eine lampe oder ein schalter ist. alle dimmer sind ziemlich sicher eher lampen als etwas anderes. zu zwave kann ich nichts sagen. aber vermutlich sind auch hier wandschalter eher lampen als etwas anderes. im zweifel ist default er wahrscheinlich stimmt besser als gar keiner. und der endanwender kann ja eingreifen. lieber den spatz und der hand ...


genauer würde ich es nicht machen, aber die möglichkeit vorsehen das ein gerät mehr als einen der typen haben kann. wobei zumindest die vorgeschlagenen switch, outlet, light, blind, speaker, thermostat vermutlich eher zu wenig mehrfach geräten führt.

das 'alte' ist das aus dem anderen frontend referenzierte device. den device namen zu verwenden reicht meiner meinung nach nicht weil schon ein einfaches rename während das andere frontend offline ist und die nachricht verpasst dazu führt das die verknüpfung verloren geht.

die fhem device id soll das modul setzen so fern es die nötige information hat (also dann wenn es tatsächlich eine eindeutige device id gibt) und wenn das nicht möglich ist (oder für module die noch nicht umgestellt sind) sollte fhem diese id setzen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

herrmannj

Hi,

kommt mir so vor als wäre das nicht die erste Runde zu dem Thema :)

Die Frage (Aufgabe) ist mMn falsch gestellt.

Beispiel Lampe. Aus Sicht des "Bedienenden" (fremdsystem) reicht mir die Info "Lampe" noch lange nicht aus. Die Frage ist doch: was kann das Ding ? Schon für "Lampe" wirde die Liste recht lang:

an/aus ? dimmen ?, Farbe ?, Wenn ja: nur RGB oder auch Weiß ?. Gemischt oder nur "entweder/oder" ? Farbraum ? Vielleicht das Weiß mit Temperatur ? In Kelvin ?
Was passiert wenn die Lampe Farbwechselprogramme kann ?.

Das beinhaltet (für mich) den aussichtslosen Versuch alle existierenden und zukünftigen device zu kategorisieren.

Nicht zu vergessen das sich dann auch die Modulautoren komplett an die, wie auch immer gearteten, Guidelines halten müssen. Was ja auch bedeutet das ich also "Neu" Modulautor erst einmal ein halbes Studium absolvieren muss.

Persönliche Meinung: fhem lebt doch zum großen Teil auch davon das ich, "hemdsärmlig" und im Zweifel innerhalb von wenigen Minuten, was auf die Beine stellen kann. Wenn auch eben improvisiert. (in fact: ich wäre schon froh wenn sich alle module auf nonblocking und robuste Fehlerbehandlung einigen könnten :) )

Tatsächlich haben doch alle funktionierenden frontends das Problem auf die eine oder andere Art gelöst (mMn ist das auch eine Schlüsselfaktor für ein erfolgreiches frontend, neben "sexy sein" :) )

vg
joerg

Wuppi68

Zitat von: justme1968 am 17 Juli 2015, 20:07:30
ich finde genericDisplayType so ok.

ich auch

Zitat von: justme1968 am 17 Juli 2015, 20:07:30die fhem device id soll das modul setzen so fern es die nötige information hat (also dann wenn es tatsächlich eine eindeutige device id gibt) und wenn das nicht möglich ist (oder für module die noch nicht umgestellt sind) sollte fhem diese id setzen.

wir haben doch eine "unique" Device ID

das Internal Nr es überlebt auch ein Rename :-) auch einen Neustart :-)

ich denke auch man sollte den genericDisplayType auf primitives setzen (switch, blind, thermostat, multi)
dazu dann generericDisplayProperties (switch (on/off), analog (8bit/16bit/%), temperature, humitiy, power ..., special)

dann wäre es auch cool, wenn ich alle Devices mit den "primitives" ansteuern kann. Will ich mehr, dann muss ich eine Sonderbehandlung selber bauen (wie jetzt auch)
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

justme1968

die möglichkeiten die die lampe bietet bekomme ich relativ gut aus der set list abgeleitet. zumindest für einen grossen teil der geräte.

was ich aber aus der set liste nicht ableiten kann ist ob es sich bei einem device das nur on und off zur verfügung stellt um eine lampe oder etwas anderes handelt. ein zwischenstecker der eine lampe schaltet ist in diesem zusammenhang eine lampe.

was ich aus der set liste auch nicht ableiten kann ist ob ein device das pct zur verfügung stellt eine dimmer für eine lampe ist (egal ob die lampe direkt, ein zwischenstecker der ein einbau aktor) oder ob es ein rollladen ist.

zur zeit krankt jedes frontend und jede mobile app genau daran. das entweder der benutzer sagen muss das ist eine lampe, das ein dimmer und das ein rolladen oder die app muss für jeden device TYPE alle möglichen geräte fest verdratet haben. und das für jeden neuen typ und jedes neue gerät immer wieder mehr oder weniger von hand. durch den endanwender oder den frontend entwickler.

genau diese einfache unterscheidung lampe/rolladen/anderes gerät kann man man er ein mal zentral für alle bereit stellen. entweder durch das fhem modul oder ein mal durch den anwender konfiguriert dann aber nicht immer wieder und für jedes frontend neu.

um dieses attribut aus dem modul passend zu setzen braucht es kein studium. und das ganze soll ja so hemdsärmelig sein das es erst mal die meisten allgemeine fälle abdeckt. das ist schon sehr viel besser als das was es jetzt gibt. ohne anspruch auf vollständigkeit, ohne zwang nur mir der hoffnung das es so gut ist das nach und nach immer mehr module folgen.

im gegensatz zu den anderen diskussionen soll es auch nicht auf der grünen wiese passieren sondern ganz praktisch an einem tatsächlichen beispiel bei der die unterscheidung lampe/rolladen/gerät tatsächlich wichtig ist damit so funktioniert.

tatsächlich fungiert das schalten von lampen mit siri wirklich sehr sehr gut. aber eben nur wenn ich automatisch festellen kann was eine lampe ist und was ein anderes gerät.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

klaus.schauer

Bei EnOcean gibt es inzwischen den Device Type "Generic Profil". Bei diesem Typ gibt es eine einheitliche Beschreibung für x-Kanäle eines Devices mit den Parametern:
- channel type
- signal type
- value type
- resolution
- engineering minimum
- scaling minimum
- engineering maximum
- scaling maximum

Z. B. gibt es einen signal type "flag" mit der Funktion "On/Off" und den Stati (1) on, (0) off oder beim signal type "data" eine Variante "temperature", bei der die Auflösung und Wertebereiche über die Parameter resolution, engineering minimum, scaling minimum, engineering maximum und scaling maximum festgelegt werden.

Aus meiner Sicht ein sehr universeller Ansatz zur generischen Beschreibung von Kanälen. Die Liste der vorgesehenen Profile ist schon sehr lang und universell, deckt aber wahrscheinlich auch nicht alle Ideen ab und lässt sich nicht ohne weiteres auf andere (bestehe) Module oder Device Typen übertragen.

Natürlich könnte man diesen Standard (zukünftig) generell in Fhem verwenden, aber aus der Erfahrung mit der Diskussion um die "vollständige" Darstellung von Readings mit value und unit scheint mir das ein nicht umsetzbares Vorhaben.

Das EnOcean-Modul wird zukünftig Generic Profils parallel zu den vorhandenen Devices Typen unterstützen. Die Funktionen sind bereits in der aktuellen Fassung des Moduls enthalten. Da es derzeit noch ein paar Probleme beim Anlernen mit speziellen teach-in Varianten gibt und die Commandref noch nicht fertig ist, sind diese Profile noch nicht offiziell.

rudolfkoenig

Zitatprobleme hat das ein serienschalter in fhem nicht als zwei geräte auftaucht
Ich vermute du meinst nicht ZWave, ABI0 erinnert mich an EnOcean AI/B0
Fuer ZWave/MULTI_CHANNEL Geraete legt 10_ZWave.pm jeweils eine eigene FHEM Instanz an, ich habe aus der Vergangenheit gelernt :)


Zitatauch bei fs20 gibt es manche geräte bei denen sich automatisch (vorher) sagen lässt ob es eine lampe oder ein schalter ist.
Nope. Automatisch erkennt man bei FS20 gar nix, du kannst als Benutzer das model Attribut sezten, daraus koennte man genericDisplayType ableiten, finde aber nicht sehr schoen. Insb. wenn manche (wie ich) Unterputzschalter, die fuer Lampen gedacht sind, fuer Rollandenschalter missbrauchen.

Aber wie gesagt, ich sehe ein, dass andere Module eine "einfache Sicht der Dinge" anbieten koennen, und manche Frontends das auch gerne haetten, also wieso nicht.

justme1968

wäre genericDeviceType nicht besser als genericDisplayType? es geht ja nicht (nur) um die darstellung sondern eher um 'was bist du für einer'

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Ich wollte mit dem Wort Display staerker die Ziele von diesem Attribut einschraenken. Ich sehe das Problem, dass jemand versucht es ganz genau zu beschreiben, und damit nur Aerger einhandelt. An Beispiel von DECT200: Schalten, Temperatur, Spannung, Stromstaerke, Verbrauch, diverse weitere, die ich nicht verstanden habe, Einheiten/Schwellwerte/Intervalle Konfigurabel, usw. usf.

Wenn es allgemeiner Konsens ist, dass "generic" das alleine schon ausdrueckt, dann ist das von mir aus ok.
Nach diesem Prinzip sollte das Geraet auch nur eins sein.