[FHZ] FHEM Standards

[Martin Fischer]

hiya,

in einigen threads wurde dieses thema ja bereits angerissen, daher möchte ich
hiermit einen neuen thread öffnen, der sich ausschliesslich mit diesem thema
befassen soll.

um das thema mal etwas zu strukturieren würde ich die inhalte in Internals,
Attributes, Readings, Notifies, Logging, Syntax und Dokumentation aufteilen.

ziel sollte es sein einen quasi standard für die entwicklung von modulen und
dessen harmonisierung bzw. interoperabilität bereit zu stellen.

profitieren könnten dadurch

1. die nutzer durch eine einheitliche syntax, sowie regeln für notifies und
das einfache lesen von logeinträgen (parsing mit eingeschlossen),

2. modul-entwickler, da die grundsätzliche architektur und die definition von
z.b. STATE und READINGS klar beschrieben ist,

3. "helfer"-tools, die nicht auf jede eventualität bzw. gesonderte
moduldefinitionen reagieren müssten und

4. eine bereitstellung einer einheitlichen api für webinterfaces.

bevor ich aber hier die bereits genannten ideen zusammentrage und mir einen
wolf schreibe, lade ich erstmal jeden dazu ein die allererste frage zu
beantworten:

ist das überhaupt erwünscht?

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.

[rudolfkoenig]

                                                   

> ist das überhaupt erwünscht?

Ja.

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

Definitiv!

a.


On 29.01.10 15:33, "Martin Fischer" wrote:

> ist das überhaupt erwünscht?


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

[Mr. P]

                                                       

Wäre echt klasse!

On 29 Jan., 16:01, Andy Fuchs wrote:
> Definitiv!
>
> a.
>
> On 29.01.10 15:33, "Martin Fischer" wrote:
>
> > ist das überhaupt erwünscht?

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

Martin Fischer wrote:

[...]

Danke!

> bevor ich aber hier die bereits genannten ideen zusammentrage und mir einen
> wolf schreibe, lade ich erstmal jeden dazu ein die allererste frage zu
> beantworten:
>
> ist das überhaupt erwünscht?

Definitiv!
         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]

am ende der nachricht habe ich eine übersicht (vermeitlich) aller derzeit in
den modulen verwendeten Internals zusammengestellt. Internals gilt erstmal als
bezeichnung für device spezifische parameter die über
   $hash->{}
direkt dem device zugeordnet werden, solange niemand eine treffendere
bezeichnung bestimmt.

auf den ersten blick fällt hier die durchaus unterschiedliche schreibweise und
einige scheinbar doppelte belegungen auf.

beispiele:
local, LOCAL
po, PortObj
socket, SOCKET
Type, TYPE

weitere teils unklare bezeichnungen, die evtl. harmonisiert werden könnten:
DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT
CODE, FamilyCode, HOUSE
INTERVAL, Timer, TRIGGERTIME
NAME, DeviceName
NR, DEVNR

dann sind da die standardfunktionen bei Initialize, die einfach mal
dokumentiert werden müssten:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

einer weiteren betrachtung bedarf der trigger für notify's:
CHANGED
sowie der eigentlichen
READINGS
welche aber in einem anderen context behandelt werden sollten.

einige feste parameter können vorab schonmal gefiltert werden:
DEF
IODev
NAME
NR
STATE
TYPE

je nach IODev können weitere dazu kommen:
CUN868_MSGCNT
CUN868_RAWMSG
CUN868_RSSI
CUN868_TIME
LASTIODev
MSGCNT
RAWMSG
RSSI

bei X10 fiel auf, das in den Internals
MODEL
gesetzt wird aber explizit nochmal
model
in den Attributes vorkommen.

bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in
den Readings auftaucht, obwohl in den Readings einzelne werte vorhanden sind:
Internals:
STATE T: 16.7 H: 66.7
Readings:
humidity 66.7
state T: 16.7 H: 66.7
temperature 16.7

aber zu den Readings kommt ja eine extra diskussion.

verbleiben also noch die am ende folgende Internals. hier gilt es nun zu
überlegen, ob es eine wie bereits oben beschriebene vereinheitlichung, also
das recyclen von bezeichnungen möglich ist. aber auch generell eine regelung
zur schreibweise.

paar gedanken und vorschläge aus meiner sicht:

- wenn möglich immer in GROSSBUCHTSTABEN.

- sollen die bezeichner aus mehreren wörtern zusammengesetzt werden müssen,
dann sind diese durch einen _ (unterstrich) zu kennzeichnen.

- maximale zeichenzahl 20 zeichen (bedarf dann der anpassung von list zur
besseren lesbarkeit).

- wenn abkürzungen gewünscht, dann sollten sie nachvollziehbar sein. eine
längere schreibweise ist jedoch vorzuziehen um verwechslungen mit anderen
modulen vorzubeugen.

- vom device ausgelesene werte gehören (bis auf wenige ausnahmen, die dann
noch zu definieren wären) in die Readings. dazu gehören auch vom device
gemeldete typenbezeichnungen. soll jedoch ein wert dennoch in den Internals
auftauchen, dann gilt für diesen obige regeln.

- attribute gehören in die attribute und nicht in die internals. das könnten
z.b. UNITS, umrechnungsfaktoren, schwellwerte wie min und max, etc. betreffen.


verbleibende Internals:

ALARM
ATTR
BasicFeePerMonth
BTN
CHANGETIME
Cmd
CONTENT
corr1
corr2
corr3
corr4
CostPerUnit
currentlogfile
DELTAFACTOR
DELTAUNIT
DeviceName
DEVNR
DIAMETER
FACTOR
FamilyCode
FD
FH
FHTID
FIXNEW
FIXRENUMBER
GEOMETRY
HEIGHT
Host
HOUSE
ID
IDX
INATTR
INPUT
INSET
INTERVAL
INTV_ALARM
INTV_CHECK
LENGTH
LINK
LircObj
local
LOCAL
LOCATION
logfile
MAX
MOBILE
MODEL
NEXT_OPEN
NR_CMD_LAST_H
NR_EMSG
NR_FMSG
NR_KMSG
NR_RMSG
NR_TMSG
NTM
NUMUNITS
OFFSET
OLDDEF
OW_FAMILY
OWFS_ID
OW_ID
OW_PATH
OW_SCALE
PARTIAL
pipeopentime
po
PortObj
pos
PRESENT
PREV
QUEUE
RAINUNIT
RA_Timeout
RE
REGEXP
REP
RExt
ROUTERID
SelectObj
SENSOR
SERIAL
SERIALS
socket
SOCKET
STEP
TCPDev
Timer
TRIGGERTIME
ttytype
Type
UNIT
UNITS
USBDev
VERSION
VOLATILE
WIDTH
WINDUNIT
XMIT
XMIT_TIME

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

