wiederverwendbares Mapping a la ReadingsGroup

[Dr. Boris Neubert]

Die Analyse ist aus meiner Sicht korrekt.

Ich halte die Standardisierung der Readings für eine übergeordnete Aufgabe von FHEM. Hierauf bezieht sich Aktivität "API" (RTypes.pm usw. mit Leben füllen).

Aus dem Standard die Signale für den Verwender zu konvertieren, ist eine zweite Schicht darüber. Wir können diese dem Verwender des API überlassen, dann gehört es in die Module und Frontends. Wir können diese Aufgabe unterstützen durch einen wiederverwendbaren Konverter. Das war - meine ich - der Ausgangspunkt dieses Threads.

disparate                    standardisierte
Readings          --->     Zugriffsschicht     ---->    standardisierter ----> Verwender
aus Modulen               (API)                                Konverter
                                                                         
                 
M.E. werden wir nur Erfolg haben, wenn wir uns zunächst auf eine Sache fokussieren: API für Readings, jeweils mit Blick auf Erweiterbarkeit hin zum großen Ziel (think big, start small).

Viele Grüße
Boris

[herrmannj]

Wir können diese Aufgabe unterstützen durch einen wiederverwendbaren Konverter. Das war - meine ich - der Ausgangspunkt dieses Threads.

Korrekt, deckt sich mit meiner Sicht. Beim Konverter war (bin) ich bzgl Wiederverwendbarkeit skeptisch da dort schon sehr viel Frontend spezifisches einfließest.

Norberts Gedanke das wiederverwendbar zu gestalten ist allerdings auch folgerichtig, dem möchte ich mich nicht verschließen wenn sich ein praktikabler Weg ergibt.

[justme1968]

ja es sind auf jeden fall zwei unterschiedliche aber zusammenhängende dinge. deshalb der hinweis auf de diskussion zu den generalisierten attributen. es wäre z.b. schön das attribut sortorder abhängig vom aktuellen room oder dargestellter group zu ändern. oder die group zugehörigkeit vom aktuellen raum. oder den angezeigten alias.

das zweite kann man noch mal in zwei ebenen unterteilen. das ist zum einen eine anzah readings und kommandos (auch device übergreifend) zu einer logischen funktion zusammen zu fassen und zum anderen eine anzahl solcher funktionen zu einem logischen device zusammen zu fassen.

um beim thermostat beispiel zu bleiben: zusätzlich zur nachtabsenkung würde z.b. noch ist- und solltemperatur dazu kommen (die nicht aus dem gleichen device kommen müssen) und vielleicht ein wochenprofil. und die zuordnung zu welchem raum und stockwerk das ganze dann gehört.

ob für die nachtabsenkung dann drei buttons, ein menü, oder ein button mit drei zuständen dargestellt wird gehört aber glaube ich nicht mehr dazu. das ist sache des frontend.

beim  generellen converter muss man aufpassen. dinge wie darstellung einer bestimmten anzahl von nachkommt stellen lassen sich sicher wiederverwendbar lösen.  einfärben oder schriftgrössen z.b. sind aber frontend abhängig. hier ist unter umständen sogar die angabe an sich nicht generell möglich. das eigentliche anwenden z formatieren sicher nicht mehr.

[Dr. Boris Neubert]

Ah, ich sehe gerade eine Anforderung, die mir vorher nicht aufgefallen ist: es soll in der API-Schicht möglich sein, sich ein virtuelles Gerät mit den Readings aus realen Geräten zusammenzubasteln.

Der einfachste Fall ist, dass das virtuelle Gerät das reale Gerät widerspiegelt.

Verstehe ich das richtig? Kann dann bitte jemand, der das vor mir/besser verstanden hat, die Doku ergänzen (auch in Bezug auf die die Abgrenzung zum wiederverwendbaren Konverter)?

Viele Grüße
Boris

[herrmannj]

ob für die nachtabsenkung dann drei buttons, ein menü, oder ein button mit drei zuständen dargestellt wird gehört aber glaube ich nicht mehr dazu. das ist sache des frontend.

Hier aufpassen: wenn ich das Ausgabe device anpassen kann stimmt das so. Wenn das Ausgabedevice (frontend) gegeben ist muss ich die Daten dahin entsprechend formatieren (=Konverter)

