Support für verschiedene Geräte

[gvzdus]

Das Problem:
Da Readings / Attribute / Kommandos unterschiedlich je nach Gerät sind, funktionieren die Templates von FHEM-App jeweils oft nur für ein Gerät.

Wir können das Problem auf verschiedene Weisen angehen:

• durch ein Mapping
• durch viele Templates

Für 1) spricht: Die Anzahl der Templates bleibt sehr übersichtlich
Für 2) spricht: Es sind keine Code-Anpassungen nötig, und die Inhalte eines Templates sind gar nicht so viel mehr Text als die Readings. Der Anpassungsaufwand ist gering. Außerdem sind die Features der Geräte ja unterschiedlich.

Hier ein Ansatz zu 1)

.... Auf der anderen Seite, muss zukünftig vermieden werden, dass jeder seine eigenen Templates baut und die Arbeit am Ende immer wieder gemacht wird. Es gibt aktuell zwei interessante Ansätze hierfür.
1) universelle Templates die, die verschiedenen Gerätearten unterstützen. (hierfür wäre eine Art Mapping nötig)
2) eine Bibliothek schaffen, in der jeder neue Templates einstellen kann und die jedem Nutzer von FHEMApp zugänglich ist

Ich habe heute mit meinem gebrochenen Javascript noch einmal überlegt, wie dieser Mapper aufgebaut sein könnte.
Ja, auch ich habe MAX-Thermostate, und das Template geht natürlich nicht, weil 2-3 Readings anders heißen.

Ich will nicht das "homebridgeMapping" von alexa - ich hasse jede neu erfundene Syntax.
Ich bin auf das hier gestoßen:

https://github.com/edudavid/json-map-transform

Wäre das eine "Mapper-Sprache", die allgemeintauglich ist? Ich würde das hilfsweise als Attribut "mapper" in "appOption" sehen: Das Mapper-Template wird geladen und jedes Event vom Device da durchgenudelt. Ein Kommando von fhemApp wird als Objekt "{ "action": "set pct 75" }" instanziert, durch den Mapper gejagt und dann wird "action" an FHEM geschickt.

Beispiel für das Device:

Code: [Auswählen]

{ "template":"thermostat","room": "Buero","name": "Heizung Büro", "mapper": "thermostat_max" }

thermostat_max.json:

Code: [Auswählen]

{
   "measured-temp": {
       "path": "temperature"
    },
   "pct": {
       "path": "valveposition"
    },
    "desired-temp": {
       "path": "desiredTemperature"
    }, ...
}
Mein Ansatz zu 2)
Einer der großen Vorteile von github ist, wie simpel es ist, einen Pull-Request zu starten - es kostet Jens nur 1-2 Klicks, ein neues Template zu übernehmen.

Wir sollten uns dann nur auf eine Konvention einigen, wie z.B. "template_(shutter|switchWithKwh|switch|thermostat|...)_(max|shelly|hm|hmip|hue)", wobei die 3. Gruppe vorzugsweise der Modulname in Lowercase sein sollte.

Wie soll es weitergehen?

[Wzut]

Zum Thema Templates : Ich denke die MQTT Fraktion hat es bereits schön vorgemacht wie das laufen kann, in FHEMWEB das passende Template auswählen und fertig.
Und Wunder oh Wunder, da kommt man sogar ohne git aus... das normale svn schafft das auch locker      

[Benni]

Das Problem:
Da Readings / Attribute / Kommandos unterschiedlich je nach Gerät sind, funktionieren die Templates von FHEM-App jeweils oft nur für ein Gerät.

Wir können das Problem auf verschiedene Weisen angehen:

• durch ein Mapping
• durch viele Templates

Für 1) spricht: Die Anzahl der Templates bleibt sehr übersichtlich
Für 2) spricht: Es sind keine Code-Anpassungen nötig, und die Inhalte eines Templates sind gar nicht so viel mehr Text als die Readings. Der Anpassungsaufwand ist gering. Außerdem sind die Features der Geräte ja unterschiedlich.

Hier ein Ansatz zu 1)
Ich habe heute mit meinem gebrochenen Javascript noch einmal überlegt, wie dieser Mapper aufgebaut sein könnte.
Ja, auch ich habe MAX-Thermostate, und das Template geht natürlich nicht, weil 2-3 Readings anders heißen.

Ich will nicht das "homebridgeMapping" von alexa - ich hasse jede neu erfundene Syntax.
Ich bin auf das hier gestoßen:

https://github.com/edudavid/json-map-transform

Wäre das eine "Mapper-Sprache", die allgemeintauglich ist? Ich würde das hilfsweise als Attribut "mapper" in "appOption" sehen: Das Mapper-Template wird geladen und jedes Event vom Device da durchgenudelt. Ein Kommando von fhemApp wird als Objekt "{ "action": "set pct 75" }" instanziert, durch den Mapper gejagt und dann wird "action" an FHEM geschickt.

