[FHZ] 95_RRD_Log.pm

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Martin Fischer]

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.

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Guest]

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.

[Martin Fischer]

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.