[FHZ] 95_RRD_Log.pm

[Guest]

Originally posted by: <email address deleted>

Salve,

kann es sein, daß S300 & das RRD-Log-Modul derzeit einfach nicht gehen,
weil CUL_WS/wer_auch_immer gar keine relevanten READINGS setzt?

Internals:
    CODE       7
    CUL_MSGCNT 18
    CUL_RAWMSG K61106257E7
    CUL_RSSI   -86.5
    CUL_TIME   2010-01-24 19:29:04
    DEF        7
    IODev      CUL
    LASTIODev  CUL
    MSGCNT     18
    NAME       Bad_TH
    NR         34
    STATE      T: 21  H: 57.6
    TYPE       CUL_WS
    corr1      0
    corr2      0
    corr3      0
    corr4      0
    Readings:
      2010-01-24 19:29:04   DEVFAMILY       WS300
      2010-01-24 19:29:04   DEVTYPE         S300TH
      2010-01-24 19:29:04   state           T: 21  H: 57.6
Attributes:
    room       Bad


Internals:
    CODE       07bf
    CUL_MSGCNT 12
    CUL_RAWMSG H07BF00433233E0
    CUL_RSSI   -90
    CUL_TIME   2010-01-24 19:39:22
    DEF        07bf
    IODev      CUL
    LASTIODev  CUL
    MSGCNT     12
    NAME       Arbeit_TF
    NR         27
    STATE      T: 24.3  H: 33.3  Bat: ok
    TYPE       HMS
    Readings:
      2010-01-24 19:39:22   battery         ok
      2010-01-24 19:39:22   humidity        33.3 (%)
      2010-01-24 19:39:22   temperature     24.3 (Celsius)
      2010-01-24 19:39:22   type            HMS100TF
Attributes:
    model      hms100-tf
    room       Arbeit


Sofern ich das richtig analysiert habe -- comments, please --, fixe ich
das in CUL_WS (oder wo auch immer die Meldungen landen) und klebe in
95_RRD_Log.pm noch die Definitionen für Plugwise hinzu.
         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.

[rudolfkoenig]

                                                   

> Sofern ich das richtig analysiert habe -- comments, please --, fixe ich
> das in CUL_WS (oder wo auch immer die Meldungen landen) und klebe in
> 95_RRD_Log.pm noch die Definitionen für Plugwise hinzu.

Gegen mehr Readings habe ich nichts. Allerdings moechte ich in der Zukunft
CUL_EM/KS300 Artige notify's (10xCHANGED/Trigger pro RF-Telegramm) vermeiden.
Insb. mit autocreate kriegt man sehr schnell sehr viele FileLogs, und damit
enorm viele Funktionsaufrufe.

Ich haette gerne nur ein Trigger pro RF-Nachricht, aber gerne beliebig viele
Readings...

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> Sofern ich das richtig analysiert habe -- comments, please --, fixe ich
>> das in CUL_WS (oder wo auch immer die Meldungen landen) und klebe in
>> 95_RRD_Log.pm noch die Definitionen für Plugwise hinzu.
>
> Gegen mehr Readings habe ich nichts. Allerdings moechte ich in der Zukunft
> CUL_EM/KS300 Artige notify's (10xCHANGED/Trigger pro RF-Telegramm) vermeiden.
> Insb. mit autocreate kriegt man sehr schnell sehr viele FileLogs, und damit
> enorm viele Funktionsaufrufe.
>
> Ich haette gerne nur ein Trigger pro RF-Nachricht, aber gerne beliebig viele
> Readings...

Da ich zumindest das noch nicht wirklich verstanden habe , vielleicht kannst
Du da -- auch für zukünftige Modulbastler -- ähnlich wie zum Thema der Funk-
tionsaufrufe mal ein HowTo zurechttippern?

Konkrete Frage: wie vermeidet man denn "CUL_EM/KS300 Artige notify's"?

Welche Funktion hat/wann rufe ich DoTrigger() auf?

Was bewirkt das Setzen von $hash->{CHANGED}[$i] mit $i==0, $i==1, ...

(In meinem Pw_Circle-Modul für die Auswertung der Plugwise-Teile habe ich
z. B. keinen DoTrigger()-Aufruf und dennoch wird sowohl der Status aktuali-
siert als auch notify-Kommandos in .cfg ausgeführt.)

(Ah, und etwas, was mich ziemlich überrascht hat: Wieso ändert eine Änderung
an $hash->{STATE} $hash->{READINGS}{state}{VAL}?!)

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

Also, mea culpa, aber für mich ist RRD_Log mehr als borked

fhem> rereadcfg

