Hi all,
da nun inmanchen Threads über Abstraktion/Meta Ebenen diskutiert wird,
wir aber mehr oder weniger alle das Module-Konzept von FHEM als große
Stärke ansehen und es behalten wollen, wie wäre es neue, abtrakte
Geräte/Module zu entwerfen, die eben genau die Schnittstelle nach oben
liefern die wir haben wollen.
Diese Meta-Devices könnten dann auch geeignete Weise mit den echen
Hardware-Modulen (Dimmer/FS20-Steckdosen/X10) über einen geeigenten
Mechanismus verknüpft werden, um so ein mapping von Meta-Device auf
Hardware-Modul zu realisieren.
Dadurch können wir die Module die wir haben weiter pflegen, und die
jenigen zufrieden stellen, die diese Ebene mögen und nutzen/ausbauen.
Für die Front-End Jungs wäre die Meta-Ebene deutlich hilfreicher, da
sie abstrakt alle "guten" Funktionen unterstützt.
Also sowas wie: Modul Dimmer.
Dieses mapped dann auf das unterliegende Modul X10 / FS20-Dimmer, oder
was auch immer in geeigneter Weise (wie auch immer diese aussieht).
Dabei ist es explizit das Ziel die abstrakten Module als Aufsatz/
Abstraktion zu haben, OHNE die existierenden zu ersetzen, denn diese
bilden die Funktionalität für das Zielsystem (FS20/X10, etc) ab.
Dies ist ein Versuch die X10 und EnvSense Diskussion mal zu
konkretisieren und einen ersten Ansatz passend zum FHEM-Konzept mit
Modulen zu machen, die wir alle immer wieder gerne bauen.
Falls dies ein Thread zu viel in diese Richtung ist, einfach
ignorieren bzw. löschen.
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.
Originally posted by: <email address deleted>
Moin,
Olaf wrote:
> da nun inmanchen Threads über Abstraktion/Meta Ebenen diskutiert wird,
> wir aber mehr oder weniger alle das Module-Konzept von FHEM als große
> Stärke ansehen und es behalten wollen, wie wäre es neue, abtrakte
> Geräte/Module zu entwerfen, die eben genau die Schnittstelle nach oben
> liefern die wir haben wollen.
[...]
> Für die Front-End Jungs wäre die Meta-Ebene deutlich hilfreicher, da
> sie abstrakt alle "guten" Funktionen unterstützt.
>
> Also sowas wie: Modul Dimmer.
> Dieses mapped dann auf das unterliegende Modul X10 / FS20-Dimmer, oder
[...]
> Dies ist ein Versuch die X10 und EnvSense Diskussion mal zu
> konkretisieren und einen ersten Ansatz passend zum FHEM-Konzept mit
> Modulen zu machen, die wir alle immer wieder gerne bauen.
Danke für den Ansatz. Er geht ein gutes Stück über den simpleren Ansatz
von Boris hinaus, weshalb ich befürchte, daß das, was Rudolf diesbezüg-
lich schrieb, erst recht gilt:
| my opinion it is noth worth defining the interfaces (not an easy task) and then
| rewriting ca 50% of the fhem code. Consolidating the readings/settings would be
50% dürfte hier dann untertrieben sein, denn derzeit gibt es keine saubere
Schnittstelle zwischen Modulen auf gleicher Ebene untereinander; definiert
ist nur vom "physischen" zum "logischen" (Dispatch()) und vom "logischen"
zum "physischen" (IOWrite()):
| Es gibt zwei Arten von Geraeten, die man (wenn moeglich) nicht zu einem
| zusammenfassen sollte:
| - das Physische, was man also direkt am Rechner anschliesst, z.Bsp. FHZ/CUL
| - das Logische, was ueber das physisch angeschlossene indirekt gesteuert wird
| (FS20, FHT)
Ich sehe ad hoc auch keinen trivialen Weg, das bisherige Modell um einen
Abstraktionslayer zu erweitern: um Schreibbefehle an das eigentliche Ge-
rät umsetzen zu können, müßte "Dimmer" derzeit das IODev eines Gerätes sein;
um geänderten Status zu kennen, müßte "Dimmer" aus der ParseFN() jedes
Moduls getriggert werden -- wobei, das könnte man ggf. im Notify zentral
aufhängen. Da aber jetzt für ein UI der Gerätetyp "Dimmer" (und nicht mehr
"FS20"/"X10"/...) wäre, wie sollte das UI noch die spezifischeren Funk-
tionen des Gerätes addressieren?
Die Idee finde ich charmant; aber da schon die Sinnhaftigkeit einer simplen
Definition von "Dimmer", "Schalter", "Thermometer" ziemlich kollektiv in
Abrede gestellt wird, ganz zu schweigen von einem ebenso simplen Zusatz-
eintrag $hash->{INTERFACES} mit einer oder mehrer dieser Definitionen, sehe
ich für einen derart komplexen Ansatz wenig Chancen?
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.
Originally posted by: <email address deleted>
Hallo Zusammen,
> das bisherige Modell um einen Abstraktionslayer zu
Der Layer ist doch nur eine andere Sicht auf die Dinnge .....
Könnte man die benötigten Infos nicht unter $mod "unterbringen" ?
So etwa:
$mod{}{INTERFACES}{}{TYPE}
$mod{}{INTERFACES}{}{GET}
$mod{}{INTERFACES}{}{SET}
etc. = ???
Beispiele:
HMSTF
$mod{HMS}{INTERFACES}{HMSTF}{TYPE} = EnvSensor
kein SET/GET = der Typ kann nix ;-)
FS20ST
$mod{FS20}{INTERFACES}{FS20ST}{SET} = "ON;OFF"
$mod{FS20}{INTERFACES}{FS20ST}{TYPE} = "Aktuator"
Die Daten werden beim define von den Modulen gesetezt.
Ev. ein paar neue FHEMCommands:
ChangeInterface NewInterfaceType
ListInterfaces TYPE=EnvSensor
Und z.B. in FHEMWEB gibt einen neuen Menupunkt "DEVICE-VIEW" und
"INTERFACE-VIEW" zum Umschalten der "Ansicht" ...
Also das UI stellt die Infos dann dar....
Schoene Gruesse
Axel
--
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.
Hi,
kann man sicherlich, ist aber weniger, als ein zusätzlicher Layer.
Denn dieser Layer bietet mehr, als nur eine andere Sicht, da man durch
diesen Layer nämlich Frontends bauen könnte, die nichtmal wissen,
welchen physikalischen Bus die eigentlichen Devices verwenden.
Wenn man es in die jeweiligen Module mit reincodieren würde, so wie Du
vorgeschlagen hast, muß jedes Frontend, doch jedes einzelne Device
kennen, und richtig interpretieren.
Mein Ziel war es mit diesem zusätzlichen Layer, Spezialitäten der
einzelnen Devices zu verstecken, so wie man dies halt mit Abstraktion
versucht zu machen.
Gruß,
Olaf
On 9 Feb., 20:22, Axel
wrote:
> Hallo Zusammen,
>
> > das bisherige Modell um einen Abstraktionslayer zu
>
> Der Layer ist doch nur eine andere Sicht auf die Dinnge .....
>
> Könnte man die benötigten Infos nicht unter $mod "unterbringen" ?
> So etwa:
> $mod{}{INTERFACES}{}{TYPE}
> $mod{}{INTERFACES}{}{GET}
> $mod{}{INTERFACES}{}{SET}
> etc. = ???
> Beispiele:
> HMSTF
> $mod{HMS}{INTERFACES}{HMSTF}{TYPE} = EnvSensor
> kein SET/GET = der Typ kann nix ;-)
>
> FS20ST
> $mod{FS20}{INTERFACES}{FS20ST}{SET} = "ON;OFF"
> $mod{FS20}{INTERFACES}{FS20ST}{TYPE} = "Aktuator"
>
> Die Daten werden beim define von den Modulen gesetezt.
> Ev. ein paar neue FHEMCommands:
> ChangeInterface NewInterfaceType
> ListInterfaces TYPE=EnvSensor
>
> Und z.B. in FHEMWEB gibt einen neuen Menupunkt "DEVICE-VIEW" und
> "INTERFACE-VIEW" zum Umschalten der "Ansicht" ...
> Also das UI stellt die Infos dann dar....
>
> Schoene Gruesse
>
> Axel
--
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.
Originally posted by: <email address deleted>
Moin,
Dem kann ich so uneingeschränkt zustimmen. So ist man flexibel in alle
Richtungen und der fhem-code sollte davon eigentlich auch profitieren.
a.
On 10.02.10 09:51, "Olaf" wrote:
> Mein Ziel war es mit diesem zusätzlichen Layer, Spezialitäten der
> einzelnen Devices zu verstecken, so wie man dies halt mit Abstraktion
> versucht zu machen.
--
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.
Originally posted by: <email address deleted>
Olaf wrote:
> Denn dieser Layer bietet mehr, als nur eine andere Sicht, da man durch
> diesen Layer nämlich Frontends bauen könnte, die nichtmal wissen,
> welchen physikalischen Bus die eigentlichen Devices verwenden.
Dieser Layer läge oberhalb der bestehenden logischen Module? Damit
verdeckte er die Sicht auf diese, was -- aus verschiedenen Gründen
nicht erwünscht ist.
Ein Layer parallel zu den logischen wäre kein Layer, oder bin ich da
zu sehr auf die gute alte Zwiebel fixiert?
> Wenn man es in die jeweiligen Module mit reincodieren würde, so wie Du
> vorgeschlagen hast, muß jedes Frontend, doch jedes einzelne Device
> kennen, und richtig interpretieren.
Das ist ein Irrtum.
Mit der Information eines Moduls, welche Eigenschaften ein spezifisches
Gerät hat, kann man beides nutzen.
*Heute* liefert FHEM die Information Name, Typ, Model, Readings, z. B.
also {Wohnz_LED; FS20; FS20ST; Status=on} oder {myWS; WS3600; Ti; Status=
T: 23.1}.
Die Interpretation kann nur das Frontend machen auf Bases des *vorher* be-
kannten Wissens um "was ist ein FS20ST bzw. generell ein FS20-Gerät" usw.
Lieferte nach diversen Vorschlägen FHEM *stattdessen* nun Name, Typ, Model,
Geräteklasse, Readings, also z. B. {Wohnz_LED; FS20; FS20ST; Schalter;
Status=on} oder {myWS; WS3600; Ti; Temperatursensor; Status=T: 23.1},
könnte jedes Frontend anfangen, diese *vordefinierten* Geräteklassen zu
unterstützten. Nutzung spezifischerer Kenntnis bliebe unbenommen.
Im Gegenzug dazu müßte sich beim Metadevice-Vorschlag das Frontend ent-
scheiden, *entweder* Meta- *oder* logische Geräte zu unterstützten; ge-
nau genommen müßte der Metalayer sogar die logischen Geräte überlagern,
eine Nutzung spezifischerer Funktionen also verunmöglichen. Das wäre ein
ziemlicher Rückschritt.
> Mein Ziel war es mit diesem zusätzlichen Layer, Spezialitäten der
> einzelnen Devices zu verstecken, so wie man dies halt mit Abstraktion
> versucht zu machen.
Ich sehe eigentlich keine Notwendigkeit, etwas zu verstecken; das bis-
herige Setup hat sich, wie von anderer Seite auch postuliert, eigent-
lich bewährt. Was (mir) fehlt ist eine Abstraktionsinformation, die es
einem Frontend ermöglich, bei Kenntnis der Gerätefunktion F auch ohne
Kenntnis des Gerätes X sinnvoll zu agieren, basierend auf einem (noch
nur angenommenen, hernach festzuschreibenden) Gleichverhalten der Module
(lies: "set off" wird *immer* zum *aus*schalten benutzt, nicht mal
das und mal "set poweroff").
Ein zusätzlicher Layer schadet meines Erachtens mehr, als das er nützt. Um
für ein UI wirksam zu sein, muß er über FS20, X10 und Co. liegen. Damit
nimmt er entweder Funktionaliät oder wird unendlich komplex. (Vergleiche
einen FS20-ST mit einem X10 am12; Metadevice Schalter auf Basis am12
kastriert FS20-ST, auf Basis FS20-ST bietet es Funktionen, die am12 nicht
kennt und die demnach das Metadevice nachbilden muß.)
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.
Originally posted by: <email address deleted>
Salve,
auch wenn das Thema wohl keinen mehr wirklich interessiert, dann
vielleicht zumindest für mein Seelenheil^WVerständnis ...
Es gab jetzt mehrere Verschläge, um überhaupt etwas zu ändern.
Vielleicht wäre ein gemeinsames Bild doch sinnvoll, ich versuche
mich mal in ASCII-Art, als PNG im Attachment.
Beschreibt das folgende das Zusammenwirken der verschiedenen, vor-
handenen Ebenen in FHEM Stand heute? (Logisches und physisches Mo-
dul können in einem zusammengefaßt sein, was konzeptionell aber
eher einen Sonderfall darstellt, logisch die Abläufe nicht ver-
ändert.) Die Pfeildarstellung ist vereinfacht, natürlich kommt
auf ein "set" auch was zurück und das "get" muß fon fhem.pl in
Richtung log. Device auf den Weg gebracht werden, ...)
+----------------+
| Anwendung |
| z. B. Frontend |
+----------------+
| "xmllist" ^
v | DATA
+--------------+
| fhem.pl |
+--------------+
| "set" ^ "get"
v |
+--------------+
| log. device |
| (FS20, ...) |
+--------------+
| "write" ^
v | "read"
+--------------+
| phys. device |
| (FHZ, ...) |
+--------------+
: ^
| | (read and/or write)
v :
+-------------+
| Interfacing |
| Hardware |
+-------------+
Das ist jedenfalls meine abstrakte Vorstellung vom Zusammenspiel der
Komponenten in FHEM -- vielleicht sehe ich das auch falsch, dann kor-
rigiert mich bitte.
In den Diskussionen ging es nun darum, daß entweder die Information
über Geräte, die vom logischen Gerät kommend via xmllist und Co. in
Richtung Frontend transportiert werden, über das heutige Maß hinaus
erweitert werden oder aber, daß eine weitere Schicht eingeführt wird,
die von der Hardware weiter abstrahiert.
Korrekt soweit?
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.
Originally posted by: <email address deleted>
Hallo Kai, Hallo Ihr SoftwareDesigner
On 10 Feb., 20:55, "Kai 'wusel' Siering"
wrote:
> Salve,
>
> auch wenn das Thema wohl keinen mehr wirklich interessiert, dann
> vielleicht zumindest für mein Seelenheil^WVerständnis ...
Es ist nicht richtig, das "NichtSichtbarReagieren" mit Desinterese
gleich gesetzt wird.
Ich hatte vor Jahren das Problem, das es nicht ganz einfach war, die
geloggten Daten der S555TH in webpgm2
zu visualisieren. Bis ich ansatzweise verstanden hatte (ich hoffe ,
ich habe es verstanden) , in welcher Reihenfolge in den *.gplot files
definierte Filter durchlaufen werden, verging schon einiges an Zeit :-
(
Ich glaube, das ein sehr gutes Design einer Software perfekt angelegte
Zeit ist, im Verhältnis zu immer größerem und daraus resultierend
immer schlechter wartbarem Code.
Ich kann nur (noch) kein Perl und ich sehe, das wohl ein sehr sehr
großer Aufwand entsteht bei der Implementierung einer (meiner Meinung
nach "perfekten" weiteren Metaschicht).
Ich würde mir folgendes von dem guten Programmiergeist aus der Flasche
(wenn ich denn die drei Wünsche frei hätte) wünschen:
1)
Die diskutierte Abstraktionsebene in Richtung Frontends
2)
Multithredding
würde die Stabilität verbessern.
Nach mehrfachem "probieren" (vor ca. 1,5Jahren) von "rereadconfig" war
das Ergebnis eine kalte Wohnung und Logfileeinträge von Pearl im
(vermutlich) Millisekundentakt.
nicht falsch verstehen!!! Ich bin sehr erstaunt/begeistert über die
Stabilität/Qualität, welche hier mit Perl erreicht wird. Es ist nur
so, das wenn einem mal ein Fehler unterläuft, bleibt halt sehr
warscheinlich alles "stehen".
3)
verständlichere(Selbsterklärende) interne Variablenbezeichner in
(z.Bsp.) Modulen.
Wenn man versucht einem Code zu folgen, dessen Syntax/Grammar man
nicht kennt, so ist es doppelt schwer, wenn Variablenbezeichner
A:=
B:=
... siebzig Zeilen Später:
(eine Zeile, welche aus sieht wie ein "Fluch von Asterix auf
schwäbisch" :-), in der auch "A" und "B" vorkommt.
Vorsorglich aber noch einmal:
Alles obige bitte ausschließlich als Anregung/konstruktive Kritik :-)
verstehen!!!
Und vielen, vielen Dank für die viele Zeit, welche viele Leute in
dieses Projekt investiert haben und hoffentlich auch weiterhin bereit
sind zu investieren.
Mit "ein bisschen ScriptSprache" :-) sowas zu realisieren, ist m.e.
schon toll.
Gruss
Christian
--
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.
Originally posted by: <email address deleted>
Mahlzeit,
nur kurz, ruexelfuex wrote:
>> auch wenn das Thema wohl keinen mehr wirklich interessiert, dann
>> vielleicht zumindest für mein Seelenheil^WVerständnis ...
> Es ist nicht richtig, das "NichtSichtbarReagieren" mit Desinterese
> gleich gesetzt wird.
Ich bezog mich mehr auf die Parallelität dreier Threads zu grob
dem gleichen Thema und die vermutlich auch bei anderen Diskutan-
ten einsetzende Sättigung des Appetits daran. Es sollte bitte
nicht als "ey, Ihr Schreibfaulen da draußen, sagt auch mal was"
mißverstanden werden.
Dennoch danke auch für Deine Wortmeldung ;)
kai
P.S.: (Un-)Lustige Effekte mit rereadconfig hatte ich auch mal, ich
restarte seit dem fhem nach Änderungen komplett, just in case,
auch wenn rereadconfig aktuell bei mir problemlos funktioniert.
--
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.
Hi FHEMler,
ich möchte mich wie Christian (ruexelfuex) als leiser Mitleser auch
mal zu Wort melden und seine Ausführung weitgehend unterstützen.
Ich fahre FHEM immer noch in Version 4.1 vom 2007-08-05 und hatte
bisher kaum Zeit, auf eine neuere Version upzugraden. Mitlesen wird
auch zunhemend schwieriger, weil bei mir dann Grundlagen, eine Version
zum Mitttesten und vor allem die Zeit fehlen.
Unter dem Eindruck des "Wust" an Funktionen, die FHEM heute bietet,
und ohne gleich einen CUL einzusetzen (ist aber vorhanden, muss aber
noch geflasht werden), traue ich mich das auch gar nicht.
Umso willkommener wären/sind mir Vereinfachungen wie autocreate und
Meta-/Interface-Definitionen, die allerdings nicht die Modularität von
FHEM unterdrücken sollten.
Das meine 2 Cent zum Thema ...
Gruß,
Jürgen
--
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.
Originally posted by: <email address deleted>
Hallo Kai,
das sieht alles toll aus! Optimal wäre es natürlich, wenn sich ein
Frontend nur um die Darstellung kümmern muss und nicht auch um Interna
für alle möglichen Geräte.
Wie auch andere hier geschrieben haben, sind >95 Prozent der User mit
Standardgeräten unterwegs und haben (aktuell) keinen Bedarf für
weiterreichendes. Wenn ich deine Erfahrungsberichte hier so lese, dann
gehörst du eindeutig zu den verbliebenen 5 Prozent :-))
Sicherlich werden alle Frontends zukünftige Entwicklungen gerne
integrieren. Wenn der bisherige FHEM-Code zu mehr als 50 Prozent
angefasst werden muss, dann dauert das. Und vor allem: wer macht das?
Da ist eindeutig die Community gefragt, aber aus meiner Sicht
sicherlich nicht Rudi.
Also, es bleibt spannend hier ;-)
Viele 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.
Originally posted by: <email address deleted>
'n Abend,
Martin Haas wrote:
> das sieht alles toll aus! Optimal wäre es natürlich, wenn sich ein
> Frontend nur um die Darstellung kümmern muss und nicht auch um Interna
> für alle möglichen Geräte.
Jedenfalls würde *ich* das wollen, wenn ich mit FHEM mehr machte als nur
define at_TV_On notify 47LG7000:power:.on { fhem("set TV_LED on") if($attr{TV_LED}{EsIstDunkel})}
> Wie auch andere hier geschrieben haben, sind >95 Prozent der User mit
> Standardgeräten unterwegs und haben (aktuell) keinen Bedarf für
> weiterreichendes. Wenn ich deine Erfahrungsberichte hier so lese, dann
> gehörst du eindeutig zu den verbliebenen 5 Prozent :-))
Getting used to that ;) Lt. lokalem Archiv bin ich nun seit rd. 1 Jahr
"dabei"; viele Themen wurden diskutiert, wenige Module kamen hinzu. Alles
ganz normal. Da ich bislang auf fhem.cfg-Ebene "arbeite", ist mir die
Frontendgeschichte recht egal gewesen; aber wenn FHEM mehr machen soll
als die Terrariumslampen schalten und gelegentlich mal die LED-Zeile
hinterm TV an/aus, dann brauche ich ein WAF-taugliches Frontend -- und
habe dann ein Problem mit dem Status Quo.
> Sicherlich werden alle Frontends zukünftige Entwicklungen gerne
> integrieren. Wenn der bisherige FHEM-Code zu mehr als 50 Prozent
> angefasst werden muss, dann dauert das. Und vor allem: wer macht das?
> Da ist eindeutig die Community gefragt, aber aus meiner Sicht
> sicherlich nicht Rudi.
Hat letzteres wer behauptet? $jemand wird es machen, das weiß ich aus ge-
wöhnlich gut unterrichteter Quelle ;) -- aber die Frage wäre erst einmal:
was?
Ich habe das Problem bei der Wurzel gepackt und die Abhängigkeit von Spe-
zialkenntnis reduziert --- das wäre eine schnelle Lösung gewesen (statt
dutzenden, Code duplizierender Module eine Handvoll mit, wie heute, defi-
nierten Möglichkeiten; nur kümmerte sich jenes Modul um die Unterschiede
bei Dimmen von X10 und FS20, nicht das Frontend); das hat, wie ich auch
schon bei der Umsetzung feststellte, ein paar Haken an anderer Stelle und
ich bin wenig überrascht, daß die "FHEM-Aktivposten" durch diesen brennen-
den Reifen nicht springen möchten. Denke, die Diskussion war dennoch sinn-
voll; unter anderem brachte sie neue Vorschläge ;)
Der Meta-Layer, wie ich ihn verstehe, hat allerdings identische Probleme:
massives Codeanfassen und latente Funktionsreduktion oder Aufgabe einer
sauberen Trennung der Module untereinander als Alternative. (Und, ehrlich
gesagt, verstehen, wie Olafs Aussagen im EnvSens-Thread zu seinem Meta-
Layer-Vorschlag passen -- außer "gar nicht"--, tue ich nicht.)
Der "Interfaces"-Vorschlag Boris' führt Zusatzinformationen ein, die ein
"hardwarekenntnisunabhängiges Frontend" ermöglichen könnten. Aber auch da
müßte eine Definition festgezurrt werden; derlei gestaltet sich schwierig,
das Interesse daran schein nicht existent.
Oder man läßt einfach alles so, wie es für 95% der Nutzer funktioniert,
denn der Modulzuwachs ist ja nach wie vor überschaubar und i. d. R. auch
im Frontend durch Blockkopieraktionen und Search&Replace über die Namen
leicht zu erschlagen (wie im Backend, d. h. dem Modul, also ;)). Ist der
arbeitsärmste Ansatz, und man kann ja auch von Fliegen lernen ;)
Hay varias posibilidades ... oder so.
> Also, es bleibt spannend hier ;-)
Jepp. Und in der Zwischenzeit tarne ich meinen Kram z. B. als FS20, X10
oder CUL_WS als kleinstem gemeinsamen Nenner, damit ist für mich wie für
jeden, der 5%-Hardware und ein beliebiges Frontend nutzen will, die Kuh
auch vom Eis. Technisch funktioniert es über die Abstraktionsebene IODev
hervorragend, mangels Hooks für sowas bleibt es leider eine eklige, aber
eben notwendige, Krücke. Und da ich nur meine Module anfasse, stört's
niemanden und alle sind zufrieden -- Problem vertagt, aber Tag gerettet ;)
Ich denke weiterhin, daß FHEM einer Renovierung des Interfacings bedarf,
will man generisch "Hausautomatisation" adressieren und nicht nur FS20
und X10 -- HS485 z. B. klingt ja spannend, aber wenn's wieder keine Vi-
sualisierung im Frontend gibt (außer, ich verbrate da für mich zusätz-
lich noch Wochen dran), ist der Spaß schnell dahin. Aber egal, ich kann
das jetzt ganz entspannd abwarten, und die Nutzer "meiner" 5%-Hardware
auch ;)
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.
HI all,
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.
Was stelle ich mir in so einem abstrakten Layer vor, und warum und
wie ?
Also: Zur Vorstellung:
Ich hätte gerne Module, die Kategorien von Devices darstellen, aber
dynamisch verdrahtbar sind. Sowas wie:
Sensors (die man dann z.B. pro Raum hat [WZ-Sensors] und alle Sensoren
eines Wohnzimmers beinhalten);
Der Sinn der Kategorie: Diese "Klasse" unterstützt nur GET-Methoden,
wie auch immer wir die Dinger dann nennen.
Dann eine Kategorie: Dimmer, Switch, ....
Diese kann man dann zu noch höheren Meta-Devices, wie Room-Control
(beinhaltet Sensors und Aktuators) wieder neu verdrahten.
So, wer macht, dies und warum, und wie ?
Also, in meiner Vorstellung macht das der User, der auch die FHEM.CFG
bastelt.
Warum macht er das ? Aus mehreren Gründen:
1) Weil er alle Sensoren (X10, FS20, HS..., etc) eines Raumes komplett
abfragen will und eine Standard-Methode dazu verwenden will
2) Weil Frontends dadurch nur diese Kategorie kennen müssen, und nicht
die verschiednen Basis-Module
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.
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 ;)
Wie erkennt nun das höhere Modul die richtige Schittstelle:
Es kann den Modul-Typ auslesen, da es ja die Instanz per Namen
mitgeteilt bekommen hat.
Zu jedem Modul hätte ich gern eine "Header-Datei" oder laßt sie uns
Interface-Datei nennen, die z.B. per IDL (Corba) angibt, wie die
Funktionen heißen und welche Parameter+Typen sie hat.
Ich spendiere dann einen IDL-Parser, den wir in die abstrakten Module
legen, so dass diese die verschiedenen Syntax-Auflösungen für z.B. Get-
Temp pro Modul macht.
Dadurch kann ein Sensor-Modul alle Get(s), wie auch immer diese
syntaktisch aussehen, pro unterem Modul aufrufen, bzw. sich per Notify
dort registrieren.
Nach oben liefert Sensors dann eine gemeinsame Sicht auf alle
beteiligten Sensordaten ab, und das über eine Funktion. (Hier sind
dann die Modul-Kategorie-Designer gefragt).
Was ist der Vorteil:
1) Falls es doch Basismodule gibt, die sich nicht einfach IDL-Parsen
lassen, müssen nur die abstrakten Module nachkompiliert werden, und
nicht die Front-Ends.
2) Wenn neue Basis-Module dazukommen, müssen nur die abstrakten Module
die IDLs nachparsen, und kein Frontend
3) Die IDLs müssen nur beim FHEM-Server liegen, wie auch die
abstrakten Module, und nicht beim Front-End Server, der evtl. auf
anderen Maschinen residiert.
4) Die unteren Module werden nicht angefaßt, lediglich eine IDL dazu
generiert. ( und das sogar automatisch, wenn gewünscht).
Was man braucht:
EInen Satz an Kategorien wie:
Sensor, Dimmer, Switch, Heating ..... mit Standard-Befehlen, die
einfach und unkompliziert sind, und spezifische Dinge verbergen.
Darüber hinaus, wenn man mag, noch höhere Module, die dann ein higher-
control erlauben, wie Room-Control = Sensor + Heating ... oder so
Diese Module kann man dann später sogar mit einem grafischen Editor
verdrahten, so dass die Zuprdnung: Abstraktes Modul <:-> Basis-Module
einfach konfigurierbar wird.
Soviel zu meinen Ideen. Ich habe dieses Konzept einmal bereits für Web-
Services und Telco-Dienste realisiert, und recht gute Erfahrungen
damit gemacht. Es gibt dazu sogar eine JAVA-Workbench für grafische
Komposition mit Logik.
Und nun auf zu Kommentaren ;)
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.
Am Freitag 12 Februar 2010 schrieb Kai 'wusel' Siering:
> [...]
> > Sicherlich werden alle Frontends zukünftige Entwicklungen gerne
> > integrieren. Wenn der bisherige FHEM-Code zu mehr als 50 Prozent
> > angefasst werden muss, dann dauert das. Und vor allem: wer macht das?
> > Da ist eindeutig die Community gefragt, aber aus meiner Sicht
> > sicherlich nicht Rudi.
>
> Hat letzteres wer behauptet? $jemand wird es machen, das weiß ich aus ge-
> wöhnlich gut unterrichteter Quelle ;) -- aber die Frage wäre erst einmal:
> was?
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
bedauere ich es auch sehr, das rudi sich zu den ganzen threads (meta,
internals, etc.) bisher eher im hintergrund hält.
> [...]
> Ich denke weiterhin, daß FHEM einer Renovierung des Interfacings bedarf,
> will man generisch "Hausautomatisation" adressieren und nicht nur FS20
> und X10 -- HS485 z. B. klingt ja spannend, aber wenn's wieder keine Vi-
> sualisierung im Frontend gibt (außer, ich verbrate da für mich zusätz-
> lich noch Wochen dran), ist der Spaß schnell dahin. Aber egal, ich kann
> das jetzt ganz entspannd abwarten, und die Nutzer "meiner" 5%-Hardware
> auch ;)
ACK!
gruss 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.
Am Freitag 12 Februar 2010 schrieb Olaf:
> [...]
> Soviel zu meinen Ideen. Ich habe dieses Konzept einmal bereits für Web-
> Services und Telco-Dienste realisiert, und recht gute Erfahrungen
> damit gemacht. Es gibt dazu sogar eine JAVA-Workbench für grafische
> Komposition mit Logik.
ich finde den gedanken ganz interessant.. bis auf das mit java :-) just
kidding..
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..
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
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.
gruß 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.
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.
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.
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.
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.
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.