Da ich grade WS3600.pm anfasse, schon mal ein paar Kommentare zu
Martins Zuammenfassung (danke nochmal!).

Martin Fischer wrote:

> am ende der nachricht habe ich eine übersicht (vermeitlich) aller derzeit in
> den modulen verwendeten Internals zusammengestellt. Internals gilt erstmal als
> bezeichnung für device spezifische parameter die über
>    $hash->{}
> direkt dem device zugeordnet werden, solange niemand eine treffendere
> bezeichnung bestimmt.
>
[...]
> weitere teils unklare bezeichnungen, die evtl. harmonisiert werden könnten:
[...]

Naja, über die Modulinterna würde ich erst beim Punkt "Säuberung des Codes
von politisch unkorrekten Inhalten", d. h. weit nach Ende jeglicher Agenda,
diskutieren wollen; das sind, wie der Name schon sagt, *interne* Variablen
des Moduls für modulinterne Verwendung. Da ist keine API betroffen (anders
als bei $dev->{STATE}, $dev->{READINGS} und $dev->{CHANGED}[]), daher sind
Tipps sicher angebracht, aber alles weitere würde ich gerne hintenanstellen
wollen.

> dann sind da die standardfunktionen bei Initialize, die einfach mal
> dokumentiert werden müssten:
> AttrFn
> AttrList
> Clients
> DefFn
> GetFn
> ListFn
> Match
> MatchList
> NotifyFn
> ParseFn
> ReadFn
> ReadyFn
> SetFn
> ShutdownFn
> StateFn
> UndefFn
> WriteFn

<20091026184748.GB28353@bzzz.fritz.box> (26.10.09) enthält Erklärungen von
Rudolf zu FD, ReadyFn, ReadFn, WriteFn, Clients, MatchList sowie Match,
ParseFn und DefFn, UndefFn, SetFn, GetFn, StateFn, AttrList, ShutdownFn,
AttrFn. <20091027135141.GA13036@bzzz.elysianfields> erklärt dann noch fol-
gendes:

|> Kann es auch mehrere MatchFn/ParseFn-Kombies für eine Physischen
|> > Nachricht geben ?
|
| Ja. Falls das ParseFn eines Moduls "undef" zurueckliefert, dann wird nach dem
| naechsten Modul gesucht.

=> Klassischer Fall für's Wiki.

In <368e912b-6cbc-45e4-8308-87b7b2cae0aa@c34g2000yqn.googlegroups.com> erklärt
Axel noch, wie man auf Attribute zugreift:

| so:
| my $TheValue = $attr{MyDevice}{MyAttribute}

Und, FTR, Dispatch() bringt Daten vom Hardwaremodul zu den logischen;
IOWrite() wiederum schickt Aktionen eines logischen Gerätes zum passenden
IODev, also der Hardware (bzw. dem entsprechenden FHEM-Modul für jene).

> einer weiteren betrachtung bedarf der trigger für notify's:
> CHANGED
> sowie der eigentlichen
> READINGS
> welche aber in einem anderen context behandelt werden sollten.
[...]
>
> bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in
> den Readings auftaucht, obwohl in den Readings einzelne werte vorhanden sind:
> Internals:
> STATE T: 16.7 H: 66.7
> Readings:
> humidity 66.7
> state T: 16.7 H: 66.7
> temperature 16.7

Ah. Ok, an dieser Stelle wäre wohl angebracht festzuhalten, daß
$dev->{STATE} *kein* "Interna" eines Moduls ist sondern den ak-
tuellen Status abbildet/abbilden soll. Oder die Verlagerung nach
§dev->{READINGS}{state} sollte vollzogen werden -- siehe zum Kom-
plex $dev->{STATE} vs. $dev->{READINGS}{state} auch Rudolfs Aus-
sage in <20100125075235.GA23923@bzzz.fritz.box>:

| > (Ah, und etwas, was mich ziemlich überrascht hat: Wieso ändert eine Änderung
| > an $hash->{STATE} $hash->{READINGS}{state}{VAL}?!)
|
| > Das ist krank und sollte geaendert werden:
| > Im list angezeigt wird STATE, aber manche Module setzen {READINGS}{state}.
| > fhem.pl versucht die beiden zu synchronisieren. STATE wird auch fuer $value
| > verwendet, der im perl Einzeiler einen schnellen Zugriff auf STATE zulaesst
| > ($value{Lampe1} statt $value{Lampe1}{READINGS}{state}{VAL}). $value sollte in
| > $state umbenannt werden.

> aber zu den Readings kommt ja eine extra diskussion.

Yepp; zu CUL_WS einzig noch angemerkt, daß initial gar keine READINGS
gesetzt wurden; STATE aber nun leer zu lassen, machte die Darstellung
in mindestens pgm2 karpott, wo für jedes (unbekannte) Device zumindest
$dev->{STATE} anzeigt wird ...

> verbleiben also noch die am ende folgende Internals. hier gilt es nun zu
> überlegen, ob es eine wie bereits oben beschriebene vereinheitlichung, also
> das recyclen von bezeichnungen möglich ist. aber auch generell eine regelung
> zur schreibweise.

Wie gesagt, um modul-interne Variablen sollte man sich derzeit IMHO
nicht kümmeren; 1. eine Harmonisierung der READINGS und die in Folge
notwendige Anpassung *wohl aller* Module als auch 2. ein resourcen-
schonenderer Weg im Umgang mit Notify (und damit $dev->{CHANGED}) mit
ebenfalls notwendiger Anpassungen *aller Module und auch FHEM-Nutzer-
Konfigurationsdateien* sollte als Aufgabe für 2010 erst mal reichen