RRDLOG[SET::ERROR] Bad_TH => temperature => Unkown
RRDLOG[SET::ERROR] Essz_TH => temperature => Unkown
RRDLOG[SET::ERROR] Flur_TH => temperature => Unkown
RRDLOG[SET::ERROR] Kammer_TH => temperature => Unkown
RRDLOG[SET::ERROR] Keller_TH => temperature => Unkown
RRDLOG[SET::ERROR] Huette_TH => temperature => Unkown
RRDLOG[SET::ERROR] Parkplatz_TH => temperature => Unkown
RRDLOG[SET::ERROR] Terrarium_TH => temperature => Unkown
RRDLOG[SET::ERROR] Arbeit_TF => temperature => Unkown
RRDLOG[SET::ERROR] Circle_1 => usage => Unkown
RRDLOG[SET::ERROR] Circle_Sheeva => usage => Unkown
RRDLOG[SET::ERROR] Media_EM => current => Unkown
RRDLOG[SET::ERROR] Arbeit_EM => current => Unkown
RRDLOG[SET::ERROR] TerSrv_EM => current => Unkown

fhem> list Essz_TH
Internals:
    CODE       1
    DEF        1
    IODev      CUL
    NAME       Essz_TH
    NR         37
    STATE      T: 22.2  H: 36.9
    TYPE       CUL_WS
    corr1      0
    corr2      0
    corr3      0
    corr4      0
    Readings:
      2010-01-25 00:27:17   DEVFAMILY       WS300
      2010-01-25 00:27:17   DEVTYPE         S300TH
      2010-01-25 00:27:17   humidity        36.9
      2010-01-25 00:27:17   state           T: 22.2  H: 36.9
      2010-01-25 00:27:17   temperature     22.2
Attributes:
    room       Essen

fhem> list Circle_1
Internals:
    DEF        4be246
    ID         4be246
    IODev      TheStick
    LASTIODev  TheStick
    LASTSEEN   2010-01-25 00:32:53
    MSGCNT     7
    NAME       Circle_1
    NR         6
    STATE      off, 0.21 W
    STATUS     off
    TYPE       Pw_Circle
    TheStick_MSGCNT 7
    TheStick_TIME 2010-01-25 00:32:53
    Calibrate:
      TIME_T     1264375848
      gaina      1.00552022457123
      gainb      -2.3054280973156e-06
      offruis    0
      offtot     -0.000490037200506777
    Power:
      QUERYTIME_T 1264375973
      TIME       2010-01-25 00:32:53
      TIME_T     1264375973
      initialized yes
      pulse1sec  0
      pulse8sec  0
      totals     156
    Readings:
      2010-01-25 00:30:21   state           off, 0.21 W
      2010-01-25 00:32:53   usage           0.00021
Attributes:
    TIMER      30
    room       Wohnen

fhem> list Media_EM
Internals:
    BasicFeePerMonth 0
    CODE       6
    CostPerUnit 0
    DEF        6
    IODev      CUL
    NAME       Media_EM
    NR         69
    STATE      CNT: 54 CUM: 88.347  5MIN: 0.010  TOP: 0.010
    TYPE       CUL_EM
    corr1      0.01
    corr2      0.001
    Readings:
      2010-01-25 00:28:52   RAW             CNT: 54 CUM: 22811  5MIN: 1  TOP: 1
      2010-01-11 14:28:29   basis           65536
      2010-01-25 00:03:52   cum_day         CUM_DAY: 1.647 CUM: 88.344 COST: 0.00
      2010-01-25 00:28:52   current         0.01
      2010-01-25 00:28:52   current_cnt     1
      2010-01-25 00:28:52   peak            0.01
      2010-01-25 00:28:52   peak_cnt        1
      2010-01-25 00:28:52   seqno           54
      2010-01-25 00:28:52   total           88.347
      2010-01-25 00:28:52   total_cnt       22811
      2010-01-25 00:28:52   tsecs           1264375732
Attributes:
    room       Wohnen

