Autor Thema: Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2  (Gelesen 871 mal)

Offline philipptrenz

  • New Member
  • *
  • Beiträge: 30
    • Philipp Trenz
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
FHEM 5.8 auf Raspberry Pi 2, RaspBee Gateway mit IKEA Tradfri & Philips Hue, HomeMatic, FS20, WifiLight

Online DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3402
  • Wer anderen eine Bratwurst brät...
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #1 am: 25 Januar 2017, 11:36:34 »
  • 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... :P

Gruß
Dan
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

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13602
  • Das "S" in "IoT" steht für "Security"
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #2 am: 25 Januar 2017, 11:37:02 »
  • 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.
« Letzte Änderung: 25 Januar 2017, 11:38:52 von betateilchen »
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline philipptrenz

  • New Member
  • *
  • Beiträge: 30
    • Philipp Trenz
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #3 am: 25 Januar 2017, 12:54:48 »
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
FHEM 5.8 auf Raspberry Pi 2, RaspBee Gateway mit IKEA Tradfri & Philips Hue, HomeMatic, FS20, WifiLight

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16958
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #4 am: 25 Januar 2017, 13:03:11 »
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
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 betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13602
  • Das "S" in "IoT" steht für "Security"
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #5 am: 25 Januar 2017, 13:33:25 »
"Eier, wir brauchen Eier."

Kommas, wir brauchen Kommas.
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Online DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3402
  • Wer anderen eine Bratwurst brät...
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #6 am: 25 Januar 2017, 13:55:30 »
"Eier, wir brauchen Eier."

Kommas, wir brauchen Kommas.

 ;D ;D ;D
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

Offline philipptrenz

  • New Member
  • *
  • Beiträge: 30
    • Philipp Trenz
Antw:Geräte-Abstraktion: Suche nach Dokumentation/Hilfe bei jsonList2
« Antwort #7 am: 24 März 2017, 17:46:40 »
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!
« Letzte Änderung: 24 März 2017, 17:50:25 von philipptrenz »
FHEM 5.8 auf Raspberry Pi 2, RaspBee Gateway mit IKEA Tradfri & Philips Hue, HomeMatic, FS20, WifiLight

 

decade-submarginal