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.
> 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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
Originally posted by: <email address deleted>
Hallo Zusammen,
95_RRD_Log -> FHEM Restart:
Das ist ein timing Problem....zuerst müssen die READINGs dasein.
Wollte es komfortabel halten...das hatt dann halt im Nachinein diesen
Effekt...
"BestPractise": RRD-Log defineren und dann per FHEMWEB die Devices
konfigurieren.
Da alle Einstellungen inden READINGs gespeichert werden...klappts dann
auch nach dem Restart von FHEM ;-))
Also keine "set RRDLog ..." in der fhem.cfg
Und ja..das READING muss da sein und per CHANGED "gemeldet" werden...
Bin offen für andere Wege...
> keine kritik aber motivation um z.b. die doku aufzuarbeiten. ;-)
Im Kopf steht:
#*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA
# 95_RRD_Log.pm
# Feedback: http://groups.google.com/group/fhem-users
# Logging to RRDs
Bisher kam nicht sooo viel...das hier ist fast der erste thread
dazu.... ;-))))
Doku zu schreiben ist nicht das Problem...aber dazu muss das Modul
doch erstmal durch den FHEM-BETA-TEST....
Dann ne Finale Version mit Doku und "Aufnahme" in den CVS-FHEM-
Zweig ;-)))))
Notify/$hash->{CHANGED}[0]:
Ev. sollten wir mal über die gesamte Datenstruktur nachdenken...
Momentan gibt es doch faktisch (auch per save gesichet) nur de Device-
$hash und den zugehörenden Attr-Hash.
Und im device-hash wird auch nicht alles "gesaved"...
Es fehlt z.B. "Platz" um die ganzen Berechnungen (CUM_DAY stc..)
abzulegen.
Quasi die READINGs aufraumen ;-))
Und unter {READINGS}{VAL} noch {READINGS}{UNIT} einfuegen....
Die Anzahl der Notifies könnte man ev. dadurch ändern, daß fhem fuer
einen Event nicht mehr alle NotifyFN's durchlaufen muss.
Ev. könnte man hier nen eigenen NotifyBaum aufbauen als LookUpTable:
%notify{ALL} -> gilt für alle devices quasi notify *
%notify{DEVICE_NAME}{EVER} -> gilt immer fuer dieses Device: notify
FS20TFK_001.*
%notify{DEVICE_NAME}{REgEx} -> gilt nur fuer das EIN Device mit der
RegEX: notify FS20TFK_001.*Off
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>
Moin,
Axel wrote:
> 95_RRD_Log -> FHEM Restart:
> Das ist ein timing Problem....zuerst müssen die READINGs dasein.
> Wollte es komfortabel halten...das hatt dann halt im Nachinein diesen Effekt...
> "BestPractise": RRD-Log defineren und dann per FHEMWEB die Devices
> konfigurieren.
Äh, was? Klickorgien nach FHEM-Restart war jetzt nicht so mein
Ansatz ;) Oder wie meinst Du obiges?
> Also keine "set RRDLog ..." in der fhem.cfg
> Und ja..das READING muss da sein und per CHANGED "gemeldet" werden...
Das erklärt die gähnende Leere bei meinen Plugwise-Geräten :(
> Bin offen für andere Wege...
Äh, wenn getriggert für $Gerät, die entsprechenden Settings ein-
fach auslesen -- auf deren Existenz ja vorher schon getestet wurde? ;)
>> keine kritik aber motivation um z.b. die doku aufzuarbeiten. ;-)
> Im Kopf steht:
> #*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA*BETA
> # 95_RRD_Log.pm
> # Feedback: http://groups.google.com/group/fhem-users
> # Logging to RRDs
> Bisher kam nicht sooo viel...das hier ist fast der erste thread
> dazu.... ;-))))
Ich schrieb' schon mal, daß es bei mir nicht tut, aber da kam glaube
ich nix zurück -- oder ich wollte erst auf 'n aktuelles CVS gehen ;)
> Doku zu schreiben ist nicht das Problem...aber dazu muss das Modul
> doch erstmal durch den FHEM-BETA-TEST....
> Dann ne Finale Version mit Doku und "Aufnahme" in den CVS-FHEM-
> Zweig ;-)))))
Gut, dann mal Manöverkritik: es stimmt, das, was ich per "set" händisch
eingegen habe, ist via READINGS im fhem.save gelandet. Aber das ist, äh,
nicht so der Bringer finde ich -- mal tut "set foo bar", mal nicht, das
ist doch doof :(
Welchen Sinn hat denn das Bestehen auf *vorhandene* READINGS zum Zeit-
punkt des "set" --- wenn Du die READINGS doch nachher nicht mal mehr
mit der Kneifzange anfaßt? ;) (Nicht per CHANGED gemeldet => ignoriert.)
Wobei ich die Variante mittels "set" recht genial finde -- vielleicht un-
gewöhnlich (hätte eher defines erwartet), aber gut, es funktioniert ja ;)
> Notify/$hash->{CHANGED}[0]:
> Ev. sollten wir mal über die gesamte Datenstruktur nachdenken...
> Momentan gibt es doch faktisch (auch per save gesichet) nur de Device-
> $hash und den zugehörenden Attr-Hash.
> Und im device-hash wird auch nicht alles "gesaved"...
Nicht? IIRC werden alle READINGS gesichert (naja, nicht mehr alle,
die, die nur TIME aber kein VAL haben, werden ja nun gefiltert),
oder?
> Die Anzahl der Notifies könnte man ev. dadurch ändern, daß fhem fuer
> einen Event nicht mehr alle NotifyFN's durchlaufen muss.
> Ev. könnte man hier nen eigenen NotifyBaum aufbauen als LookUpTable:
> %notify{ALL} -> gilt für alle devices quasi notify *
> %notify{DEVICE_NAME}{EVER} -> gilt immer fuer dieses Device: notify
> FS20TFK_001.*
> %notify{DEVICE_NAME}{REgEx} -> gilt nur fuer das EIN Device mit der
> RegEX: notify FS20TFK_001.*Off
Da ich mit mit dem Notify-Mechanismus derzeit überhaupt nicht auskenne,
lausche ich hier einfach mal, was Ihr so ausbaldowert.
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 Kai,
ich bin nicht so der fhem.cfg "Nutzer" ;-)))
Ich nutz lieber FEHEMWEB...deswegen habe den FHEMWEB-Set
"missbraucht" ;-))
> Gut, dann mal Man verkritik: es stimmt, das, was ich per "set" h ndisch
> eingegen habe, ist via READINGS im fhem.save gelandet. Aber das ist, h,
> nicht so der Bringer finde ich -- mal tut "set foo bar",
der foo tu genau so wie beschrieben...
Ich kanns auch als Feature verkaufen...bei RRD_Log bruacht man nicht
in der fhem.cfg zu "fummeln".
Geht fats alle sper GUI....
> mal nicht, das ist doch doof :(
Besser wäre gewesen: "Find ich nicht so schoen"
> Welchen Sinn hat denn das Bestehen auf *vorhandene* READINGS zum Zeit-punkt des "set" --
Na was nuetzt es dir irgendwas zu setzten und dann nacher per Lag-
Anaylse den Fehler zu suchen.
Wie lange hettest du gesucht, bis zu dem Schluss gekommen wearst das
Modul schluckt die S300TH einfach nicht.
So kam der Fehler fruehzeitig und hat dir 'ne Menge suchen
erspart ;-)))
Ich wollte schon bei der Eingabe alles soweit kontrollieren, dass
spaeter moeglichst wenig Fehler auftreten.
> Nicht? IIRC werden alle READINGS gesicher
READINGs schon zumindest > 0; in $hash wird nicht alles gesichert...
Jetzt muss ich doch mal fragen: Was heisst das IIRC ;-)))
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>
Axel wrote:
> ich bin nicht so der fhem.cfg "Nutzer" ;-)))
> Ich nutz lieber FEHEMWEB...deswegen habe den FHEMWEB-Set
> "missbraucht" ;-))
ich gestehe, ich bin Shell-Nutzer ;)
>> Gut, dann mal Man verkritik: es stimmt, das, was ich per "set" h ndisch
>> eingegen habe, ist via READINGS im fhem.save gelandet. Aber das ist, h,
>> nicht so der Bringer finde ich -- mal tut "set foo bar",
> der foo tu genau so wie beschrieben...
> Ich kanns auch als Feature verkaufen...bei RRD_Log bruacht man nicht
> in der fhem.cfg zu "fummeln".
> Geht fats alle sper GUI....
Nein, der "set foo bar" geht nicht immer. Er geht nicht aus der
fhem.cfg, wo er vollkommen zulässig ist, aber eben Fehlermeldun-
gen produziert (die 5 Sekunden später nicht mehr stimmen und die
die Funktion des Loggings nach RRD verhindern, wenn man die le-
galen Befehle in die fhem.cfg schreibt). (Davon abgesehen, es soll
Leute geben, die fhem.save in einer RAM-Disk betreiben -- auf Em-
beddeds macht das ggf. Sinn, da man sein FLASH ja nicht unnötig
streßen will.)
Für die Konfiguration ist meiner Überzeugung nach die .cfg da; die
.save habe ich in der Vergangenheit wiederholt gelöscht, weil da
eben keine relevanten Daten drinstehen, dafür aber durchaus auch
mal Murks. Aber ok, das ist MEINE Interpretation, Rudolf mag das
anders sehen ;)
>> mal nicht, das ist doch doof :(
> Besser wäre gewesen: "Find ich nicht so schoen"
Oh, bitte, keine Wagschalen jetzt. Ich finde es super, wenn sich
jemand hinsetzt und etwas schreibt -- allerdings betone ich das
vielleicht zuwenig. Insofern hier deutlich: DANKE FÜR 95_RRD_LOG.pm!
Ich finde es allerdings auch scheiße, wenn mir das Modul um die
Ohren fliegt, obwohl ich alles korrekt konfiguriert habe -- DAS
kommuniziere ich i. d. R. deutlich ;) Und, s. o., daß bei RRD_Log
"set" nur grade *nicht* in der Konfigurationsdatei funktionieren
soll, halte ich für ein no-go. Das fände ich nicht nur "nicht so
schön", das fände ich "irreführend" und "problematisch". Zumal
das Webfrontend optional ist. (Ja, es funktioniert auch über das
telnet-Interface.)
Um das abzuschließen: Auch über das Webfrontend gäbe es Fehler,
wenn ich "define myTH CUL_WS 8" und direkt danach "set myRRDLOG
ADD myTH temperature:humidity" angeben würde (sollte die Syntax
fehlerhaft sein: auch bei korrekter Syntax täte es nicht, was
mein Punkt ist)! Erst nach dem Erstempfang kann ich das also de-
finieren -- das ist doch nun wirklich die Abwesenheit von "schön",
oder? :(
(Nicht persönlich nehmen; ich mag RRD_Log und ich habe nichte ge-
gen Dich; ich mag nur nicht diese -- in meinen Augen -- proble-
matische "Designdecision".)
>> Welchen Sinn hat denn das Bestehen auf *vorhandene* READINGS zum Zeit-punkt des "set" --
> Na was nuetzt es dir irgendwas zu setzten und dann nacher per Lag-
> Anaylse den Fehler zu suchen.
Naja, was nützt mir der vermeintliche Funktionscheck, wenn dann
die überprüften Werte gar nicht ausgewertet werden? (CHANGED vs.
READINGS.)
> Wie lange hettest du gesucht, bis zu dem Schluss gekommen wearst das
> Modul schluckt die S300TH einfach nicht.
Wahrscheinlich nicht so lange wie ich gesucht HABE, warum das $%&/()=?-
Modul meine "set"-Eingaben (aus der .cfg) bemängelt, obwohle diese ver-
kackten Werte doch verdammtnochmal in "list" auftauchen, also tatsäch-
lich da sind ... Hey, das hat mich gestern locker 'ne Stunde gekostet.
Darauf, daß das beim Start des Moduls nicht gesetzt ist, zum Zeitpunkt
meines Guckens dann aber natürlich schon, bin ich erst heute gekommen.
Erklärt auch, warum das bei Dir tut und bei mir eben nicht ;) Und das
erklärt auch, warum der "Arbeit_TF"-Eintrag drin war, den ich spaßes-
halber mal per Web-IF eingetragen hatte -- also im Nachhinein ist es
mir jetzt klar ;)
Wie gesagt, no worries, das "BETA * BETA * BETA" habe ich ja gelesen,
daher auch meine Frage, ob das a) mit CUL_WS sowieso nicht tun würde
und b) warum es bei mir nicht rennt.
Aber ok, ich bin eher der exzessive Logger; Du gehst da offensicht-
lich anders ran, ist ja auch nicht schlimm. Ich fände es nur sehr
bedenklich, wenn generische Befehle nun nicht mehr über jeden Kanal
funkionierten. Der Ansatz ist löblich, ich hätte dann aber eben einen
Logfile-Eintrag erwartet und kein "geht nicht" (zumal es, wenn man
sich *dann* das Logfile anguckt und den Befehl händisch absetzt, ja
evtl. geht.)
> So kam der Fehler fruehzeitig und hat dir 'ne Menge suchen
> erspart ;-)))
Äh, eher im Gegentum? Dieses Vorgehen hat seit dem 13.11.2009 ver-
hindert, daß ich RRD_Log nutzen kann. Wie ich damals schon schrieb:
# Aus der fhem.cfg:
#
# # RRD
# define myRRD RRD_Log /var/lib/rrd-fhem/
# set myRRD ADD FHT1 measured-temp:desired-temp:actuator:rssi
# set myRRD ADD FHT2 measured-temp:desired-temp:actuator:rssi
# set myRRD ADD FHT_Palsherm1 measured-temp:desired-temp:actuator:rssi
# set myRRD ADD FHT_Palsherm2 measured-temp:desired-temp:actuator:rssi
# set myRRD ADD Parkplatz_TH temperature:humidity:rssi
# set myRRD ADD Bad_TH temperature:humidity:rssi
# set myRRD ADD Essz_TH temperature:humidity:rssi
# [...]
#
# Logfile:
#
# 2009.11.13 04:14:28 5: RRDLOG[Define]: main: /usr/local/bin/fhem.pl LINE: 518 SUB: main::AnalyzeCommand
# 2009.11.13 04:14:28 5: Cmd: >set myRRD ADD FHT1 measured-temp:desired-temp:actuator:rssi<
# 2009.11.13 04:14:28 3: RRDLOG[SET::ERROR] FHT1 => measured-temp => Unkown
# 2009.11.13 04:14:28 5: Cmd: >set myRRD ADD FHT2 measured-temp:desired-temp:actuator:rssi<
# [...]
#
# Irgendeine Idee, was ich falsch mache?
Lt. meinem Archiv gab's dazu leider keine Antwort *sigh*
> Ich wollte schon bei der Eingabe alles soweit kontrollieren, dass
> spaeter moeglichst wenig Fehler auftreten.
Löblicher Ansatz; jetzt sollten wir konstruktiv gucken, wie man das
mit generischer Funktion von's Ganze unter einen Hut bekommt ;)
>> Nicht? IIRC werden alle READINGS gesicher
> READINGs schon zumindest > 0; in $hash wird nicht alles gesichert...
Würde ich zumindest für Pw_* und andere meiner Modukle auch nicht
wollen; ich lege da explizit Dinge außerhalb READINGS an, da diese
eher kontraproduktiv wirkten, wenn man sie über FHEM-Läufe rettete.
> Jetzt muss ich doch mal fragen: Was heisst das IIRC ;-)))
If I Remember Correctly. Bin halt schon alt, was man auch an der Nutzung
des Jargons erkennen mag ;)
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 Kai,
abschließened... ;-))
> Um das abzuschlie en: Auch ber das Webfrontend g be es Fehler,
> wenn ich "define myTH CUL_WS 8" und direkt danach "set myRRDLOG
> ADD myTH temperature:humidity" angeben w rde (sollte die Syntax
Das ist doch klar....
Ein define definiert nur ein Gerät (initailisert den $hash) aber OHNE
READINGs.
Erst nachdem zum erstenmal die ParseFN durchlaufen wurde,nach dem
ersten Empfang sind die READINGs da...
So...jetzt zur Sache:
Wie haettet ihrs denn gerne.... ;-)))
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.
hiya..
jetzt nochmal mein senf dazu :-)
obwohl ich die diskussion rund um 95_RRD_Log.pm richtig und wichtig finden,
kann man dem topic doch entnehmen, dass das thema inzwischen gewechselt hat:
Re: Einheitliche READINGs / Notify (Re: [FHZ] 95_RRD_Log.pm)
nun wollten wir hier doch allgemein über die behandlung von CHANGED und wie
von rudi auch schon angesprochen eher die harmonisierung der READINGS
diskutieren.
das thema driftet jetzt aber wieder in einen 95_RRD_Log.pm support thread ab.
vielleicht sollten wir doch etwas disziplin wahren und ihr verlagert diese
diskussion wieder in den ursprünglichen thread.
wie ich schon schrieb: auch ich bin seit jahren rrd-freund habe es soar in
myhce 0.9.2 verwendet. da ich aber nicht nur module sondern auch eine webgui
für fhem entwickle, ist es schon interessant beim thema readings zu bleiben,
da dieses dann auch auswirkungen auf weitere entwicklungen hat.
und wie rudi schon schrieb ist rrd nicht seine baustelle, also wird er sich
dann in diesem thread (obwohl es um readings geht) auch zurückhalten und wir
kommen nicht zum ziel.
wenn dann das thema readings geklärt ist und ich dadurch ggf. viel code in der
web-gui myhce und in modulen ändern muss, dann kann ich mich auch mit rrd_log
befassen.
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:
> 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.
Naja. Gehe ich mal von meiner Hütte aus, hätte ich ca. 16 Mußpunkte für
T/H-Sensoren (10 bislang im Einsatz). Dazu 6-20 Energieverbrauchssensoren
(Hutschienenzwischenzähler für Drehstrom == gesamt und 1 bis 3 "inter-
essante" Stromkreis(e); dazu bestehende 5 Zwischenstecker (3x EM, 2x Plug-
wise; letzteres würde ich wohl erweiteren um 5-10 über die Zeit, z. B.
für Kühlschrank, Minna, Mikrowell, Backofen ...). Macht heute schon mal
16 Sensoren, die so alle 3-5 Minuten senden. Und bei denen sich eher je-
desmal der Wert ändert (und falls nicht, man ihn dennoch haben will in
einem Notify, um "keine Änderung" von "kein Empfang" unterscheiden zu
können).
Bei "meinen" Modulen sollte es, so es Sinn macht (Tür-Fenster-Kontakte,
TV-Steuerung), schon so sein, und CUL_WS sendet, wenn ich nicht völlig
verwirrt bin, zumindest bei den von CUL_WS selbst behandelten Sensoren
(SxxxTH, W7000 usw.) auch nur 1 CHANGED/Nachricht.
[...]
> 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.
Die Frage ist allerdings, ob man wirklich die READINGS harmonisieren soll/muß.
EMEM speichert z. B. kWh; für Plugwise nehme ich lieber Watt, weil mir ein
0,3 kWh ungleich harmloser klingt als "400 Watt, wenn TV & PS3 rennen?!".
Aber will ich, daß orginal gelieferte Werte umgerechnet werden oder möchte
ich die Sensordaten lieber unverfälscht? (Und ehrlich gesagt verstehe ich
auch nicht, wieso kWh/1000 plötzlich W sein soll, die Zeitkomponente habe
ich doch gar nicht angefaßt, nur 1000 (das k) durch 1000 weggekürzt?)
(An dem Problem stehe ich grade; Plugwise liefert -- soweit bislang bekannt --
aktuelle Werte nur auf Basis eines 1- und 8-Sekundenmittelwertes sowie die
Summe der letzten vollen Stunden. Ich habe vorhin der Versuch mit Kaffeema-
schine und Toaster gemacht: die 1- bzw- 8-Sek-Werte lagen locker bei 600-1000W;
daher mittle ich jetzt selbst Ticks/Zeitraum (Zeitraum default: 300 sec),
das gibt bei konstanten Lasten wie einem Sheevaplug oder einer STB meist
Werte +/- 0,5 um den 8-Sekunden-Wert, bei Spunglasten wie Mikrowelle, Toaster,
Pad-Automat, die unter 5 Min. laufen, zwar geringere Spitzen, aber in der
Summe denke ich korrekte Graphen. Alternative wäre, Plugwise im 8-Sek-Raster
abzufragen, das wären derzeit maximal 63 Zwischenstecker, die alle 8 Sekunden
Daten liefern sollen *grusel* 'ne Fritzbox dürfte da gründlich die Grätsche
machen bei der Notify-Last ...)
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>
Martin Fischer wrote:
> Am Montag 25 Januar 2010 schrieb Axel:
>> Mein Vorschalg zur "Hormisierung" von READINGs wäre:
>> $hash->{CHANGED}{SHORT} = "T:12.6 H:55.8";
>> $hash->{CHANGED}{READINGS} = "Temperature;Humidity;etc...";
>
> auch ein vorschlag, der meinem (mit dem array) nahekommt. nur wozu sollte man
> dann noch SHORT benötigen?
Ack; über die normierte Auflistung[1] der (modulspezifischen), sich geän-
dert habenden (das kann das Modul am besten erkennen, hinten dran ist ex-
ponentieller Aufwand, imho), READINGS hätte man zwei Fliegen mit einer
Klappe erschlagen: 1. nur noch 1 Notify, egal, wieviel sich ändert und
2. jeder Notify-"Kunde" kann auswerten, welche Werte sich änderten und
auf diese zugreifen. Bedeutet u. a. (größere?) Änderungen an FileLog und
sicherlich Nutzer-Konfigurationen, aber keiner sagte, daß es nicht weh
tun dürfe ;)
Und es wäre vollkommen unabhängig von einer Namensgebungsharmonisierung um-
setzbar, da die Namen im Klartext übertragen werden. (Nutzerspezifische Dinge
würde bei Namensänderungen in Modulen dann ggf. berührt -- sehe ich grade
keinen Weg dran vorbei :()
kai
[1] Also "Reading1;Reading2" oder "Reading1, Reading2" oder "Reading1; Reading2" oder ..?
--
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>
Axel wrote:
>> Um das abzuschlie en: Auch ber das Webfrontend g be es Fehler,
>> wenn ich "define myTH CUL_WS 8" und direkt danach "set myRRDLOG
>> ADD myTH temperature:humidity" angeben w rde (sollte die Syntax
> Das ist doch klar....
> Ein define definiert nur ein Gerät (initailisert den $hash) aber OHNE
> READINGs.
Klar ist das klar. Unklar ist mir, warum es READINGS zum Gerät geben
muß, zu dem Punkt in Zeit und Raum, an dem man dazu ein Logging beauf-
tragt. Das erscheint mir unlogisch. Wenn noch nix logbares da ist,
wird eben noch nichts geloggt; da eine Fehlermeldung auszuspucke, ist,
äh, eigenwillig ;)
> Erst nachdem zum erstenmal die ParseFN durchlaufen wurde,nach dem
> ersten Empfang sind die READINGs da...
Genau. Und vorher braucht das LOG-Modul sich auch keinen Kopf zu machen,
ob es jemals Daten bekommen mag oder nicht. Das ist nicht seien Aufgabe,
seine Aufgabe ist es, *wenn* Daten da sind, diese wie angewiesen zu log-
gen. Aber eben nicht, den Anwender zu bevormunden wie ein naseweiser Drei-
käsehoch: "Ätschbätsch, da ist gar nix zu loggen, nänänänänäää!" ;)
> So...jetzt zur Sache:
>
> Wie haettet ihrs denn gerne.... ;-)))
Gut, _ich_ hätte es am liebsten, wenn ich das Device und die READINGS
definierte (vielleicht will man ja auch nicht alle READINGS nach RRD
packen, was bei nicht-numerischen Windrichtungen wie WSW auch mehr so
keinen Sinn macht ;)) und RRD_Log dann bei einem Notify diese READINGS
auslesen täte. Fehlen sie, EINMAL ein Eintrag ins Logfile (also in
etwa: if(!defined(...)) {Log 1, "Mooep, $name has no $reading ...";}).
Der Test, ob für die Modul-Reading-Kombination eine RRD-Regel hinter-
legt ist, macht vorab klar Sinn, das sollte bleiben. Nur der Test auf
existierendes READING (und das Verhalten bei notify) sollte überarbei-
tet werden.
My 2 cents,
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:
> das thema driftet jetzt aber wieder in einen 95_RRD_Log.pm support thread ab.
> vielleicht sollten wir doch etwas disziplin wahren und ihr verlagert diese
> diskussion wieder in den ursprünglichen thread.
Äh.
Also, lt. Thread-Anzeige in Thunderbird zumindest *ist* das hier noch
immer der 95_RRD_Log.pm-Thread ;) Sieht im übrigen auch GoogleGroups
so ...
Neuer Thread == Mail ohne References. Sprich: komplett neue Mail startet
hier einen neuen Thread; nicht wie "man" das aus Usenettagen vielleicht
noch gewohnt sein mag, durch Subjectänderung. (Hatten wir ja grade erst,
"entführte Threads"-Beschwerde von Rudi.)
Insofern sollte jemand *Martin anguck ;)* ein kurzes Summary in eine neue
Mail klatschen und damit jene Diskussion von der um 95_RRD_Log.pm abtren-
nen. (Ja, ist nicht meine Art, Mails zu lesen, aber offensichtlich, siehe
wiederholte Beschwerden, ist das für andere effizienter; für mich macht's
keinen Unterschied, wo eine Nachricht einsortiert wird.)
kai
P.S.: Grade gesehen, in der GoogleGroups-Webansicht fehlen meine Umlaute;
ich habe mein Sendeformat mal von 8-Bit auf quoted-printable umgestellt,
vielleicht hilft das 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>
Axel wrote:
> So...jetzt zur Sache:
>
> Wie haettet ihrs denn gerne.... ;-)))
Um da mal konstruktiv vorzugehen: so viele Änderung sind das gar nicht ;)
root@plug-2:/usr/local/lib/FHEM# diff -u ~wusel/fhem-20100122/contrib/rrd/95_RRD_Log.pm 95_RRD_Log.pm
--- /home/wusel/fhem-20100122/contrib/rrd/95_RRD_Log.pm 2009-12-14 21:38:31.000000000 +0100
+++ 95_RRD_Log.pm 2010-01-26 07:38:42.000000000 +0100
@@ -79,11 +79,13 @@
$data{RRD_LOG}{READING}{KS300}{'temperature'} = "RRD_Log_5minGAUGE";
$data{RRD_LOG}{READING}{KS300}{'humidity'} = "RRD_Log_5minGAUGE";
$data{RRD_LOG}{READING}{KS300}{'wind'} = "RRD_Log_5minGAUGE";
- # CUL_WS => S55TH&S300TH
+ # 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";
#FS20
$data{RRD_LOG}{READING}{FS20}{'state'} = "RRD_Log_10secGAUGE";
# IODEVSTATS=CUL
@@ -150,7 +152,7 @@
}
if($a[1] eq "ADDTYPE") {
my $add_type = $a[2];
- if(!defined($data{RRD_LOG}{READING}{$add_type})) {return "RRDLOG[SET::ERROR] $a[2] => Unkown Type";}
+ if(!defined($data{RRD_LOG}{READING}{$add_type})) {return "RRDLOG[SET::ERROR] $a[2] => Unknown Type";}
my ($reading,$reading_list);
foreach $reading (keys %{$data{RRD_LOG}{READING}{$add_type}}) {
$reading_list .= ":" . $reading;
@@ -167,14 +169,14 @@
}
if($a[1] eq "ADD") {
# Device check
- if(!defined($defs{$a[2]})) {return "RRDLOG[SET::ERROR] $a[2] => Unkown Device";}
+ if(!defined($defs{$a[2]})) {return "RRDLOG[SET::ERROR] $a[2] => Unknown Device";}
# Mindestens 3 Parameter
my @readings = split(/:/, $a[3]);
return "RRDLOG[SET::ERROR] No READING found " if(int(@readings) < 1);
# Reading check
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($defs{$a[2]}{READINGS}{$reading})) {return "RRDLOG[SET::ERROR] $a[2] => $reading => Unknown";}
if(!defined($data{RRD_LOG}{READING}{$def_type}{$reading})) {return "RRDLOG[SET::ERROR] $a[2] => $reading => not supported";}
}
$hash->{READINGS}{$a[2]}{TIME} = TimeNow();
Damit startet dann FHEM mitsamt RRD_Log auch, wenn man unflätigerweise
RRD_Log-set-Befehle nach fhem.cfg packt -- und über die Zeit füllt sich
dann einfach das RRD-Verzeichnis mit RRD-Daten ;)
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>
Salve,
noch was:
==> /var/log/messages <==
Jan 26 11:51:13 plug-2 logger: Circle_1 on
==> /var/log/fhem/fhem-2010-01.log <==
2010.01.26 11:51:13 0: Server started (version =VERS= from =DATE= ($Id: fhem.pl,v 1.97 2010/01/01 15:18:09 rudolfkoenig Exp $), pid 18447)
Use of uninitialized value $changed_value in concatenation (.) or string at /usr/local/lib/FHEM/95_RRD_Log.pm line 282.
Das geht zurück auf:
else {
($changed_reading, $changed_value) = split(/:/,$defs{$dev_name}{CHANGED}[$i]);
}
Log $ll, "RRDLOG[Notify] $dev_name => $changed_reading => $changed_value";
Nicht jedes CHANGED beinhaltet zwingend ":", siehe FS20-Sonderregel vorher.
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 Dienstag 26 Januar 2010 schrieb Kai 'wusel' Siering:
> Martin Fischer wrote:
> > das thema driftet jetzt aber wieder in einen 95_RRD_Log.pm support thread
> > ab. vielleicht sollten wir doch etwas disziplin wahren und ihr verlagert
> > diese diskussion wieder in den ursprünglichen thread.
>
> Äh.
>
> Also, lt. Thread-Anzeige in Thunderbird zumindest *ist* das hier noch
> immer der 95_RRD_Log.pm-Thread ;) Sieht im übrigen auch GoogleGroups
> so ...
äh, jain.. ja, der ursprung ist "95_RRD_Log.pm" aber du hast zwischenzeitlich
das thema in "Einheitliche READINGs / Notify" zwar mit dem zusatz auf
95_RRD_Log.pm gelenkt und damit suggeriert, das es jetzt um die
_einheitlichen_ READINGs gehen soll und zwar nicht mehr nur noch bezogen auf
rrd_log. _so_ habe ich es zumindest verstanden.
> [...]
> Insofern sollte jemand *Martin anguck ;)* ein kurzes Summary in eine neue
> Mail klatschen und damit jene Diskussion von der um 95_RRD_Log.pm abtren-
> nen. (Ja, ist nicht meine Art, Mails zu lesen, aber offensichtlich, siehe
gerne zu einer anderen zeit.. vielleicht kann das ja mal wer anderes machen,
da ich mich eigentlich zur zeit auf myhce konzentrieren will. und da ich seit
montag wieder meinem eigentlichen beruf nachgehe, ist meine zeit
dementsprechend wieder etwas knapper ;-)
die grundsteine sind ja gelegt für eine diskussion. :-)
regards..
--
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.