[FHZ] 95_RRD_Log Update...

[Guest]

Originally posted by: <email address deleted>

Hallo Zusammen,

habe das Modul 95_RRD_log upgedatet....

Aenderungen:
- keine Ueberpruefung auf existierende READINGs im set-Command
-> dami sollte die Config auch ohne Probleme ueber fhem.cfg gehen.

ALT-NEU:

Attribute "IODEVSTATS" fuer RRD_Log-Device
1.) Je IODEV wird die Anzahl an Messages der letzten 5min geloggt
-> RRDFile: /[...]/IODEV_Name/RAWMSGCOUNT.rrd
2.) je definiertem Device wird RSSI und MSG-Count geloggt
-> RRDFile: /[...]/IODEV_Name/Device_name_rssi.rrd
-> RRDFile: /[...]/IODEV_Name/Device_name_msg.rrd

NEU:

ADDTYPE
set RRDLOG001 ADDTYPE FHT
-> es werden alle Devices vom Type FHT hinzugefuegt
-> mit den READINGs aus:
  $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";

-> fuer FHT waeren das: measured-temp,desired-temp,actuator


Mit der Bitte um FeedBack

Schoene Gruesse

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>

Hallo Kai,

wenn ich deine Diffs richtig verstanden habe....

Per fhem.cfg gehts nur, wenn sowhl die Ueberpruefung auf existierende
READINGs
als auch die Ueberpruefung auf existierende Devices im Set-Befehl
"ausgeschaltet" wird

Letzteres ist im aktuellen Update nicht umgestetzt...wuerde ich dann
nachholen...

Wie generierst du die Grafiken ?? drraw

Die Grafiken wuerde ch ja gerne auch noch in FHEMWEB einbinden...
Mir fehlt hier aber noch ein schluessiger Ansatz...

Vorschlaege

Schoene Gruesse

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,

> wenn ich deine Diffs richtig verstanden habe....
>
> Per fhem.cfg gehts nur, wenn sowhl die Ueberpruefung auf existierende
> READINGs als auch die Ueberpruefung auf existierende Devices im Set-Befehl
> "ausgeschaltet" wird

ja, das war mein quick-and-dirty-Ansatz; da die READINGS gar nicht benötigt
werden.

Denn, soweit ich das verstanden habe und per Loglevel überprüft, die Aus-
wertung erfolgt alleine aufgrund im Quellmodul gesetzter CHANGED[]-Werte,
die über Notify dann bei RRD_log ankommen und in Notify können durchaus
andere Dinge stehen als in READINGS übernommen werden.
Beispiel (vielleicht ein schlechtes ) mein Plugwise-Modul: Ich schicke
ein 'CHANGED[0]="Usage: $value";', schreibe aber in die READINGS nach
{usage} (klein geschrieben). Ob das so im Sinne des Rudolfs ist, weiß
ich nicht So ganz verstanden habe ich das mit CHANGED[] vs READINGS
vielleicht noch nicht -- aber dazu läuft ja eine Diskussion.

(Im Prinzip würde ich ja erwarten, daß der Notify für das entsprechende
Modul bzw. das entsprechend per .cfg konfigurierte Skript nur den Trigger
darstellt, sich neue Daten aus den READINGS zu holen.
Erst bei näherer Überlegung komme ich drauf, daß das Kontraproduktiv ist:
Die Entscheidung, *was* sich geändert hat, sollte das Quellmodul überneh-
men und die Info "*das* hat sich geändert" übermitteln; so muß nicht diese
Intelligenz in alles Nachgeschaltete implantiert werden. Konsequent umges-
etzt heißt das dann aber, wie in meinem WS3600-Modul, daß mit jedem Update
vielleicht 20 CHANGED[] und damit Notifies generiert werden => das ist
mehr so Overkill.
Eine grundlegende Änderung des Status Quo hat aber weitreichende Implika-
tionen; "define foo notify bar" würde dann nicht mehr "$what $value" so-
wie "$otherwhat $otherval" in einem zweiten Aufruf, sondern "$what;$otherwhat"
ohne konkrete Werte => ALLE Module, die auf Notifies reagieren und ALLE
Definitionen in .cfg brechen ins Essen (== tun nicht mehr). Daher sollte
das gut überlegt sein, jetzt, wo das Notify-Mengenproblem erkannt ist!)

> Letzteres ist im aktuellen Update nicht umgestetzt...wuerde ich dann
> nachholen...

Ich schicke nachher noch mal 'nen diff zu Deiner aktuellen Version bzw.
die Definitionen für Plugwise & WS3600 rum, um die Entwicklungen zu har-
monisieren.

> Wie generierst du die Grafiken ?? drraw