Nach meinem *Verständnis* besteht die API fhem.pl <-> beliebiges_modul.pm
derzeit in den definierten Fn()-Aufrufen und dem definierten Datenraum
$dev->{READINGS} für relevante, "exportierte" Gerätedaten, $dev->{CHANGED}[]
für das Triggern von Notifies aufgrund von geänderten Gerätewerten sowie
eben $dev->{STATE}/$dev->{READINGS}{state}. Anything else, worüber Module
miteinandern Daten austauschen?

> paar gedanken und vorschläge aus meiner sicht:
>
> - wenn möglich immer in GROSSBUCHTSTABEN.

Hmm. Habe ich momentan keine abschließende Meinung zu; tendentiell finde
ich Groß-klein-gemischt aber eher schöner. (Bauchgefühl; GROSS == laut.)

> - sollen die bezeichner aus mehreren wörtern zusammengesetzt werden müssen,
> dann sind diese durch einen _ (unterstrich) zu kennzeichnen.

Ack.

> - maximale zeichenzahl 20 zeichen (bedarf dann der anpassung von list zur
> besseren lesbarkeit).

Hmm. Bin kein Freund von Limits ohne Not, allerdings
SINDUNENDLICHLANGEBEZEICHNERAUCHNICHTIMMERHILFREICH=1 -- insofern: Ack.
(SindUnendlichLangeBezeichnerAuchNichtImmerHilfreichAberMitGrossUndKleinDochBesserLesbarOder=1 )

> - vom device ausgelesene werte gehören (bis auf wenige ausnahmen, die dann
> noch zu definieren wären) in die Readings. dazu gehören auch vom device
> gemeldete typenbezeichnungen. soll jedoch ein wert dennoch in den Internals
> auftauchen, dann gilt für diesen obige regeln.

I beg to differ; nicht alles, was das Modul ausliest, gehört in die
READINGS. (Hintergrund: READINGS werden über FHEM-Läufe ggf. ge-
speichert, nicht für alle Daten macht das Sinn, es stellt für ein
Modul aber einen unverhältnismäßigen Aufwand dar, unerwünschte Alt-
lasten erst löschen zu müssen, wenn man sie doch gleich gar nicht
zur Speicherung vorsehen kann.) In die READINGS gehört, was *sinnvoll*
von anderen Modulen (-> Webfrontends) weiterverarbeitet werden kann.

*Nicht* in die READINGS gehören z. B. Hilfsvariablen, interne Status-
marker, ...

> - attribute gehören in die attribute und nicht in die internals. das könnten
> z.b. UNITS, umrechnungsfaktoren, schwellwerte wie min und max, etc. betreffen.

Auch hier wieder: was ein Modul zur zielführenden Arbeit intern benötigt,
hat das Modul nach Gutdünken da zu versenken, wo es dem Modulschreiberling
am besten aufgehoben erscheint. Die "Attribute" sind meinem Verständnis
nach Stellschrauben, die die Funktionsweise des Moduls ggf. auf den An-
wendungsfall hin anpassen.

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

Hallo Zusammen,

- GROSSBUCHTSTABEN => eher MischMasch aus GrossUndKleinSchreibung
- _ (unterstrich)  = JA
- maximale zeichenzahl 20 = JA
Beispiel aus RRDLog warum das sinnvoll sein könnte:
READING-Name = DS-Name; der DS Name darf max. 19 Zeichen lang
sein...nur als Beispiel ))


> - vom device ausgelesene werte gehören (bis auf wenige ausnahmen, die dann
noch zu definieren wären)
> - attribute gehören in die attribute und nicht in die internals. das könnten


? Was ist mit einem Zwischenspeicher, um z.B. Werte fuer Berechnungen
  (z.B. BasicFeePerMonth,CostPerUnit, CumDay etc. ) zu
speichern...alle nach $attr ??

? Welche Werte sind per "save" in der Sicherung.

Kann man das so Kategorisieren
1. FHEM-CORE -> der "nackte"-Hash in der 1. Zeile vom Initialize ->
$defs{}
2. MOD-CORE -> letzte Zeile vom Define -> $defs{}
3. DEVICE-READINGS -> "reine" Messdaten -> $defs{}{READINGS}
4. DEVICE-PROPERTIES -> $attr z.B. Model...
5. MOD-DATA -> Daten fuer Berechnungen etc. -> ? -> $defs{}
{DATA}
6. "Anzeige-Daten" -> fuer die UI's ->

Model:
Es gibt einige Module mit Model z.B. FS20 (von Hand setzten) und HMS
(wird gesendet).
Warum sollten die Daten an unterschiedlichen Stellen stehen.

Die beiden BasicFeePerMonth (Monatlicher GrundFreibetrag) und
CostPerUnit (Kosten pro Einheit z.B. kWh oder m3) sind aus CUL_EM.
Braucht das Modul zum Rechnen.... = $attr

Schöne Grüße

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.

[Martin Fischer]

Am Samstag 30 Januar 2010 schrieb Kai 'wusel' Siering:
> Da ich grade WS3600.pm anfasse, schon mal ein paar Kommentare zu
> Martins Zuammenfassung (danke nochmal!).
>
> Martin Fischer wrote:
> > am ende der nachricht habe ich eine übersicht (vermeitlich) aller derzeit
> > in den modulen verwendeten Internals zusammengestellt. Internals gilt
> > erstmal als bezeichnung für device spezifische parameter die über
> >    $hash->{}
> > direkt dem device zugeordnet werden, solange niemand eine treffendere
> > bezeichnung bestimmt.
>
> [...]
> Naja, über die Modulinterna würde ich erst beim Punkt "Säuberung des Codes
> von politisch unkorrekten Inhalten", d. h. weit nach Ende jeglicher Agenda,
> diskutieren wollen; das sind, wie der Name schon sagt, *interne* Variablen
> des Moduls für modulinterne Verwendung. Da ist keine API betroffen (anders
> als bei $dev->{STATE}, $dev->{READINGS} und $dev->{CHANGED}[]), daher sind
> Tipps sicher angebracht, aber alles weitere würde ich gerne hintenanstellen
> wollen.

