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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
hallo andy..
Am Mittwoch 03 Februar 2010 schrieb Andy Fuchs:
> [...]
>
> 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.
bei weitem: nein! endlich ist das eis gebrochen ;-) und das bei den
temperaturen..
> [...]
> 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)
ich bin da dicht bei dir. du steigst allerdings schon tiefer auf quelltext
ebene ein was die schreibweise angeht. ich wär schon froh, wenn wir erstmal
eine regel für die inhalte hinbekämen, die mittels "list" dargestellt wird und
dann natürlich "empfehlungen" für den quelltext zu definieren.
ein schönes beispiel ist in meinen augen:
http://pear.php.net/manual/de/standards.php
dies ist nur ein beispiel von vielen. es ist ja nicht so, das wir die ersten
sind die sich darüber gedanken machen. vielleicht kann man ja auch gewisse
sachen einfach übernehmen und viele diskussionen sparen.
> 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...
ja, da schliess ich mich ein, das auch mein code nicht immer sauber
dokumentiert ist. zumindest habe ich meist camel-case eingesetzt :-) aber mit
den inline kommentaren war ich auch eher sparsam ;-)
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.