Yepp. Aber rrdgraph ist massiv resourcenintensiv; ich habe das vorher
auf einem Celeron 700 laufen lassen (minütlich 10 Images holen, 2 aus
rrds generieren (rrdtool graph ...), davon 7 zu einm 1280x720er Image
zusammenbasteln (ImageMagick), die meiste Zeit brauchte da rrdtool
für die beiden zu erstellenden Graphen ), das war schon kein Witz.
Auf dem SheevaPlug dauert die Erstellung der Graphen einer drraw-
Ansicht auch mehrere Sekunden.

Ich exportiere daher die rrds (NFS) und lagere die Grafikerzeugung
(ein Bild der lokalen Webcams plus Wetterinformationen je Minute)
auf den Mehrkern-PC aus, der auch die Windows-VMs und andere lokale
Service enthält.

> Die Grafiken wuerde ch ja gerne auch noch in FHEMWEB einbinden...
> Mir fehlt hier aber noch ein schluessiger Ansatz...
>
> Vorschlaege

Naja, wäre mal zu evaluieren, ob rrdtool da resourcenschonender
als die aktuelle SVG-gnuplot-Geschichte wäre. Sonst machte das in
meinen Augen für FHEMWEB wenig Sinn. Den Sinn von RRDs sehe ich
auch eher in der Weiterverarbeitung/Langzeitbetrachung, und für
das Erstellen des rrdtool graph-Aufrufs in eigenen, anderen Skripten
eignet sich drraw hervorragend (oder anderen Frontends mit einge-
bauter rrd-Untersützung, also z. B. myHCE). Aber das sind meine 2
Cents dazu
         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>

Ich male alle Grafiken client-seitig. Meiner Ansicht nach ist das Malen von
Verlaufsgrafiken auf dem Server Resourcen-Verschwendung, zumal ich ja am
Frontend bestimmen will, welchen Zeitrahmen, bzw. WAS ich überhaupt sehen
will...

a.


On 27.01.10 08:58, "Axel" wrote:

> Hallo Kai,
>
> wenn ich deine Diffs richtig verstanden habe....
>
> Per fhem.cfg gehts nur, wenn sowhl die Ueberpruefung auf existierende
> READINGs
> als auch die Ueberpruefung auf existierende Devices im Set-Befehl
> "ausgeschaltet" wird
>
> Letzteres ist im aktuellen Update nicht umgestetzt...wuerde ich dann
> nachholen...
>
> Wie generierst du die Grafiken ?? drraw
>
> Die Grafiken wuerde ch ja gerne auch noch in FHEMWEB einbinden...
> Mir fehlt hier aber noch ein schluessiger Ansatz...
>
> Vorschlaege
>
> Schoene Gruesse
>
> 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]

hallo axel,

Am Dienstag 26 Januar 2010 schrieb Axel:
> habe das Modul 95_RRD_log upgedatet....

da ich gerade am scheideweg stehe wie ich künftig graphen in myhce darstellen
werde, habe ich mir mal dein rrd_log etwas näher betrachtet. dazu habe ich ein
paar anmerkungen, die bitte nicht als kritik sondern als "ungefilterte
gedanken" anzusehen sind und ja, ich weiss es ist BETA

ich selber hantiere schon viele jahre mit rrdtool (siehe u.a. myhce 0.9.2),
wobei ich die letzten zwei jahre aber komplett über cacti abgebildet habe.

generell finde ich deinen ansatz gut. allerdings ist er mir persönlich noch
nicht flexibel genug.

wenn ich ich mir den source betrachte fällt mir als erstes auf, das dort
überall noch DOS-like carriage returns und linefeeds enthalten sind. das
solltest du evtl. vorher nochmal durch dos2unix jagen.

bei der definition erwartest du als parameter und nimmst hier
eine prüfung vor, ob das verzeichnis existiert. wenn nicht meldest du invalid
path. ich würde hier den pfad auflösen und dann das nicht existente
verzeichnis anlegen lassen. also beispiel:
"/var/cache/rrd/" auflösen in "/var/cache/" existiert, also "rrd" erzeugen.
später bei "set foo ADD device readings" legst du ja auch das entsprechende
verzeichnis an.

ein weiterer punkt der mir auffiel ist die art der logfile einträge, bzw. der
rückmeldungen:
RRDLOG[5minCOUNTER] => NEW RRD-FILE => /var/log/fhem/EG.wz.HZ/desired-temp.rrd
=> Start: 1264712304
oder
RRDLOG[SET::ERROR] EG.bu.HZ  => night-temp => not supported
das weicht von den anderen logfileeinträgen / rückmeldungen ab. sicherlich
sind das noch debug infos, aber ich wollte es mal anmerken.

wenn ich mir nun die commandref.html ansehe, dann erkenne ich dort, das bei
set meist alle parameter in kleinbuchstaben übergeben werden (mit wenigen
ausnahmen und zwei schreibfehlern in OWTEMP, das auch noch von mir stammt
). vielleicht solltest du das für ADD / DEL auch übernehmen und ADDTYPE analog
zum "TYPE=" von z.b. "list TYPE=FHT" anpassen.