ACK. ich habe erstmal nur eine inventur gemacht man könnte aber auch
nachdenken, ob es für interne variablen einen extra namensraum gibt, der dann
auch nicht bei z.b. xmllist auftaucht.

> > dann sind da die standardfunktionen bei Initialize, die einfach mal
> > dokumentiert werden müssten:
> [...]
> <20091026184748.GB28353@bzzz.fritz.box> (26.10.09) enthält Erklärungen von
> Rudolf zu FD, ReadyFn, ReadFn, WriteFn, Clients, MatchList sowie Match,
> ParseFn und DefFn, UndefFn, SetFn, GetFn, StateFn, AttrList, ShutdownFn,
> AttrFn. <20091027135141.GA13036@bzzz.elysianfields> erklärt dann noch fol-
>
> gendes:
> |> Kann es auch mehrere MatchFn/ParseFn-Kombies für eine Physischen
> |>
> |> > Nachricht geben ?
> |
> | Ja. Falls das ParseFn eines Moduls "undef" zurueckliefert, dann wird nach
> | dem naechsten Modul gesucht.
>
> => Klassischer Fall für's Wiki.

wenn die dann auch soweit "gesetzt" sind, dann sollte das tatsächlich
offiziell erfasst werden. vielleicht sollte es im fhem-cvs ein spezielles
README.developer dazu geben..

> [...]
>
> > bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als
> > auch in den Readings auftaucht, obwohl in den Readings einzelne werte
> > vorhanden sind: Internals:
> > STATE T: 16.7 H: 66.7
> > Readings:
> > humidity 66.7
> > state T: 16.7 H: 66.7
> > temperature 16.7
>
> Ah. Ok, an dieser Stelle wäre wohl angebracht festzuhalten, daß
> $dev->{STATE} *kein* "Interna" eines Moduls ist sondern den ak-
> tuellen Status abbildet/abbilden soll. Oder die Verlagerung nach
> §dev->{READINGS}{state} sollte vollzogen werden -- siehe zum Kom-
> plex $dev->{STATE} vs. $dev->{READINGS}{state} auch Rudolfs Aus-

$hash->{STATE} ist, wie du richtig erkannt hast, kein interna sondern der
aktuelle status. aus meiner sicht ist er da auch gut aufgehoben. ich wollte
nur drauf aufmerksam machen, das ein
$hash->{STATE} _und_ ein $hash->{READINGS}{state} aus meiner sicht doppelt
ist, da die einzelnen werte ja meist eh in den READINGS stehen. aber dazu dann
im späteren READINGS thread..

> [...]
>
> Wie gesagt, um modul-interne Variablen sollte man sich derzeit IMHO
> nicht kümmeren; 1. eine Harmonisierung der READINGS und die in Folge
> notwendige Anpassung *wohl aller* Module als auch 2. ein resourcen-
> schonenderer Weg im Umgang mit Notify (und damit $dev->{CHANGED}) mit
> ebenfalls notwendiger Anpassungen *aller Module und auch FHEM-Nutzer-
> Konfigurationsdateien* sollte als Aufgabe für 2010 erst mal reichen

ACK! aber ich verweise noch mal auf meine neuerliche idee für die modul-
internen variablen evtl. einen eigenen namensraum zu verwenden.

> Nach meinem *Verständnis* besteht die API fhem.pl <-> beliebiges_modul.pm
> derzeit in den definierten Fn()-Aufrufen und dem definierten Datenraum
> $dev->{READINGS} für relevante, "exportierte" Gerätedaten,
>  $dev->{CHANGED}[] für das Triggern von Notifies aufgrund von geänderten
>  Gerätewerten sowie eben $dev->{STATE}/$dev->{READINGS}{state}. Anything
>  else, worüber Module miteinandern Daten austauschen?

sehe ich auch so. und hätte erstmal nicht zuzufügen..

> > paar gedanken und vorschläge aus meiner sicht:
> >
> > - wenn möglich immer in GROSSBUCHTSTABEN.
>
> Hmm. Habe ich momentan keine abschließende Meinung zu; tendentiell finde
> ich Groß-klein-gemischt aber eher schöner. (Bauchgefühl; GROSS == laut.)

jain. hatte ich auch erst gedacht. dann aber doch zu den grossen tendiert, da
sie auch eine art "signal" wirkung haben. wer mich kennt, bzw. meine mails
kennt, weiss das meine "shift-tasten" kaputt sind nicht nur hier, auch
beruflich na gut. in offiziellen schreiben, finde ich die tasten auch
wieder auf der tastatur

> > - sollen die bezeichner aus mehreren wörtern zusammengesetzt werden
> > müssen, dann sind diese durch einen _ (unterstrich) zu kennzeichnen.
>
> Ack.

ok.

> > - maximale zeichenzahl 20 zeichen (bedarf dann der anpassung von list zur
> > besseren lesbarkeit).
>
> Hmm. Bin kein Freund von Limits ohne Not, allerdings
> SINDUNENDLICHLANGEBEZEICHNERAUCHNICHTIMMERHILFREICH=1 -- insofern: Ack.
> (SindUnendlichLangeBezeichnerAuchNichtImmerHilfreichAberMitGrossUndKleinDoc
> hBesserLesbarOder=1 )



> > - vom device ausgelesene werte gehören (bis auf wenige ausnahmen, die
> > dann noch zu definieren wären) in die Readings. dazu gehören auch vom
> > device gemeldete typenbezeichnungen. soll jedoch ein wert dennoch in den
> > Internals auftauchen, dann gilt für diesen obige regeln.
>
> I beg to differ; nicht alles, was das Modul ausliest, gehört in die
> READINGS. (Hintergrund: READINGS werden über FHEM-Läufe ggf. ge-
> speichert, nicht für alle Daten macht das Sinn, es stellt für ein
> Modul aber einen unverhältnismäßigen Aufwand dar, unerwünschte Alt-
> lasten erst löschen zu müssen, wenn man sie doch gleich gar nicht
> zur Speicherung vorsehen kann.) In die READINGS gehört, was *sinnvoll*
> von anderen Modulen (-> Webfrontends) weiterverarbeitet werden kann.