Also, die READINGS sind da; warum ...

         my $def_type = $defs{$a[2]}{TYPE};
         foreach my $reading (@readings){
             if(!defined($defs{$a[2]}{READINGS}{$reading})) {return "RRDLOG[SET::ERROR]
$a[2] => $reading => Unkown";}
             if(!defined($data{RRD_LOG}{READING}{$def_type}{$reading})) {return
"RRDLOG[SET::ERROR] $a[2]  => $reading => not supported";}
             }

... ins Essen bricht bei ...

   # CUL_WS => S555TH, S300TH
   $data{RRD_LOG}{READING}{CUL_WS}{'temperature'} = "RRD_Log_5minGAUGE";
   $data{RRD_LOG}{READING}{CUL_WS}{'humidity'} = "RRD_Log_5minGAUGE";
   #CUL_EM
   $data{RRD_LOG}{READING}{CUL_EM}{'current'} = "RRD_Log_5minGAUGE";
   #Pw_Circle
   $data{RRD_LOG}{READING}{Pw_Circle}{'usage'} = "RRD_Log_10secGAUGE";

... verstehe ich nicht
         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.

[rudolfkoenig]

                                                   

> Was bewirkt das Setzen von $hash->{CHANGED}[$i] mit $i==0, $i==1, ...

Im ParseFn Funktion eines Moduls wie FS20/CUL_EM/etc, wird die eingetroffene
Nachricht analysiert, und in "lesbare" Form umgewandelt.

Die Daten werden dann im device eigenen READINGS gespeichert, mit Wert und
Zeitstempel. Letzteres ist fuer Geraete wie FHT noetig, die nicht immer alle
Werte auf einmal uebertragen, im Gegensatz zu einem EM.

Manche dieser Werte (also nur VAL) werden zusaetzlich ins CHANGED gepackt.
Dispatch ruft DoTrigger auf, der  alle Geraete nach NotifyFn absucht, und
diese Funktion mit jedem CHANGED Eintrag einzeln aufruft. Aus dem CHANGED
Eintrag wird ueblicherweise das beruechtigte "%" im notify

Nachdem DoTrigger durch ist, wird CHANGED komplett entfernt.


> Konkrete Frage: wie vermeidet man denn "CUL_EM/KS300 Artige notify's"?

Meine Befuerchtung: Zu viele CHANGED Eintraege machen fhem langsam: ein CUL_EM
RF-Nachricht erzeugt z.Zt 10 CHANGED Eintraege. Das Problem: Mit einem
autocreate lege ich bei mir ca 50 FileLogs an (die jeweils ein NotifyFn
haben) + 20 "richtige" notify = (50+20)*10 = 700 Funktionsaufrufe _pro_
RF Nachricht.

Ich will nur einen Aufruf (== CHANGED Eintrag) pro Nachricht, aber im NotifyFN
auf alle Werte zugreifen koennen. Ich denke man sollte im CUL_WS wie bisher ein
CHANGED Eintrag generieren, aber man bereitet alle Daten "lesbar" im READINGS
vor.


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

Eine weitere Aufgabe ist alle Module durchzugehen, und auf einem gleichen
Namens-schema zu einigen. Das wird zwar wahrscheinlich dann alle irgendwo
treffen, aber es ist besser als der aktuelle Zustand.


> ... ins Essen bricht bei ...

Diese Redewendung bzw. das ganze dazugehoerige Posting verstehe ich nicht.
Kanns du bitte ein Management Summary dazu abgeben ?


Gruss,
  Rudi

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:

>> Was bewirkt das Setzen von $hash->{CHANGED}[$i] mit $i==0, $i==1, ...
>
> Im ParseFn Funktion eines Moduls wie FS20/CUL_EM/etc, wird die eingetroffene
> Nachricht analysiert, und in "lesbare" Form umgewandelt.
>
[...]
> Manche dieser Werte (also nur VAL) werden zusaetzlich ins CHANGED gepackt.
> Dispatch ruft DoTrigger auf, der  alle Geraete nach NotifyFn absucht, und
> diese Funktion mit jedem CHANGED Eintrag einzeln aufruft. Aus dem CHANGED
> Eintrag wird ueblicherweise das beruechtigte "%" im notify
>
> Nachdem DoTrigger durch ist, wird CHANGED komplett entfernt.

Management Summary: Aus jedem CHANGED wird ein notify. Jedes notifiy
wird *jedem Modul mit einer NotifyFn* angeboten.

=> Daumenregel: nur 1 CHANGED-Eintrag pro Gerät setzen! Auswertungen
müssen entsprechend dann Anhand der READINGS in einer entsprechenden
notify-Regel der Config erfolgen; das macht zwar die einzelne fhem.cfg-
notify-Regel komplexer, sie wird aber nur eventuell ausgeführt -- jedes
CHANGED-Feld erzeugt aber *immer* einen Aufruf der NotifyFn *aller*
Geräte, in der Zeit werden auch *keine* anderen Events prozessiert!

(Korrekt so?)

>> Konkrete Frage: wie vermeidet man denn "CUL_EM/KS300 Artige notify's"?
>
> Meine Befuerchtung: Zu viele CHANGED Eintraege machen fhem langsam: ein CUL_EM
> RF-Nachricht erzeugt z.Zt 10 CHANGED Eintraege. Das Problem: Mit einem
> autocreate lege ich bei mir ca 50 FileLogs an (die jeweils ein NotifyFn
> haben) + 20 "richtige" notify = (50+20)*10 = 700 Funktionsaufrufe _pro_
> RF Nachricht.
>
> Ich will nur einen Aufruf (== CHANGED Eintrag) pro Nachricht, aber im NotifyFN
> auf alle Werte zugreifen koennen. Ich denke man sollte im CUL_WS wie bisher ein

"aber im NotifyFN auf alle Werte zugreifen koennen" verstehe ich nicht. Was
in READINGS steht, sollte doch zugreifbar sein?

> CHANGED Eintrag generieren, aber man bereitet alle Daten "lesbar" im READINGS
> vor.

Also $hash->{CHANGED}[0]="new status" und gut? Oder meinst Du mit dem Verweis
auf NofityFn eher $hash->{CHANGED}[0]="T: 99.9 H: 11.1 W: 17,4", also alle
aktuellen Werte in *ein* CHANGED-Feld?

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

Ah, habe mich schon gewundert, wo $value{} wieder herkommt

> Eine weitere Aufgabe ist alle Module durchzugehen, und auf einem gleichen
> Namens-schema zu einigen. Das wird zwar wahrscheinlich dann alle irgendwo
> treffen, aber es ist besser als der aktuelle Zustand.

Namensschema konkret wo?




>> ... ins Essen bricht bei ...
>
> Diese Redewendung bzw. das ganze dazugehoerige Posting verstehe ich nicht.
> Kanns du bitte ein Management Summary dazu abgeben ?

Aber sicherlich doch: 95_RRD_Log.pm funktioniert nicht wie dokumentiert,
es spuckt Fehlermeldungen aus, wo es funktionieren sollte, meckert nicht
existende READINGS an, die de facto aber existieren.


Konkrete Frage: wie definiert man ein CUL_WS, CUL_EM oder HMS-Gerät? Das
Beispiel

   # Beispiel FHT-Name: FHT001
   # set ADD FHT001 measured_temperature:desired_temperature:actuator

ist schon mal doof, da sowohl in FHT-READINGS als auch später im 95_RRD_Log-
Code desired-temp, measured-temp und actuator verwendet werden.

Ich verwende daher in meiner fhem.cfg:

set RRDLog ADD Bad_TH temperature:humidity
set RRDLog ADD Essz_TH temperature:humidity
set RRDLog ADD Flur_TH temperature:humidity
set RRDLog ADD Kammer_TH temperature:humidity
set RRDLog ADD Keller_TH temperature:humidity
set RRDLog ADD Huette_TH temperature:humidity
set RRDLog ADD Parkplatz_TH temperature:humidity
set RRDLog ADD Terrarium_TH temperature:humidity
set RRDLog ADD Arbeit_TF temperature:humidity
set RRDLog ADD Circle_1 usage
set RRDLog ADD Circle_Sheeva usage
set RRDLog ADD Media_EM current
set RRDLog ADD Arbeit_EM current
set RRDLog ADD TerSrv_EM current

Ich bekomme da ausschließlich Fehlermeldungen:

RRDLOG[SET::ERROR] Bad_TH => temperature => Unkown
RRDLOG[SET::ERROR] Essz_TH => temperature => Unkown
RRDLOG[SET::ERROR] Flur_TH => temperature => Unkown
RRDLOG[SET::ERROR] Kammer_TH => temperature => Unkown
RRDLOG[SET::ERROR] Keller_TH => temperature => Unkown
RRDLOG[SET::ERROR] Huette_TH => temperature => Unkown
RRDLOG[SET::ERROR] Parkplatz_TH => temperature => Unkown
RRDLOG[SET::ERROR] Terrarium_TH => temperature => Unkown
RRDLOG[SET::ERROR] Arbeit_TF => temperature => Unkown
RRDLOG[SET::ERROR] Circle_1 => usage => Unkown
RRDLOG[SET::ERROR] Circle_Sheeva => usage => Unkown
RRDLOG[SET::ERROR] Media_EM => current => Unkown
RRDLOG[SET::ERROR] Arbeit_EM => current => Unkown
RRDLOG[SET::ERROR] TerSrv_EM => current => Unkown

Zumindest bei den "alten" Geräten HMS (Arbeit_TF) und CUL_EM (*_EM) hätte
ich Funktion statt Fehler erwartet.
         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.

[rudolfkoenig]

                                                   

> Management Summary: Aus jedem CHANGED wird ein notify. Jedes notifiy
> wird *jedem Modul mit einer NotifyFn* angeboten.

Voll korrekt.


> "aber im NotifyFN auf alle Werte zugreifen koennen" verstehe ich nicht. Was
> in READINGS steht, sollte doch zugreifbar sein?

Ja, das habe ich auch gemeint.


> Also $hash->{CHANGED}[0]="new status" und gut? Oder meinst Du mit dem Verweis
> auf NofityFn eher $hash->{CHANGED}[0]="T: 99.9 H: 11.1 W: 17,4", also alle
> aktuellen Werte in *ein* CHANGED-Feld?

Ich moechte letzteres, sonst kann man die Werte mit FileLog nicht loggen.


> Namensschema konkret wo?

Wir muessten irgendwie vermeiden, dass HMS "temperature: 19.3 (Celsius)", und
FHT "measured-temp: 19.3 (Celsius)" meldet. Oder "current: x.y" in CUL_EM vs.
"power: x.y kW" in EMWZ.


> Konkrete Frage: wie definiert man ein CUL_WS, CUL_EM oder HMS-Gerät? Das
> Beispiel

RRD ist nicht meine Baustelle...

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:

>> Konkrete Frage: wie definiert man ein CUL_WS, CUL_EM oder HMS-Gerät? Das
>> Beispiel
>
> RRD ist nicht meine Baustelle...

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

Rudolf Koenig wrote:

>> "aber im NotifyFN auf alle Werte zugreifen koennen" verstehe ich nicht. Was
>> in READINGS steht, sollte doch zugreifbar sein?
>
> Ja, das habe ich auch gemeint.
>
>> Also $hash->{CHANGED}[0]="new status" und gut? Oder meinst Du mit dem Verweis
>> auf NofityFn eher $hash->{CHANGED}[0]="T: 99.9 H: 11.1 W: 17,4", also alle
>> aktuellen Werte in *ein* CHANGED-Feld?
>
> Ich moechte letzteres,

Das widerspricht sich jetzt

> sonst kann man die Werte mit FileLog nicht loggen.

Mit anderen Worten:

   define FileLog_Arbeit_EM FileLog /var/log/fhem/Arbeit_EM-%Y.log Arbeit_EM:CNT:.*

*setzt voraus*, daß ein CHANGED-Feld "CNT:.*" beinhaltet? Ohne CHANGED landen
die Werte also *niemals* in einem FileLog? Gut zu wissen

Generell wäre es sinnvoll, wenn Module nur geänderte Werte (Status-Änderungen,
also Fenster zu -> auf, TV an -> aus) senden würden, ja; außer bei Temperatur-
und Energiesensoren hingegen will man eher zu jedem Zeitpunkt einen Wert haben
(-> Graphen).

>> Namensschema konkret wo?
>
> Wir muessten irgendwie vermeiden, dass HMS "temperature: 19.3 (Celsius)", und
> FHT "measured-temp: 19.3 (Celsius)" meldet. Oder "current: x.y" in CUL_EM vs.
> "power: x.y kW" in EMWZ.

Oh. Ja, was wäre fein. Wobei das natürlich auch stark verallgemeinert:
FHT ist nun mal ein anderes Gerät als HMS, HMS kennt eine, die aktuelle,
Temperatur, FHT schon mehrere (wenn nicht alle gemessen). Die WS3600 (und
andere WS ebenso) kennen Innen- und Außentemperatur, letztere (und/oder
erstere?) ggf. mehrfach. Siehe commandref.html, was die WS3600/WS2300
so alles ausspuckt.

Das packe ich z. B. *nicht* alles in STATUS, da ich das Web-IF sonst auch
gleich entsorgen könnte (sieht Scheiße, alles in einem ).

   Ti: 21.4 T: -2.9 DP: -4.1 Hi: 32 H: 92 W: 0.0 Dir: WSW WC: -2.9 R: 0.00 P: 1013.900 Tendency: Rising Forecast: Sunny

... ist schon recht lang. Wie also z. B. bei Wetterstationen die unter-
schiedlichen Temperaturen benennen? "measured-temp" sei ok für FHT & HMS,
was ist dann aber "measured-temp" für eine Wetterstation, die Innen- (Ti)
oder die Außentemperatur (T im Beispiel oben)? Bei einem SxxxTH hängt
innen/außen dann wieder von dessen Standort ab, da wäre "measured-temp"
wohl ok.

Anyway, da das eigentlich modulspezifische Dinge sind, die ggf. in der
commandref.html dokumentiert sein sollten (gib's noch kein Feld für),
weiß ich nicht, ob eine "globale Harmonisierung" wirklich irgendwas nach
vorne bringt. Klar wäre es schön, wenn ich nur 1 Eintrag ins Configfile
schreiben müßte, der alle Temperaturwerte, da alle immer "measured-temp.*"
beginnen, abfangen könnte. Da aber Sensoren teils ein unterschiedliches
Zeitraster haben, weiß ich gar nicht, ob das wirklich vorteilhaft wäre?
         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,

> RRD ist nicht meine Baustelle...
95_RRD_Log ist von mir... )
> Also, mea culpa, aber f r mich ist RRD_Log mehr als borked
Also...
> kann es sein, da S300 & das RRD-Log-Modul derzeit einfach nicht gehen,
> weil CUL_WS/wer_auch_immer gar keine relevanten READINGS setzt?
richtig.. )
CUL_WS hat keine READINGs ala $defs{$d}{READINGS}{humidity}