weiterhin fiel mir auf, das du (scheinbar) nur bestimmte readings zulässt:

beispiel 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";

wie verhält es sich aber mit anderen FHT readings? z.b. möchte ich da freier
sein und bei bedarf auch windowopen-temp, day-temp o.a. erfassen.

dann fielen mir noch die min und max werte der roundrobins auf:
z.b.:
RRD_Log_5minGAUGE = GAUGE:900:-20:100

was ist z.b. mit windgeschwindigkeiten > 100?
$data{RRD_LOG}{READING}{KS300}{'wind'} = "RRD_Log_5minGAUGE";

dann wäre da noch der heartbeat den du fest vorgibst.

das sind so die ersten eindrücke die ich gesammelt habe. und bitte versteh es
nicht falsch. kein abriss sondern nur das gewünschte feedback.

mein ansatz sehe vielleicht so aus:
ein RRD_Log als provider wo z.b. die defaultwerte wie pfad, etc. (also globale
rrd-werte) hinterlegt werden. dann evtl. für jeden data source type einen
eigenen client, also RRD_GAUGE, RRD_COUNTER, etc. der provider schaut für
welches device ein notify kam geparst dieses (also yes/no, toggle, "strip non
aplha", to integer, etc.) und übergibt die werte an den/die client(s) der/die
das device gesetzt hat/haben.

damit könnten dann auch ADD / DEL entfallen, da es jeweils einen eigenen
define type geben würde.

bei den defines für die DS-Typen könntest du dann gewisse werte wie z.b.
hearbeat als default vorbelegen, aber auch zulassen, das diese überschrieben
werden, ebenso wie min und max werte. das hat dann zwar zur folge, das man
viele defines benötigt aber das ist dann aus meiner sicht eher "fhem.cfg"
konform.

so könnte es z.b. aussehen:
define RRD_LOG /var/cache/rrd
attrib rssi
attrib msgcnt

define RRD_GAUGE data:actuator heart:600 min:0
max:100 rra-avg:0.5,3,17280 rra-min:0.5,48,7300 rra-max:0.5,48,7300 rrd-
last:1,1,100

das liest sich im ersten moment zwar mächtig, wäre aber nur notwendig, wenn
default werte überschrieben werden.

ein minimal define mit defaultwerten für einen actuator wäre dann z.b. nur:
define RRD_GAUGE data:actuator

sollte es mehrere data sources mit den gleichen standard default werten für
diese dst geben, dann könnte man sie ebenfalls mit , trennen.

beispiel mit veränderten minx und max werten:
define RRD_GAUGE data:measured-temp,desired-temp,day-
temp,night-temp,windowopen-temp min:-20 max:50

würde roundrobins für alle FHT's im unterverzeichnis des RRD_LOG
für die angegebenen data sources mit der zulässigen spanne zwischen min
und max (-20 +50) anlegen.

eine andere alternative wäre die parameter heart, min, max, rra-avg, rra-min,
etc. als attribute anzugeben:
define RRD_GAUGE data:actuator
attrib heartbeat 600
attrib min 0
attrib max 100
etc.

letzteres ist zwar schwieriger zu realisieren, da die meisten attribute
bereits bei der anlage gesetzt werden müssen (nur bedingt lässt sich da
rrdtune verwenden, wobei ich gerade nicht weiss ob das von RRDs.pm unterstützt
wird) wäre aber aus meiner sicht die elegantere variante. man könnte natürlich
in diesem fall mit einem gezielten
set active
den definierten RRD_GAUGE anweisen das rrd anzulegen (active). das wäre dann
auch in "STATE active" zu sehen. andernfalls könnte dort stehen "STATE
defined", wenn der set noch nicht gesendet wurde.

in den "Readings" würde dann der timestamp des letzten updates für in diesem
beispiel actuator stehen:
2010-01-28 22:41:27   actuator        0%

sodele... das ist mein brainstorm dazu. auch wenn das ein anderer ansatz ist,
möchte ich dennoch deine arbeit hier auch wirklich loben!

gruß martin

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

[Guest]

Originally posted by: <email address deleted>

Martin Fischer wrote:
> hallo axel,
>
> Am Dienstag 26 Januar 2010 schrieb Axel:
>> habe das Modul 95_RRD_log upgedatet....

[...]
> ich selber hantiere schon viele jahre mit rrdtool (siehe u.a. myhce 0.9.2),
> wobei ich die letzten zwei jahre aber komplett über cacti abgebildet habe.
>
> generell finde ich deinen ansatz gut. allerdings ist er mir persönlich noch
> nicht flexibel genug.

Tja. Und ich stehe am anderen Scheideweg: ich möchte die Daten nach RRD
packen (oder etwas anderem mit gleicher Funktionalität: fixe Datenmenge
für fixe Intervalle), allerdings erfolgt die *Erfassung* auf *armel*,
die *Präsentation* auf *x86*. RRDs, geschrieben unter *armel*, sind lei-
der nicht kompatibel zu *x86* (die Abspeicherung von floating-point-Var-
iablen unterscheidet sich)

Was jetzt?

Ratlos,
         kai

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

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

> als "ungefilterte gedanken" anzusehen sind und ja, ich weiss es ist BETA
Kein Problem....
Ich glaube da steht ja auch sowas wie "Bitte um FeedBack" )))

