wiederverwendbares Mapping a la ReadingsGroup

Begonnen von ntruchsess, 21 November 2014, 15:29:33

Vorheriges Thema - Nächstes Thema

herrmannj

#30
ich verstehe den Punkt. Konzeptionell anders sieht das aus wenn ich ein Frontend habe was die Darstellung ohnehin übernimmt. Da habe ich eine Temperatur Anzeige und benötige nur eine (implizite) Vereinbarung über den Wertebereich. Das Frontend sagt fhem "ich brauch den Wert 'aussen'" (bei Dir, glaub ich 'subscribe'?). Dann kommen dimensionslose Werte rein, den Rest macht das frontend.

Vermutlich könnten wir hier zwei Klassen von Ausgabedevice unterscheiden:

Klasse A fragt, sinngemäß, bei fhem an: "was hast Du ?", fhem schickt das und das frontend kümmert sich alleine darum das intelligent grafisch darzustellen. In die Klasse würde bspw fhemweb gehören.

Klasse B hat ein (vom User) vorgegebenes Design und befüllt das (nach Konvention) mit Werten. In diesem Fall ist das Frontend (nach Vorgaben des User) dafür zuständig wann, wie, welches Icon in welchem Kontext dargestellt wird. (smartVisu)

Klasse A bräuchte dann im Prinzip die gleichen Daten wie B plus Darstellungskonvention.  Von daher würde ich vorschlagen die Darstellungskonvention, zumindest konzeptionell, von den reinen Werten zu trennen. (wenn ich richtig verstanden habe sollen Deine metadaten das sein)

Die metadaten können / sollen dann natürlich von der geeigneten Schnittstelle gleich mit übertragen werden können (aber eben nicht müssen).

Damit ein frontend vom typ A damit was anfangen kann müssten die metadaten (abgestuft?) die Daten in Bezug auf Einheit, Wertebereich etc beschreiben. (?). Zusätzlich noch den devicetyp (?). Beispiel Thermostat vs Thermometer. Beide senden eine Temperatur mit dem unterschied das ich die am Thermostat auch setzen kann.

ntruchsess

#31
Jörg, sehe ich ganz genauso. Wir reden hier erst mal über das API (in perl), das ein Schnittstellen-Device nutzt um z.B. Daten für ein Frontend bereitzustellen. Das muss natürlich keine Daten weitergeben, die das Frontend nicht nutzen kann. Die Abbildung auf das Schnittstellenformat (z.B. JSON für WebSocket, MQTT-topics oder auch plain HTML) ist ja nicht Aufgabe der API, die soll nur alle Werte einheitlich zugänglich machen.

EDIT: API-Vorschlag zur Überarbeitung wieder entfernt
while (!asleep()) {sheep++};

herrmannj

ich seh schon, das wird. Lass uns aber bitte das was und wie noch zurückstellen um die Anforderungen noch weiter zu vervollständigen.

Andre, als Klasse A Vertreter: was genau bräuchtest Du denn gerne von der API ?

Vielleicht gibt es ja auch noch mehr stakeholder die sich noch gar nicht zu Wort gemeldet haben  ;)

vg
jörg

Dr. Boris Neubert

Zitat von: herrmannj am 24 November 2014, 17:55:35

Die metadaten können / sollen dann natürlich von der geeigneten Schnittstelle gleich mit übertragen werden können (aber eben nicht müssen).

Damit ein frontend vom typ A damit was anfangen kann müssten die metadaten (abgestuft?) die Daten in Bezug auf Einheit, Wertebereich etc beschreiben. (?). Zusätzlich noch den devicetyp (?). Beispiel Thermostat vs Thermometer. Beide senden eine Temperatur mit dem unterschied das ich die am Thermostat auch setzen kann.

Das ist genau meine Vorstellung.

Die Metadaten sollen hierarchisch vererbar sein, jedes Modul kann abgeleitete Metadaten anmelden.

Angenommen, Temperatur ist nicht Teil von API v1, aber Real mit Wertebereich ist es. Das FHT-Modul meldet dann desiredTemp als Temperatur an und sagt, es sei von Real mit Wertebereich abgeleitet, und der Wertebereich sei (5, 5.5, ..., 30). Dann weiß das GUI, dass es den Value als Zahl gemäß Formatierungsvorschrift zeigt. Wenn Temperatur noch eine Einheit mitliefert, und diese °C nennt, kann das GUI das nutzen. Ganz schlaue Metadaten enthalten alternative Einheiten und Umrechnungsvorschriften...

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