Ich wollte nicht für jedes Modul einen eigenen READINGs-Parser
schreiben...
z.B. CUL_WS: READING: T:15 H:70
Beim Split auf irgendwas:
CUL_WS => Pos 0 = T -> Pos 1 dann der Werte fuer T = 15 etc.
....bei HMS dann wieder anders...
Deshalb habe ich mich entschieden nur "sprechende READINGs" zu
unterstützen.
Beim defineren wird dann überprüft, ob es das READING überhaupt
gibt..wenn nicht -> RRDLOG[SET::ERROR]

Dafür kann man je Device-Type unterscheidliche RRD-Definition
verwenden...
z.B. FHT:
$data{RRD_LOG}{READING}{FHT}{'measured-temp'} = "RRD_Log_15minGAUGE";
$data{RRD_LOG}{READING}{FHT}{'desired-temp'} = "RRD_Log_15minGAUGE";
$data{RRD_LOG}{READING}{FHT}{'actuator'} = "RRD_Log_5minGAUGE";
$data{RRD_LOG}{READING}{FHT}{'rssi'} = "RRD_Log_5minGAUGE";
measured-temp wird nur alle 15min gesendet...deshalb 15minGAUGE
actuator wird alle 2min gesendet...deshalb 5minGAUGE

Oder:
# CUL_WS => S55TH&S300TH
$data{RRD_LOG}{READING}{CUL_WS}{'temperature'} = "RRD_Log_5minGAUGE";
$data{RRD_LOG}{READING}{CUL_WS}{'humidity'} = "RRD_Log_5minGAUGE";
$data{RRD_LOG}{READING}{CUL_WS}{'rssi'} = "RRD_Log_5minGAUGE";