Beispiel für das Device:

Code: [Auswählen]

{ "template":"thermostat","room": "Buero","name": "Heizung Büro", "mapper": "thermostat_max" }

thermostat_max.json:

Code: [Auswählen]

{
   "measured-temp": {
       "path": "temperature"
    },
   "pct": {
       "path": "valveposition"
    },
    "desired-temp": {
       "path": "desiredTemperature"
    }, ...
}

Da ist aber der unterschied zum spezialisierten Template nicht sehr groß, sprich ich sehe den Vorteil nicht!

Ich denke eher, es sollte eine entsprechende Template-Bibliothek geben, aus der man sich bedienen kann.

gb#

[moustic999]

That's a lont time issue with fhem, all modules can have their own naming convention.
I already asked if it should be possible to align between all, but it seems impossible due to have each maintainer to do the job.

[Jamo]

Hi,
ich wäre auch eher ein Freund einer Template Bibliothek, die jedem zugänglich ist. Letztendlich hat man doch immer irgendwas was spezielles oder eigenes. Sei es für die Darstellung des 'Bars' oben, oder der Info Leiste unten. Mit connected holt man sich dann doch genau die Info die man persönlich haben will, ein Template kann man immer leicht für sich anpassen. Mit dem Homebridge-Mapping für Alexa bin ich z.B. nie warm geworden, das mapping zwingt dann immer ein festes Schema auf, und die Gefahr besteht, das man den mapper dann links liegen lässt und doch wieder zum Template greift.

Mit den Templates von Jens habe ich bisher meine Heizungssteuerung/Hue/Tradrfri/Roomate/Fernseher/etc/ problemlos einbinden koennen, ich liebe die Flexibilität die Jens da innerhalb des fhemapp Konzeptes bereitgestellt hat. Bin bisher mehr als zufrieden mit dem Ansatz so wie es ist, und ich habe schon alles was ich brauche.

Die Templates müssen nur geordnet und suchbar sein, entweder nach 'Typ' (Max) oder 'Funktion' (Rollo). 

[gvzdus]

Was haltet Ihr denn folgender Idee:

• fhemApp lässt sich auch den Type eines Devices geben
• Es wird probeweise versucht, "tmpl_<templatename>_<type>.json zu laden, sonst Fallback auf tmpl_<templatename>
• TYPE wird gelowercased, und Unterstriche entfernt.

In meinem Zoo komme ich bei den realen Geräten auf:

Code: [Auswählen]

CUL_HM
MAX
HTTPMOD
HUEDevice
LaCrosse
MQTT2_DEVICE
ModbusAttr
OBIS
Shelly
readingsGroup
structure
Bei "structure" oder "readingsGroup" geht natürlich nichts, und MQTT2_DEVICE ist auch nicht eindeutig. Aber die Masse der HUEDevices, Shellys und MAXe liesse sich damit erschlagen.

[Benni]

In meinem Zoo komme ich bei den realen Geräten auf:

Code: [Auswählen]

CUL_HM
MAX
HTTPMOD
HUEDevice
LaCrosse
MQTT2_DEVICE
ModbusAttr
OBIS
Shelly
readingsGroup
structure
Bei "structure" oder "readingsGroup" geht natürlich nichts, und MQTT2_DEVICE ist auch nicht eindeutig. Aber die Masse der HUEDevices, Shellys und MAXe liesse sich damit erschlagen.

Und mit CUL_HM fiele das komplette Homematic-Zeug aus dem Rahmen!

Die meisten größeren Device-Typen haben noch weitere Untertypen oder Models, oder ... wie auch immer das TYPE-Spezifisch dann schon wieder heißt.

Mit der Idee fängst du quasi nie wirklich was ein! Da ist die aktuelle switch, thermaostat, ... Geschichte m.E. noch besser!

gb#

[moustic999]

KNX devices doesn't have any structure or naming value.

one idea should be to define what could be the best common name for each attribute.

then having the possibiliy to map is very good, but that could be also the good time to align the naming within fhem itself.

[coolice]

Hat schon jemand Hue Devices vernünftig mit Helligkeit und Farbauswahl eingebunden?

[binford6000]

Hat schon jemand Hue Devices vernünftig mit Helligkeit und Farbauswahl eingebunden?

Helligkeit: ZB. ein Slider mit pct?
Farbauswahl: ZB. als Menü mit festen Werten machbar. Farbrad / Farbauswahl steht noch auf der ToDo Liste...
https://github.com/jemu75/fhemApp/issues/11

VG Sebastian