Zitat von: herrmannj link=topic=29428.msg223130#msg223130

Schlussendlich lebt fhem sehr gut davon das ich mal eben einen Arduino irgendwie "ranklebe" und dann macht der was total nerdiges  8). MMn ist es ganz entscheidend möglichst "weich" (sprich maximale Eingriffsmöglichkeit) mit der Konvertierung umzugehen und schlicht und ergreifend jeden FHEM Input auf jedes gewünschte Output Format konfigurieren zu können. Wenn ich aber sowieso jeden Wert dazu händisch anfassen muss (ist ja die Folge) wird 1. in einen Augen obsolet.

Ich habe mit ECMDDevice eine generische Geräteklasse. Jedes Gerät hat ausschließlich benutzerdefinierte Readings. Brauche also das API in Fassung 1.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

ntruchsess

@Jörg: Klasse A fragt z.B: was für Räume? -> Liste der Räume -> Auswahl Raum -> welche Widgets gibt's hier? -> Iteration über die Wigets -> Welche Werte sind im Widget? -> Iteration über die Werte -> Hat der Wert weitere Metadaten? Datentyp, WerteBereich, Einheit?

Die Frage ist halt, sind das alles 'flache Metadaten' oder soll sich eine logische Hirarchie auch in Referenzen unter den Metadaten wiederfinden. und wie bildet man die generisch ab ohne, dass man auf einen speziellen Fall festgelegt ist?

Die von Boris gewünschten vererbten Typklassen würde ich ja eher einfach flach in den direkt zugeordneten Metadaten zugänglich machen {'type'=>'real','lowerlimit'=>'-30','upperlimit'=>'100','unit'=>'°C','represents'=>'temperature'}, wie soll eine vererbte Klassenhirarchie über das API denn sonst sinnvoll (und einfach) zugänglich sein? Über eine echte perl package-hirarchie? (in der man sich durch die @ISA-arrays durchhangelt)? Wäre das tatsächlich etwas, was dem Entwickler eines Frontends nutzt?
while (!asleep()) {sheep++};

herrmannj

wenn ich jetzt der Klasse A Typ wäre dann würde ich sagen so ungefähr müsste das wohl ablaufen. Bin aber der Klasse B Typ  ;) ¹

Das System von Boris klingt ebenfalls stringent. In beiden Fällen gibt es halt die Herausforderung das irgendjemand die ganzen metadaten erst einmal füllen muss. Zusätzlich braucht es sehr genaue Normierungen. Beides ist extrem Ressourcen-intensiv.

Mir persönlich (!) erscheint Augenblick der Aufwand im Augenblick weitaus höher als der erzielbare Nutzen. (bitte nicht Missverstehen. Am Ende muss man das Verhältnis Ressourceneinsatz/Nutzen ja bewerten)

¹ beim nächsten mal muss ich das naming anders vorschlagen. jetzt bin ich nur "b"  ....  :)

herrmannj

ich habe den sv convertern eine Eigenschaft "meta" spendiert. Die ist dazu gedacht das man dort später eine (wie auch immer geartete / zu ergänzende) struktur abrufen kann die den converter maschinenlesbar beschreibt.

Damit hoffe ich eine mögliche Verwendbarkeit der converter in der api (hier) zu unterstützen. Gedanke ist: wenn die meta an den readings etabliert sind könnte die api über die wir hier reden evtl anhand der source-meta (reading) und target-meta (item) selbstständig den passenden converter wählen. ob das funktioniert muss sich erst noch zeigen.

vg
jörg

ntruchsess

Zitat von: herrmannj am 24 November 2014, 23:11:06
[...]die Herausforderung das irgendjemand die ganzen metadaten erst einmal füllen muss. Zusätzlich braucht es sehr genaue Normierungen. Beides ist extrem Ressourcen-intensiv.