Habe CUL_WS entsprechend angepasst....

Im "Kopf" vom Modul kannst du eigene RRDs fuer jeden Device-Tye
defieren...

Mein Vorschalg zur "Hormisierung" von READINGs wäre:
$hash->{CHANGED}{SHORT} = "T:12.6 H:55.8";
$hash->{CHANGED}{READINGS} = "Temperature;Humidity;etc...";
Es gibt nur noch die zwei Einträge...
Fuer FileLog $hash->{CHANGED}{SHORT}.
Alle anderen koennen sich hier $hash->{CHANGED}{READINGS} abholen was
geaendert wurde
und die Werte direkt aus den READINGs holen.
Aber an den "Massen-Notifies" wird das glaube ich nix aendern...
Da fhem immer alle Notifies durchgehen muss um zu entscheiden, welches
denn nun fuer das aktuelle Event zustaendig ist.
Ich glaube das kann man nur vermeiden, wennd as Event "seine Notifies"
kennt )


Schöne Grüße

Axel

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Martin Fischer]

Am Montag 25 Januar 2010 schrieb Rudolf Koenig:
> > Was bewirkt das Setzen von $hash->{CHANGED}[$i] mit $i==0, $i==1, ...
>
> Im ParseFn Funktion eines Moduls wie FS20/CUL_EM/etc, wird die
>  eingetroffene Nachricht analysiert, und in "lesbare" Form umgewandelt.
> [...]
> Nachdem DoTrigger durch ist, wird CHANGED komplett entfernt.

