hiya,
nach einem shutdown in fhem bekomme ich immer mehrfach
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
ins logfile gehagelt.
um das mal einzugrenzen, habe ich ein
Log 4, "SETSTATE: $d $r->{$c}{TIME} $c $r->{$c}{VAL}";
nach zeile 845 eingebaut. als ergebnis kommt:
2009.12.22 14:42:07 4: SETSTATE: EG.wz.TF.01 2009-12-22 14:42:04 state T: 15.2
H: 64.3
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
2009.12.22 14:42:07 4: SETSTATE: EG.wz.TK.01 Battery
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
2009.12.22 14:42:07 4: SETSTATE: EG.wz.TK.01 PREV
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
2009.12.22 14:42:07 4: SETSTATE: EG.wz.TK.01 Reliability
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 845.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/fhem.pl line 846.
2009.12.22 14:42:07 4: SETSTATE: EG.wz.TK.01 Warning
hierbei handelt es sich um ein CUL_FHTTK device:
define EG.wz.TK.01 CUL_FHTTK 471494
da das (und andere CUL_FHTTK) device ansonsten sauber laufen (bis auf das
skipping state)
2009.12.22 14:50:01 4: FHTTK Device EG.wz.TK.01 (Window: Closed)
2009.12.22 14:50:01 4: CUL868: T47149482 -63
2009.12.22 14:50:01 3: FHTTK skipping state 02 as last similar telegram was
received less than 5 secs ago
scheint das modul noch einen fehler in bezug auf die readings zu haben, wenn
ich das richtige deute.
ah ja, habe da auch gerade mal ein list drauf gemacht:
fhem> list EG.wz.TK.01
Internals:
CODE 471494
CUL868_MSGCNT 2
CUL868_RAWMSG T4714940217
CUL868_RSSI -62.5
CUL868_TIME 2009-12-22 14:50:01
DEF 471494
IODev CUL868
LASTIODev CUL868
MSGCNT 2
NAME EG.wz.TK.01
NR 17
OPEN 0
PREVSTATE Closed
PREVTIMESTAMP 1261489553
STATE Closed
TYPE CUL_FHTTK
Readings:
Battery
Reliability
Warning
2009-12-22 14:50:01 Window Closed
Prev:
STATE 02
TIMESTAMP 1261489801
Attributes:
room Wohnen
da wird's deutlich, das "Battery, Reliability, Warning" nicht korrekt gesetzt
werden. und auch "Prev" entspricht nicht dem READINGS format.
cvs version von heute, 22.12.
gruß martin
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Moin,
> nach einem shutdown in fhem bekomme ich immer mehrfach
>
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bin/fhem.pl line 845.
>
> ins logfile gehagelt.
>
> um das mal einzugrenzen, habe ich ein
>
> Log 4, "SETSTATE: $d $r->{$c}{TIME} $c $r->{$c}{VAL}";
>
> nach zeile 845 eingebaut. als ergebnis kommt:
>
> 2009.12.22 14:42:07 4: SETSTATE: EG.wz.TF.01 2009-12-22 14:42:04 state T: 15.2
> H: 64.3
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bin/fhem.pl line 845.
[...]
> 2009.12.22 14:42:07 4: SETSTATE: EG.wz.TK.01 Reliability
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bin/fhem.pl line 845.
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bin/fhem.pl line 845.
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bin/fhem.pl line 846.
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bin/fhem.pl line 846.
> 2009.12.22 14:42:07 4: SETSTATE: EG.wz.TK.01 Warning
>
> hierbei handelt es sich um ein CUL_FHTTK device:
> define EG.wz.TK.01 CUL_FHTTK 471494
>
> da das (und andere CUL_FHTTK) device ansonsten sauber laufen (bis auf das
> skipping state)
>
> 2009.12.22 14:50:01 4: FHTTK Device EG.wz.TK.01 (Window: Closed)
> 2009.12.22 14:50:01 4: CUL868: T47149482 -63
> 2009.12.22 14:50:01 3: FHTTK skipping state 02 as last similar telegram was
> received less than 5 secs ago
>
> scheint das modul noch einen fehler in bezug auf die readings zu haben, wenn
> ich das richtige deute.
>
> ah ja, habe da auch gerade mal ein list drauf gemacht:
>
> fhem> list EG.wz.TK.01
> Internals:
> CODE 471494
> CUL868_MSGCNT 2
> CUL868_RAWMSG T4714940217
> CUL868_RSSI -62.5
> CUL868_TIME 2009-12-22 14:50:01
> DEF 471494
> IODev CUL868
> LASTIODev CUL868
> MSGCNT 2
> NAME EG.wz.TK.01
> NR 17
> OPEN 0
> PREVSTATE Closed
> PREVTIMESTAMP 1261489553
> STATE Closed
> TYPE CUL_FHTTK
> Readings:
> Battery
> Reliability
> Warning
> 2009-12-22 14:50:01 Window Closed
> Prev:
> STATE 02
> TIMESTAMP 1261489801
> Attributes:
> room Wohnen
>
> da wird's deutlich, das "Battery, Reliability, Warning" nicht korrekt gesetzt
> werden. und auch "Prev" entspricht nicht dem READINGS format.
>
> cvs version von heute, 22.12.
Cool, danke für den Hinweis; der Bug liegt dann wohl im Löschen der
Variablen:
undef($defs{$self}{READINGS}{"Reliability"}{VAL});
undef($defs{$self}{READINGS}{"Reliability"}{TIME});
undef($defs{$self}{READINGS}{"Reliability"});
undef($defs{$self}{READINGS}{"Battery"}{VAL});
undef($defs{$self}{READINGS}{"Battery"}{TIME});
undef($defs{$self}{READINGS}{"Battery"});
undef($defs{$self}{READINGS}{"Warning"}{VAL});
undef($defs{$self}{READINGS}{"Warning"}{TIME});
undef($defs{$self}{READINGS}{"Warning"});
Wie macht man's richtig?
"Prev" sollte eigentlich intern sein, darüber löse ich die Erkennung
doppelter Ereignisse (da kommt auch diese "skipping"-Meldung her);
wenn derlei nicht in READINGS geht, weil deren Format fest steht
(Rudolf?), muß ich das anders lösen ...
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 22 Dezember 2009 schrieb Kai 'wusel' Siering:
> Cool, danke für den Hinweis; der Bug liegt dann wohl im Löschen der
> Variablen:
>
> undef($defs{$self}{READINGS}{"Reliability"}{VAL});
> undef($defs{$self}{READINGS}{"Reliability"}{TIME});
> undef($defs{$self}{READINGS}{"Reliability"});
>
> undef($defs{$self}{READINGS}{"Battery"}{VAL});
> undef($defs{$self}{READINGS}{"Battery"}{TIME});
> undef($defs{$self}{READINGS}{"Battery"});
> undef($defs{$self}{READINGS}{"Warning"}{VAL});
> undef($defs{$self}{READINGS}{"Warning"}{TIME});
> undef($defs{$self}{READINGS}{"Warning"});
warum löscht du die überhaupt? können doch in den readings stehen bleiben (nur
richtig) und z.b. den VAL "ok" haben. und warnings setzt du dann halt immer
auf "none" und nur wenn sich aus den werten von Battery und/oder Reliabilty
(was kommen denn hier überhaupt für werte?) irgendeine warnung ergibt, setzt
du halt diesen in warnings.
so könnte ich mir das vorstellen.
und PREV könntest du ja auch richtig in die readings setzen und dann später
wieder nutzen. es sei denn rudi hat dafür noch einen anderen vorschlag.
--
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.
> warum löscht du die überhaupt? können doch in den readings stehen bleiben (nur
> richtig) und z.b. den VAL "ok" haben. und warnings setzt du dann halt immer
> auf "none" und nur wenn sich aus den werten von Battery und/oder Reliabilty
> (was kommen denn hier überhaupt für werte?) irgendeine warnung ergibt, setzt
> du halt diesen in warnings.
Auch meine Meinung...
> und PREV könntest du ja auch richtig in die readings setzen und dann später
> wieder nutzen. es sei denn rudi hat dafür noch einen anderen vorschlag.
Readings ist fuer Werte, die man gerne nach einem Neustart haben will. Ich
meine PREV koennte man auch direkt ins hash schreiben ($hash->{PREV}) oder in
eine lokale Variable (%defptr), wenn es nicht fuer "list" sichtbar sein soll.
--
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 22 Dezember 2009 schrieb Rudolf Koenig:
> > und PREV könntest du ja auch richtig in die readings setzen und dann
> > später wieder nutzen. es sei denn rudi hat dafür noch einen anderen
> > vorschlag.
>
> Readings ist fuer Werte, die man gerne nach einem Neustart haben will. Ich
> meine PREV koennte man auch direkt ins hash schreiben ($hash->{PREV}) oder
> in eine lokale Variable (%defptr), wenn es nicht fuer "list" sichtbar sein
> soll.
stimmt! habe ich z.b. bei 21_OWTEMP auch so gemacht, das ich $hash->{PRESENT}
setze, obwohl ich auf ein present in den readings habe. so kann ich z.b.
unterscheiden ob ich PRESENT manuell gesetzt habe oder ob present vom sensor
gemeldet wurde (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>
Martin Fischer wrote:
> Am Dienstag 22 Dezember 2009 schrieb Kai 'wusel' Siering:
>> Cool, danke für den Hinweis; der Bug liegt dann wohl im Löschen der
>> Variablen:
[...]
>
> warum löscht du die überhaupt? können doch in den readings stehen bleiben (nur
> richtig) und z.b. den VAL "ok" haben. und warnings setzt du dann halt immer
> auf "none" und nur wenn sich aus den werten von Battery und/oder Reliabilty
> (was kommen denn hier überhaupt für werte?) irgendeine warnung ergibt, setzt
> du halt diesen in warnings.
Für Reliability habe ich mal "medium" (letzer Wert zw. 300 und 600 Sekunden
alt; ~1 verlorenes Telegramm), "low" (zw. 600 und 720 Sekunden) und "dead"
(>720 Sekunden keine Nachricht mehr -- geklaut? ;)) vorgesehen. Kann man
sicher auf "ok" setzen statt zu löschen (sah' das mehr als Warnindikator,
aber da das Löschen ja schein's nicht vorgesehen/preferiert ist ... ;)).
Battery & Warning sind doppelt gemoppelt, wenn Batteriewarnung gesendet wird
geht Warning auf "Battery low" und Battery auf "Low". Ich schmeiße dann
"Battery" raus und "Warning" toggelt dann zwischen "none" & "Battery low". Ack?
> so könnte ich mir das vorstellen.
>
> und PREV könntest du ja auch richtig in die readings setzen und dann später
> wieder nutzen. es sei denn rudi hat dafür noch einen anderen vorschlag.
Rudi schrieb:
> Readings ist fuer Werte, die man gerne nach einem Neustart haben will. Ich
> meine PREV koennte man auch direkt ins hash schreiben ($hash->{PREV}) oder in
> eine lokale Variable (%defptr), wenn es nicht fuer "list" sichtbar sein soll.
Schon um den Datendump nicht unnötig aufzublähen, würde ich Prev da raus-
halten wollen; das ist poor man's state machine, die aber nicht von Werten
aus einem vorigen Lauf sinnvoll profitieren kann.
Nun denn; nachdem der Herpes-Versand mir meinen zweiten SheevaPlug noch immer
nicht geliefert hat (angeblich seit Freitag in deren kalten Händen), muß ich
mir 'ne andere Entwicklungskiste zusammenstricken. (Dachte ja, ich könnte
den WD TV Live nehmen, aber da fehlen (noch?) die Kernelmodule beim Debian-
Live-FS. Und der DockStar ist leider noch immer "zu".) Mal gucken ...
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 22 Dezember 2009 schrieb Kai 'wusel' Siering:
> Für Reliability habe ich mal "medium" (letzer Wert zw. 300 und 600 Sekunden
> alt; ~1 verlorenes Telegramm), "low" (zw. 600 und 720 Sekunden) und "dead"
> (>720 Sekunden keine Nachricht mehr -- geklaut? ;)) vorgesehen. Kann man
> sicher auf "ok" setzen statt zu löschen (sah' das mehr als Warnindikator,
> aber da das Löschen ja schein's nicht vorgesehen/preferiert ist ... ;)).
warum setzt du es dann nicht auf diese werte (ok, medium, low, dead) und
erwähnst es in der doku? dann könntest du auch bei den warnings ein "dead"
setzen, wenn es denn dead ist.
> Battery & Warning sind doppelt gemoppelt, wenn Batteriewarnung gesendet
> wird geht Warning auf "Battery low" und Battery auf "Low". Ich schmeiße
> dann "Battery" raus und "Warning" toggelt dann zwischen "none" & "Battery
> low". Ack?
NACK:
wenn du das mit der Reliability berücksichtigen willst, dann sollte "Warning"
noch ein "dead" toogle dazu bekommen. fände ich nicht verkehrt, wenn man z.b.
längere zeit nicht auf die "Battery low" reagiert hat, bzw. es vergessen hat.
dann stünde da ein "dead" weil er sich nun halt überhaupt nicht mehr meldet.
ACK:
wenn du das obige nicht berücksichtigst.
--
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:
> warum setzt du es dann nicht auf diese werte (ok, medium, low, dead) und
> erwähnst es in der doku?
First shot; ist ja schön, daß es soweit funktioniert, ob & wie diese
Werte sinnvoll nutzbar sein/genutzt werden könnten war/ist mir nicht
klar. Darum steht davon derzeit auch nix in der Doku, ich hasse Än-
derungen an APIs.
>> Battery & Warning sind doppelt gemoppelt, wenn Batteriewarnung gesendet
>> wird geht Warning auf "Battery low" und Battery auf "Low". Ich schmeiße
>> dann "Battery" raus und "Warning" toggelt dann zwischen "none" & "Battery
>> low". Ack?
>
> NACK:
> wenn du das mit der Reliability berücksichtigen willst, dann sollte "Warning"
> noch ein "dead" toogle dazu bekommen. fände ich nicht verkehrt, wenn man z.b.
> längere zeit nicht auf die "Battery low" reagiert hat, bzw. es vergessen hat.
> dann stünde da ein "dead" weil er sich nun halt überhaupt nicht mehr meldet.
Warning: "Dead Battery low" oder "Battery low Dead" oder "Battery low, DEAD", ..?
Der Grund, warum ich derzeit verschiedene Werte setze ist der, daß dann
am Vorhandensein (initiale Idee, kommt aber ja nicht so gut an ;)) bzw. am
Wert der Variablen X auf einen Status Y rückschließen kann.
Ich habe keine Ahnung, wie das an anderer Stelle gehandhabt wird; komplexestes
Gerät scheint mir derzeit der FHT-80B zu sein, da kommt im Zweifel
Warnings: Battery low; Temperature too low; Window open; Fault on window sensor
sofern ich das richtig überfliege. Konveniert das so? Für Frontends (und
mich als Serverschabe) finde ich ja getrennte Werte eigentlich besser als
ein zu parsender Bandwurm, aber letztlich ist's mir Wurscht ;)
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 22 Dezember 2009 schrieb Kai 'wusel' Siering:
> Warning: "Dead Battery low" oder "Battery low Dead" oder "Battery low,
> DEAD", ..?
keine ahnung!
ich kenne ja nicht das genaue verhalten. das musst schon du entscheiden :-)
--
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.