[herrmannj]

Ah, ich sehe gerade eine Anforderung, die mir vorher nicht aufgefallen ist: es soll in der API-Schicht möglich sein, sich ein virtuelles Gerät mit den Readings aus realen Geräten zusammenzubasteln.

Der einfachste Fall ist, dass das virtuelle Gerät das reale Gerät widerspiegelt.

Verstehe ich das richtig? Kann dann bitte jemand, der das vor mir/besser verstanden hat, die Doku ergänzen (auch in Bezug auf die die Abgrenzung zum wiederverwendbaren Konverter)?

Viele Grüße
Boris

Ja gern. Hier fehlt aber die Schärfe im Lastenheft (als Gesamtheit der Anforderungen an Lieferung und Leistung seitens des Auftraggebers  ).
Die Anforderungen müssen mMn erst erarbeitet werden bevor abgegrenzt werden kann. (Ziele vs Nichtziele).

[ntruchsess]

super, so viele echt konstruktive Beträge in so kurzer Zeit, ich bin echt beeindruckt

Ich arbeite dann mal einen Vorschlag zur konkreten API aus. Ich denke damit wird das schon greifbarer.

Gruß,

Norbert

[ntruchsess]

es soll in der API-Schicht möglich sein, sich ein virtuelles Gerät mit den Readings aus realen Geräten zusammenzubasteln.

Das Virtuelle Gerät sei eine Menge zusammengruppierter Werte und Funktionen (n>1), also z.B. das Thermostat aus Jörgs Beispiel. Ist diese Anforderung dann orthogonal zu den Anforderungen an die Aggregation und Transformation 'echter' Werte zu sehen? Also soll man die Transformierten Werte einfach nur zusätzlich Gruppieren (ggf. auch mehrfach - also zuordnung zum virtuelles Device, Widget, Raum, Gebäude...), oder soll der Output der Transformation dann schon ein Gruppierter Wert (also ein Array oder ein Hash mit mehreren Werten) sein? Ich persönlich würde das in der API eher voneinander trennen. Das wäre sicher übersichtlicher und universeller verwendbar.

- Norbert

[herrmannj]

ich plädiere stark dafür das wir wir gemeinsam doch noch eine Schritt zurückgehen und uns zu erst gemeinsam den erwarteten Nutzen erarbeiten. MMn macht es erst dann sich sich darüber zu unterhalten was wir implementieren wollen und dann im nächsten Schritt dann entscheiden wie wir das implementieren.

Zur Frage nach potentiellen Abnehmern der API, vielleicht sollten wir die mal Zusammenstellen. Als einer der potentiellen Abnehmer melde ich mich für smartVisu.

Disclaimer: da bin ich in der Zielgeraden, deshalb habe ich auch einen kleinen Interessenkonflikt hier weil ich unter Umständen etwas verabschiede was ich schon längst anders implementiert habe.

Wer würde sich denn noch als potentieller Abnehmer hier melden ? (Und wenn ja, was wäre der erwartete Nutzen von der API ?)

Zur Frage nach dem gruppieren: hat mMn gar nichts in der API zu suchen und wäre da auch (für mich) völlig unbedeutend. Es ist ja Aufgabe des Ausgabe Device das, nach gusto, zusammenzufügen.

vg
jörg

[justme1968]

ein schritt zurück ist sicher noch mal gut. auch um die unterschiedlichen bereiche zu erkennen um die es gerade geht.

wenn wir die unterschiedlichen und zusammenhängenden bereiche identifiziert haben und alle vom gleichen reden ist zu entscheiden was davon in welcher reihenfolge weiter verfolgt werden soll.


ich sehe in der diskussion das folgende:
1. alles was mit readings im hinblick auf einheiten und semantik zu tun hat
  - einheitenkonvertierung 
  - das formatieren von werten im hinblick auf nachkommt stellen
2. das was norbert ursprünglich unter mapping genannt hat
3. die n:m zuordnung von readings aus dem fhem devices zu gui elementen in frontend

an 1. habe ich interesse für readingsGroup und vermutlich auch für lightScene

an 2. habe ich (über fhemweb) interesse für 'meine' widgets

