[FHZ] Meta-Devices

[Guest]

Originally posted by: <email address deleted>

On 12 Feb., 21:07, Martin Fischer wrote:
> hier verstehe ich die aussage von martin auch nicht. entweder hat er hier
> "insider-wissen" also die aussage direkt von rudi oder es ist eine
> pauschalaussage. warum sollte rudi davon ausgeschlossen sein? davon ab

Nein, Insiderwissen o.ä. habe ich nicht, evtl. liege ich ja auch ganz
falsch.
Von "ausgeschlossen" habe ich schonmal gar nichts geschrieben.

"Aus meiner Sicht" wird hier eine Art Erwartungshaltung aufgebaut, die
ich so nicht teilen kann.
In den letzten Beiträgen hat sich das allerdings wieder ganz anders
angehört (bzw. ich so verstanden).

Mehr wollte ich dazu nicht sagen -- also bitte nichts
überinterpretieren.

Modul-Programmierer (Perl) bin ich ja bekanntlich nicht,
professioneller Programmierer erst recht nicht. Meine Bereitschaft
beim Frontend nachzuziehen habe ich geäußert, viel mehr beitragen kann
ich zu dem Thema leider nicht.

Grüße,
Martin

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Martin Fischer]

Am Freitag 12 Februar 2010 schrieb Martin Haas:
> On 12 Feb., 21:07, Martin Fischer wrote:
> > hier verstehe ich die aussage von martin auch nicht. entweder hat er hier
> > "insider-wissen" also die aussage direkt von rudi oder es ist eine
> > pauschalaussage. warum sollte rudi davon ausgeschlossen sein? davon ab
>
> Nein, Insiderwissen o.ä. habe ich nicht, evtl. liege ich ja auch ganz
> falsch.
> Von "ausgeschlossen" habe ich schonmal gar nichts geschrieben.

ich habe auch nicht behauptet das du geschrieben hast rudi auszuschliessen.

> "Aus meiner Sicht" wird hier eine Art Erwartungshaltung aufgebaut, die
> ich so nicht teilen kann.

ohne diese diskussion jetzt vertiefen zu wollen, da es a) überhaupt nicht in
diesen thread gehört und b) auch nicht zielführend ist, möchte ich jedoch
anmerken, das niemand irgendwo geschrieben hat, dass rudi das alleine heben
soll. demnach wurde die erwartungshaltung auch nicht geschürt. dennoch gebe
ich dazu meine abschätzung ab und wage zu behaupten, das es ohne rudi's
mithilfe sicherlich schwieriger werden würde.

> In den letzten Beiträgen hat sich das allerdings wieder ganz anders
> angehört (bzw. ich so verstanden).
>
> Mehr wollte ich dazu nicht sagen -- also bitte nichts
> überinterpretieren.

von daher schliesse ich mich dir an: nichts sollte überbewertet werden. rudi
hat sich bisher nur wenig beteiligt, was ich aber bitte hier nicht als vorwurf
dargestellt haben will!

wenn ich es richtig im gedächtnis habe, äusserte er, das er ungern davon
abweichen möchte die bisherige modulstruktur von fhem auszuhebeln und
weiterhin hat er durchaus interesse an einer harmonisierung der bezeichnungen
von readings, internals und attributes signalisiert.

und da nun ja schon einige sehr interessante ansätze diskutiert wurden, wäre
es vielleicht sinnvoll, wenn wir uns _gemeinsam_ auf eine linie einigen oder
aber wenn es keine gemeinsame linie gibt, fhem so belassen wie es ist.

ich persönlich mache das hier ja auch letztlich aus spass an der freude und
verfolge die philosophie "wenn ich mich an oss bediene, kann ich auch mal was
zurückgeben". und da ich nicht nur zu den modulliefernten gehöre sondern auch
ein mittlerweilen sehr komplexes gui entwickelt habe, wäre es für mich schon
sehr von interesse zu wissen, wohin die karavane denn zieht.

ist es nämlich so, das fhem so bleibt wie es ist, dann muss ich weiterhin viel
aufwand bei der gui betreiben um alle eventualitäten abzufangen, werde dann
aber meinen persönlichen milestone verfolgen myhce 2.0.0 ende Q1 / 2010 zu
releasen.

ist es aber so das absehbar ist, das wir uns auf einen neuen layer einigen,
dann heisst das für mich, das ich mir den aufwand in myhce sparen kann und
dann die 2.0.0 lieber später mit mehr funktionalität release.

persönlich halte ich den ansatz von olaf als derzeit den interessantesten.

martin

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Moin,

Olaf wrote:

> also, da meine Ausführungen wohl nicht eindeutig waren, anbei nun der
> Versuch das ganze etwas aufzuklären, und einen konkreten Vorschalg zu
> machen:



> Zur Abstraktion / zum Layer:
> Das Ziel eines Layer (der in diesem Falle ÜBER den anderen Modulen
> liegt) ist es, diese zu verdecken.
> Heißt: Wer den abstrakten Layer nutzt, sieht die anderen Dinge nicht,
> und will es auch nicht.
> Heißt aber auch: Wer die unteren Module weiter nutzen will, kann dies
> natärlich immernoch tun, und ignoriert einfach den höheren Layer.

