wiederverwendbares Mapping a la ReadingsGroup

[ntruchsess]

es gibt in FHEM mehrere Module die im Kern eine Funktion implementiert haben, die Readings anderer(auch mehrerer) Devices abbilden. Prominentester Vertreter 'readingsGroup', aber auch sowas wie MQTT_DEVICE. Für SmartVisu implementiert herrmannj gerade eine weitere solche Lösung. Und nicht zuletzt gibt's noch das eventMap-attribut.

Die Anforderung Reading-werte für ein Frontend oder ein Externes System geeignet zu übersetzen, zu aggregieren und zu formatieren ist dabei im Grunde genommen immer die gleiche. Es wäre also eigentlich eine prima Sache, wenn man das nur einmal einheitlich wiederverwendbar implementiert hätte. Aktuell kocht hier jeder sein eigenes Süppchen - und auch noch so, dass man es eigentlich nur konzeptionell, aber nicht auf code-ebene wiederverwenden kann.

Ist jetzt nicht so, dass ich erwarte, dass hier alle gleich auf den Zug aufspringen und begeistert Ihre Module umstellen wollen - ich möchte nur mal die Diskussion bzw. ein bischen Brainstorming dazu anstoßen (und ggf. selber etwas passendes implementieren... ).
Das könnte z.B. so aussehen, dass man die nicht unmittelbar darstellungsbezogene Funktionalität aus der readingsGroup wiederverwendbar herauslöst, was meint Ihr?

- Norbert

[Markus Bloch]

Das ganze wurde schon lang und breit im folgenden Thread diskuttiert und meiner Meinung nach auch beschlossen: http://forum.fhem.de/index.php/topic,21247.0.html

Gruß
Markus

[Martin Fischer]

und es reicht vieeeeel weiter zurück als vielleicht einigen bekannt:
FHEM Standards

[ntruchsess]

Markus: der Thread mir bekannt, nur kann ich da keinen 'Beschluss' und erst Recht keine Umsetzung innerhalb seit Anfang April 2014 erkennen außer dass Boris in der Richtung etwas entwickeln wollte, ich aber nicht wissen kann, ob er das auch getan hat.

Ging mir auch nicht darum, das alte Thema aufzuwärmen, das Thema 'Mapping' läßt sich auch umsetzen ohne irgendwas am derzeitigen Readings-konzept oder an den bisherigen FHEM-standards zu ändern. Auch wenn das es Synergien gäbe, sehe ich das weitestgehend orthogonal zueinander.

Also mir geht es darum:

Wert/e (aus Readings, Internals, Events oder Attributen) => Abbildungsvorschrift => neue Wert/e (zur Darstellung in Frontends, an Schnittstellen etc...)

Die Abbildungsvorschrift soll konfigurierbare und flexible Kombination/Aggregation/Separierung ermöglichen und über ein wiederverwendbares API zugänglich sein. Gibt's bisher nicht, aber wenn es das gäbe, könnte man es als Entwickler nutzen (oder eben auch nicht... soll ja die bestehenden Konzepte nicht ändern, sondern nur ergänzen). Der Ansatz einer einheitlichen Semantik wurde wohl schon hinreichend diskutiert, aber nie umfassend umgesetzt. Ich bin da pragmatisch: Mit einem flexiblen Adapter (In anderen Kontexten heißt sowas z.B. 'Middleware' oder 'Mediator') kommt man auch ohne eine solche aus. Zusätzlich kann man mit dem gleichen Konzept auch externe Schnittstellen (auch ein GUI ist eine solche), die eh eine andere Semantik besitzen, bedienen.

D.h. mir geht's hier um Ideen und Wünsche zum
- möglichen API
- Konfigurationskonzept

Wenn es von Boris oder jemand anderem in der Richtung schon was modular verwendbares geben sollte, um so besser

[justme1968]

@norbert: ich bin immer sehr für das wiederverwenden aber mir ist gerade nicht ganz klar wie gross die gemeinsamkeiten der module die du beispielhaft angeführt hast tastächlich in dieser beziehung ist. zumindest sehe ich readingsGroup auf einer anderen logischen ebene als MQTT und die SmartVisu integration.

wenn du auf etwas im hinblick auf die semantik eines readings hinaus willst (das würde bei MQTT und SmartVisu sehr gut passen) dann sind die links von markus und martin sowie die interfaces die hier: http://www.fhemwiki.de/wiki/DevelopmentInterfaces beschrieben sind vermutlich tatsächlich das richtige. nichts davon ist aber umgesetzt.

