[FHZ] FHEM Standards

[Guest]

Originally posted by: <email address deleted>

Martin Fischer wrote:

[kleinschreibung]
>> 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

Den Spruch habe ich übrigens nie verstanden; so'n Ponyhof ist doch alles
andere als »leichtes Leben«? Egal ...

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

Hmm? Also, ich bin *für* Mischmasch, zumindest gegen NURGROSS
Und was konkret meinst Du?

list Circle_1
Internals:
    DEF        4be246
    ID         4be246
    IODev      TheStick
    LASTIODev  TheStick
    LASTSEEN   2010-02-01 20:20:00
    LASTSEEN_T 1265052000
    MSGCNT     1363
    NAME       Circle_1
    NR         6
    STATE      on, 7.87 W
    STATUS     on
    TYPE       Pw_Circle
    TheStick_MSGCNT 1363
    TheStick_TIME 2010-02-01 20:20:00
    Calibrate:
      TIME_T     1265032499
      gaina      1.00552022457123
      gainb      -2.3054280973156e-06
      offruis    0
      offtot     -0.000490037200506777
    Power:
      QUERYTIME_T 1265052000
      TIME       2010-02-01 20:20:00
      TIME_T     1265052000
      initialized yes
      pulse1sec  3
      pulse8sec  3
      totals     4466
    Readings:
      2010-02-01 20:20:00   state           on, 7.87 W
      2010-02-01 20:20:00   usage           0.00787
Attributes:
    TIMER      300
    room       Wohnen

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

Ich denke, Du bist -- wie ich -- zu sehr Techniker. Ich denke, wenn
ich meiner besseren Hälfte oder meinen Kindern obigen "list" zeigen
würde, würde ich als Feedback zurück bekommen "äh, was ist 'offruis',
ist der Wert jetzt gut? Und was sind das alles für Zeiten da, muß das
da stehen? Das verwirrt doch nur! 7 Watt, DAS will ich doch nur wissen!".

Und, um beim Beispiel zu bleiben: Was sagen Dir nun gaina, gainb, offtot
und offruis? Und sind diese jetzt besser oder schlechter als jene:

list Circle_Sheeva
Internals:
    DEF        59af7f
    ID         59af7f
    IODev      TheStick
    LASTIODev  TheStick
    LASTSEEN   2010-02-01 21:00:13
    LASTSEEN_T 1265054413
    MSGCNT     1253
    NAME       Circle_Sheeva
    NR         9
    STATE      on, 17.15 W
    STATUS     on
    TYPE       Pw_Circle
    TheStick_MSGCNT 1253
    TheStick_TIME 2010-02-01 21:00:13
    Calibrate:
      TIME_T     1265032507
      gaina      1.00217533111572
      gainb      -1.64761138421454e-06
      offruis    0
      offtot     0.0241989828646183
    Power:
      QUERYTIME_T 1265054413
      TIME       2010-02-01 21:00:13
      TIME_T     1265054413
      initialized yes
      pulse1sec  7
      pulse8sec  8
      totals     250
    Readings:
      2010-02-01 21:00:13   state           on, 17.15 W
      2010-02-01 21:00:13   usage           0.01715
Attributes:
    TIMER      300
    room       Wohnen

Diese Werte sind Werte, die vom jeweiligen Gerät stammen und mittels einer
lustigen Formel aus 7 Pulsen 0.01715 kWh machen. Jeder Circle hat hier an-
dere Werte, vermutlich (das Protokoll ist ja reverse engineered) sind das
Meßwerte oder Konstanten aus der Herstellung, vielleicht auch aus dem lau-
fden Betrieb, die aus Zählerdurchläufen eine Lastaussage machen. Das hat,
bei aller Liebe, in keinem Frontend auf diesem Planeten irgendeine endnutz-
errelevante Bedeutung. Daher wäre ich *sehr* dafür, das auch schon *nicht*
bei "list" auszugeben ("list all" oder "list debug" wäre
da zielführend). Relevant ist, und das ist ja auch die Funktion dieser
Zwischenstecker a) die aktuell gemessene Leistungsaufnahme und b) der Zu-
stand des Relais (an/aus). Genau das steht in den READINGS.

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