_das_ war auch mir so neu... lag wohl am mangel an doku

> [...]
> Ich will nur einen Aufruf (== CHANGED Eintrag) pro Nachricht, aber im
>  NotifyFN auf alle Werte zugreifen koennen. Ich denke man sollte im CUL_WS
>  wie bisher ein CHANGED Eintrag generieren, aber man bereitet alle Daten
>  "lesbar" im READINGS vor.

mal auf die schnelle eine idee:
jedes reading bekommt einen schlüssel. alle schlüssen, die geändert wurden,
werden dann in ein array geschrieben. und das array wird dann von CHANGED
gentzt. wer dann auf diese änderungen reagieren will/muss hat dann im array
eine eindeutige kennung des devices (z.b. devicenamen, nr., etc) und im array
die schlüssel zu den geänderten readings. dann kann anhand der eindeutigen
kennung und des schlüssels der geänderte wert direkt abgefragt werden.

> [...]
> Eine weitere Aufgabe ist alle Module durchzugehen, und auf einem gleichen
> Namens-schema zu einigen. Das wird zwar wahrscheinlich dann alle irgendwo
> treffen, aber es ist besser als der aktuelle Zustand.

eindeutiges ACK! schön das du das ansprichst, sonst hätte ich es die tage in
die runde geschmissen. ein paar beispiele, die mir gerade so einfallen:
bat, battery, Battery
zusammengesetzte wörter mal zusammengeschrieben, mal mit - als trenner und mal
mit _. besonders das - bereitet mir zusätzliche arbeit, da ich für myhce
smarty als template-engine nutze und ich das vorher immer in z.b. {assign
var=measured_temp value="measured-temp"} mappen und dann mit {measured_temp}
weiterabreiten muss/kann, da smarty sonst subtrahieren will, also "measured
minus temp" = ?

ich wäre auch sehr dafür, dass das ganze harmonisiert wird. und wenn wir schon
dabei sind auch gleich UTF unterstützung beinhaltet.