Gut, das deckt sich nicht mit meiner (OSI- oder Kernel-)Schichten-Denke,
aber vielleicht ist einfach auch die Übersetzung Layer auf Schicht nicht
so prall.

[...]

Nur, damit wir nicht weiter aneinander vorbei reden: faktisch verlagerst
Du das Detailwissen um die Devices (ich versuche jetzt einfach mal, bei
den englischen (FHEM-) Begriffen zu bleiben) vom Frontend (auch) in diese
neuen "abstrakten Layer".

Aus ...

> Wie soll das gehen?
> Nun, da wirds etwas kniffelig. Wie ich schon mehrfach sagte, will ich
> keinen Code duplizieren, und ich glaube auch nicht, dass wir 50% von
> FHEM neu bauen müssen.
> In meiner Vorstellung ist das folgende das Ziel:S300TH
> Ein User bestimmt, dass das Modul "Sensors" (als Beispiel) un die
> Daten von einem X10, FS20-HGS, einem FHT und einem S300TH aufnimmt.
> Verdrahtet wir das per Attribute (sowas wie IODev) indem man dem Modul
> Sensors bekanntgibt, welche Basis-Geräte/Module) es benutzt.
>
> Wie kommuniziert das höhere Modul nun ?
> In meiner Vorstellung per Notify um Daten zu erhalten, und per FHEM-
> Kommando (set ... bla) um Daten an die Basis-Module zu versenden.
> Dadurch müssen wir keine Basis-Module ändern.

... ergibt sich dann für mich, daß für ein neues (logisches) Device auch
"Arbeit" (Dokumentation, Schnittstellenfedinition, wasweißich) seitens
des Modulschreibers (oder der Dritten Manns ) für die Abstraktionsebene
geleistet werden muß? Das wäre aus meiner Sicht zumindest dahingehend ein
Fortschritt, als daß ich derzeit nur ein Modul auf den Markt schmeißen
kann nach dem Motto "friß oder stirb" (OpenSource tendiert hier dann eher
zu stirb, es sei denn, der konkrete Autor hat grade spezifischen Appetit).

> Wie soll das nun dynamisch gehen:
> Mein Ziel ist es, jedem Basis-Modul Entwickler voll Freiheit zu
> lassen, wie er denn nun die Funktionen nennt, und welche Datentypen er
> übergibt.
> Das kommt den Basis-Entwicklern entgegen, da die meisten bei Open-
> Source für Ihre Bedürfnisse entwickeln, und das ist auch gut so.
> Nichtmal große Software-Schmieden kriegen einheitliche Schnittstellen
> hin

Das stellt aber das bisherige Konzept schon auf den Kopf, oder? Zumin-
dest, was die Kommunikation mit fhem.pl angeht ($dev->{STATUS}, $dev->
{READINGS}{$reading}{VAL}, ...). Zumal, wenn wie eingangs postuliert,
ein Frontend über die Abstraktionsschicht zugreifen können soll als auch
direkt das Device ansprechen?

[...IDL...CORBA...]

[...]
> Und nun auf zu Kommentaren

Uff. Okay... Das muß ich mal einwirken lassen Es klingt gründlich durch-
dacht, keine Frage. Was mich momentan abschreckt, sind diese Geschichten mit
IDL/CORBA, ich zweifele derzeit, ob das wirklich an diese Stelle so eine
gute Idee ist; setzt das nicht die Einstiegshürden schon recht hoch?

Aber vielen Dank für die ausführliche Erläuterung!
         kai

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[nobody0472]

                                                                 

HI Martin, all

> damit wären wir aber auch wieder bei der ursprungsdiskussion angelangt,
> nämlich dem harmonisieren von internals, readings, etc. damit diese dann auch
> möglichst -wie du schriebst- unkompliziert abgebildete werden können. das
> würde auch den codeaufwand des von dir angesprochenen IDL-Parsers veringern..
> ganz nach dem KISS prinzip..

Das stimmt nur fü+r die höhere Schicht. Denn wie die Readings/
Internals in den existierenden Modulen aussehen kann in der IDL
stehen, und muß nicht für alle gleich sein.
>
> also wären sinnvolle nächste schritte aus meiner sicht:
>
> 1. sammeln der möglichen kategorien (dabei können alle unterstützen)
> 2. konsolidierung der gesammelten kategorien aufgrund ähnlicher / gleicher
> bedeutungen.
> 3. diese dann als ersten wurf festlegen.
> 4. für jeden kategorientyp die möglichen generischen funktionen erarbeiten.
> 5. die funktionnen möglichst harmonisieren damit es nicht einmal z.b. "set"
> und an anderer stelle "put" oder so heisst und das gleiche gemeint ist. es sei
> denn set und put sind tatsächlich völlig verschiedene funktionen.
> 6. jeder modulentwickler macht sich dann gedanken ob aufgrund der obigen punkt
> 3 und 5 ggf. code angepasst werden muss.
> 6.1. parallel prüft rudi, was an fhem.pl ggf. angepasst werden müsste, da er
> nunmal den meisten durchblick bezgl. des codes hat.
> 7. die definition der von dir benannten "header-datei / interface-datei"
> beschreiben
> 8. erstellen der header/interface-datei je modul durch die jeweiligen
> modulentwickler.
> 9. entwicklung des IDL-parsers
> 10. prototyping