Siehe oben, das ist, um es deutlich zu sagen, in meinen Augen in dieser
Allgemeinheit, "nicht zielführend". (Die gelesenen Infos werden noch
steigen, da für Aussagen über Zeiträume ungleich 1 & 8 Sekunden der "to-
tals"-Zähler ausgewertet werden muß; der nullt sich aber zur vollen Stun-
de (die Zwischenstecker sind zeitsynchronisiert), weshalb beim Stunden-
übergang der Wert der letzten Stunde über eine andere Abfrage geholt wer-
den muß. Auch das muß noch irgendwo hin (da die Abfragen und Antworten
nur in einem losen Zusammenhang stehen), und auch das hat ohne weitere
Informationen, die z. T. als Augenblickswert nicht gespeichert werden,
da hernach nicht mehr benötigt, keinen Informationsgehalt für $irgendwen
außer das Modul selbst.)

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

Gut, aber am konkreten Beispiel Plugwise wird imho schon deutlich, daß
nicht alles, was gelesen wird, sinnvolle, präsentable Information dar-
stellt?

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

Ich hatte die DS1820-Doku so verstanden, daß man durchaus auf den 1-Wire-Bus
ein Kommando legen kann, woraufhin dann die 1820 mit Alarm wg. Schwellwert-
übertretung sich melden? Aber ich kann mich irren, vielleicht implementiert
OWFS das auch nur nicht; ist hier auch egal.

Aber, nach Deiner eigenen Definition oben ...

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

... gehörte das doch in die READINGS, da "vom device _ausgelesen_". Oder
verstehe ich Dich miß?

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

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

ich mach dann einfach mal einen "konkreten" Vorschlag als
Dikusionsgrundlage ))

:CORE
$defs{} -> fhem.pl Core-Daten z.B. DEF,BTN,CODE

:READINGS
$defs{}{READINGS}{VAL} -> Messdaten vom Device u.a. Switch:On/
Off,Temperature,WindowOpen
$defs{}{READINGS}{TIME} -> Zeitstempel
$defs{}{READINGS}{UNIT} -> Einheit °C, rel% etc.
$defs{}{READINGS}{HISTORY} -> die letzten n Werte (z.B. 20) ->
z.B. für http://omnipotent.net/jquery.sparkline/

WindowOpen könnte auch unter $defs{}{PROPERTIES} stehen ??

:PROPERTIES
"Physikalische" Eigenschaften des Devices
$defs{}{PROPERTIES}{MODEL}
$defs{}{PROPERTIES}{MODELFAMILY}
$defs{}{PROPERTIES}{BATTERY}
Informationen wie z.B. Modell oder Battery stehen dann immer an der
selben Stelle,
unabhängig ob jetzt z.B. Modell vom Device (HMS) geliefert wird oder
vom User (FS20) gesetzt wurde.

:UI
Daten zur Darstellung im UI
$defs{}{UI}{SETS} -> Select-Liste FHEMWEB z.B. On/Off, mon-
from1, Model etc.
$defs{}{UI}{STATE} -> Statusübersicht

:DATA
$defs{}{DATA}{HASH} -> Ergebnisse von Berechnungen/
Zwischenspeicher für Berechnungen
"Logische" Devices z.B. Dummy oder RRDLog schreiben ihre Daten NUR
hier.

:TMP
$defs{}{TMP} -> Temporäre Daten; keine Sicherung z.B. MSG_COUNT

:MSG
$defs{}{MSG}[ARRAY] -> Meldungen vom Device/Modul z.B. "Habe
DasOderDas getan"
Hier könnten auch die letzten 5 Log-Einträge des Devices stehen....
Oder was auch immer der Entwickler des Moduls für wichtig hält....

:LOG
$defs{}{LOG}{SHORT} -> so in der Art: T:29 H:50%
$defs{}{LOG}{CHANGED_READINGS} ->
"Temperature,Humidity,Rain"....
$defs{}{LOG}{CHANGED_DATA} -> "Cum_Day,Avg_Month" ....

:ATTR
$attr{}
- Deviceabhängige Werte zum Steuern des Gerätes
- Berechnungsgrundlagen CostePerUnit; Umrechnungsfaktoren etc.
- Enable/Disable
- z.B. $attr{}{HISTORY_Count} -> Anzahl der Werte in $defs
{}{READINGS}{HISTORY}

Bis auf $defs{}{TMP} werden alle Daten per SAVE gesichert.


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.

[Guest]

Originally posted by: <email address deleted>

Nur kurze Frage:

