[FHZ] INTERFACES proof of concept / uniform dimmer interface

[Dr. Boris Neubert]

                                             

Hallo,

zum einen bat Martin darum, bei X10-Dimmern auch dimXX%-Befehle
einzuführen, um im User Interface X10-Dimmer und FS20-Dimmer
gleichermaßen ansprechen zu können. Ich habe stattdessen einen dimto
XX-Befehl eingeführt, um der Tatsache gerecht zu werden, daß
unterschiedliche Dimmertypen unterschiedliche Helligkeitsniveaus
zwischen ganz dunkel und ganz hell können (FS20 einerseits und X10
andererseits, wobei die Niveaus bei X10 vermutlich auch noch vom
Geräterhersteller abhängen).

Andererseits hatten wir ja die Interfaces-Diskussion. Als Proof of
Concept habe ich das X10-Modul so gestaltet, daß X10-Geräte entweder das
Interface "switch" oder "dimmer" implementieren. Beschreibung siehe
unten. Bitte faßt das ganze als Vorschlag auf, wie Interfaces
ausgestaltet sein könnten.

Wenn es sich herausstellt, daß die hier vorgestellte Implementierung in
X10 etwas taugt, würde ich die FS20-Geräte analog ergänzen
(dimto-Befehl, Interfaces).

Das Modul ist nicht im CVS sondern angehängt. Ich würde mich
insbesondere über Feedback von den UI-Programmieren freuen.

Viele Grüße,
Boris




USING INTERFACES

Any device that supports interfaces has an internal named INTERFACES.

Perl code:     $hash->{INTERFACES}= "dimmer";
xmllist:          
list:                Internals:
                           INTERFACES dimmer

Multiple interfaces are separated by colons, e.g. "temperature:humidity".

Interfaces support inheritance. A derived interface supports all
readings and setters of its ancestors.



INTERFACE DEFINTIONS

*interface*

The common ancestor of all interfaces.

Readings:
    state    string, function and argument of last command

Setter:
    none


*switch* (inherits from interface)

Any device that can be switched on and off implements this interface.

Readings:
    onoff    integer, 0..1, the current state of the switch (off or on)

Setter:
    on        Turns device on.
    off        Turns device off.


*dimmer* (inherits from switch)

Any device that change the brightness level, e.g. a lamp dimmer.

Readings:
    dimmer    float, 0.0..100.0,  indicates the brightness level in percent.

Setter:
    dimto x        changes the brightness level to be x%, x float,
0.0..100.0
    dimup x       increases the brightness level by x%, x float, 0.0..100.0
    dimdown x   decreases the brightness level by x%, x float, 0.0..100.0
   
Notes:
(1) switch being an ancestor of dimmer, it is assumed that a dimmer
always can be switched on and off.
(2) The user cannot assume that off and on are equivalent to brightness
levels of 0% or 100% respectively. For example, for FS20 dimmers,
brightness level and on/off state are independent settings.



--
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>

On 13 Feb., 20:06, "Dr. Boris Neubert" wrote:
> Wenn es sich herausstellt, daß die hier vorgestellte Implementierung in
> X10 etwas taugt, würde ich die FS20-Geräte analog ergänzen
> (dimto-Befehl, Interfaces).
>
> Das Modul ist nicht im CVS sondern angehängt. Ich würde mich
> insbesondere über Feedback von den UI-Programmieren freuen.


Die FS20-Dimmer werden auch in den Frontends unterstützt. Insofern
sollte es für das Frontend nicht schwer sein, sowas wie eine neue
Geräteklasse INTERFACES zu implementieren.
Das 10_X10.pm habe ich zwar geladen, aber aus Mangel an X10-Geräten
passiert natürlich nichts

Für mich wünschenswert wäre, wenn in der xmllist einfach sowas wie ein
neues Device INTERFACE analog zu z.B. FS20 auftauchen würde:
**********************

                       
                       
                       
                       
                       
                       
                       
                       
                       
                        measured="2010-02-12 06:51:16"/>
               
***************************************

Evtl. habe ich das alles allerdings noch immer nicht richtig
verstanden, also einfach mal ausprobierbare Lösungen anbieten.
Überhaupt sehe ich das Frontend als das kleinste Problem an. Solange
da genormte Daten eingelesen werden können --ob nun für viele
unterschiedliche Geräteklassen oder eines für das "INTERFACE"-- sollte
das alles machbar sein.

Der schwierigste Part ist sicher, so ein Perl-Modul zu bauen, das eben
auswertbare Daten anbieten kann.

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.

[Dr. Boris Neubert]

                                             