Genau so stell ich mir das vor. Wobei Punkt 8 automatisch gehen kann,
und 9 quasi vorhanden ist.

Da ich als Hobby ein Compiler-Entwickler bin denke ich darüber hinaus
an eine Spezifikations-Sprache für abstrakte Module (basierend auf
EBNF, oder so) mit der man dann diese Dinger automatisch generieren
lassen kann. Das hat den Vorteil, dass alle Funktionen dann
automatisch gleich heißen, und nur die Paramtere spezifiziert werden
müssten. Aber das ist weitere Zukunft

>
> dazu könnten wir ja evtl. einen extra branch im cvs öffnen um sicherzustellen,
> das fhem selber erstmal so bleibt wie es ist und das in ruhe angepasst werden
> kann.

Stimmt. Für die abstrakten Module könnte ich nächste Woche (ab
Mittwoch) mal einen ersten Aufschlag machen. Ich würd dazu allerdings
gern das Wiki nehmen, die diese Mailerei zu umständlich wird.

Gruß,
Olaf

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[nobody0472]

                                                                 

Hallo Kai,
> > Zur Abstraktion / zum Layer:
> > Das Ziel eines Layer (der in diesem Falle ÜBER den anderen Modulen
> > liegt) ist es, diese zu verdecken.
> > Heißt: Wer den abstrakten Layer nutzt, sieht die anderen Dinge nicht,
> > und will es auch nicht.
> > Heißt aber auch: Wer die unteren Module weiter nutzen will, kann dies
> > natärlich immernoch tun, und ignoriert einfach den höheren Layer.
>
> Gut, das deckt sich nicht mit meiner (OSI- oder Kernel-)Schichten-Denke,
> aber vielleicht ist einfach auch die Übersetzung Layer auf Schicht nicht
> so prall.

Doch doch, das passt schon, denn auch im OSI-Layer können schichten
leer sein.
BSP: verwende einen Socket über natives Bluetooth (ohne IP). Dann hast
Du Layer 5 und 2/1, aber faktisch nichts auf 3+4.

>
> [...]
>
> Nur, damit wir nicht weiter aneinander vorbei reden: faktisch verlagerst
> Du das Detailwissen um die Devices (ich versuche jetzt einfach mal, bei
> den englischen (FHEM-) Begriffen zu bleiben) vom Frontend (auch) in diese
> neuen "abstrakten Layer".

Genau. So der Plan. Wobei das Detail-wissen automatisch eingelesen
werden soll (IDL) und nicht reinprogrammiert werden muß. Für wietere
Funktionen, die das Dingen dann noch haben soll, kann man sich noch
verschiedene Spezifikationssprachen und Code-Generierung vorstellen.
>
> ... ergibt sich dann für mich, daß für ein neues (logisches) Device auch
> "Arbeit" (Dokumentation, Schnittstellenfedinition, wasweißich) seitens
> des Modulschreibers (oder der Dritten Manns ) für die Abstraktionsebene
> geleistet werden muß? Das wäre aus meiner Sicht zumindest dahingehend ein
> Fortschritt, als daß ich derzeit nur ein Modul auf den Markt schmeißen
> kann nach dem Motto "friß oder stirb" (OpenSource tendiert hier dann eher
> zu stirb, es sei denn, der konkrete Autor hat grade spezifischen Appetit).

Genau. Diese abstrakten Dinger sollen bekannte, und für einen Typ (bei
mehreren ausprägungen) immer die gleiche Schnittstelle haben.
>
> Das stellt aber das bisherige Konzept schon auf den Kopf, oder? Zumin-
> dest, was die Kommunikation mit fhem.pl angeht ($dev->{STATUS}, $dev->
> {READINGS}{$reading}{VAL}, ...). Zumal, wenn wie eingangs postuliert,
> ein Frontend über die Abstraktionsschicht zugreifen können soll als auch
> direkt das Device ansprechen?

Ein FrontEnd kann immernoch wählen, oder beides nutzen. Mein Ziel wäre
es aber, dass die Frontends früher oder später auf die akstrakten
migrieren, aber das kann ja jeder selbst entscheiden.
>
> [...IDL...CORBA...]
>
> Uff. Okay... Das muß ich mal einwirken lassen Es klingt gründlich durch-
> dacht, keine Frage. Was mich momentan abschreckt, sind diese Geschichten mit
> IDL/CORBA, ich zweifele derzeit, ob das wirklich an diese Stelle so eine
> gute Idee ist; setzt das nicht die Einstiegshürden schon recht hoch?

Will kein CORBA nutze, aber die IDL verwenden, denn für die gibt's
bereits fertige Parser/Syntax-Checks, etc. und man müßte nicht extra
Grammatiken/Parser und Compiler für eine Interface-Sprache bauen

Gern,
Olaf

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.