Axel wrote:
> ich mach dann einfach mal einen "konkreten" Vorschlag als
> Dikusionsgrundlage ))
[...]

> :READINGS
> $defs{}{READINGS}{VAL} -> Messdaten vom Device u.a. Switch:On/
> Off,Temperature,WindowOpen
> $defs{}{READINGS}{TIME} -> Zeitstempel
> $defs{}{READINGS}{UNIT} -> Einheit °C, rel% etc.
> $defs{}{READINGS}{HISTORY} -> die letzten n Werte (z.B. 20) ->
> z.B. für http://omnipotent.net/jquery.sparkline/

Das müßte $defs{}{READINGS}{}{... sein,
also {VAL}, {TIME}, {UNIT}, {HISTORY} je gelesenem Wert, oder?
         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>

Ja...

:READINGS
$defs{}{READINGS}{}{VAL} -> Messdaten vom Device
u.a. Switch:On/
Off,Temperature,WindowOpen
$defs{}{READINGS}{}{TIME} -> Zeitstempel
$defs{}{READINGS}{}{UNIT} -> Einheit °C, rel% etc.
$defs{}{READINGS}{}{HISTORY} -> die letzten n
Werte (z.B. 20) ->
z.B. für http://omnipotent.net/jquery.sparkline/

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 Montag 01 Februar 2010 schrieb Kai 'wusel' Siering:
> 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

me, myself and i... wenn du dir die screenshots von myhce mal näher anschaust,
dann wirst du sehen (achtung übertreibung ) der wolf im schafspelz daher
kommt. einerseits wird in z.b. den räumen nur angezeigt, was der nutzer (mann,
frau, kind, oma, opa ) sehen will: welche geräte kann ich schalten, bzw.
welchen zustand hat sensor x.

_ich_ oder vielleicht auch _du_ oder ein anderer der mit den internals
vertraut ist, will aber auch bei bedarf mal schnell einen value sehen _ohne_
erst ein telnet zu öffnen. und genau deshalb habe ich das so realisiert, dass
wenn man in myhce auf das geräte-icon selber klickt, werden alle internals,
readings und attribute angezeigt. und das möchte ich auch so beibehalten und
deshalb wäre es einfach zu wenig wenn xmllist künftig nur die readings liefern
würde.

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

wäre zu überlegen.

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

das liegt einfach daran, das es zu zeiten von myhce 0.9.2 keinerlei CUL geräte
gab! der schwerpunkt war damals FS20 (st, di) sowie fht.

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.

[Martin Fischer]

Am Montag 01 Februar 2010 schrieb Kai 'wusel' Siering:
> [...]
>
> Ich denke, Du bist -- wie ich -- zu sehr Techniker. Ich denke, wenn
> ich meiner besseren Hälfte oder meinen Kindern obigen "list" zeigen
> würde, würde ich als Feedback zurück bekommen "äh, was ist 'offruis',
> ist der Wert jetzt gut? Und was sind das alles für Zeiten da, muß das
> da stehen? Das verwirrt doch nur! 7 Watt, DAS will ich doch nur wissen!".

nö.. ich bin zwar techniker aber ich sehe das ganz anders als du es
interpretierst. ich habe das gerade im anderen post anhand von myhce 2.0.0 und
den screenshots erklärt:
deine bessere hälfte oder deine kinder sehen in myhce erstmal nur "7 Watt".
du, der jedoch was mit "offruis" anfangen kann, hat dennoch die möglichkeit
auf das icon _vor_ dem gerätenamen zu klicken und kannst dich auf die schnelle
über genau diese werte informieren ohne ein telnet öffnen zu müssen oder aber
deiner family erklären zu müssen, was sich dahinter verbirgt.
 
> [...]
> Siehe oben, das ist, um es deutlich zu sagen, in meinen Augen in dieser
> Allgemeinheit, "nicht zielführend". (Die gelesenen Infos werden noch
> steigen, da für Aussagen über Zeiträume ungleich 1 & 8 Sekunden der "to-
> tals"-Zähler ausgewertet werden muß; der nullt sich aber zur vollen Stun-
> de (die Zwischenstecker sind zeitsynchronisiert), weshalb beim Stunden-
> übergang der Wert der letzten Stunde über eine andere Abfrage geholt wer-
> den muß. Auch das muß noch irgendwo hin (da die Abfragen und Antworten
> nur in einem losen Zusammenhang stehen), und auch das hat ohne weitere
> Informationen, die z. T. als Augenblickswert nicht gespeichert werden,
> da hernach nicht mehr benötigt, keinen Informationsgehalt für $irgendwen
> außer das Modul selbst.)

ich glaube du verstehst hier meinen ansatz nicht oder aber ich habe mich da
unklar ausgedrückt:

alles was in readings steht, heisst auch nicht gleich, das alles
wiederverwertet werden muss. und schon garnicht in frontends. es geht hier um
eine klare abgrenzung:

readings = was liefert mir das gerät an informationen, die ich evtl.
weiterverarbeiten will. wenn man jedoch die ausgelesenen werte wieder
aufsplitten würde, dann würde es nur irreführend sein.

> >> 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.
>
> Gut, aber am konkreten Beispiel Plugwise wird imho schon deutlich, daß
> nicht alles, was gelesen wird, sinnvolle, präsentable Information dar-
> stellt?

siehe oben: nicht alles soll auch nach auss präsentiert werden. und damit
meine ich ein frontend. seien wir doch mal ehrlich: die anzahl der nutzer die
ihre haussteuerung ausschliesslich von der fhem-console aus steuern würde ich
als gering bezeichnen. dieser geringer anteil kennt jedoch fhem so gut, das
man sich auch bewusst ist, was die einzelnen werte bedeuten. und wenn nicht,
dann sind diese ja hoffentlich in der commandref.html dokumentiert.

der endanwender sollte weder die notwendigkeit haben die commandref.html lesen
zu müssen, geschweige denn die werte eines "list " interpretieren zu
müssen. dafür gibts dann frontends wie pgm2, pgm3, myhce, etc.

> [... OWTEMP ALARM ...]
> | 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.
>
> ... gehörte das doch in die READINGS, da "vom device _ausgelesen_". Oder
> verstehe ich Dich miß?

ja machst du weil der alarm nicht vom sensor ausgelesen wird, sondern die
temperatur. ALARM ist eine erfindung von mir, nicht vom OW-device. ergo:
ALARM gehört nicht in die readings.

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.

[Martin Fischer]

Am Dienstag 02 Februar 2010 schrieb Axel:
> ich mach dann einfach mal einen "konkreten" Vorschlag als
> Dikusionsgrundlage ))
>
> :CORE
>
> $defs{} -> fhem.pl Core-Daten z.B. DEF,BTN,CODE