letztes ist mir z.b. bei 59_Weather aufgefallen. warum soll ich englisch
nehmen, wenn ich die anzeige gerne in deutsch hätte? dann könnte nämlich
Weather einfach als parameter die landessprache anhängen und boris müsste z.b.
nicht extra fahrenheit und mph umrechnen.

ich gebe aber kai recht, dass das namensschema gut überlegt sein muss, weil es
halt auch sensoren gibt, die eben nicht nur z.b. "temperature" liefern sondern
eben mehrere temperatur-werte bereitstellen.

allerdings sollte man das theme auch nicht auf die lange bank schieben.

wie machen es denn die anderen? vielleicht kann das ja mal jemand als sein
persönlichen beitrag zu fhem recherchieren um mal paar ideen zu sammeln.

gruss...

--
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 25 Januar 2010 schrieb Rudolf Koenig:
> [...]
> > Also $hash->{CHANGED}[0]="new status" und gut? Oder meinst Du mit dem
> > Verweis auf NofityFn eher $hash->{CHANGED}[0]="T: 99.9 H: 11.1 W: 17,4",
> > also alle aktuellen Werte in *ein* CHANGED-Feld?
>
> Ich moechte letzteres, sonst kann man die Werte mit FileLog nicht loggen.

ja, dann aber bitte mit einem zeiger auf das reading, sonst diskutieren wir
morgen wieder wofür steht denn ein T oder W. w könnte nämlich beim hms auch
für "Water detect" stehen und nicht für "Wind".

> > Namensschema konkret wo?
>
> Wir muessten irgendwie vermeiden, dass HMS "temperature: 19.3 (Celsius)",
>  und FHT "measured-temp: 19.3 (Celsius)" meldet. Oder "current: x.y" in
>  CUL_EM vs. "power: x.y kW" in EMWZ.

ACK! auch das (Celsius) müsste dort raus und nur einmal in der fhem config
hinterlegt sein, welche masseinheit denn die werte haben. das wäre ein
weiterer schritt in "internationalisierung".. vielleicht noch mit einm flag
versehen ob die masseinheit immer hinter den werten angezeigt werden soll (für
status) oder eben nicht. gui's könnten dann die globalen masseinheiten nutzen
um es evtl. anzuzeigen oder aber auch eben nicht. denn auch hier muss man zur
zeit viel parsen und strings kürzen bis dann eben nur der integer angezeigt
wird.
 
> > Konkrete Frage: wie definiert man ein CUL_WS, CUL_EM oder HMS-Gerät? Das
> > Beispiel
>
> RRD ist nicht meine Baustelle...
>

obwohl auch ich seit vielen jahren rrd-tools wurde ich aus dem modul auch noch
nicht so richtig schlau. dazu muss ich aber auch sagen, das ich mich nur kur
damit befasst habe in dem ich die doku dazu lass. keine kritik aber motivation
um z.b. die doku aufzuarbeiten.

gruss..

--
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 25 Januar 2010 schrieb Kai 'wusel' Siering:
> [...]
> Generell wäre es sinnvoll, wenn Module nur geänderte Werte
>  (Status-Änderungen, also Fenster zu -> auf, TV an -> aus) senden würden,
>  ja; außer bei Temperatur- und Energiesensoren hingegen will man eher zu
>  jedem Zeitpunkt einen Wert haben (-> Graphen).

guter einwand! du hast recht: status-wechsel nur bei änderung würde auf
jedenfall di anzahl der notify's verringern.

> > Wir muessten irgendwie vermeiden, dass HMS "temperature: 19.3 (Celsius)",
> > und FHT "measured-temp: 19.3 (Celsius)" meldet. Oder "current: x.y" in
> > CUL_EM vs. "power: x.y kW" in EMWZ.
>
> Oh. Ja, was wäre fein. Wobei das natürlich auch stark verallgemeinert:
> FHT ist nun mal ein anderes Gerät als HMS, HMS kennt eine, die aktuelle,
> Temperatur, FHT schon mehrere (wenn nicht alle gemessen). Die WS3600 (und
> andere WS ebenso) kennen Innen- und Außentemperatur, letztere (und/oder
> erstere?) ggf. mehrfach. Siehe commandref.html, was die WS3600/WS2300
> so alles ausspuckt.
>
> Das packe ich z. B. *nicht* alles in STATUS, da ich das Web-IF sonst auch
> gleich entsorgen könnte (sieht Scheiße, alles in einem ).
>
>    Ti: 21.4 T: -2.9 DP: -4.1 Hi: 32 H: 92 W: 0.0 Dir: WSW WC: -2.9 R: 0.00
>  P: 1013.900 Tendency: Rising Forecast: Sunny