wenn es dir mehr um die darstellung geht dann weiss ich nicht wie viel readingsGroup wirklich wiederverwendbar ist. zumindest wenn es für einen endanwender noch benutzbar sein soll. readingsGroup ist glaube ich sehr fhemweb spezifisch und ich glaube es bleibt nicht viel wiederverwendbares übrig wenn man das alles entfernt.

es gibt einen kleinen teil in readingGroup mit dem es möglich ist einheiten an redings zu hängen und auf eine bestimmte anzahl nachkomma stellen zu runden. hier könnte ich mir vorstellen das man die ideen aus dem einheiten thread und den interfaces verwenden kann. dazu gibt es aber noch keinen code den man jetzt schon wiederverwenden kann.

wenn du ideen hast und doch noch mehr gemeinsamkeiten mit anderen modulen siehst bin ich sehr neugierig.

[ntruchsess]

Andre: unterschätz das mal nicht: ein wesentlicher (und potentiell wiederverwendbarer) Bestandteil der readingsGroup wäre ja z.B. die Syntax des Mapping-attributs. Die könnte man durchaus rauslösen und in einem wiederverwendbaren Stück code implementieren.

[herrmannj]

ich bin skeptisch weil ich die "universelle Anwendung"  nicht sehe. Vom Prinzip her ist mapping irgendwie ähnlich, aber je genauer man dann in die konkrete Anwendung einsteigt umso differenzierter wird das dann. Lasst uns doch mal kurz zusammentragen wofür das eigentlich verwendet werden soll:

Was genau ist der erwartete Nutzen ?
Wie soll das modul exakt aussehen wenn es steht ?

[Dr. Boris Neubert]

Hallo,

Markus: der Thread mir bekannt, nur kann ich da keinen 'Beschluss' und erst Recht keine Umsetzung innerhalb seit Anfang April 2014 erkennen außer dass Boris in der Richtung etwas entwickeln wollte, ich aber nicht wissen kann, ob er das auch getan hat.

ich hatte gesagt, dass ich einen Prototyp entwickeln will. Ich habe dazu schon ein leeres Modul (RTypes.pm) an die richtige Stelle im Initialisierungsprozess gesetzt. Dann habe ich angefangen, die zitierte Diskussion durchzuarbeiten, keine klare Richtung darin gefunden, festgestellt, dass die Wartung meiner Module und des Forums schon meine ganze für FHEM reservierte Freizeit frisst, und dann bin ich verendet. Das ist für mich unbefriedigend.

Ich brauche ein Konzept. Wenn sich hier ein oder zwei Reviewpartner finden, würde ich im FHEM-Wiki eine Seite anlegen, in der wir die bisherigen Erkenntnisse zusammentragen (Anforderung, Abgrenzung, Lösungsskizze).

Wert/e (aus Readings, Internals, Events oder Attributen) => Abbildungsvorschrift => neue Wert/e (zur Darstellung in Frontends, an Schnittstellen etc...)

Ich glaube, dass Deine Anforderung eine Obermenge von der Anforderung im Thread ist, Werte in Readings standardisiert zur Übernahme in einem User-Interface bereitzustellen.

Würdest Du zunächst mit mir an einem Konzept arbeiten wollen?

Viele Grüße
Boris

[ntruchsess]

Hallo Boris

[...]angefangen, die zitierte Diskussion durchzuarbeiten, keine klare Richtung darin gefunden[...]meine ganze für FHEM reservierte Freizeit frisst[...]

das kommt mir irgendwie bekannt vor

Ich glaube, dass Deine Anforderung eine Obermenge von der Anforderung im Thread ist, Werte in Readings standardisiert zur Übernahme in einem User-Interface bereitzustellen.

Würdest Du zunächst mit mir an einem Konzept arbeiten wollen?

Ja gerne.

Gruß,

Norbert

[Dr. Boris Neubert]

Ja gerne.

http://www.fhemwiki.de/wiki/DevelopmentReadingsAPI

Auf eine gute Zusammenarbeit!

Viele Grüße
Boris

[justme1968]

danke für deine zusammenfassung der aktuellen diskussion im wiki.

ich weiss nicht genau wie du dir die weitere diskussion und fortschreibung des artikels vorgestellt hast. ich hänge einfach die paar dinge dir mir spontan einfallen hier an:

Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich)