beispiele dafür? welche vom device ausgelesenen werte sollten deiner meinung
nach nicht in die readings? wer definiert was sinnvoll ist, wer nicht? von
daher vertrete ich die meinung, das alles was das device liefert (und
ausgelesen wird) dann auch in die readings gehören würde.

> *Nicht* in die READINGS gehören z. B. Hilfsvariablen, interne Status-
> marker, ...

ACK!
 
> > - attribute gehören in die attribute und nicht in die internals. das
> > könnten z.b. UNITS, umrechnungsfaktoren, schwellwerte wie min und max,
> > etc. betreffen.
>
> Auch hier wieder: was ein Modul zur zielführenden Arbeit intern benötigt,
> hat das Modul nach Gutdünken da zu versenken, wo es dem Modulschreiberling
> am besten aufgehoben erscheint. Die "Attribute" sind meinem Verständnis
> nach Stellschrauben, die die Funktionsweise des Moduls ggf. auf den An-
> wendungsfall hin anpassen.

mal ein beispiel:
die ds18s20 1-wire devices , vertreten durch owtemp liefern u.a. auch lowtemp
und hightemp. beides schwellwerte, die tatsächlich ausgelesen werden aber auch
neu gesetzt werden können.

ich hatte sie seinerzeit in $hash->{READINGS}{lowtemp|hightemp} gepackt, weil
sie halt ausgelesen werden. den dazu generierten alarm, der nicht vom 1-wire
device kommt sondern durch das modul gesetzt wird, habe ich nach $hash-
>{ALARM} gepackt, was mir sinnvoll erscheint. die temperatureinheit (Celsius)
wird wiederum über $attr{$name}{"temp-scale"} des providers owfs gesetzt, da
es sozusagen als globales attribute für alle ow-devices gilt. wird wohl kaum
jemand gemischte skalen verwenden (also diese devices in Celsius, jene in
Fahrenheit, andere in Kelvin und die da möchte ich bitte in Rankine anzeigen).

dieses beispiel zeigt die trennung in die namensräume.

übrigens:
die units könnte man sogar aus meiner sicht auf die oberste ebene direkt fhem
auf den weg geben:
attrib global temp_scale C
attrib global wind_scale kmh
...

--
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 Samstag 30 Januar 2010 schrieb Axel:
> - GROSSBUCHTSTABEN => eher MischMasch aus GrossUndKleinSchreibung

ok. auch eine begründung dazu?

> - _ (unterstrich)  = JA

ok

> - maximale zeichenzahl 20 = JA

ok

> [...]
> ? Was ist mit einem Zwischenspeicher, um z.B. Werte fuer Berechnungen
>   (z.B. BasicFeePerMonth,CostPerUnit, CumDay etc. ) zu
> speichern...alle nach $attr ??

ne, $attr würde ich da für falsch halten, da du von einem "zwischenspeicher"
sprichst..

auf kai antwortete ich bereits zum gleichen theme mit der idee evtl. einen
extra namensraum für "zwischenspeicher" zu schaffen.. ist halt nur 'ne idee um
die anderen bereiche "sauber" zu halten. dann haben es user und entwickler
einfacher auseinander zu halten, was nun was ist.

> ? Welche Werte sind per "save" in der Sicherung.

alle werte die der entwickler benötigt, damit das modul nach einem neustart
von fhem wieder so rennt wie vorher

> Kann man das so Kategorisieren
> 1. FHEM-CORE -> der "nackte"-Hash in der 1. Zeile vom Initialize ->
> $defs{}
> 2. MOD-CORE -> letzte Zeile vom Define -> $defs{}
> 3. DEVICE-READINGS -> "reine" Messdaten -> $defs{}{READINGS}
> 4. DEVICE-PROPERTIES -> $attr z.B. Model...
> 5. MOD-DATA -> Daten fuer Berechnungen etc. -> ? -> $defs{}
> {DATA}
> 6. "Anzeige-Daten" -> fuer die UI's ->

hm... nicht zu allen punkten habe ich eine meinung. aber zu 3. und 4. erstmal
ein ACK. zu 5 auch, wenn du damit den "zwischenspeicher" meinst. ob er dann
{DATA} heissen soll, müssten wir halt festlegen. und 6. halte ich für
überflüssig, da alles aus 1-4 (5 lasse ich mal aussenvor ausser jemand möchte
über eine gui auch diese werte ändern können, was aus meiner sicht aber nicht
notwendig wäre, da es sich ja um modulinteren dinge handelt) ausgelesen werden
kann.

> Model:
> Es gibt einige Module mit Model z.B. FS20 (von Hand setzten) und HMS
> (wird gesendet).
> Warum sollten die Daten an unterschiedlichen Stellen stehen.

weil wenn gesendet, dann ist es aus meiner sicht ein READING, welches aber
nicht mit einem set überschrieben werden kannm also locked ist.

bei attributen sollte man aus meiner sicht aber die linie verfolgen diese
immer durch den benutzer änderbar zu machen.

> Die beiden BasicFeePerMonth (Monatlicher GrundFreibetrag) und
> CostPerUnit (Kosten pro Einheit z.B. kWh oder m3) sind aus CUL_EM.
> Braucht das Modul zum Rechnen.... = $attr

.. und sind je nach user unterschiedlich also aus meiner sicht klar ein fall
für $attr.

so zumindest mein verständnis dazu.

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.

[Guest]

Originally posted by: <email address deleted>

Martin Fischer wrote:

>>> - wenn möglich immer in GROSSBUCHTSTABEN.
>> Hmm. Habe ich momentan keine abschließende Meinung zu; tendentiell finde
>> ich Groß-klein-gemischt aber eher schöner. (Bauchgefühl; GROSS == laut.)
>
> jain. hatte ich auch erst gedacht. dann aber doch zu den grossen tendiert, da
> sie auch eine art "signal" wirkung haben. wer mich kennt, bzw. meine mails
> kennt, weiss das meine "shift-tasten" kaputt sind nicht nur hier, auch

Ja. Nervt kollossal (kein Scherz), aber ich habe mir in den 90ern abge-
wöhnt, derlei zu thematisieren. Ich kann auch nur klein schreiben (und
spätestens seit der reformierten Reform des Reförmchens habe ich dies-
bezüglich auch den Korrektheitsfaden verloren), finde es aber lesbarer,
gelegentlich an den richtigen Stellen auch mal den Daumen unten links
niedersausen zu lassen -- mich kostet's 'ne Millisekunde, 10 Lesern
spart es vielleicht je eine => Nettogewinn. Aber, wie gesagt, das muß
jeder mit sich selbst ausmachen