> noch DOS-like carriage returns
Ist in beiden Welten geschrieben...

> parameter [...]
> pfad auflösen und dann das nicht existente
> verzeichnis anlegen lassen
Das Verzeichnis sollte expliziet vom User angelegt werden.
Er muss ja ev. auch noch entsprechende Berechtigungen setzten...
Theoretisch fehlt noch die Ueberpruefung auf Schreibrechte.
Anderes Agrument: Tippfelern vorzubeugen....sonst haste nachher
irgendwo Muell stehen
Wenn sich der User fuer ein Verzeichnis entscheiden hat...kanns
losgehen mit dem Anlegen der RRDs )

> logfileeinträgen / rückmeldungen ab. sicherlich sind das noch debug
> infos, aber ich wollte es mal anmerken.
Nein...ist Absicht )
Bei den "normalen" Logeintraegen stoert mich, dass man nie genau weiss
wo (z.B.
Zeilennummer) sie auftreten. Format sollte sein:
Modul|Function|Abschnitt: Meldung
oder wenn Werte geschrieben werden: Modul|DEVICE-NAME|Abschnitt:
Meldung
So zumindest die Theorie )

> vielleicht solltest du das für ADD / DEL auch übernehmen und ADDTYPE analog
> zum "TYPE=" von z.b. "list TYPE=FHT" anpassen
Ok...setze es auf meine ToDo-Liste...


> das du (scheinbar) nur bestimmte readings zulässt:
Nicht nur scheinbar...
READINGs die so aussehen: T:12 W:34 H:88 werden nicht unterstützt.
Da wuerde fuer jedes Modul einen eigenen Parser bedeuten....

So...jetzt mal hierzu:

> generell finde ich deinen ansatz gut. allerdings ist er mir persönlich noch
> nicht flexibel genug.

> define RRD_LOG /var/cache/rrd
> attrib rssi
> attrib msgcnt
Hier wuerde noch ein Verweis auf das "Mutter"-RRD-Log fehlen
> define RRD_GAUGE data:actuator
define RRD_GAUGE data:actuator
Das wuerde aber in sowas resulieren:
Beispiel KS300
define RRD_LOG /var/cache/rrd
define RRD_COUNTER data:rain
define RRD_GAUGE data:temperature
define RRD_GAUGE data:humidity
define RRD_GAUGE data:wind
Macht 4 zusaetzliche Devices....
Wie schaut denn dann ein FHT aus, wenn da noch Window-Opentemp und so
dazukommt.. )
Ich finde das wird einfach zu viel....

Ich bin aber mit "Wie wird ein DEVICE/READING einem RDD-TYPE"
zugeordnet auch nicht mehr sooo zufrieden...
Ich denke da an folgenden Weg....aktuelle liegt alles unter $data
{RRD_LOG}{READING}{DEVICE-TYPE}...
- das aendern nach:
      $data{RRD_LOG}{READING}{DEFAULT}
      $data{RRD_LOG}{READING}{DEV-TYPE}
      $data{RRD_LOG}{READING}{NAME}

fhem " set RRDLOG01 RRD_Log ADD HMSTF001:humidity"
Da gibt es dann den Endscheidungsweg:
- gibt es einen Eintrag unter $data{RRD_LOG}{READING}{DEV-TYPE}{HMS}
{humidity} -> wenn ja wird der genommen...wenn nein weiter
- gibt es einen Eintrag unter $data{RRD_LOG}{READING}{NAME}{humidity}
-> wenn ja wird der genommen...wenn nein weiter
- dann wird $data{RRD_LOG}{READING}{DEFAULT} = "RRD_Log_5minGAUGE"
Unabhaengig davon muss der Value des READINGs den Test durch die
Funktion ReadingToNumber bestehen...also ein geultiger INT-Wert sein

Weiterhin koennte dazu kommen:
fhem " set RRDLOG01 RRD_Log ADDFILE /[...]/rrd"
In dem File koennte dann so aussehen:
# CONFIG
$data{RRD_LOG}{READING}{DEV-TYPE}{KS300}{humidity} =
"RRD_Log_1minDERIVE"
# Functions
sub RRD_Log_1minDERIVE($){
 RRDs::create($rrd_file,
 [...]
}
Hier kann man dann frei schalten und walten )))

Ueberschreiben von Default-Werte ist dann auch moeglich:
#Config
$data{RRD_LOG}{READING}{DEFAULT} = "RRD_Log_1minDERIVE"
#

