Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2

[philipptrenz]

Ein Hallo in die Runde,

mein Name ist Philipp Trenz, ich studiere an der Hochschule Harz. Im Zuge einer Studienarbeit beschäftige ich mich in einem Team momentan damit, eine Abstraktionsschicht zu FHEM zu implementieren.

Das Ziel ist es, die verschiedenen Geräte in FHEM modulunabhängig abzubilden. Eine ansteuerbare Steckdose soll also in gleicher Form abgebildet sein, egal ob diese mit FS20 oder KNX angesteuert ist. Und ebenso bei farbigen Leuchten, egal ob Philips HUE oder WifiLight.

Die Herangehensweise dafür ist, die Werte aus den von jsonList2 gelieferten Geräten anhand von modul-spezifischen Mapping-Anweisungen zu extrahieren. Für jedes Modul wird also definiert, wie die Werte der Geräte ausgelesen werden und in welchem Format sie vorliegen, um anschließend korrekt zu konvertieren.

Um das umsetzen zu können, ist es wichtig zu wissen, welche Werte in jsonList2 vom System vorgegeben sind und welche von den Modulen kommen. Konkret haben sich mir bisher folgende Fragestellungen ergeben:

• Sind die Knoten "Value" und "Time" in den Knoten unter "Readings" standardisiert?
• Ist "state" unter "Readings" automatisch gesetzt und damit "Readings >state > Value" identisch zu "Internals > STATE"?
• Welche Werte werden grundsätzlich vom Modul gesetzt, welche sind standardisiert?

Vielen Dank für eure Hilfe!

Philipp

[DeeSPe]

• Sind die Knoten "Value" und "Time" in den Knoten unter "Readings" standardisiert?
• Ist "state" unter "Readings" automatisch gesetzt und damit "Readings >state > Value" identisch zu "Internals > STATE"?
• Welche Werte werden grundsätzlich vom Modul gesetzt, welche sind standardisiert?

Zu Punkt 1:
Ja!

Zu Punkt 2:
Reading state wird vom Modul selbst verwendet und gesetzt.
Internal STATE kann mittels stateFormat vom Benutzer selbst verändert werden.

Zu Punkt 3:
Ich denke da gibt es keinen Standard.
Da kann jeder Modulentwickler selbst entscheiden wie seine Readings, Setter und Getter heißen.

Du müsstest (denke ich) wirklich Modul für Modul durchgehen und Dir die benötigten Informationen für Dein Mapping selbst besorgen.
Man möge mich bitte berichtigen wenn ich hierbei falsch liegen sollte...

Gruß
Dan

[betateilchen]

• Sind die Knoten "Value" und "Time" in den Knoten unter "Readings" standardisiert?
• Ist "state" unter "Readings" automatisch gesetzt und damit "Readings >state > Value" identisch zu "Internals > STATE"?
• Welche Werte werden grundsätzlich vom Modul gesetzt, welche sind standardisiert?

• ja
• nein. Der Zusammenhang zwischen dem reading state und dem internal STATE ist in der fhem Doku hinreichend beschrieben. Ausserdem gibt es da kein Standardverhalten, vor allem, wenn ein Modul schon älter ist. Ausserdem kann der User in STATE auch einfach "Günter" reinschreiben, wenn er das möchte. Im Regelfall sollte STATE aus state abgeleitet werden, aber wie gesagt, dieses Verhalten ist per Attribut modifizierbar
• TYPE und NAME in den internals sind bei einer korrekten device-Definition immer vorhanden

Du solltest noch ein bisschen mehr Doku lesen, bevor Du an Deinem Projekt weiterschraubst.
Insbesondere empfehle ich die fhem DevelopmentGuidelines.

[philipptrenz]

Hallo ihr beiden,

vielen Dank euch! Das hilft mir auf jeden Fall schon konkret weiter, besonders der Hinweis auf die DeveloperGuidlines ist super, die hatte ich noch nicht auf dem Schirm! Da werde ich mich mal durcharbeiten.

Beste Grüße,
Philipp

[justme1968]

zu 3.: devices unterschiedlicher typen komplett automatisch aufeinander abzubilden geht nicht. selbst mit einer internen liste (die niemals vollständig ist) gibt es zum teil funktionalität die sich nicht ohne handarbeit aufeinander abbilden lässt.

über ein konzept wie genericDeviceType und homebridgeMapping in verbindung mit internen defaults für die häufigsten devices so wie es bei homebridge-fhem und alexa-fhem verwendet wird kann man das etwas aufsetzen das flexibel genug ist 99% der anforderungen abzudecken.

TYPE und NAME reichen bei weitem nicht aus.

aber zum teil nur mit konfiguration auf endanwender seite.

gruss
   andre

[betateilchen]

"Eier, wir brauchen Eier."

Kommas, wir brauchen Kommas.

[DeeSPe]

"Eier, wir brauchen Eier."

Kommas, wir brauchen Kommas.

[philipptrenz]

zu 3.: devices unterschiedlicher typen komplett automatisch aufeinander abzubilden geht nicht. selbst mit einer internen liste (die niemals vollständig ist) gibt es zum teil funktionalität die sich nicht ohne handarbeit aufeinander abbilden lässt.

über ein konzept wie genericDeviceType und homebridgeMapping in verbindung mit internen defaults für die häufigsten devices so wie es bei homebridge-fhem und alexa-fhem verwendet wird kann man das etwas aufsetzen das flexibel genug ist 99% der anforderungen abzudecken.

TYPE und NAME reichen bei weitem nicht aus.

aber zum teil nur mit konfiguration auf endanwender seite.

gruss
   andre

Vielen Dank für den Hinweis auf homebridge-fhem und alexa-fhem. Letztlich haben wir genau so etwas vor. Der Entwurf sieht vor, dass ein Format für Mapping-Anweisungen je FHEM-Modul entwickelt wird, die Mapping-Anweisung wird anhand des TYPE zugeordnet. Diese Mapping-Anweisungen sollen als JSON ausgeprägt und damit gut lesbar und editierbar sein. Durch Hinzufügen neuer Mapping-Anweisungen als JSON-Dateien kann so Unterstützung von weiteren Modulen nachgereicht werden.

Das Mapping erfolgt in definierte Funktionen des Systems, welche standardisiert sind (An/Aus, Dimmer, Color Picker, Temperaturanzeige, ...). Ein Gerät definiert sich schließlich über STATE, NAME, die Funktionen, die er inne hat sowie GROUP und ROOM.

Dies wird nicht gänzlich ohne Anforderungen an die FHEM-Installation funktionieren, aber das ist okay.

Grüße!