Aber, um es kurz zu machen -- und zum Thema zurückzukehren --: frei-
willig bin ich nicht für GROSSBUCHSTABEN zu haben, weil ich darin genau
keinen Vorteil sehe. (In den Benamsungen der, _meiner_, Variablen.)

>>> - vom device ausgelesene werte gehören (bis auf wenige ausnahmen, die
>>> dann noch zu definieren wären) in die Readings. dazu gehören auch vom
>>> device gemeldete typenbezeichnungen. soll jedoch ein wert dennoch in den
>>> Internals auftauchen, dann gilt für diesen obige regeln.
>> I beg to differ; nicht alles, was das Modul ausliest, gehört in die
>> READINGS. (Hintergrund: READINGS werden über FHEM-Läufe ggf. ge-
>> speichert, nicht für alle Daten macht das Sinn, es stellt für ein
>> Modul aber einen unverhältnismäßigen Aufwand dar, unerwünschte Alt-
>> lasten erst löschen zu müssen, wenn man sie doch gleich gar nicht
>> zur Speicherung vorsehen kann.) In die READINGS gehört, was *sinnvoll*
>> von anderen Modulen (-> Webfrontends) weiterverarbeitet werden kann.
>
> beispiele dafür? welche vom device ausgelesenen werte sollten deiner meinung
> nach nicht in die readings?

Zum Beispiel die Kalibrierungsdaten des einzelnen Plugwise-Zwischensteckers.
Diese können vom Gerät problemlos bei der Initialisierung erfragt werden und
könnten sich, theoretisch zumindest, bis Sankt Nimmerlein auch mal ändern.
Davon abgesehen haben sie für niemanden einen konkreten Nutzen, außer für
das Modul beim Empfang bestimmter Werte. Wenn Du meinst, besser/genauer um-
rechnen zu können, ändere bitte das Modul und frickele nicht mit dem Front-
end an bestehenden Problemen rum. (Du == der geneigte Leser )

> wer definiert was sinnvoll ist, wer nicht? von

Der Autor des Moduls, wer sonst? Das Modul wird nicht zum Selbst-, son-
dern einem konkreten Zweck geschrieben, den zu Erfüllen sollte der Autor
die Freiheit haben, die er benötigt. Und insbesondere sollte er nicht
den Endanwender mich Hilfsvariablen, zumal von zeitlich befristeter Gül-
tigkeit, den Endnutzer zur Eintrag in den READINGS verwirren müssen.

>>> - attribute gehören in die attribute und nicht in die internals. das
>>> könnten z.b. UNITS, umrechnungsfaktoren, schwellwerte wie min und max,
>>> etc. betreffen.
>> Auch hier wieder: was ein Modul zur zielführenden Arbeit intern benötigt,
>> hat das Modul nach Gutdünken da zu versenken, wo es dem Modulschreiberling
>> am besten aufgehoben erscheint. Die "Attribute" sind meinem Verständnis
>> nach Stellschrauben, die die Funktionsweise des Moduls ggf. auf den An-
>> wendungsfall hin anpassen.
>
> mal ein beispiel:
> die ds18s20 1-wire devices , vertreten durch owtemp liefern u.a. auch lowtemp
> und hightemp. beides schwellwerte, die tatsächlich ausgelesen werden aber auch
> neu gesetzt werden können.

Keine Ahnung, wo diese Werte herkommen; vom Sensor meine ich nicht, digi-
temp wirft diese auch nicht aus:

root@plug-2:/usr/local/lib/FHEM# (cd ; digitemp_DS9097 -q -s /dev/ttyUSB3 -a -o "%R %s %C %N")
10A5522101080078 0 15.750000 1264973027
108B3E21010800ED 1 0.812500 1264973029

Oder meinst Du die Schwellwerte, bei deren Über-/Unterschreitung ein Alarm
abgefragt werden kann?

> ich hatte sie seinerzeit in $hash->{READINGS}{lowtemp|hightemp} gepackt, weil
> sie halt ausgelesen werden. den dazu generierten alarm, der nicht vom 1-wire
> device kommt sondern durch das modul gesetzt wird, habe ich nach $hash-
>> {ALARM} gepackt, was mir sinnvoll erscheint. die temperatureinheit (Celsius)
> wird wiederum über $attr{$name}{"temp-scale"} des providers owfs gesetzt, da
> es sozusagen als globales attribute für alle ow-devices gilt. wird wohl kaum
> jemand gemischte skalen verwenden (also diese devices in Celsius, jene in
> Fahrenheit, andere in Kelvin und die da möchte ich bitte in Rankine anzeigen).

AFAIK geht nur C oder F, die Umrechnung macht meinem Verständnis nach der 1820
sogar selbst. Naja, und grade bei OWFS mit der Möglichkeit der Vernetzung würde
ich das auch wieder als Attribut des Devices sehen -- warum sollte ich nicht
ein meinem FHEM auch Werte meines Servers in Übersee verwerten, jene aber in F
ausweisen, um den Jungs drüben sagen zu können, daß (was auch immer 0 Grad C in
F sein mögen) jetzt wirklich zu kalt für ein DC ist Aber wir schweifen ab in
Detaildiskussionen.

> dieses beispiel zeigt die trennung in die namensräume.

Ich sehe Deinen Punkt nicht. Daß die Schnittstelle READINGS heißt, hatten wir
zwei Hübschen doch abgehakt? Dann gehört $hash->{ALARM} als $hash->{READINGS}{ALARM}
reinkarniert. Wenn ich Fahrenheit vom (hoffentlichen ) Default Celsius will,
setze ich "attr MyOWSFDev OWFS unit F" oder wie auch immer es heißt. ("temp-
scale" finde ich übrigends krank, ist das oettingerisch für Temperaturskala?
C oder F ist doch aber die Maßeinheit, also "unit", oder?)
(Abgesehen davon, daß DS1820 doch die Kreuzung des Schwellwertes signalisieren
kann, also dies "nur" abgefragt und dann in FHEM ausgewerden werden müßte, oder
habe ich da was falsch verstanden? Habe derlei nie benutzt und auch keine Ver-
wendung dafür (== würde es im "Backend", also FHEM, be- und auswerten).)