Die Datei wuerde dann einfach per perl "do $file" eingebunden
@Rudi: Ist das dann perlechnisch so ok???

Kommt das deinen flexibilitaets Wuenschen entgegen ?? )))))


Schoen Gruesse

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.

[rudolfkoenig]

                                                   

> Die Datei wuerde dann einfach per perl "do $file" eingebunden
> @Rudi: Ist das dann perlechnisch so ok???

Ja, evtl. in eval gepackt, siehe fhem.pl/CommandReload
Bitte das hier nicht als "Rudi will es auch so haben" werten, dazu habe ich im
Moment gar keine Meinung.

--
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 Freitag 29 Januar 2010 schrieb Kai 'wusel' Siering:
> Martin Fischer wrote:
> > hallo axel,
> >
> > Am Dienstag 26 Januar 2010 schrieb Axel:
> >> habe das Modul 95_RRD_log upgedatet....
>
> [...]
>
> Was jetzt?

tja.. fällt mir eben auch nichts zu ein..

--
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 Freitag 29 Januar 2010 schrieb Axel:
> [...]
> > noch DOS-like carriage returns
>
> Ist in beiden Welten geschrieben...

mag ja sein aber dennoch würde _ich_ es durch dos2unix jagen, bevor _ich_
es release..

> > parameter [...]
> > pfad auflösen und dann das nicht existente
> > verzeichnis anlegen lassen
>
> [...]
> Wenn sich der User fuer ein Verzeichnis entscheiden hat...kanns
> losgehen mit dem Anlegen der RRDs )

ok, ist ja auch nichts gegen einzuwenden.. meine denke ging da mehr in
richtung autocreate..

> > logfileeinträgen / rückmeldungen ab. sicherlich sind das noch debug
> > infos, aber ich wollte es mal anmerken.
>
> Nein...ist Absicht )
> Bei den "normalen" Logeintraegen stoert mich, dass man nie genau weiss
> wo (z.B.
> Zeilennummer) sie auftreten. Format sollte sein:

jaein.. auch ich habe das in vielen anderen projekte so gehandhabt.. aber hier
ist es halt nicht so.. ohne es negativ zu meinen: deine logfileeinträge sind
dann 'ausreisser' zwischen den anderen. es erhöht nicht die lesbarkeit, wenn
99% der module anders verfahren. hier sollte man das evtl. berücksichtigen und
harmonisieren. du kannst dir ja ein debug flag einbauen, dass du dann setzt
wenn du testest und dann die entsprechenden ausgaben bekommst. nur im
normalfall sollte das _aus_meiner_sicht_ angepasst sein.

> [...]
> Nicht nur scheinbar...
> READINGs die so aussehen: T:12 W:34 H:88 werden nicht unterstützt.
> Da wuerde fuer jedes Modul einen eigenen Parser bedeuten....

auf die schnelle fällt mir kein modul ein wo das so ist, bzw. wo es die
readings _nur_ in diesem format gibt. ausnahme vielleicht KS300. aber hier
gibt es die werte auch einzeln als readings, mit ausnahme der kummulierten und
durchschnittswerte. hier könnte man jedoch diese ganzen T: H: W: R: zeiler in
vernünftige readings umsetzen.
also beispiel: humitidy_cum_month, humidity_cum_day, etc.

> So...jetzt mal hierzu:
> > generell finde ich deinen ansatz gut. allerdings ist er mir persönlich
> > noch nicht flexibel genug.
> >
> > define RRD_LOG /var/cache/rrd
> > attrib rssi
> > attrib msgcnt
>
> Hier wuerde noch ein Verweis auf das "Mutter"-RRD-Log fehlen

nö... dieses wäre die mutter...

> > define RRD_GAUGE data:actuator
>
> define RRD_GAUGE data:actuator
> Das wuerde aber in sowas resulieren:
> Beispiel KS300
> define RRD_LOG /var/cache/rrd
> define RRD_COUNTER data:rain
> define RRD_GAUGE data:temperature
> define RRD_GAUGE data:humidity
> define RRD_GAUGE data:wind
> Macht 4 zusaetzliche Devices....
> Wie schaut denn dann ein FHT aus, wenn da noch Window-Opentemp und so
> dazukommt.. )
> Ich finde das wird einfach zu viel....

ja, das ist viel aber sauber. da auf den ersten blick ersichtlich ist, was man
denn für dst und rrd angelegt hat.. vorallem ist das auch besser
"fernzusteuern" also von einer gui aus, bzw. könnte das evtl. auch durch
autocreate unterstützt werden.

> [...]
> Kommt das deinen flexibilitaets Wuenschen entgegen ?? )))))