vielleicht ist die formulierung 'werteberich ermitteln' nicht genau genug. ich denke es ging eher in die richtung zu überwachen ob werte innerhalb eines 'grünen' bereiches liegen oder oder eine warnung (gelb) oder störung (rot) gemeldet werden sollte. z.b. batterie level für alle geräte einer bestimmten klasse unter 0.7v -> warnung, unter 0.6v -> fehler. oder temperatur aussen < 1 grad -> frostwarnung. das geht zwar über die reine darstellung hinaus ist meiner Meinung nach aber ein idealer anwendungsfall.

Es soll keine Vereinheitlichung von Readings-Namen erfolgen (temp, temperature)

ich weiss das der letzte versuch mit den interfaces nicht erfolgreich war. aber sollte es deshalb gleich ausgeschlossen werden? wenn sich ein weg findet bei dem 'standardisierte' reading namen automatisch teil haben und andere erst über ein mapping teilhaben können ist das vielleicht indirekt ein anreiz für einen standard.

bei den nichtfunktionalen anforderungen halte ich es aber auf jeden fall für wichtig das es möglich ist bestehende fhem module auch ohne änderung am modul selber mit einzubinden. d.h. es muss für diese 'alten' module die nicht/noch nicht geändert sind die möglichkeit geben die nötige konfiguration/information von aussen zu verfügung zu stellen und nicht aus dem modul selber zu holen.

wenn es nicht auf einfache art möglich ist so viele alte module wie möglich teil haben zu lassen wird das ganze keinen erfolg haben.

gruss
  andre

[ntruchsess]

ich weiss nicht genau wie du dir die weitere diskussion und fortschreibung des artikels vorgestellt hast.