ACK

> :READINGS
>
> $defs{}{READINGS}{VAL} -> Messdaten vom Device u.a. Switch:On/
> Off,Temperature,WindowOpen
> $defs{}{READINGS}{TIME} -> Zeitstempel
> $defs{}{READINGS}{UNIT} -> Einheit °C, rel% etc.
> $defs{}{READINGS}{HISTORY} -> die letzten n Werte (z.B. 20) ->

ACK

> z.B. für http://omnipotent.net/jquery.sparkline/
>
> WindowOpen könnte auch unter $defs{}{PROPERTIES} stehen ??
>
> :PROPERTIES
>
> "Physikalische" Eigenschaften des Devices
> $defs{}{PROPERTIES}{MODEL}
> $defs{}{PROPERTIES}{MODELFAMILY}
> $defs{}{PROPERTIES}{BATTERY}
> Informationen wie z.B. Modell oder Battery stehen dann immer an der
> selben Stelle,
> unabhängig ob jetzt z.B. Modell vom Device (HMS) geliefert wird oder
> vom User (FS20) gesetzt wurde.

könnte ich mit leben, sofern klar definiert ist, was properties sind, so dass
das nicht von modulentwicklern missverstanden wird und dann viele readings in
properties verschoben werden.

> :UI
>
> Daten zur Darstellung im UI
> $defs{}{UI}{SETS} -> Select-Liste FHEMWEB z.B. On/Off, mon-
> from1, Model etc.
> $defs{}{UI}{STATE} -> Statusübersicht

NACK. da alle daten bereits in den readings, core, properties, etc. stehen.
ausserdem würdest du die frontend-entwickler damit eingrenzen bzw. sie
bedienen sich zusätzlich wieder den werten aus readings.

> :DATA
>
> $defs{}{DATA}{HASH} -> Ergebnisse von Berechnungen/
> Zwischenspeicher für Berechnungen
> "Logische" Devices z.B. Dummy oder RRDLog schreiben ihre Daten NUR
> hier.

ACK