nein, da es ein ganz anderer ansatz ist, den ich nicht gehen würde. ich möchte
nicht in einem submodul den perlcode ändern um defaultwerte zu überschreiben,
sondern diese werte direkt beim define setzen. gerade neulinge und "nicht
perl" bewanderte nutzer würdest du so aussperren, geschweige denn die
möglichkeit über webinterfaces andere werte als die von die per default
gesetzt zu ändern, da diese ja wohl kaum in der lage wären in diese submodule
einzugreifen. wenn du es aus dieser sichtweise betrachtest, dann wirst du
erkennen, das es eben nicht flexibel ist.

meine generelle meinung zu einer modulearchitektur in fhem im allgemeinen ist:

define:
definition inkl. der notwendigen / möglichen werte

attrib:
eine optionale eigenschaft, die den define ergänzt

room:
weisst dem define einen raum zu (dabei ist der room "hidden" für mich hier an
falscher stelle, da ich in meinem haus keinen raum "hidden" habe, aber
vielleicht den raum "abstellkammer" hidden (als attribut haben will))

comment:
hinterlegung eines kommentares für das device, wie z.b. "wird automatisch
durch dämmerung geschaltet"

alias:
menschenlesbarer name des define, z.b. "Deckenstrahler links" (also das wozu
heute comment meist missbraucht wird)

set:
eine aktion auf das device ausführen

get:
eine information vom device beziehen

zur zeit beobachte ich halt nur, das ein "gewisser" wildwuchs entsteht was die
konformität der module angeht. das beziehe ich nicht auf dein RRD_Log sondern
im allgemeinen. wenn jedes modul künftig seinen eigenen kontext mitsich bringt
und dieser von den "ungeschriebenen standards" abweichen, dann wird sich der
aufwand erhöhen, diese module dann auch in andere module, bzw. webgui's
einzubinden/abzubilden.

beispiele sind dann eben schon die oben genannten wie z.b. abweichende syntax
wie set, das eigentlich ein define ist oder ein abweichendes logformat.

deshalb halte ich auch solch diskussionen wie "Harmonisierung von READINGS"
oder "CHANGED" wichtig, damit bereits in einem frühen stadium gewisse policies
feststehen. der aufwand später alle module anzufassen und zu ändern ist immens
grösser als gleich von vornherein einen gewissen "code of cunduct"
einzuhalten.

gruß martin

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

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

> _ich_ es durch dos2unix jagen, bevor _ich_ es release..
mach ich zukuenftig )

> deine logfileeinträge sind dann 'ausreisser' zwischen den anderen. es erhöht nicht die lesbarkeit,
ok..
> wenn 99% der module anders verfahren. hier sollte man das evtl. berücksichtigen und
> harmonisieren.
Dann lass uns doch auch die anderen Moudle einfach anpassen )))
Oder ich "harmonisiere" RRD_Log )

>> Kommt das deinen flexibilitaets Wuenschen entgegen ?? )))))

> nein, da es ein ganz anderer ansatz ist, den ich nicht gehen würde. ich möchte
> nicht in einem submodul den perlcode ändern um defaultwerte zu überschreiben,
Ist auch nur als Option gedacht, um deine eigenen Wuensche
umzusetzten.
> sondern diese werte direkt beim define setzen. gerade neulinge und "nicht
> perl" bewanderte nutzer würdest du so aussperren,
Das denke ich nicht...gerade FHEM-Neulinge müssten sich dann erstmal
in RRDTools einarbeiten
um den Syntax zu verstehen...
> geschweige denn die möglichkeit über webinterfaces andere werte
Aber gehen wir dann nicht stark in Richtung Drraw...nur fuers anlegen
der RRDs ??
Es wird wesentlich komplexer...

> da diese ja wohl kaum in der lage wären in diese submodule einzugreifen.
Sollen sie das denn ?? Wie schauts denn beim FileLog und gplot
aus...da gabs doch hier immer wieder Nachfragen "Wie mache ichs".
Dachte eher daran, dass z.B. die häufigsten Definition mitgeliefert
werden...
Wenn dann z.b. ein neues Modul dazukommt, kann der Ersteller des
Moduls ja die Definitionen liefern...
Oder wer ein bissle perlisch kann und was von RRDs versteht, kann sich
seine eigenen basteln )
Oder du oder ich basteln ihm welche und stellen sie dann der
Allgemeinheit zur Verfuegung.....
> wenn du es aus dieser sichtweise betrachtest, dann wirst du erkennen, das es eben nicht flexibel ist.
Ich verstehe deinen Wunsch nach Felxibilaet ja...aber gleich soooo
viel )

> meine generelle meinung zu einer modulearchitektur in fhem im allgemeinen ist:
Stimme ich dir auch soweit zu....
Nur )
Das ist alles auf physische Devices zugeschnitten...
Da kann ich ein set oder ein get machen...
Aber wie soll mann dann mit "logischen" Devicen "richtig" umgehen...
Und der "Umweg" ueber set ist der einzige Weg per FHEMWEB etwas ins
Devcie zu schreiben...
(Soweit mir bekannt)
Waere das Thema nicht eher was fuer einen eigenen Thread )