ich würde vorschlagen, wer etwas z.B. neue Anforderungen beitragen will fügt das der Wikiseite hinzu. Wer einen Punkt diskutieren möchte, muss selber entscheiden, ob das Wiki der richtige Ort dazu ist (man kann z.B. einzelne Punkte im Wiki prima mit einer pro/contra-liste ergänzen und dort stichwortartig seine Kritik oder Zustimmung bzw. 'was geht damit'/'was geht damit nicht'' eintragen). Echte (längere) Diskussionen dazu aber bitte hier im Thread.

vielleicht ist die formulierung 'werteberich ermitteln' nicht genau genug. ich denke es ging eher in die richtung zu überwachen ob werte innerhalb eines 'grünen' bereiches liegen oder oder eine warnung (gelb) oder störung (rot) gemeldet werden sollte. z.b. batterie level für alle geräte einer bestimmten klasse unter 0.7v -> warnung, unter 0.6v -> fehler. oder temperatur aussen < 1 grad -> frostwarnung. das geht zwar über die reine darstellung hinaus ist meiner Meinung nach aber ein idealer anwendungsfall.

Wertebereich(e) halte ich prinzipiell für Sinnvoll (damit man z.B. einen Slider oder eine analoge Anzeige sinnvoll skaliert darstellen kann). Weitere 'echte' Semantik sollte aber besser auf eingene Ausgangsgrößen abgebildet werden. Was nutzt es, wenn ein Battery-level zu einem roten Icon führt, aber nirgendwo eine Aktion erfolgt, weil es nur das Frontend selber ermittelt und darstelltt? Ggf. sollte es möglich sein in einer Abbildungsvorschrift ein Tupel von Ausgangswerten zu erzeugen (Also z.B.: Batteriestand in % + Batteriestatus (gut, mittel, schlecht)), aber ehrlich gesagt halte ich das schon fast für overengineered.

ich weiss das der letzte versuch mit den interfaces nicht erfolgreich war. aber sollte es deshalb gleich ausgeschlossen werden? wenn sich ein weg findet bei dem 'standardisierte' reading namen automatisch teil haben und andere erst über ein mapping teilhaben können ist das vielleicht indirekt ein anreiz für einen standard.

Ja, so sehe ich das auch. Mit einem flexiblen Mapping könnte man alle Devices einheitlich zugänglich machen. Devices, die es unterstützen liefen die nötige Mapping-konfiguration gleich selber automatisch oder per Konvention (bekanntes Interface) mit (Ohne die Allgemeinheit einzuschränken kann ja auch eine triviale performante 1<->1-Abbildung erlaubt sein).

bei den nichtfunktionalen anforderungen halte ich es aber auf jeden fall für wichtig das es möglich ist bestehende fhem module auch ohne änderung am modul selber mit einzubinden. d.h. es muss für diese 'alten' module die nicht/noch nicht geändert sind die möglichkeit geben die nötige konfiguration/information von aussen zu verfügung zu stellen und nicht aus dem modul selber zu holen.

Das zu ermöglichen ist meine primäre Motivation.
EDIT: aus meiner Sicht ist das hier ein ganz zentraler Punkt: Es muss auch einfach durch den Benutzer konfigurierbar sein. Bisher sehe ich da 2 Ansätze: 1 Device mit (vielen) Attributen (oder multi-value Attributen á la readingsGroup), oder Ablage in einem dafür besser geeigneten Format (z.B. xml oder JSON) und ein dafür spezialisiertes Widget. (So was wird aktuell von herrmanj für smartVisu entwickelt).

Danke an Boris, für den Grundstock. Ich habe die Anforderungsliste im Wiki schon mal in Richtung verallgemeinerter Zugriff (nicht beschränkt auf Readings) erweitert.

Gruß,

Norbert

[Dr. Boris Neubert]

Wow, es geht ja schon richtig los.

Zur Zusammenarbeit: ich finde es gut, Ergänzungen, Pros und Contras direkt ins Wiki zu schreiben. Mit der Vergleichen-Funktion in der Versionsgeschichte kann man auch sofort sehen, was geändert wurde.

Habe selbst gerade ein paar Gedanken dazugetan.

Für Diskussionen gibt es auch eine Diskussions-Seite im Wiki. Diese ist noch nicht angelegt. Der Erste, der eine Diskussion startet, könnte die Seite anlegen, eine Überschrift aufmachen, und reinschreiben. Do everything in one place.

Grüße
Boris

[justme1968]

EDIT: aus meiner Sicht ist das hier ein ganz zentraler Punkt: Es muss auch einfach durch den Benutzer konfigurierbar sein. Bisher sehe ich da 2 Ansätze: 1 Device mit (vielen) Attributen (oder multi-value Attributen á la readingsGroup), oder Ablage in einem dafür besser geeigneten Format (z.B. xml oder JSON) und ein dafür spezialisiertes Widget. (So was wird aktuell von herrmanj für smartVisu entwickelt).

ich würde hier drei komponenten sehen. eine optimierte interne struktur zur ablage, eine syntax um um per kommandozeile zu konfigurieren und ein widget das dies komfortabler im frontend ermöglicht.

die kommandozeilen syntax würde ich auch zur persistenten ablage bei neustarts in einem file/der config db verwenden.

etwas in attribute der devices selber zu stecken wird nicht funktionieren so lange es hier keine möglichkeit gibt über mehr als ein device zu gruppieren. dazu gab es mal eine diskussion die aber ebenfalls verendet ist. wenn sich beides auf die gleiche art generalisieren lässt wäre das natürlich perfekt. 

[herrmannj]

soweit ich das sehe behandeln wir hier zwei, zwar zusammenhängende und doch unterschiedliche Themen.

Das eine ist die konkrete Ablage in den Readings (Einheit, Darstellung, Physikalische Größe).
Das zweite ist eine logische Konvertierung. Konkretes Beispiel zur logischen Konvertierung

Gegeben ist ein fhem device (thermostat). Ein reading ist die Temperaturabsenkung mit den möglichen Einträgen "Frost" / "Nacht" / "Komfort"
Im gegebenen Frontend existieren jetzt 3 Buttons dazu und jeder Button wird im Frontend durch einen eigenen "Kanal" repräsentiert. Dann muss  innerhalb von fhem dafür Sorge getragen werden das aus dem (fhem decive) Reading, anhand des dort stehenden Wertes, jeweils einer der drei Buttons angesteuert werden. Eine Änderung am Reading erzeugt also drei getrennte Signale an das Frontend (Frost=false, Nacht=true, Komfort=false). Bidirektional muss folgerichtig aus dem Frontend Signal "Komfort = true" das entsprechende SET generiert werden.

Die Anforderung Reading-werte für ein Frontend oder ein Externes System geeignet zu übersetzen, zu aggregieren und zu formatieren

Das Beispiel zeigt das es zusätzlich zur Organisation der Ablage auch den Bedarf für einen (wie auch immer gearteten) "Konverter" gibt. Der würde, wünschenswerter weise, diese Aufgabe universell und wiederverwendbar lösen sollen.