Am 14.02.2010 10:25, schrieb Martin Haas:
> On 13 Feb., 20:06, "Dr. Boris Neubert" wrote:
> Das Modul ist nicht im CVS sondern angehängt. Ich würde mich
> insbesondere über Feedback von den UI-Programmieren freuen.
>  
>
> Die FS20-Dimmer werden auch in den Frontends unterstützt. Insofern
> sollte es für das Frontend nicht schwer sein, sowas wie eine neue
> Geräteklasse INTERFACES zu implementieren.
>
> Für mich wünschenswert wäre, wenn in der xmllist einfach sowas wie ein
> neues Device INTERFACE analog zu z.B. FS20 auftauchen würde:
> **********************
>  
bei mir sieht ein X10-Dimmer in der xmllist so aus:

                sets="dimdown,dimto,dimup,off,on,on-for-timer,on-till" attrs="room
comment alias IODev do_not_notify:1,0 dummy:1,0 showtime:1,0
model:lm12,lm15,am12,tm13 loglevel:0,1,2,3,4,5,6">
                       
                       
                       
                       
                       
                       
                       
                       
                       
                       
                       
                       
                       
                        measured="2010-02-14 11:25:21"/>
                        measured="2010-02-14 11:25:21"/>
                        measured="2010-02-14 11:25:21"/>
               

Ich hatte mir vorgestellt, daß das Frontend nicht mehr auswertet, daß es
sich bei einem Eintrag in der xmllist um ein X10-Gerät (FS20-Gerät,
KS300-Gerät, ...) handelt, sondern für jeden Eintrag in der xmllist nur
prüft, was im INT "INTERFACES" steht. Erkennt das Frontend, daß das
Interface "dimmer" unterstützt wird, weiß es aufgrund der
standardisierten Definition, daß es bei "STATE" "dimmer" und "onoff"
gibt mit definierten Typen und Bedeutungen sowie die Setter
dimdown,dimto,dimup,off,on.

Wenn ein Gerät beispielsweise die INTERFACES "temperature" und
"humidity" unterstützt (wie S555TH oder HMS100TF oder KS300), sucht das
Frontend die für ein derartiges Gerät beste Darstellungsweise, ohne zu
wissen, ob es sich um Temperatur-Feuchte-Sensoren oder Empfänger zu
einer Wetterstation handelt. Eine KS300-Wetterstation würde zusätzlich
noch die Interfaces "wind" und "rain" unterstützen. Frontends, die mit
diesen Interfaces nichts anfangen können, würden dann die KS300 wie die
vorgenannten Temperatur-Feuchte-Sensoren darstellen.