> übrigens:
> die units könnte man sogar aus meiner sicht auf die oberste ebene direkt fhem
> auf den weg geben:
> attrib global temp_scale C
> attrib global wind_scale kmh

Sischer dat, wenn FHEM dann gleich Umrechnungsroutinen bereit legt,
damit $Modul und $Frontend dem Wunsch entsprechen können ... Denn
'ner Wetterstation ist das mehr so latte, was Du möchtest, die
liefert stumpf in der Einheit, die in ihr programmiert wurde Und:
das sollte schon auf Device-Ebene einstellbar sein; das Beispiel mit
dem US-Sprachraum, wo man besser Fahrenheits nennt, brachte ich ja
schon. Um DAS haber sauber zu machen, müßte jedes Modul zu jedem
Wert die Quellmaßeinheit -- unveränderbar -- ausweisen (ginge ja mit
{unit} parallel zu {time} & {val}); derzeit geht man wohl eher davon
aus, daß Windgeschwindigkeit m/s ist, bei der Regenmenge (WS3600: mm)
bin ich mir schon nicht mehr so sicher, bei der Energieverbrauchsmes-
sung wird's schon lustig (kWh; ist das nicht dann auch mehr so eine
Hochrechnung, denn dieser Wert würde neu bei Konstanz über 360 Sec.
erreicht?), bei 1-Wire per digitemp kann ich C oder F zumindest ex-
plizit vorgeben ...
         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>

Martin Fischer wrote:

> auf kai antwortete ich bereits zum gleichen theme mit der idee evtl. einen
> extra namensraum für "zwischenspeicher" zu schaffen.. ist halt nur 'ne idee um
> die anderen bereiche "sauber" zu halten. dann haben es user und entwickler
> einfacher auseinander zu halten, was nun was ist.

Eigener Namensraum dafür: wäre nicht notwendig, wenn FHEM (in list, xmllist,
woauchimmer) konsequent nur die READINGS ausgäbe => marginaler Aufwand (nur
fhem.pl).
         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]

Am Sonntag 31 Januar 2010 schrieb Kai 'wusel' Siering:
> Martin Fischer wrote:
> > auf kai antwortete ich bereits zum gleichen theme mit der idee evtl.
> > einen extra namensraum für "zwischenspeicher" zu schaffen.. ist halt nur
> > 'ne idee um die anderen bereiche "sauber" zu halten. dann haben es user
> > und entwickler einfacher auseinander zu halten, was nun was ist.
>
> Eigener Namensraum dafür: wäre nicht notwendig, wenn FHEM (in list,
>  xmllist, woauchimmer) konsequent nur die READINGS ausgäbe => marginaler
>  Aufwand (nur fhem.pl).

dagegen

das wäre zu wenig.. so wie es jetzt ist, ist es schon in ordnung:
device internals, readings und attributtes..

das sollte auch so bleiben..