an 3. habe ich ebenfalls interesse für die widgets. konkret zunächst für das heizungswidget (http://forum.fhem.de/index.php?action=dlattach;topic=27291.0;attach=19336;image). die einzelnen komponenten können bei mir aus unterschiedlichen devices kommen und die zuordnung von reading zu set kommando auch.

gruss
  andre

[herrmannj]

schöne Struktur, klemm ich mich dran:

1. für mich untergeordnet (weil mit 2 zu erledigen)
2. yes, definitiv (allerdings bereits implementiert)
3. nicht von Interesse (weil im Ausgabedevice)

ps heizungswidget: schick!
pps and ot:

zuordnung von reading zu set kommando auch.

Hast Du eine konkrte Anwendung ?

vg
jörg

[ntruchsess]

MQTT und WebSocket wären Abnehmer von allen 3 Punkten.

- Im Websocket Interface wäre der Output jeweils eine Struktur aus formatiertem Einzelwert mit Metadaten. Gruppierungen wäre als 'Tags' in den Metadaten zu finden, dazu käme die Möglichkeit jeweils alle Werte zu einem Tag abzufragen.
- Für MQTT würde ich die Topic-struktur aus den Metadaten und Formatierungen ableiten, und die formatierten Einzelwerte (aus 1+2) in dieser Topic-struktur an passender Stelle publishen.

zuordnung von reading zu set kommando auch.

Den Rückweg (ein Wert wird über die API geschrieben) sehe ich primär als Abbildung auf Set- bzw. Attr- kommandos. Eine direkte Abbildung auf Reading-werte würde ich der Vollständigkeit halber mit einbauen (das ist vorraussichtlich für fast umsonsts zu haben...), damit könnte man dann z.B. einen Dummy als Container für die Einzelkanäle eines RGB-Widgets nutzen.

- Norbert

[herrmannj]

Im Websocket Interface wäre der Output jeweils eine Struktur aus formatiertem Einzelwert mit Metadaten

Ich hab das Konzept mal untersucht als ich mit sv begonnen habe. Ich halte das jedoch für sehr herausfordernd  weil die quantitativ sehr viele Informationen gibt die sich kaum klassifizieren lassen. "Normale" Werte wie Temp lassen das zu. Was aber ist mit Zisternen ? (%, m, m³ ...?). RGB Werte ? Klingeltöne (Fritz phone), Batterie ? (%, gut, mittel, schlecht, Volt ...). IP-Cam Bilder. Türzylinder (Keymatic).  (Liste endlos... )

Schlussendlich lebt fhem sehr gut davon das ich mal eben einen Arduino irgendwie "ranklebe" und dann macht der was total nerdiges  . 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.

[ntruchsess]

Wenn ich aber sowieso jeden Wert dazu händisch anfassen muss (ist ja die Folge) wird 1. in einen Augen obsolet.

Da hast Du nicht ganz unrecht. Man kommt auf jeden Fall auch ganz gut ohne aus. Wenn man es aber erst mal (optional) mit drin hat, dann eröffnen sich Möglichkeiten einiges im Frontend zu vereinfachen. Natürlich nur für Dinge, die semantisch unter einen Hut zu bringen sind. Auf jeden Fall ist der Ansatz aussichtsreicher, als wenn man versucht einen Standard zu dekarieren und dann (Henne/Ei Problem) darauf wartet dass Front- und Backendentwickler anfangen den Standard umzusetzen. Mit Einheit könnte z.B. ein dimensionsloser Arduino-messwert von allen Frontends die das unterstützen allein durch simple Konfiguration passend visualisiert werden, ohne dass der konfigurierende Benutzer z.B. die passenden Icons kennen muss. Ist bei Dir für SmartVisu halt nicht auf dem Radar, weil es da nicht Bestandteil der Schnittstelle ist.

[klausw]

an 3. habe ich ebenfalls interesse für die widgets. konkret zunächst für das heizungswidget (http://forum.fhem.de/index.php?action=dlattach;topic=27291.0;attach=19336;image). die einzelnen komponenten können bei mir aus unterschiedlichen devices kommen und die zuordnung von reading zu set kommando auch.

auch wenns OT ist, ich muss einfach fragen 
Ist das "heizungswidget" ein readingsgroup? Und gibt es da ein Template für