Die Kunst auf Seite der Modulentwickler besteht darin, sich auf
sinnvolle Interface-Definitionen zu verständigen. Aus Programmiersicht
ist das ganze dann äußerst simpel - man braucht keine neuen Module,
keine neuen Meta-Devices, und der Programmieraufwand ist minimal (eine
Zeile Code für $hash->{INTERFACES}="..." und die Harmonisierung der
Readings und Setter. Der Nettoaufwand für X10 lag bei mir bei einer
viertel Stunde plus die Zeit für die Neuentwicklung der Funktionalität
hinter dimto.

Viele Grüße,
Boris

--
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>

On 14 Feb., 11:44, "Dr. Boris Neubert" wrote:
> Ich hatte mir vorgestellt, daß das Frontend nicht mehr auswertet, daß es
> sich bei einem Eintrag in der xmllist um ein X10-Gerät (FS20-Gerät,
> KS300-Gerät, ...) handelt, sondern für jeden Eintrag in der xmllist nur
> prüft, was im INT "INTERFACES" steht. Erkennt das Frontend, daß das
> Interface "dimmer" unterstützt wird, weiß es aufgrund der
> standardisierten Definition, daß es bei "STATE" "dimmer" und "onoff"
> gibt mit definierten Typen und Bedeutungen sowie die Setter
> dimdown,dimto,dimup,off,on.

Das hört sich prima an. Schalten der Akteure ist zumindest bei pgm3
allerdings mehr eine Nebensache.

> Wenn ein Gerät beispielsweise die INTERFACES "temperature" und
> "humidity" unterstützt (wie S555TH oder HMS100TF oder KS300), sucht das
> Frontend die für ein derartiges Gerät beste Darstellungsweise, ohne zu
> wissen, ob es sich um Temperatur-Feuchte-Sensoren oder Empfänger zu
> einer Wetterstation handelt. Eine KS300-Wetterstation würde zusätzlich
> noch die Interfaces "wind" und "rain" unterstützen. Frontends, die mit
> diesen Interfaces nichts anfangen können, würden dann die KS300 wie die
> vorgenannten Temperatur-Feuchte-Sensoren darstellen.

Das Anzeigen de Logfiles als PHP-und Gnuplot-Grafik erfordert den
meisten Aufwand und das meiste Spezialwissen über die Geräte.
Wenn es jetzt passend zur obigen Definition noch ein standardisiertes
Logformat gäbe, dann wäre das für mich auf den ersten Blick ein
pragmatischer und einfach umzusetzender Weg.


> Die Kunst auf Seite der Modulentwickler besteht darin, sich auf
> sinnvolle Interface-Definitionen zu verständigen. Aus Programmiersicht
> ist das ganze dann äußerst simpel - man braucht keine neuen Module,

Das hört sich wirklich so an, als ob man nicht 50% von FHEM neu
schreiben müsste

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.

[Dr. Boris Neubert]

                                             

Am 14.02.2010 12:28, schrieb Martin Haas:
>
> Das Anzeigen de Logfiles als PHP-und Gnuplot-Grafik erfordert den
> meisten Aufwand und das meiste Spezialwissen über die Geräte.
> Wenn es jetzt passend zur obigen Definition noch ein standardisiertes
> Logformat gäbe, dann wäre das für mich auf den ersten Blick ein
> pragmatischer und einfach umzusetzender Weg.
>
>  
Wie wäre es, wenn alle Readings in der Form

timestamp maneofdevice reading1: value1 reading2: value2 ...

in den Logfile geschrieben würden? Wobei reading1 usw. die Readings
gemäß Interface-Spezifikation sind? Eine Reihenfolge wäre nicht garantiert.

Beispiele:

1. Interface: dimmer (für einen X10-Ferndimmer)
2009-11-27_03:19:02 3.dz.birne onoff: 1 dimmer: 82

2. Interface: temperature:humidity (für einen HMS100TF):
2009-11-27_03:19:02 0.kr.tf temperature: 15 humidity: 65
(ohne Celsius und %, wenn man es so in der Spezifikation vereinbart)

3. Interface: temperature:humidity (für einen S555TH):
2009-11-27_03:19:02 1.eg.tf humidity: 68 temperature: 17
(die Reihenfolge ist im Log nicht festgelegt)

4. Interface: temperature:humidity wind rain (für eine KS300):
2009-11-27_03:19:02 e.ws wind: 0.0 rain: 2132.2 humidity: 68 temperature: 17

Viele Grüße,
Boris

--
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.

[rudolfkoenig]

                                                   

> Wie wäre es, wenn alle Readings in der Form
>
> timestamp maneofdevice reading1: value1 reading2: value2 ...
>
> in den Logfile geschrieben würden? Wobei reading1 usw. die Readings
> gemäß Interface-Spezifikation sind? Eine Reihenfolge wäre nicht garantiert.

Waer schlecht Klar kann man das auch parsen, aber es ist aufwendiger (sowohl
von Programmieren als auch vom CPU).  Nach etwas nachdenken sehe ich keine
wirklichen Vorteile zu dem aktuellen Zustand (abgesehen davon dass es fuer
Menschen etwas lesbarer ist), der Benutzer muss dem Plotter-Programm weiterhin
manuell mitteilen, fuer welchen Plot welche Teile der Datei extrahieren soll.

--
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.

[Dr. Boris Neubert]

                                             

Rudolf Koenig schrieb:
>> Wie wäre es, wenn alle Readings in der Form
>>
>> timestamp maneofdevice reading1: value1 reading2: value2 ...
>>
>> in den Logfile geschrieben würden? Wobei reading1 usw. die Readings
>> gemäß Interface-Spezifikation sind? Eine Reihenfolge wäre nicht garantiert.
>>    
>
> Waer schlecht Klar kann man das auch parsen, aber es ist aufwendiger (sowohl
> von Programmieren als auch vom CPU).  Nach etwas nachdenken sehe ich keine
>  
ich bin verwirrt. Die Logs sehen doch jetzt schon fast alle so aus, wie
in der obigen Musterzeile beschrieben, mit der Ausnahme, dass die
Bezeichnungen fuer die readings nicht standardisiert sind und die values
ggf. mit Einheiten verziert sind.
> wirklichen Vorteile zu dem aktuellen Zustand (abgesehen davon dass es fuer
> Menschen etwas lesbarer ist), der Benutzer muss dem Plotter-Programm weiterhin
> manuell mitteilen, fuer welchen Plot welche Teile der Datei extrahieren soll.
>  
Waere das nicht durch die Standardisierung aus der Welt geschafft?
Beispiel: das Frontend erkennt am Internal
"temperature:humidity:wind:rain", dass das Geraet die Interfactes
"temperature" und "humidity" unterstuetzt, waehrend es mit "wind" und
"rain" nichts anfangen kann. Es zieht sich dann die Vorlage fuer den
Temperatur-Feuchte-Plot und erkennt an der ersten Zeile des Logs
("12.12.2010_12:12:12 e.ext.ws rain: 823.2 temperature: 14.3 wind: 0.0
humidity: 20.2 IR: 0"), dass die Temperatur aus Spalte 6 und die Feuchte
aus Spalte 10 gezogen werden muss. Zur Erleichterung koennten die
Spalten sogar in einem Internal auslesbar sein. Altternativ koennte
FileLog um einen Getter erweitert werden, mit dem sich das Frontend die
angeforderten Zeitreihen abholen kann, z.B. get e.ext.ws.log -20d 0d
temperature humidity fuer die Temperatur und Feuchte der letzten 21 Tage
inklusive heute.

Jedenfalls halte ich die von Martin vorgeschlagene Standardisierung fuer
das Log fuer eine sinnvolle Sache. Gerade ist mir naemlich aufgefallen,
dass meine S555TH-Geraete keineswegs ploetzlich spinnen sondern dass das
letzte fhem-Upgrade dafuer gesorgt hat, dass die zugehoerigen Logs jetzt
mit extra Zeilen vollgerotzt werden, die da bisher nicht drin waren und
die Generierung der Plots stoeren.

Viele Gruesse,
Boris

--
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>

On 15.02.10 21:30, "Dr. Boris Neubert" wrote:

>> wirklichen Vorteile zu dem aktuellen Zustand (abgesehen davon dass es fuer
>> Menschen etwas lesbarer ist), der Benutzer muss dem Plotter-Programm
>> weiterhin
>> manuell mitteilen, fuer welchen Plot welche Teile der Datei extrahieren soll.
>>  
> Waere das nicht durch die Standardisierung aus der Welt geschafft?
> Beispiel: das Frontend erkennt am Internal
> "temperature:humidity:wind:rain", dass das Geraet die Interfactes
> "temperature" und "humidity" unterstuetzt, waehrend es mit "wind" und
> "rain" nichts anfangen kann.

Ich hatte mal angeregt, dass die Devices sog. 'Properties' unterstützen
(oder wie man die auch immer nenne mag). Fragt man ein Device nach seinen
Properties, könnte es einfach z.B. 'Humidity, Temperatur' rückmelden.

z.B.
myGettableProperties = supportedProperties('get');

respektive setzbare Properties:

mySettableProperties = supportedProperties('set');

Diese Properties verändern sich ja für ein Device nicht so häufig

Back- und Frontends unterstützen alle definierten Properties. D.h.
neue/andere/ähnliche Geräte werden sofort erkannt und korrekt behandelt.

> Es zieht sich dann die Vorlage fuer den
> Temperatur-Feuchte-Plot und erkennt an der ersten Zeile des Logs
> ("12.12.2010_12:12:12 e.ext.ws rain: 823.2 temperature: 14.3 wind: 0.0
> humidity: 20.2 IR: 0"), dass die Temperatur aus Spalte 6 und die Feuchte
> aus Spalte 10 gezogen werden muss. Zur Erleichterung koennten die
> Spalten sogar in einem Internal auslesbar sein. Altternativ koennte
> FileLog um einen Getter erweitert werden, mit dem sich das Frontend die
> angeforderten Zeitreihen abholen kann, z.B. get e.ext.ws.log -20d 0d
> temperature humidity fuer die Temperatur und Feuchte der letzten 21 Tage
> inklusive heute.

Warum liegen die Timestamps eigentlich in so einem merkwürdigen Format vor?
Hat das was mit Perl zu tun? Wäre es nicht sinnvoller, wenn man bei der
Gelegenheit gleich Standards (z.B: ISO DateTime-Notation) verwenden würde -
oder gar einfach Unix-Timestamps?

a.



--
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.

[rudolfkoenig]

                                                   

> ich bin verwirrt. Die Logs sehen doch jetzt schon fast alle so aus,
> wie in der obigen Musterzeile beschrieben, mit der Ausnahme, dass
> die Bezeichnungen fuer die readings nicht standardisiert sind und
> die values ggf. mit Einheiten verziert sind.

Ich habe ein Problem damit, dass die eizelnen Spalten nicht mehr in definierten
Reihenfolge kommen, dann muss der Plotter naemlich in jede Zeile und jede
Spalte einen zusaetzlichen hash-lookup durchfuehren.


> Altternativ koennte FileLog um einen Getter erweitert werden, mit
[...]

Das gibt es schon seit dem es gnuplot-scroll gibt.


> Gerade ist mir naemlich aufgefallen, dass meine S555TH-Geraete keineswegs
> ploetzlich spinnen sondern dass das letzte fhem-Upgrade dafuer gesorgt hat,
> dass die zugehoerigen Logs jetzt mit extra Zeilen vollgerotzt werden, die da
> bisher nicht drin waren und die Generierung der Plots stoeren.

Ja, ich habe es auch mit erstaunen festgestellt, dass CUL_WS neuerdings
zusaetzliche notifies  generiert, um alles nochmal einzeln im Klartext zu
versenden. Ich fuerchte gegen solche "Angriffe" ist auch eine standardisierte
Version nicht gefeit, bzw. wenn die plot-Definition genauer ist, dann wird es
in einem nicht-standardisierten Welt genausogut funktionieren.


Was die Standardisierungsdiskussion der einzelnen Module betrifft, bin ich
nicht sicher, ob Interfaces der richtige Weg sind.

- man kann nicht alle Module ueber einen Kamm scheren (oder ueber mehrere
  Kaemme). Siehe der Plugwise oder FHT. Ja klar, wenn man die kennt, kann man
  ein Interface so bauen, oder aendern, dass sie es auch einschliesst, aber es
  geht ja darum, dass die Schnittstellen nicht geaendert werden.

- Ich finde es ist nicht so schlimm, wenn fuer was ganz spezielles/wichtiges
  (wie ein Slider fuers dimmen) das Frontend angefasst werden muss, den Rest
  kann das Frontend generisch anbieten, so dass auch neue Geraete
  funktionieren.

- fuer die Frontends wird es nicht einfacher, wenn die statt eine Menge von
  Befehlen pro Geraet ploetzlich mehrere bedienen sollen: warum sind zwei
  Listen von moeglichen get/set besser als eine wie z.Zt.? Nein, ich will nicht
  jedes Interface im Frontend explizit "ausprogrammieren".  Und was sollte man
  als erstes/wichtigeres darstellen, wenn mehrere Interfaces da sind?
  Womoeglich das dem Benutzer konfigurierbar ueberlassen?

- eine Interface-Ebene zusaetzlich zum Modulen ist fuer den Neuanfaenger
  schwieriger: manches funktioniert durchs interface, manches durch Modul.

- der Aufwand um alles anzupassen (backend/frontends/doku/beispiele) ist fuer
  mich im Moment viel hoeher, als gelegentliche Anpassungen fuer neuere
  Geraete.  Wobei die Anpassung auch mit Interfaces wahrscheinlich erfolgen
  muss, evtl. seltener.

Ich habe Angst, dass mit dem Interfaces angefangen wird, es funktioniert nicht
perfekt, und es bleibt bei einem halbherzigen Versuch. Weiterhin versuche ich
sogut es geht in fhem das Prinzip KISS zu behalten...

Ich faende es Klasse, wenn wir zum Anfang fuer die einzelnen Module eine
gemeinsame Nomenklatur der READINGS finden wuerden, aber selbst das ist nicht
trivial, siehe temperatur beim FHT vs.  S300TH vs. WS3600. Wenn das dann immer
noch nicht reicht, dann koennen wir ueber Interfaces oder vergleichbares
nachdenken.

--
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>

Rudolf Koenig wrote:

>> Gerade ist mir naemlich aufgefallen, dass meine S555TH-Geraete keineswegs
>> ploetzlich spinnen sondern dass das letzte fhem-Upgrade dafuer gesorgt hat,
>> dass die zugehoerigen Logs jetzt mit extra Zeilen vollgerotzt werden, die da
>> bisher nicht drin waren und die Generierung der Plots stoeren.
>
> Ja, ich habe es auch mit erstaunen festgestellt, dass CUL_WS neuerdings

Gut, das Thema hatten wir grade in "FileLog/weblink hints case-insensitive?", ...

> zusaetzliche notifies  generiert, um alles nochmal einzeln im Klartext zu

... dazu gab's auch eine Info an die Liste IIRC und ...

> versenden. Ich fuerchte gegen solche "Angriffe" ist auch eine standardisierte

... wenn es ein "Angriff" war, dann einer, der mangelnder (ins Auge sprin-
gender) Dokumentation, was wie notified werden "darf" und was nicht geschul-
det ist.

> Version nicht gefeit, bzw. wenn die plot-Definition genauer ist, dann wird es
> in einem nicht-standardisierten Welt genausogut funktionieren.

Yepp, siehe mein "_TH" vs. "T"- & "H"-Pattern ... Also eher kein Fall von
"Angriff", sondern vom guten alten "Garbage in, Garbage out"

> Was die Standardisierungsdiskussion der einzelnen Module betrifft, bin ich
> nicht sicher, ob Interfaces der richtige Weg sind.

Ich sehe nach wie vor zwei Diskussionen; einmal "Standardisierung" (aka "-3.1"
vs. "-3.1 (Celsius)", {READINGS}{T} vs. {READINGS}[temperature}) und einmal
"Abstraktion", d. h. die Zusatzinformation, daß Device "FooBar" Ergebnisse wie
andere Devices der Gruppe "G" liefert.

> - man kann nicht alle Module ueber einen Kamm scheren (oder ueber mehrere
>   Kaemme). Siehe der Plugwise oder FHT. Ja klar, wenn man die kennt, kann man
>   ein Interface so bauen, oder aendern, dass sie es auch einschliesst, aber es
>   geht ja darum, dass die Schnittstellen nicht geaendert werden.

Huh? Plugwise kann ich nicht auf EM vergewaltigen; sehr wohl kann ich aber
über "Interfaces" signalisieren, daß es ein "Energysensor" ist und ggf. IST-
Werte in kWh oder $whatever liefern. Genauso kann ich dann über das "Interface"
"Switch" signalisieren, daß man ein Plugwise-Device ein- und ausschalten kann.

Und dann müßte ich nicht fake-FS20-Geräte für ein Plugwisegerät erzeugen, damit
ein x-beliebiges Frontend dies zumindest schalten, wenn es auch nicht den Ener-
giebedarf auslesen, kann.

> - Ich finde es ist nicht so schlimm, wenn fuer was ganz spezielles/wichtiges
>   (wie ein Slider fuers dimmen) das Frontend angefasst werden muss, den Rest
>   kann das Frontend generisch anbieten, so dass auch neue Geraete
>   funktionieren.

Wenn das geht, zeige bitte am Beispiel meines Plugwise-Moduls sowie meines
SIS_PMS, wie.

> - eine Interface-Ebene zusaetzlich zum Modulen ist fuer den Neuanfaenger
>   schwieriger: manches funktioniert durchs interface, manches durch Modul.

Hinfällig, da "Interfaces" keine Ebene darstellt. Es ist eine Zusatzinforma-
tion, die das Modul dem Frontend an die Hand gibt, von gleicher Sinnhaftig-
keit wie die schon existierende Information des Devicetyps, anhand das Front-
end zwangsläufig auf das Modul getrimmt wird.

> - der Aufwand um alles anzupassen (backend/frontends/doku/beispiele) ist fuer
>   mich im Moment viel hoeher, als gelegentliche Anpassungen fuer neuere
>   Geraete.  Wobei die Anpassung auch mit Interfaces wahrscheinlich erfolgen
>   muss, evtl. seltener.

Da "Interfaces", im worst case stumpf über READINGS ausgeführt, vollkommen
transparent funktionierte, kann ich diese Vorbehalte nicht nachvollziehen.
Da neue Geräte derzeit in bestehenden Frontends schlicht und ergreifend *nicht*
*richtig* *nutzbar* sind, sehe ich den einmaligen Aufwand für die Einführung
von "Interfaces" (nach Boris' Definition) als minimal, verglichen mit dem
(potentiellen) Nutzen.

> Ich habe Angst, dass mit dem Interfaces angefangen wird, es funktioniert nicht
> perfekt, und es bleibt bei einem halbherzigen Versuch. Weiterhin versuche ich
> sogut es geht in fhem das Prinzip KISS zu behalten...

Da, wo KISS zur Behinderung wird, sollte man über die Definition des "simple"
nachdenken, meine ich. Meta-Layer, da sehe ich "simple" in latenter Gefahr;
bei der Selbstauszeichnung eines Devices, zu einer vordefinierten funktionalen
Gruppe zu gehören, sehe ich KISS nicht bedroht. Niemand muß es nutzen, wenn
er/sie/es lieber jedes Bit kennen möchte; aber man kann es nutzen, ohne die erst-
genannte Gruppe zu beeinflussen.

> Ich faende es Klasse, wenn wir zum Anfang fuer die einzelnen Module eine
> gemeinsame Nomenklatur der READINGS finden wuerden, aber selbst das ist nicht
> trivial, siehe temperatur beim FHT vs.  S300TH vs. WS3600. Wenn das dann immer
> noch nicht reicht, dann koennen wir ueber Interfaces oder vergleichbares
> nachdenken.

Im Zuge von EnvSens wurde aus dem einen Gerät WS3600 gut zwei Handvoll Geräte
bekannter Funktionalitäten: 4 Temperatursensoren (Innen, Außen, Außen (ge-
fühlt aka Wind Chill), Außen (Taupunkt aka Dew Point); 2x Luftfeuchte (innen,
außen), Luftdruck, Regen, Wind, ... Das paßt deutlich besser, sei es zur
Graphendarstellung, sei es für's Triggering.
         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.

[Martin Fischer]

auf das vorher geschriebene möchte ich an dieser stelle erstmal nicht
eingehen. nicht aus desinteresse, sondern weil ich eine bestimmte passage von
rudi aufgreifen möchte:

Am Montag 15 Februar 2010 schrieb Rudolf Koenig:
> [...]
> Ich faende es Klasse, wenn wir zum Anfang fuer die einzelnen Module eine
> gemeinsame Nomenklatur der READINGS finden wuerden, aber selbst das ist
> nicht trivial, siehe temperatur beim FHT vs.  S300TH vs. WS3600. Wenn das
> dann immer noch nicht reicht, dann koennen wir ueber Interfaces oder
> vergleichbares nachdenken.

danke für deinen beitrag! wir haben ja in den letzten tagen/wochen schon so
einige gute ansätze gesammelt, bzgl. interfaces, meta-devices etc.

dennoch würde ich mich gerne rudi anschliessen und erstmal die basis schaffen
und eine harmonisierung und nomenklatur zu finden.

ABER: bevor wir zu den READINGS übergehen, sollten wir doch bitte erstmal das
thema

http://groups.google.com/group/fhem-users/t/7c650c75d97606bd

abschliessen, da es ja aufeinander aufbaut. wenn wir für die internals
schonmal die nomenklatur (max. länge, camelCase (ja/nein), etc.) wie bereits
angefangen zu diskutieren auch definieren, dann können wir das auch vorlage
für die READINGS nutzen und hätten damit dann gleich beides erschlagen. dann
noch das ganze auf die attributes übertragen und schon hätte jeder
modulentwickler erstmal die möglichkeit seine module anzupassen.

dann in einem späteren wurd könnte man dann die ganzen vorschläge bzgl.
interfaces, meta-devices, logfiles, etc. erneut aufgreifen.

mir persönlich geht es zur zeit etwas zu sehr durcheinander und unstrukturiert
vor. vielleicht sollten wir wirklich erstmal ein thema zum abschluss bringen
und dann weitersehen.

von daher unterstreiche ich rudi's vorschlag, aber mit der bitte erst die
INTERNALS zu klären und dann mit den READINGS weiterzu machen.

einwände?

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.

[rudolfkoenig]

                                                   

> Wenn das geht, zeige bitte am Beispiel meines Plugwise-Moduls sowie meines
> SIS_PMS, wie.

Alle set Parameter eines Moduls sind in pgm2 / pgm3(?) / pgm5 auswaehlbar,
falls das Modul auf die Anfrage "set ?" eine Liste aller Sets
zurueckliefert (siehe auch xmllist-output).  Das war fuer gets bisher nicht
noetig, da die meisten Module nicht auf polling ausgerichtet waren, kann aber
gerne implementiert werden.  Die Liste aller Attribute mit moeglichen Werten
ist auch vorhanden.

Da jetzt mehrere Module on/off anbieten, sollte pgm2 so erweitert werden, dass
fuer Geraete mit on & off (wie beim FS20) dies auch auf dem Summary page
anbietet. Die Unterscheidung sollte also nicht nach Modul, sondern nach
unterstuetzte Befehle (==Interface?) erfolgen.


> Da "Interfaces", im worst case stumpf über READINGS ausgeführt, vollkommen
> transparent funktionierte, kann ich diese Vorbehalte nicht nachvollziehen.

Ich habe wohl nicht alle Wendungen der Diskussion genau verfolgt und
verinnerlicht. Wenn Interface nur einen weiteren Eintrag im Hash (nicht
READINGS) bedeutet, der sagt, welche sets/gets unterstuetzt werden, dann habe
ich natuerlich kein Problem damit, und mache hiermit einen Rueckzieher.

Frontends koennen zwar auch ohne Interface Eintrag was vergleichbares aus
der Liste aller Sets extrahieren (siehe oben), aber z.Zt ist es nirgendwo
dokumentiert, was alles zu einem definierten set gehoert.

Also schlage ich vor, fuer jedes Interface folgendes zu dokumentieren:
  - set
  - get
  - attribut
  - READING
  - trigger

Beispiel actor_switch
  - set: on off
  - get:
  - attribute:
  - READING: last_set
  - trigger: -

Beispiel sensor_switch
  - set:
  - get: state
  - attribute:
  - READING: state
  - trigger: on off

Ich sehe immer noch einen nicht zu unterschaetzenden Aufwand (Definition,
Dokumentation, Implementation, insb. in den Fronteds), und Probleme fuer
Module, fuer die sich keiner zustaendig fuehlt.

Gruss,
  Rudi

--
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>

Rudolf Koenig wrote:

>> Wenn das geht, zeige bitte am Beispiel meines Plugwise-Moduls sowie meines
>> SIS_PMS, wie.
>
> Alle set Parameter eines Moduls sind in pgm2 / pgm3(?) / pgm5 auswaehlbar,
> falls das Modul auf die Anfrage "set ?" eine Liste aller Sets

Ah! "set ?" als Trigger ist bislang mir nicht bekannt gewesen, danke.

> zurueckliefert (siehe auch xmllist-output).  Das war fuer gets bisher nicht
> noetig, da die meisten Module nicht auf polling ausgerichtet waren, kann aber
> gerne implementiert werden.  Die Liste aller Attribute mit moeglichen Werten
> ist auch vorhanden.

Hier wäre dann wieder die Vereinheitlichungsthematik berührt, "temp" oder
"temperature".

> Da jetzt mehrere Module on/off anbieten, sollte pgm2 so erweitert werden, dass
> fuer Geraete mit on & off (wie beim FS20) dies auch auf dem Summary page
> anbietet. Die Unterscheidung sollte also nicht nach Modul, sondern nach
> unterstuetzte Befehle (==Interface?) erfolgen.

Das ist aber doch wieder ein Ratespiel; bietet "set on" & "set off" an => ist
wohl ein Schalter ... Ich würde nicht ausschließen wollen, daß ein Gerät "on"
und "off" anbietet, welches nicht als Schalter fungiert, daher würde ich das
gerne explizit modulseitig auszeichnen können.

>> Da "Interfaces", im worst case stumpf über READINGS ausgeführt, vollkommen
>> transparent funktionierte, kann ich diese Vorbehalte nicht nachvollziehen.
>
> Ich habe wohl nicht alle Wendungen der Diskussion genau verfolgt und
> verinnerlicht. Wenn Interface nur einen weiteren Eintrag im Hash (nicht
> READINGS) bedeutet, der sagt, welche sets/gets unterstuetzt werden, dann habe
> ich natuerlich kein Problem damit, und mache hiermit einen Rueckzieher.

Das ist Boris' Vorschlag gewesen, den ich für simpel genug halte, daß er ohne
Bauchweh umgesetzt werden könnte --- nur die Definition der "Interfaces" muß
vorab mal erfolgen _und_ dokumentiert werden.

> Frontends koennen zwar auch ohne Interface Eintrag was vergleichbares aus
> der Liste aller Sets extrahieren (siehe oben), aber z.Zt ist es nirgendwo
> dokumentiert, was alles zu einem definierten set gehoert.

Jein; es bleibt eine Ableitung, ein Ratespiel, aus meiner Sicht. Zumindest
würde "Interfaces" diese Raten erfolgversprechender machen
         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.

[Guest]

Originally posted by: <email address deleted>

Teil Zwei der Antwort ...

Rudolf Koenig wrote:

> Also schlage ich vor, fuer jedes Interface folgendes zu dokumentieren:
>   - set
>   - get
>   - attribut
>   - READING
>   - trigger
>
> Beispiel actor_switch
>   - set: on off
>   - get:

- get: switch_state (if listed)

Zur Diskussion, aber was ich mir vorstelle, vielleicht ist es zu simplizistisch,
als das es einfach 'rüber zu bringen wäre, ist, daß ein Frontend anstatt FS20-
Typen, X10-Typen und ABC-Typen kennen zu müssen, diesen "Interface-Typ" (statt:
"Device-Typ") kennt und damit rudimentäre Funktion hinbekommen kann. Beim "Schal-
ter" wäre ein aktueller Status zu erfragen sicherlich von Interesse; bei be-
stimmten Geräten (SIS_PMS, Plugwise) kann man das real erfragen, bei anderen
(FS20, X10 AFAIK) geht das nur über die interne Statemachine (nach dem ersten
"set" ist der (erwartete) Status bekannt, vorher nicht). Rüstet man FHEM der-
gestalt auf, daß ein "get ?" eine Liste der "GETables" zum liefert,
könnte man festschreiben, daß, wenn eine Statusabfrage möglich ist, das Kommando
dazu "get switch_state" wäre ... Fehlt das bei "get ?", wird dies
nicht unterstützt.

(Nota bene: ich mache um "state"/"STATE" einen großen Bogen, daß dieser Wert
in meinen Augen durch aktuelle Nutzung "verbrannt" ist.)

>   - attribute:
>   - READING: last_set
>   - trigger: -

Was ist "trigger"?

> Beispiel sensor_switch
>   - set:
>   - get: state
>   - attribute:
>   - READING: state
>   - trigger: on off

Ah, trennst Du den actor- und den sensor-Part hier auf? Ja, das wäre 'ne
valide Alternative (KISS ), SIS_PMS, Plugwise & Co. würden also actor_switch
und sensor_switch unterstützen, FS20/X10 nur actor_switch, ist es das, was
Du meinst?

> Ich sehe immer noch einen nicht zu unterschaetzenden Aufwand (Definition,
> Dokumentation, Implementation, insb. in den Fronteds), und Probleme fuer
> Module, fuer die sich keiner zustaendig fuehlt.

Wenn's jemanden gibt, der die Funktion des Moduls nach Änderungen zu
testen in der Lage & bereit ist, würde ich mich -- neben hoffentlich
noch anderen Freiwilligen ) -- anbieten, entsprechende Änderungen
vorzunehmen. (Wenn auf Nachfrage sich niemand bzgl. zumindest Nutzung
meldet, schlüge ich vor, das fragliche Modul erst einmal auszuklammern.)

Ob Frontends dieses "Feature" nutzen werden, hängt sicherlich von dem
Ausmaß der Integration in bestehende Module ab (für FS20 & X10 hat sich
wohl schon Boris positioniert ; was nutzen "die 95%" noch?). Bedarf
sehe ich, aber das ist natürlich subjektiv gefärbt, für Temperatursen-
soren & Wetterstationen (sensor_temperature, sensor_hygrowieauchimmer;
sensor_wind, sensor_rain, ...) und Schaltaktoren.

In den Modulen halte ich die Änderungen für marginal; zeitaufwendig er-
scheinen mir Definition und Dokumentation -- ohne die Folgeschritte nicht
erfolgen können.

Als Fingerübung Start vielleicht mit "Switch" & "Dimmer"?
         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.

[Dr. Boris Neubert]

                                             

Martin Fischer schrieb:
> mir persönlich geht es zur zeit etwas zu sehr durcheinander und unstrukturiert
> vor. vielleicht sollten wir wirklich erstmal ein thema zum abschluss bringen
> und dann weitersehen.
>
>  
Danke fuer diesen Beitrag. Ich erlaube mir in einem separaten Thread auf
die Meta-Ebene zu gehen, um dem Themaen Struktur zu geben.

Viele Gruesse,
Boris

--
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.