--
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 Sonntag 31 Januar 2010 schrieb Kai 'wusel' Siering:
> [...]
> > jain. hatte ich auch erst gedacht. dann aber doch zu den grossen
> > tendiert, da sie auch eine art "signal" wirkung haben. wer mich kennt,
> > bzw. meine mails kennt, weiss das meine "shift-tasten" kaputt sind
> > nicht nur hier, auch
>
> Ja. Nervt kollossal (kein Scherz), aber ich habe mir in den 90ern abge-
> wöhnt, derlei zu thematisieren. Ich kann auch nur klein schreiben (und
> [...]

das leben ist halt kein ponyhof

> [...]
> Aber, um es kurz zu machen -- und zum Thema zurückzukehren --: frei-
> willig bin ich nicht für GROSSBUCHSTABEN zu haben, weil ich darin genau
> keinen Vorteil sehe. (In den Benamsungen der, _meiner_, Variablen.)

wenn man mal list macht, dann sieht man das rudi, das ja
konsequenterweise bereits so umgesetzt hat. aus diesem grund fände ich ein
zulässiges misch-masch auch eher unleserlich.

> [...]
>
> Zum Beispiel die Kalibrierungsdaten des einzelnen
>  Plugwise-Zwischensteckers. Diese können vom Gerät problemlos bei der
>  Initialisierung erfragt werden und könnten sich, theoretisch zumindest,
>  bis Sankt Nimmerlein auch mal ändern. Davon abgesehen haben sie für
>  niemanden einen konkreten Nutzen, außer für das Modul beim Empfang
>  bestimmter Werte. Wenn Du meinst, besser/genauer um- rechnen zu können,
>  ändere bitte das Modul und frickele nicht mit dem Front- end an
>  bestehenden Problemen rum. (Du == der geneigte Leser )

es ging mir auch nicht darum, das jemand das im front-end verändern soll,
sondern das diese ausgelesenen werte dort zur info dargestellt werden
könnten.. daher der vorschlag es so zu definieren:
was vom device _ausgelesen_ wird kommt in die _readings_, das macht halt die
definition einer abgrenzung einfacher für eine gemeinsame policy.

> > wer definiert was sinnvoll ist, wer nicht? von
>
> [...]
> die Freiheit haben, die er benötigt. Und insbesondere sollte er nicht
> den Endanwender mich Hilfsvariablen, zumal von zeitlich befristeter Gül-
> tigkeit, den Endnutzer zur Eintrag in den READINGS verwirren müssen.

ACK, wie bereits schon erwähnt..

> [...]
> >> Modulschreiberling am besten aufgehoben erscheint. Die "Attribute" sind
> >> meinem Verständnis nach Stellschrauben, die die Funktionsweise des
> >> Moduls ggf. auf den An- wendungsfall hin anpassen.

auch ein ACK

> > mal ein beispiel:
> > die ds18s20 1-wire devices , vertreten durch owtemp liefern u.a. auch
> > lowtemp und hightemp. beides schwellwerte, die tatsächlich ausgelesen
> > werden aber auch neu gesetzt werden können.
>
> Keine Ahnung, wo diese Werte herkommen; vom Sensor meine ich nicht, digi-
> temp wirft diese auch nicht aus:

doch kommen sie, nur digitemp zeigt die nicht an.. siehe hier:
http://owfs.org/index.php?page=ds18s20

> [...]
> dieses beispiel zeigt die trennung in die namensräume.
>
> Ich sehe Deinen Punkt nicht. Daß die Schnittstelle READINGS heißt, hatten
>  wir zwei Hübschen doch abgehakt? Dann gehört $hash->{ALARM} als
>  $hash->{READINGS}{ALARM} reinkarniert. Wenn ich Fahrenheit vom

ich kürze das hier mal ab, da ich eigentlich jetzt in diesem thread nicht auf
bestehende module eingehen will.. owtemp war nur ein beispiel (sicherlich
nicht _das_ musterbeispiel, sondern nur um es etwas deutlicher zu machen.

aber soviel noch zu owtemp:
$hash->{ALARM} gehört aus meiner sicht nicht $hash->{READINGS}{ALARM}, da
ALARM eine funktion des moduls in diesem beispiel ist. der sensor sendet bzw.
signalisiert kein alarm. der misst die temperatur und man kann dem sensor noch
sagen wo ist hightemp und wo ist lowtemp. was du letztlich bei über-/
unterschreitung machst, das scherrt den sensor nicht die bohne. und hier kommt
halt die alarmfunktion des moduls zum einsatz, die aus den readings generiert
wird.

>  [...]
> > übrigens:
> > die units könnte man sogar aus meiner sicht auf die oberste ebene direkt
> > fhem auf den weg geben:
> > attrib global temp_scale C
> > attrib global wind_scale kmh
>
> Sischer dat, wenn FHEM dann gleich Umrechnungsroutinen bereit legt,
> damit $Modul und $Frontend dem Wunsch entsprechen können ... Denn
> 'ner Wetterstation ist das mehr so latte, was Du möchtest, die
> liefert stumpf in der Einheit, die in ihr programmiert wurde Und:
> das sollte schon auf Device-Ebene einstellbar sein; das Beispiel mit
> dem US-Sprachraum, wo man besser Fahrenheits nennt, brachte ich ja
> schon. Um DAS haber sauber zu machen, müßte jedes Modul zu jedem
> Wert die Quellmaßeinheit -- unveränderbar -- ausweisen (ginge ja mit
> {unit} parallel zu {time} & {val}); derzeit geht man wohl eher davon
> [...]

auch das kürze ich mal ab.. ich meine es anders.. nicht als umrechungsroutine,
sondern bei bedarf einfach einen globalen bezeichner, den der entwickler bei
bedarf an seine werte anhängen kann um zu vermeiden, das jemand "° Celsius",  
der nächste "Celsius" und ein anderer "C" und das ganze dann noch mit "()"
gemischt anzeigt.

ABER:
nu ist erstmal schluss... denn aktuell wird das nur zu einem kai, axel, martin
thread.

ich warte nun erstmal weitere reaktionen / meinungen ab. wir haben ja
mittlerweilen einiges an ideen / vorschlägen / vetos / scenarien / etc.
diskutiert, so dass auch andere mal die chance bekommen sollten was dazu zu
äussern.

vielleicht kann man dann ja auch mal zu einem ergebnis und einem entschluss
kommen (nicht so wie beim wiki, was bis heute nicht öffentlich (obwohl von
arno erwünscht) entschieden wurde.).

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.

[Guest]

Originally posted by: <email address deleted>

Martin Fischer wrote:

>>  Eigener Namensraum dafür: wäre nicht notwendig, wenn FHEM (in list,
>>  xmllist, woauchimmer) konsequent nur die READINGS ausgäbe => marginaler
>>  Aufwand (nur fhem.pl).
>
> dagegen
>
> das wäre zu wenig..

Says who? Also, die "internals" verwirren im Zweifel mehr, als sie
nützen. Zumindest bei telnet & pgm2; andere Interfaces mögen ja weniger
ausgeben (hier zeigt sich dann wieder die Zwiespältigkeit, FHEM als
Backend einerseits, das andererseits aber auch ein Frontendinterface
darstellt).
Aber ok, letztlich sehe ich hier auch keinen dringenden Handlungsbedarf;
wenn ich wirklich "allein" sein will, lege ich mir eben einen eigenen
(globalen) Hash an, den keiner kennt und in dem daher auch keiner rum-
macht.

Was mich aber mehr interessieren würde, wäre eine bessere »Reusability«
bestehender Module. Ich probiere mich grade an einem digitemp-Interface
(periodischer Aufruf von digitemp; OWFS hat bei mir zu Problemen ge-
führt, die in der HW begründet sein dürften, aber wo sich OWFS in den
Fuß schoß, lieferte digitemp zumindest noch teilweise Werte), um aber
die Anzahl an Modulen nicht exponentiell steigen zu lassen, wollte ich
mich an OWTEMP dranhängen -- was aber nicht geht, da OWTEMP augenschein-
lich direkt OW:: anspricht und nicht, wie bei CUL/FHZ vs. FHT/HMS/KS300,
das OWFS-Modul Werte aus dem owfs per Dispatch() an die ParseFN des
OWTEMP-Moduls schickt             (Kein Vorwurf, nicht mißverstehen!)

Ich überlege daher, anstatt weite Codeteile zu duplizieren und dem Nutzer
ein weiteres "Temperaturwertpräsentationsmodul" aufzubürden, CUL_WS umzu-
modeln in ein generischeres "Umgebungssensorenmodul", das dann von CUL_WS,
aber auch von OWFS und ggf. einem JeeNode-IT+-Empfänger benutzt werden
kann. Das würde zugleich dazu führen, daß nicht jedes Frontend für jeden
neuen Sensor angepaßt werden müßte und auch das Thema der Variablennamen
erschlagen ... (Das myHCE 0.9.2 z. B. (nur bei mir?) gar keine CUL_WS an-
zeigt, hat mich etwas betrübt; daß meine Wetterstation nicht auftaucht,
nunja, DAS war zu erwarten. Das liesse sich aber durch Aufruf von CUL_WS
aus WS3600 durchaus ändern ...)

Any comments?
         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.