Die Metadaten erfüllen mehrere Zwecke: zum einen können damit (möglichst) standartisierte Eigenschaften eines Wertes beschrieben werden (die im Idealfall 'automatisch' darin auftauchen), zum anderen kann man optional auch nur für bestimmte Schnittstellen benötigte Werte konfigurativ darin ablegen.
while (!asleep()) {sheep++};

Dr. Boris Neubert

Hallo,

mal was anderes: ich habe mir aus gegebenen Anlass vorgestellt, wie schön es wäre, FHEM auf einer sparsamen Maschine und FHEMWEB auf einer leistungsfähigen Maschine laufen zu lassen. FHEMWEB war in dieser Vorstellung eine Variante, die über das API alle Informationen vom FHEM auf der anderen Maschine beschafft: gib mir Deine Devices, gib mir deren Räume, Gruppen, Sortierwerte, Zustände, Readings, ... Ist das der Anwendungsfall, an dem wir unsere Konzepte gedanklich erproben sollen?

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

justme1968

ich habe vorhin in readingsGroup zwei neue attribute valuePrefix und valueSuffix eingebaut. damit kann man das formatieren eines wertes auf eine bestimmte anzahl von nachkommstellen bzw. das umrechnen auf eine andrer einheit vom davor oder dahinter hängen der einheit trennen.

sobald es den mechanismus gibt das system weit zu konfigurieren sollte es einfach möglich sein die lookup routinen so zu erweitern das sie auch in dieser systemweiten konfiguration nachschauen und dann z.b. alle readings die temperature heißen in der hinterlegten umrechnung, genauigkeit und einheit anzeigen.

gruß
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

ntruchsess

Zitat von: Dr. Boris Neubert am 02 Dezember 2014, 21:31:03
FHEM auf einer sparsamen Maschine und FHEMWEB auf einer leistungsfähigen Maschine laufen zu lassen[...]Ist das der Anwendungsfall, an dem wir unsere Konzepte gedanklich erproben sollen?

Im Prinzip natürlich 'ja'. Ein Webfrontend auf externer Maschine ist mit einer Remoteschnittstelle die die diskutierte API vollständig publiziert sehr einfach umzusetzen.
Um damit auf der sparsamen Maschine Resourcen zu sparen muss das Frontend natürlich statefull umgesetzt sein. Also initial die komplette Konfiguration sammt Werten holen und ab da nur noch die Änderungen gepusht bekommen. Das Frontend hält dabei alle Informationen im Speicher (auch die, die man gerade nicht sieht). Für Informationen, die nicht gepushed werden können braucht es hin und weider natürlich mal einen zyklischen Refresh. Von den Mapping-funktionalitäten profitiert ein Frontend dabei insofern, als dass man damit einiges was heute sehr devicespezifisch umgesetzt ist, auf Frontendseite einheitlich handhaben könnte.

- Norbert
while (!asleep()) {sheep++};

Dr. Boris Neubert

Hallo,

welche Technologie würde man denn verwenden, um zwischen dem Client und dem API zu kommunizieren? Ich vermute, dass eine TCP/IP-Verbindung darunter liegt und dann?

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

herrmannj

Hallo,

wenn Du da schon remote draufgehen möchtest kannst Du vmtl (heute schon) direkt auf Norberts mqqt oder dem fronthem aufsetzen. Beide gehen über websockets. Für Norbert kann ich jetzt nicht sprechen (weil ich nicht weiß wie weit er jetzt ist). Für fronthem: bildet das schon komplett ab, nur die mappings erstellt man von Hand. Da kannst Du per websocket draufgehen. Das Protokoll erwartet auf fhem einen json mit {cmd: monitor; items: [xx, xx, xx, ...]} und pusht zurück {cmd: item; gad: <name>; val: <val>} (pro item/gad}. Das wars ...

vg
jörg

Dr. Boris Neubert

Hallo Jörg,

im großen und ganzen könnte es also so aussehen:


  • Ein API-Device, das die realen Geräte abstrahiert und konfigurierbare virtuelle Geräte zur Verfügung stellt.
  • Die Websockets, die anderen Prozessen auf demselben oder einem anderen Rechner birektionalen Zugriff auf das API-Device ermöglichen. Protokoll: JSON

Die anderen Prozesse wären dann z.B. aus FHEM herausgelöste separate Frontends wie ein angepasstes FHEMWEB, RSS, etc.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!