ich glaube, rudi meint das anders. für deine anzeige nutzt du ja nicht STATUS,
sondern holst dir die einzelnen werte aus den readings. so mache ich es
zumindest in myhce, da ich sonst *zig-verschiedene statusformate parsen
müsste. der aufwand wäre zu hoch.

aber ich gebe dir in so weit recht, das ein 'list' auf der fhem-console auch
möglichst lesbare werte liefern sollte. und so'ne zeile wie oben wäre da nicht
sonderlich lesbar.

aber deine statuszeile macht widerum deutlich was rudi und auch du meintest.
einerseits muss es eine unterscheidung zwischen "Temperatur innen" und
"aussen", sowie "Tendency" (bei dir Ti:, T: und Tendency:) geben aber
andererseit müsste es auch eine regel geben, die dann vermeidet, dass kein
"mischmash" zwischen abkürzungen und ausgeschriebenen bezeichnern ensteht wie
gerade von dir dargestellt.

gruss..


> ... ist schon recht lang. Wie also z. B. bei Wetterstationen die unter-
> schiedlichen Temperaturen benennen? "measured-temp" sei ok für FHT & HMS,
> was ist dann aber "measured-temp" für eine Wetterstation, die Innen- (Ti)
> oder die Außentemperatur (T im Beispiel oben)? Bei einem SxxxTH hängt
> innen/außen dann wieder von dessen Standort ab, da wäre "measured-temp"
> wohl ok.
>
> Anyway, da das eigentlich modulspezifische Dinge sind, die ggf. in der
> commandref.html dokumentiert sein sollten (gib's noch kein Feld für),
> weiß ich nicht, ob eine "globale Harmonisierung" wirklich irgendwas nach
> vorne bringt. Klar wäre es schön, wenn ich nur 1 Eintrag ins Configfile
> schreiben müßte, der alle Temperaturwerte, da alle immer "measured-temp.*"
> beginnen, abfangen könnte. Da aber Sensoren teils ein unterschiedliches
> Zeitraster haben, weiß ich gar nicht, ob das wirklich vorteilhaft wäre?
>          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 Montag 25 Januar 2010 schrieb Axel:
> [...]
> Im "Kopf" vom Modul kannst du eigene RRDs fuer jeden Device-Tye
> defieren...
>
> Mein Vorschalg zur "Hormisierung" von READINGs wäre:
> $hash->{CHANGED}{SHORT} = "T:12.6 H:55.8";
> $hash->{CHANGED}{READINGS} = "Temperature;Humidity;etc...";
> Es gibt nur noch die zwei Einträge...
> Fuer FileLog $hash->{CHANGED}{SHORT}.
> Alle anderen koennen sich hier $hash->{CHANGED}{READINGS} abholen was
> geaendert wurde
> und die Werte direkt aus den READINGs holen.

auch ein vorschlag, der meinem (mit dem array) nahekommt. nur wozu sollte man
dann noch SHORT benötigen?

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

[Guest]

Originally posted by: <email address deleted>

Martin Fischer wrote:

>> Das packe ich z. B. *nicht* alles in STATUS, da ich das Web-IF sonst auch
>> gleich entsorgen könnte (sieht Scheiße, alles in einem ).
>>
>>    Ti: 21.4 T: -2.9 DP: -4.1 Hi: 32 H: 92 W: 0.0 Dir: WSW WC: -2.9 R: 0.00
>>  P: 1013.900 Tendency: Rising Forecast: Sunny
>
> ich glaube, rudi meint das anders. für deine anzeige nutzt du ja nicht STATUS,
> sondern holst dir die einzelnen werte aus den readings. so mache ich es

pgm, äh, 2? -- also das, was "in fhem.pl drin" ist, gibt (für unbekannte
Geräte zumindest) einfach STATE aus ...

> aber deine statuszeile macht widerum deutlich was rudi und auch du meintest.
> einerseits muss es eine unterscheidung zwischen "Temperatur innen" und
> "aussen", sowie "Tendency" (bei dir Ti:, T: und Tendency:) geben aber
> andererseit müsste es auch eine regel geben, die dann vermeidet, dass kein
> "mischmash" zwischen abkürzungen und ausgeschriebenen bezeichnern ensteht wie
> gerade von dir dargestellt.

Naja, bei "T" habe ich mich an das "T" von CUL_WS gehalten, die READINGS
sehen ja wieder gaaaaanz anders aus (-> commandref.html); nur ist 1 "T"
halt zuwenig, also analog open3600 "i" für "inside" drangeklebt, das "o"
für "outside" weggelassen in der Hoffnung, $frontend parst da vielleicht
die Temperatur raus (Nein, mit Frontends habe ich mich bislang nicht aus-
einander gesetzt; initial reichte mir a) Funktion und b) Logging, vorzugs-
weise in mein heißgeliebtes rrd.)

Anyway, ich muß jetzt die Raubtierfütterung machen . Mal gucken, wo der
Trend in dieser Diskussion hingeht.
         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.