> :TMP
>
> $defs{}{TMP} -> Temporäre Daten; keine Sicherung z.B. MSG_COUNT

ACK

> :MSG
>
> $defs{}{MSG}[ARRAY] -> Meldungen vom Device/Modul z.B. "Habe
> DasOderDas getan"
> Hier könnten auch die letzten 5 Log-Einträge des Devices stehen....
> Oder was auch immer der Entwickler des Moduls für wichtig hält....

sehe ich momentan noch keine verwendung.
 
> :LOG
>
> $defs{}{LOG}{SHORT} -> so in der Art: T:29 H:50%
> $defs{}{LOG}{CHANGED_READINGS} ->
> "Temperature,Humidity,Rain"....
> $defs{}{LOG}{CHANGED_DATA} -> "Cum_Day,Avg_Month" ....

hier sehe ich auch noch nicht unbedingt den vorteil.

> :ATTR
>
> $attr{}
> - Deviceabhängige Werte zum Steuern des Gerätes
> - Berechnungsgrundlagen CostePerUnit; Umrechnungsfaktoren etc.
> - Enable/Disable
> - z.B. $attr{}{HISTORY_Count} -> Anzahl der Werte in $defs
> {}{READINGS}{HISTORY}

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.

[Guest]

Originally posted by: <email address deleted>

(Um das von der eigentlichen Diskussion abzugrenzen, separat.)

Martin Fischer wrote:

 >> [... OWTEMP ALARM ...]
 >> | 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.
 >>
 >> ... gehörte das doch in die READINGS, da "vom device _ausgelesen_". Oder
 >> verstehe ich Dich miß?
 >
 > ja machst du weil der alarm nicht vom sensor ausgelesen wird, sondern die
 > temperatur. ALARM ist eine erfindung von mir, nicht vom OW-device. ergo:
 > ALARM gehört nicht in die readings.

Äh, ich will die Liste nicht mit 1-Wire-Device-Details langweilen, daher
nur kurz und für die Langfassung dann http://www.datasheetcatalog.org/datasheet/maxim/DS1820-DS1820S.pdf
lesen:

| OPERATION – ALARM SIGNALING
| After the DS18S20 performs a temperature conversion, the temperature value is compared to the user-
| defined two's complement alarm trigger values stored in the 1-byte TH and TL registers [...]
|
| [...] If the result of a temperature measurement is higher than TH or lower than TL, an
| alarm condition exists and an alarm flag is set inside the DS18S20. [...]
|
| The master device can check the alarm flag status of all DS18S20s on the bus [...]