> deshalb halte ich auch solch diskussionen wie "Harmonisierung von READINGS"
> oder "CHANGED" wichtig, [...] einzuhalten.
Ja

Schoene Gruesse

Axel

Umlaut-Test: äöüß

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

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

einen hab ich noch ,-))

Vieleicht kann ich das von dir gewünschte "Tochter-Modul" ja als "ADD-
On" bauen...
Nach dem Motto:
define RRDLOG01 RRD_Log /../

define RRDDS01 RRDLOG01 COUNTER:data:rain
define RRDDS02 RRDLOG01 GAUGE:data:temperature
define RRDDS03 RRDLOG01 GAUGE:data:humidity
define RRDDS04 RRDLOG01 GAUGE:data:wind

letzt endlich gehts ja nur um das erstellen der RRD-Files....

mal schauen )

Axel

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

[Martin Fischer]

Am Freitag 29 Januar 2010 schrieb Axel:
> [...]
> >> Kommt das deinen flexibilitaets Wuenschen entgegen ?? )))))
> >
> > nein, da es ein ganz anderer ansatz ist, den ich nicht gehen würde. ich
> > möchte nicht in einem submodul den perlcode ändern um defaultwerte zu
> > überschreiben,
>
> Ist auch nur als Option gedacht, um deine eigenen Wuensche
> umzusetzten.

du, das geht mir eigentlich nicht um meine eigenen wünsche, denn dann könnte
ich ja auch ein RRD_Log schreiben es geht mir hier mehr um eine generelle
architektur, die auch künftige eventualitäten abdecken könnte..

> > sondern diese werte direkt beim define setzen. gerade neulinge und "nicht
> > perl" bewanderte nutzer würdest du so aussperren,
>
> Das denke ich nicht...gerade FHEM-Neulinge müssten sich dann erstmal
> in RRDTools einarbeiten
> um den Syntax zu verstehen...

und genau das denke ich eben nicht. wie ich schon schrieb: es spricht ja
nichts dagegen, wenn du sinnvolle defaultwerte setzt. das ist dann für die
neulinge gedacht. wer aber mit rrd umgehen kann und weiss an welchen schrauben
er drehen muss, der soll doch einfach diese als parameter mit übergeben.

das ist meine "denke" dabei. so kann der "rookie" erstmal mit den
standardwerten leben und der "experte" muss nicht extra in irgendwelchen
sources was ändern. zumal man ja evtl. durchaus ein define mit standardwerten
haben will und ein weiteres mit abweichenden werten. wie sollte das dann
gehen, wenn ich defaultwerte nur im source überschreiben kann? dann sind sie
ja wieder global.

> > geschweige denn die möglichkeit über webinterfaces andere werte
>
> Aber gehen wir dann nicht stark in Richtung Drraw...nur fuers anlegen
> der RRDs ??
> Es wird wesentlich komplexer...

ich weiss, das es hier nicht easy going ist... aber das leben ist ja auch kein
ponyhof davon ab nutze ich Drraw nicht, in der regel habe ich das selber
geschrieben... von daher kann ich zu Drraw nichts beitragen..

> [...]
> Oder du oder ich basteln ihm welche und stellen sie dann der
> Allgemeinheit zur Verfuegung.....

beim besten willen nein ich habe auch so schon viel zu viel zu tun. aber
du hast den nagel auf den kopf getroffen: wenn du das von anfang an freier
umsetzt, dann sparst du dir später das "nachliefern" und "hier und da" extra-
wünsche zu berücksichtigen.

> > wenn du es aus dieser sichtweise betrachtest, dann wirst du erkennen, das
> > es eben nicht flexibel ist.
>
> Ich verstehe deinen Wunsch nach Felxibilaet ja...aber gleich soooo
> viel )

jo weil noch ist es laut deiner doku BETA. wenn du also die linie
weiterverfolgst, dann könnte es später mehr aufwand bedeuten.

_das_ ist der hintergrund warum ich dir meine gedanken dazu kundtue.. da ich
nunmal auch rrd näher kenne. du versperrst dir aber auch den usern die
künftigen anforderungen nicht.

> > meine generelle meinung zu einer modulearchitektur in fhem im allgemeinen
> > ist:
>
> Stimme ich dir auch soweit zu....
> Nur )
> Das ist alles auf physische Devices zugeschnitten...
> Da kann ich ein set oder ein get machen...
> Aber wie soll mann dann mit "logischen" Devicen "richtig" umgehen...
> Und der "Umweg" ueber set ist der einzige Weg per FHEMWEB etwas ins
> Devcie zu schreiben...
> (Soweit mir bekannt)
> Waere das Thema nicht eher was fuer einen eigenen Thread )

