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
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
und es reicht vieeeeel weiter zurück als vielleicht einigen bekannt:
FHEM Standards (https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ)
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 ;-)
@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 (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.
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.
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 ?
Hallo,
Zitat von: ntruchsess am 21 November 2014, 18:14:47
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).
Zitat
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
Hallo Boris
Zitat von: Dr. Boris Neubert am 21 November 2014, 19:41:41
[...]angefangen, die zitierte Diskussion durchzuarbeiten, keine klare Richtung darin gefunden[...]meine ganze für FHEM reservierte Freizeit frisst[...]
das kommt mir irgendwie bekannt vor ;-)
Zitat von: Dr. Boris Neubert am 21 November 2014, 19:41:41
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
Zitat von: ntruchsess am 21 November 2014, 20:33:48
Ja gerne.
http://www.fhemwiki.de/wiki/DevelopmentReadingsAPI (http://www.fhemwiki.de/wiki/DevelopmentReadingsAPI)
Auf eine gute Zusammenarbeit!
Viele Grüße
Boris
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:
ZitatEs 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.
ZitatEs 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
Zitat von: justme1968 am 21 November 2014, 22:48:45
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.
Zitat von: justme1968 am 21 November 2014, 22:48:45
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.
Zitat von: justme1968 am 21 November 2014, 22:48:45
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).
Zitat von: justme1968 am 21 November 2014, 22:48:45
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
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
ZitatEDIT: 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.
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.
Zitat von: ntruchsess am 21 November 2014, 15:29:33Die 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.
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
Zitat von: Dr. Boris Neubert am 22 November 2014, 11:58:13
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.
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.
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
Zitat von: justme1968 am 22 November 2014, 12:39:03
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)
Zitat von: Dr. Boris Neubert am 22 November 2014, 12:44:54
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).
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
Zitat von: Dr. Boris Neubert am 22 November 2014, 12:44:54
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
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
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 (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
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:
Zitatzuordnung von reading zu set kommando auch.
Hast Du eine konkrte Anwendung ?
vg
jörg
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.
Zitat
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
ZitatIm 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 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.
Zitat von: herrmannj am 24 November 2014, 16:44:29
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.
Zitat von: justme1968 am 24 November 2014, 15:10:21
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 (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
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.
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
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
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
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
@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?
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" .... :)
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
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.
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
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
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
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
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
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
also ein API ist erst mal nur ein Interface, kein konkretes Device. Das würde ich als mit 'use' einbindbares perl-modul implementieren, dass die FHEM-internas komplett abkapselt. Natürlich wurd man das im ersten Schritt über ein FHEM-device konfigurieren, aber diese implementierende Seite des API wäre dann vom Design her austauschbar (sonst würde man sich den Weg zu einfacheren Konfigurationskonzepten schon zu Begin verbauen).
Auf dem API setzen dann z.B. Protokolle wie Websockets auf. Da das API ein perl-api (und nicht ein remote-protokoll) ist, können natürlich auch andere als FHEM-devices implementierte Frontends oder Schnittstellen wie MQTT darauf zugreifen und es zugänglich machen. Als Nutzer einer solchen Schnittstelle (das kann dann auch ein auf MQTT zugreifender Developer sein) muss man dafür kein Wissen über die FHEM-internen Datenstrukturen haben.
Wenn es um Websockets geht, dann natürlich primär über JSON (xml wäre genauso denkbar...). Meinen als schlankes in die FHEM-main-loop integriertes Device implementierten Websocket-stack (http://forum.fhem.de/index.php/topic,28634.msg227359.html#new) habe ich protokollunabhängig designed, da kann man dann beliebige APIs mit geringem Aufwand reinpluggen und ohne Einschränkungen zugänglich machen.
Gruß,
Norbert
Hallo,
mich stört daran, dass man bei der Verwendung von Websockets die Kommunikation/das Protokoll ausprogrammieren muss. Ich habe mir im Vergleich dazu eben SOAP::Lite angesehen (http://www.perl.com/pub/2001/01/soap.html (http://www.perl.com/pub/2001/01/soap.html)). Da bräuchte man in FHEM ein API-Package mit Wrappern für die offenzulegenden Funktionen und könnte diese dann auf dem Client genau so aufrufen, fast ohne zu merken, dass der Code gar nicht selben FHEM-Prozess sondern in einem ganz anderen Programm auf einem ganz anderen Rechner läuft. Leider ist SOAP nicht bidirektional, so dass der Client pollen müsste, um Notifies zu erhalten. Ich bin in diesen Themen leider nicht bewandert. Gibt es da ein Bestes aus beiden Welten?
Viele Grüße
Boris
Hallo,
ich antworte mir mal selbst.
Es scheint so, dass das in Prototypen hier schon verwendete Websockets die Methode der Wahl ist. Für RPC gibt es z.B. JSON::RPC (JSON-RPC 2.0). Leider ist die Integration nicht so transparent möglich, wie bei SOAP::Lite.
Viele Grüße
Boris
Prinzipiell könnte man natürlich auch SOAP (=Protokol) über Websockets (=Transport) sprechen. Allerdings ist SOAP ein sehr geschwätziges Protokol, bringt also relativ viel Overhead mit sich. (Und es gibt für die Kombination eh noch kein fertig nutzbares perl-modul).
JSON-RPC 2.0 als Protokoll um die API remote zu nutzen finde ich auch gut. Das macht es zukünftigen Verwendern leichter als was selbstgestricktes.
Das ganze ist bei mir jetzt leider ein paar Wochen liegengeblieben. Ich bin über Weihnachten zu vielem, nur nicht zum Programmieren gekommen ;-)
- Norbert
Hallo Norbert,
ggf. können wir unsere Aktivitäten bündeln und eine FHEM/JSONAPI.pm entwickeln, das es uns ermöglicht, isolierte Komponenten (FHEMWEB - Javascript im Browser, Subprocess - Aufrufendes Modul, ...) immer mit dem gleichen Protokoll miteinander sprechen zu lassen.
Siehe
http://forum.fhem.de/index.php/topic,34320.msg271321.html#msg271321 (http://forum.fhem.de/index.php/topic,34320.msg271321.html#msg271321)
Grüße
Boris
der thread ist leider wieder ziemlich alt geworden aber ich möchte ihn trotzdem noch mal aus der versenkung holen.
edit: ich habe das ganze in einen eigenen thread verschoben: http://forum.fhem.de/index.php/topic,39236.0.html (http://forum.fhem.de/index.php/topic,39236.0.html).
gruss
andre