==> Die grundsätzliche Funktion ALARM stammt vom DS18S20 selbst; wie
jetzt OWFS das implementiert, entzieht sich meiner Kenntnis. Es ist
zumindest möglich, daß ein ALARM bei einem DS18S20 nicht vom OWFS er-
funden sondern vom Gerät gelesen wird; oh, ja, OFWS bietet mit dem Alarm
zusammenhängende Funktionen (http://owfs.org/uploads/DS18S20.3.html#sect6),
daher müßte nach Deiner Definition das meines Erachtens zwingend nach
READINGS. Oder sie müßte umbenannt werden, um den Nutzer nicht damit zu
verwirren, daß die ALARM-Funktion des Geräteunterbaus (OWFS) nichts mit
der ALARM-Funktion des FHEM-Moduls zu tun hat.

Aber das nur am Rande
         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>

Hi,

vorab: ich versuche, mich kurz zu fassen ...

Martin Fischer wrote:

> deine bessere hälfte oder deine kinder sehen in myhce erstmal nur "7 Watt".
> du, der jedoch was mit "offruis" anfangen kann, hat dennoch die möglichkeit
> auf das icon _vor_ dem gerätenamen zu klicken und kannst dich auf die schnelle
> über genau diese werte informieren ohne ein telnet öffnen zu müssen oder aber
> deiner family erklären zu müssen, was sich dahinter verbirgt.

So. Nun ist aber "offruis" in erster Näherung eine Zufallszahl. Und damit
haben diese Werte, werden Sie auch vom Gerät geholt, nirgends außerhalb des
Moduls irgendwas verloren.
Lies: es muß für ein Modul/einen Modulentwickler die Möglichkeit geben, In-
formationen rein modulintern zu halten, gleich, ob diese Informationen nun
vom Gerät gelesen werden oder sonstwoher kommen.
Ein Zwang in Form eines uneingeschränkten "was vom device _ausgelesen_ wird
kommt in die _readings_" ist aus den dargelegten Gründen meiner Ansicht nach
abzulehnen.

>> Gut, aber am konkreten Beispiel Plugwise wird imho schon deutlich, daß
>> nicht alles, was gelesen wird, sinnvolle, präsentable Information dar-
>> stellt?
>
[...]
> man sich auch bewusst ist, was die einzelnen werte bedeuten. und wenn nicht,
> dann sind diese ja hoffentlich in der commandref.html dokumentiert.

Noch so ein Punkt. Warum sollte ich in der commandref.html wahrheitsgemäß ...

   READINGS:

   offruis      internal value, just ignore it
   offtot      internal value, just ignore it
   gaina      internal value, just ignore it
   gainb      internal value, just ignore it
   usage      current usage in kWh, as calculated by a complicated formula using ticks, gaina, gainb, offtot and offruis

... schreiben müssen? IMHO eine Arbeitsbeschaffungsmaßnahme, sonst nix :-/

Ciao,
         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 Mittwoch 03 Februar 2010 schrieb Kai 'wusel' Siering:
> (Um das von der eigentlichen Diskussion abzugrenzen, separat.)
>
> [...]
> Äh, ich will die Liste nicht mit 1-Wire-Device-Details langweilen, daher
> nur kurz und für die Langfassung dann
>  http://www.datasheetcatalog.org/datasheet/maxim/DS1820-DS1820S.pdf
>
> lesen:

las uns das mal bitte vertagen, dann können wir gerne darüber nochmal in einem
anderen thread fachsimpeln. das soll kein ausweichen sein aber im moment
sollten wir in diesem thread einfach mal beim thema bleiben.

denn scheinbar ist das interesse an "FHEM standards" nur bei dir, axel und mir
geweckt, da sonst nichts weiter kommt. ich frage mich ernsthaft ob es noch
sinn macht weiter zu diskutieren. ist ja schön und gut, wenn wir drei uns bis
auf wenige punkte einig sind aber was bringt es uns letztlich wenn keiner
mitzieht.

und dabei haben wir gerade mal erst die internals angesprochen und nichtmal
die readings oder attribute.

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>

Hi,

Martin Fischer wrote:

> las uns das mal bitte vertagen, dann können wir gerne darüber nochmal in einem
> anderen thread fachsimpeln. das soll kein ausweichen sein aber im moment
> sollten wir in diesem thread einfach mal beim thema bleiben.

Drum ja auch anderes Subject; will Dir auch nicht zu nahe treten damit, zu-
mal ich mich mit OWFS nicht weiter befaßt habe bislang. Wollte nur aufzeigen,
daß wir an der Stelle offensichtlich aneinander vorbei reden/andere Alarm-
Indikatoren meinten.
         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>

Hi,

Martin Fischer wrote:

 > denn scheinbar ist das interesse an "FHEM standards" nur bei dir, axel und mir
 > geweckt, da sonst nichts weiter kommt. ich frage mich ernsthaft ob es noch
 > sinn macht weiter zu diskutieren. ist ja schön und gut, wenn wir drei uns bis

Vielleicht sieht sonst keiner ein Problem und wir sollten kollektiv unseren
Geisteszustand untersuchen lassen? Oder andere haben nicht die Zeit/Muße,
sich damit detailiert zu befassen ...

Wie auch immer, ich hoffe, daß am Ende zumindest ein grober Leitfaden raus-
fällt, der es potentiellen Autoren zukünftig einfacher macht, da reinzukommen.

Und, hey, CUL_EM schreibt immerhin schon mal READINGS jetzt, und WS3600 bläßt
je Update rd. 40 CHANGED[] weniger raus -- ist doch auch schon mal was

Ciao,
         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 Kai, und das Stamdarts-Team

Kai 'wusel' Siering schrieb:
> Hi,
>
> Vielleicht sieht sonst keiner ein Problem und wir sollten kollektiv
> unseren
> Geisteszustand untersuchen lassen? Oder andere haben nicht die
> Zeit/Muße,
> sich damit detailiert zu befassen ...

Ich wuerde mich sehr gerne naeher mit den Internas und den Modulen
beschaeftigen. Ich habe noch zwei Projekte offen, fuer die es vermutlich
mal ein Modul braucht.
Da ich mich mit der Programmierung von FHEM im Speziellen, von Perl im
Allgemeinen noch nicht sehr auseinandergesetzt habe, kann ich euren
Ausfuehrungen ganz einfach nicht folgen. Deshalb vermutlich das
schweigen von den vielen anderen mitlesern hier. Das deutet weniger auf
desinteresse, ich denke es deutet eher darauf hin, das ihr bereits so
"hohe" Diskussionen führt, das hier einfach kaum mehr jemand mitreden kann.

Daher bitte ich euch, mein "Schweigen" auf der Liste bei diesem Thema
nicht als Desinteresse zu betrachten. Ich halte mich zurueck weil ich
einfach keine Ahnung habe. Denn ein alter Spruch sagt ja: Wenn du keine
Ahnung hast, einfach mal die fr*** halten.

Vielen Dank fuer den grossen Beitrag von euch,
ihr werdet mir den Einstieg damit vereinfachen.

Viele Grueße, schoenen Abend
Stefan


--
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 03.02.10 20:14, "Martin Fischer" wrote:

> denn scheinbar ist das interesse an "FHEM standards" nur bei dir, axel und mir
> geweckt, da sonst nichts weiter kommt. ich frage mich ernsthaft ob es noch
> sinn macht weiter zu diskutieren. ist ja schön und gut, wenn wir drei uns bis
> auf wenige punkte einig sind aber was bringt es uns letztlich wenn keiner
> mitzieht.

Nunja... ich hatte ja meinen Senf zur Semantik des Codes vor einer Weile
hier gepostet. Ebenso, wie ich mit meinen Änderungen zum FileLog verfahren
sollte. Da hat sich niemand geregt, weshalb ich von einer erwünschten
'Fremdbeteiligung' bisher nicht ausgegangen bin. Deshalb hielt ich diesen
Thread bislang mehr für eine 'interne' Diskussion.
 
> und dabei haben wir gerade mal erst die internals angesprochen und nichtmal
> die readings oder attribute.

Ebent...

Also versuche ich's mal:

Grundsätzlich vertrete ich diesen Standpunkt:
 
-  Alles GROSS geschrieben halte ich für etwas fragwürdig, ich würde Klassen
mit einem Grossbuchstaben beginnen und dann Camel-Case weiterschreiben.
- Variablen, Pointers klein beginnen und dann Camel-Case.
- GLOBALE gross (meinetwegen auch Konstanten)
- Weiterhin würde ich Daten vom Code trennen.
- :UI und :TMP haben in fhem.pl m.E. nix verloren, hierfür könnte man
Adapter schaffen
- dto. für :MSG (dazu gibt's ja ein Log)
- Attribute und Properties, sowie die sporadisch auftretenden STATEs könnte
man vielleicht so organisieren, dass sie abstrakter nutzbar sind. (Im Moment
ist mir in einigen Bereichen die Kategorisierung dieser Werte ohnehin nicht
so ganz klar - kann aber auch an mangelndem fhem-Verständnis meinerseits
liegen)

Viel schlimmer bei der Betrachtung des Codes ist für meine Augen aber die
Lesbarkeit des Codes. Die Variablennamen sind nicht 'sprechend', ebensowenig
wie viele Funktionsaufrufe. Inline-Kommentare/Doku vermisse ich ebenso
schmerzlich. Dies sind für mich - als potentieller Mithelfer - die größten
Hürden. Eine gemeinsame Semantik innerhalb der Module würde den Einstieg für
Non-fhem-Profis deutlich erleichtern...









andy

[Martin Fischer]

hallo stefan,

Am Mittwoch 03 Februar 2010 schrieb Stefan:
> [...]
> Daher bitte ich euch, mein "Schweigen" auf der Liste bei diesem Thema
> nicht als Desinteresse zu betrachten. Ich halte mich zurueck weil ich
> einfach keine Ahnung habe. Denn ein alter Spruch sagt ja: Wenn du keine
> Ahnung hast, einfach mal die fr*** halten.
>
> Vielen Dank fuer den grossen Beitrag von euch,
> ihr werdet mir den Einstieg damit vereinfachen.

danke für deine positive rückmeldung! sie signalisiert mir das auch künftige
entwickler sehr wohl interesse an diesem thema haben.

mein wink mit dem zaunpfahl ging ja auch in erster linie an die aktiven
entwickler mit der bitte sich zu beteiligen.

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.