ja, ja, ja... ich erkenne dein problem. genau deshalb bin ich ja auch der
meinung, das es evtl. mal die eine oder andere vorgaben geben müsste, damit
fhem-module sich nicht irgendwann total verbiegen müssen.

und den thread habe ich dazu auch schon geöffnet, möchte da aber auch nicht
als alleinunterhalter auftreten. ich versuche mir halt nur gedanken zu machen,
wohin der weg mit fhem geht und wie man recht früh designfehler abfangen kann,
damit es später nicht zum bumerang wird.

gruß martin

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

[Guest]

Originally posted by: <email address deleted>

Hi,

nachdem RRDs mir auf arm5el derzeit nix bringen tun (sie müssen
für Verwendung auf x86 (Auswertung, beträfe auch Frontends, die
auf RRD-Files zugreifen wollten, Veränderung, ...) konvertiert
werden (rrdtool dump auf Quellsystem, rrdtool create auf Auswer-
tesystem)), welche Möglichkeiten bietet RRD_Log.pm bzw. die zu-
grundeliegende Perl-Library eigentlich, auf einen rrdcached auf
einem anderen Host zuzugreifen?
         kai

P.S.: Cross-plattform-Unterstüzung soll mit rrdtool 1.5 kommen,
       1.4 ist Ende 2009 rausgekommen ...

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

Martin Fischer wrote:
> Am Freitag 29 Januar 2010 schrieb Axel:
[...]
>>> meine generelle meinung zu einer modulearchitektur in fhem im allgemeinen
>>> ist:
>> Stimme ich dir auch soweit zu....
>> Nur )
>> Das ist alles auf physische Devices zugeschnitten...
>> Da kann ich ein set oder ein get machen...
>> Aber wie soll mann dann mit "logischen" Devicen "richtig" umgehen...

Indem man bei diesen Geräten entsprechend etwas setzt oder liest.
Beispiel SISPM / SIS_PMS. Da gibt's das Gerät, die Steckdosenleiste.
Und es gibt die einzelnen Steckdosen, die behandelt SIS_PMS als lo-
gische Geräte des definierten physikalischen Geräts. Die einzelnen
Dosen kann man mit set/get beackern, die eigentliche Leiste (die
das technisch ja aber macht), nicht.

Ich würde, wenn ich mich an einen RRD-Logger setzen würde, einen
Zugriffsmechanismus definieren -- bei Dir derzeit der Filesystem-
pfand; ich brauche grade RRD über's Netzwerk und würde entsprechend
da auch einen Zugriffspfad auf entweder 'nen rrdtool im Servermodus
oder 'nen rrdcached vorsehen als Erweiterung -- das Handling macht
dann das "Hardware-Modul".
Und dann würde ich ein RRD-Logger-Modul als logisches Gerät imple-
mentieren, welches auf das vorgenannten "Hardware"-Modul zugreift.
So *könnte* ich dann die Daten auch z. B. in zwei Verzeichnisse --
oder lokal & remote -- schreiben.

define myRRDextern socket://foo:bar@192.168.5.55:5555
define myRRDlocal  /var/log/rrd-fhem

define WS3600_rrd_ext myRRDextern WS3600:humidity:temperature:wind:rain
define WS3600_rrd_int myRRDlocal WS3600:temperature-inside:pressure:rain:...

(Das jetzt on-the-fly aus dem Kopf gedrückt; ich habe mich mit RRD-
Tools Perl-Modul nicht auseinander gesetzt, keine Ahnung, was da Sinn
machen würde oder nicht oder wieauchimmer ... Wie gesagt, bislang
löste ich das "RRD-Problem" durch ein notify & ein Shell-, äh, Perl-
skript:

define RRDNotify notify .* "/usr/local/bin/fhem2rrd.pl "%TYPE" "%NAME" "%EVENT""

Das ist natürlich etwas arges CPU-Trashing; ich würde erwarten, daß
das Perl-Modul zu RRD eine Verbindung zu einem rrdtool-Prozeß auf-
recht erhält oder aber eben die rrdtool-Funktion selbst ausführt,
also die Dateien selbst liest/schreibt. rrdcached sollte man sich
dann grade bei FHEM auf low-power-devices noch mal ansehen, der
macht wohl sowas in der Art. Aber, nochmal: ich habe mich mit RRD
für FHEM bislang nicht beschäftigt, ich brauche es nur jetzt und
würde meine performancemäßig suboptimale Lösung (1 Perl-Prozeß je
Notify starten, um ggf. nur zu terminieren) im Hinblick auf einen
resourcenschonenderen Lauf gerne optimieren.)

>> Und der "Umweg" ueber set ist der einzige Weg per FHEMWEB etwas ins
>> Devcie zu schreiben...
>> (Soweit mir bekannt)
>> Waere das Thema nicht eher was fuer einen eigenen Thread )

"set" ist ja auch nicht böse per se; nur, die Log-Definitionen per set,
also, überrascht hat mich das seinerzeit auch

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