Use of uninitialized value in split at fhem.pl line 2098.

[Guest]

Originally posted by: <email address deleted>

Hi,
 
ich habe folgendes Problem:
Bei jeder Onewire - Messung die ich über ECMD auslöse kommt der oben
beschribene Fehler.
Als Hardware dient eine AVR Net IO mit E6.  Der Fehler kam früher in Line
2016 und ist mit den
CVS Updates auf Line 2098 gewandert. Es handelt sich um die Split Funktion
in
EvalSpecials($%)
foreach my $part (split(" ", $specials{"%EVENT"})) {
 
ein print $specials{"%EVENT"} führt zum gleichen Fehler...
 
Zusätzlich werden alle par Stunden die Resultate von messen und
temp_raumname getauscht.
Im Log steht dann bei messen die Temperatur und bei temp_raumname ok.
 
netio.classdef:
 
params devID
set WZLon cmd {"rfm12 2272 68,17,81 76 10"}
set WZLoff cmd {"rfm12 2272 68,17,80 76 10"}
set messen cmd {"1w convert"}
get Temp_Hof cmd {"1w get %devID"}
get Temp_Lukas cmd {"1w get %devID"}
get Temp_Schlafzimmer cmd {"1w get %devID"}
 
 
fhem.cfg:
 
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global port 7072 global
attr global statefile ./log/fhem.save
attr global userattr icon webCmd
attr global verbose 3
define WEB FHEMWEB 8083 global
attr WEB stylesheetPrefix dark
define WEBphone FHEMWEB 8084 global
attr WEBphone smallscreen 1
attr WEBphone stylesheetPrefix dark
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix dark
attr WEBtablet touchpad 1
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
define AVRNETIO ECMD telnet 192.168.0.90:2701
attr AVRNETIO classdefs netio=./netio.classdef
# Licht Anbauwand
define WZ ECMDDevice netio
attr WZ room Wohnzimmer
get Temp_Schlafzimmer cmd {"1w get %devID"}
# Temperatur Lukas
define LUKAS ECMDDevice netio 10f4d05f02080070
attr LUKAS room Lukas
define FL_Lukas_Temp FileLog ./log/Temp_Lukas_%Y.log LUKAS:(Temp_Lukas).*
attr FL_Lukas_Temp room Lukas
define WL_Lukas_Temp weblink fileplot FL_Lukas_Temp:temp4lukas:CURRENT
attr WL_Lukas_Temp label "Temperatur Lukas Min $data{min1}, Max
$data{max1}, Last $data{currval1}"
attr WL_Lukas_Temp room Plots,Lukas
# Temperatur Schlafzimmer
define SCHLAFZIMMER ECMDDevice netio 10a3dd5f02080037
attr SCHLAFZIMMER room Schlafzimmer
define FL_Schlafzimmer_Temp FileLog ./log/Temp_Schlafzimmer_%Y.log
SCHLAFZIMMER:(Temp_Schlafzimmer).*
attr FL_Schlafzimmer_Temp room Schlafzimmer
define WL_Schlafzimmer_Temp weblink fileplot
FL_Schlafzimmer_Temp:temp4schlafzimmer:CURRENT
attr WL_Schlafzimmer_Temp label "Temperatur Schlafzimmer Min $data{min1},
Max $data{max1}, Last $data{currval1}"
attr WL_Schlafzimmer_Temp room Plots,Schlafzimmer
# Tmeperatur Hof
define HOF ECMDDevice netio 103ed35f0208006e
attr HOF room Hof
define FL_Hof_Temp FileLog ./log/Temp_Hof_%Y.log HOF:(Temp_Hof).*
attr FL_Hof_Temp room Hof
define WL_Hof_Temp weblink fileplot FL_Hof_Temp:temp4hof:CURRENT
attr WL_Hof_Temp label "Temperatur Hof Min $data{min1}, Max $data{max1},
Letzte $data{currval1}"
attr WL_Hof_Temp room Plots,Hof
#Timer
define AT_SchlafzimmerTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 10;;
get SCHLAFZIMMER Temp_Schlafzimmer
attr AT_SchlafzimmerTemp room Schlafzimmer
define AT_HOFTemp at +*00:02 set HOF messen;; sleep 10;; get HOF Temp_Hof
attr AT_HOFTemp room Hof
define AT_LukasTemp at +*00:02 set LUKAS messen;; sleep 10;; get LUKAS
Temp_Lukas
attr AT_LukasTemp room Lukas
 
Liegt der Fehler in meiner Definition/cfg oder ist das ein Problem mit der
Definition von "%Event"
 
Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> ein print $specials{"%EVENT"} führt zum gleichen Fehler...

67_ECMDDevice.pm scheint EvalSpecials($%) nicht so zu verwenden, wie ich es
dachte (fuellt %EVENT nicht oder nicht immer), ich habe jetzt eine
entsprechende Abfrage eingebaut. Komisch ist nur, dass dieser Code vom
2011-09-12 erst jetzt auffaellt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[MichaS]

                                                       

Hallo Andreas,

erstmal vorab: Der Betrefftitel deiner Nachricht ist nicht wirklich
zielführend, den Inhalt habe ich nur zufällig gelesen, weil ich mir alles
neue angesehen habe. Besser wäre immer, im Betreff auf das FHEM Modul und
das Problem hinzuweisen, damit es die richtigen (wissenden) Leute auch
finden können - so etwa: ECMD - Probleme beim Auslesen 1-Wire über
AVR-NET-IO.

So nun mal zu dem was mir aufgefallen ist:

># Licht Anbauwand
> >define WZ ECMDDevice netio
> >attr WZ room Wohnzimmer
> >get Temp_Schlafzimmer cmd {"1w get %devID"}
>

Die Deklaration von WZ führt irgendwie ins leere und das nachfolgende get..
passt auch nicht hierhier, sondern in die classdef
 

>
> >#Timer
> >define AT_SchlafzimmerTemp at +*00:02 set SCHLAFZIMMER messen;; sleep
> 10;; get SCHLAFZIMMER Temp_Schlafzimmer
> >attr AT_SchlafzimmerTemp room Schlafzimmer
> >define AT_HOFTemp at +*00:02 set HOF messen;; sleep 10;; get HOF Temp_Hof
> >attr AT_HOFTemp room Hof
> >define AT_LukasTemp at +*00:02 set LUKAS messen;; sleep 10;; get LUKAS
> Temp_Lukas
> >attr AT_LukasTemp room Lukas
>  
>
Warum definierst Du mehrere gleichartige Timer, wo auch jedesmal für alle
eine Messung iniziiert wird?. Eventuell kommen sich die Sachen dann in die
Quere.
Besser wäre ein:
define AT_OnewireTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 2;; get
SCHLAFZIMMER Temp_Schlafzimmer;; sleep 2;; get HOF Temp_Hof;; sleep 2;; get
LUKAS Temp_Lukas

Ein set messen cmd {"1w convert"} in der classdef fordert alle
angeschlossenen Sensoren zum messen auf. Willst du das pro Sensor einzeln
machen, muss set messen cmd {"1w convert %devID"} in die classdef schreiben.

Gruß
Micha

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Besser wäre ein:
> define AT_OnewireTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 2;; get
> SCHLAFZIMMER Temp_Schlafzimmer;; sleep 2;; get HOF Temp_Hof;; sleep 2;; get
> LUKAS Temp_Lukas

sleep blockiert fhem. d.h. das obige Beispiel wird fhem fuer 3x2 = 6 Sekunden
blockieren.

Da mich das blockierende sleep schon immer gestoert hat, habe ich es fhem
vertraeglicher gemacht: sleep merkt nun die folgenden Kommandos, und fuehrt
diese in ein unsichtbaren "at" aus.  sleep blockiert weiterhin beim
Initialisieren (wenn sleep direkt in fhem.cfg steht) und auf der Kommandozeile
(== telnet)

Damit muesste ein Blinken jetzt ohne Nebeneffekte zu realisieren sein (das war
das eigentliche Ausloeser der Aenderung

define nBlink notify taste:on\
        set l1 on;; sleep 0.5;;\
        set l2 off; sleep 0.5;;\
        set l1 on;; sleep 0.5;;\
        set l2 off

Bitte Kommentare zu diesem Feature in einem neuen Thread.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 30. März 2012 08:05:22 UTC+2 schrieb Rudolf Koenig:
>
> > ein print $specials{"%EVENT"} f�hrt zum gleichen Fehler...
>
> 67_ECMDDevice.pm scheint EvalSpecials($%) nicht so zu verwenden, wie ich es
> dachte (fuellt %EVENT nicht oder nicht immer), ich habe jetzt eine
> entsprechende Abfrage eingebaut. Komisch ist nur, dass dieser Code vom
> 2011-09-12 erst jetzt auffaellt.
>
 
Nein ist er nicht - offensichtlich bin ich nicht der Erste der das Problem
hat.
Siehe:
https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/line$202016/fhem-users/TB85KxjredA/6E9L_Os6JWgJ
Das Problem hat isch im Laufe der letzten CVS nur nach hinten verschoben.
Danke für den schnellen Bugfix. Ich werde heute Abend mal updaten und
berichten.
 
Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 30. März 2012 08:22:31 UTC+2 schrieb MichaS:
>
> Hallo Andreas,
>
> erstmal vorab: Der Betrefftitel deiner Nachricht ist nicht wirklich
> zielführend, den Inhalt habe ich nur zufällig gelesen, weil ich mir alles
> neue angesehen habe. Besser wäre immer, im Betreff auf das FHEM Modul und
> das Problem hinzuweisen, damit es die richtigen (wissenden) Leute auch
> finden können - so etwa: ECMD - Probleme beim Auslesen 1-Wire über
> AVR-NET-IO.
>
> So nun mal zu dem was mir aufgefallen ist:
>
> ># Licht Anbauwand
>> >define WZ ECMDDevice netio
>> >attr WZ room Wohnzimmer
>> >get Temp_Schlafzimmer cmd {"1w get %devID"}
>>
>
> Die Deklaration von WZ führt irgendwie ins leere und das nachfolgende
> get.. passt auch nicht hierhier, sondern in die classdef
>  
>
>>
>> >#Timer
>> >define AT_SchlafzimmerTemp at +*00:02 set SCHLAFZIMMER messen;; sleep
>> 10;; get SCHLAFZIMMER Temp_Schlafzimmer
>> >attr AT_SchlafzimmerTemp room Schlafzimmer
>> >define AT_HOFTemp at +*00:02 set HOF messen;; sleep 10;; get HOF Temp_Hof
>> >attr AT_HOFTemp room Hof
>> >define AT_LukasTemp at +*00:02 set LUKAS messen;; sleep 10;; get LUKAS
>> Temp_Lukas
>> >attr AT_LukasTemp room Lukas
>>  
>>
> Warum definierst Du mehrere gleichartige Timer, wo auch jedesmal für alle
> eine Messung iniziiert wird?. Eventuell kommen sich die Sachen dann in die
> Quere.
> Besser wäre ein:
> define AT_OnewireTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 2;; get
> SCHLAFZIMMER Temp_Schlafzimmer;; sleep 2;; get HOF Temp_Hof;; sleep 2;; get
> LUKAS Temp_Lukas
>
> Ein set messen cmd {"1w convert"} in der classdef fordert alle
> angeschlossenen Sensoren zum messen auf. Willst du das pro Sensor einzeln
> machen, muss set messen cmd {"1w convert %devID"} in die classdef schreiben.
>
> Gruß
> Micha
>
 
Hi,
 
das Steht so auch nicht in meiner Konfig - war ein Fehler - copypaste lässt
grüßen. Deine Derinition für das Messen probiere ich heute Abend gleich
mal. Danke .
 
Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 30. März 2012 13:32:58 UTC+2 schrieb Sturi2011:
>
>
> Am Freitag, 30. März 2012 08:22:31 UTC+2 schrieb MichaS:
>>
>> Hallo Andreas,
>>
>> erstmal vorab: Der Betrefftitel deiner Nachricht ist nicht wirklich
>> zielführend, den Inhalt habe ich nur zufällig gelesen, weil ich mir alles
>> neue angesehen habe. Besser wäre immer, im Betreff auf das FHEM Modul und
>> das Problem hinzuweisen, damit es die richtigen (wissenden) Leute auch
>> finden können - so etwa: ECMD - Probleme beim Auslesen 1-Wire über
>> AVR-NET-IO.
>>
>> So nun mal zu dem was mir aufgefallen ist:
>>
>> ># Licht Anbauwand
>>> >define WZ ECMDDevice netio
>>> >attr WZ room Wohnzimmer
>>> >get Temp_Schlafzimmer cmd {"1w get %devID"}
>>>
>>
>> Die Deklaration von WZ führt irgendwie ins leere und das nachfolgende
>> get.. passt auch nicht hierhier, sondern in die classdef
>>  
>>
>>>
>>> >#Timer
>>> >define AT_SchlafzimmerTemp at +*00:02 set SCHLAFZIMMER messen;; sleep
>>> 10;; get SCHLAFZIMMER Temp_Schlafzimmer
>>> >attr AT_SchlafzimmerTemp room Schlafzimmer
>>> >define AT_HOFTemp at +*00:02 set HOF messen;; sleep 10;; get HOF
>>> Temp_Hof
>>> >attr AT_HOFTemp room Hof
>>> >define AT_LukasTemp at +*00:02 set LUKAS messen;; sleep 10;; get LUKAS
>>> Temp_Lukas
>>> >attr AT_LukasTemp room Lukas
>>>  
>>>
>> Warum definierst Du mehrere gleichartige Timer, wo auch jedesmal für alle
>> eine Messung iniziiert wird?. Eventuell kommen sich die Sachen dann in die
>> Quere.
>> Besser wäre ein:
>> define AT_OnewireTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 2;; get
>> SCHLAFZIMMER Temp_Schlafzimmer;; sleep 2;; get HOF Temp_Hof;; sleep 2;; get
>> LUKAS Temp_Lukas
>>
>> Ein set messen cmd {"1w convert"} in der classdef fordert alle
>> angeschlossenen Sensoren zum messen auf. Willst du das pro Sensor einzeln
>> machen, muss set messen cmd {"1w convert %devID"} in die classdef schreiben.
>>
>> Gruß
>> Micha
>>
>  
> Hi,
>  
> das Steht so auch nicht in meiner Konfig - war ein Fehler - copypaste
> lässt grüßen. Deine Derinition für das Messen probiere ich heute Abend
> gleich mal. Danke .
>  
> Gruß Andreas
>  
>
Hi,
 
wie komme ich an die Files zum testen? Updatefhem findet leider
nichts neues.
 
Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,

Nach dem Ändern der Config auf Michas String für den AT Befehl trat der Fehler mit dem OK als Response auf 1W get nach wie vor auf.
Nach dem Update der fhem.pl war zumindest der Fehler mit dem Split, welcher in der konsole aufläuft verschwunden. Auch die Wartezeiten
im Webinterface bei den aufeinanderfolgenden Sleep Befehlen habensich deutlich reduziert. Der Fehler mit OK als Antwort auf 1w get %devid
Bleibt aber bestehen.

Ich habe dann testhalber die Werte für die Timeouts in der 66 ecmd hochgesetzt - keine Verbesserung.
Im Fhemlog steht nach einigen Messungen die nach dem Neustart eine Weile funktionieren:
messen: OK
Temp1: 20.0
Temp2: 21.5
Temp3: 4.2
Messen:
Temp1: OK
Temp2: 20.0
Temp3: 21.5
Messen: 4.2
Temp1:
Temp2: OK
Temp3: 20.0
Messen: 21.5

Usw.


Wen das Logging auf 5 steht verschwindet der Fehler jedoch....

Gibt es dazu irgendeine Idee?

Gruß

Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich beschäftige mich erst kurz mit 1-Wire und dem NetIO, aber ich habe das
so verstanden das "1w convert" nur die Umrechnung von Hex in den dezimalen
Temperaturwert für alle Devices initialisiert.
siehe auch http://www.ethersex.de/index.php/ECMD_Reference.

Die Temperatur auslesen löst man mit "1w get device" aus.

Dann würde nähmlich die Antwort "ok" im Log für "SCHLAFZIMMER" stimmen.

MfG

Volker

Am Freitag, 30. März 2012 08:22:31 UTC+2 schrieb MichaS:
>
> Hallo Andreas,
>
> erstmal vorab: Der Betrefftitel deiner Nachricht ist nicht wirklich
> zielführend, den Inhalt habe ich nur zufällig gelesen, weil ich mir alles
> neue angesehen habe. Besser wäre immer, im Betreff auf das FHEM Modul und
> das Problem hinzuweisen, damit es die richtigen (wissenden) Leute auch
> finden können - so etwa: ECMD - Probleme beim Auslesen 1-Wire über
> AVR-NET-IO.
>
> So nun mal zu dem was mir aufgefallen ist:
>
> ># Licht Anbauwand
>> >define WZ ECMDDevice netio
>> >attr WZ room Wohnzimmer
>> >get Temp_Schlafzimmer cmd {"1w get %devID"}
>>
>
> Die Deklaration von WZ führt irgendwie ins leere und das nachfolgende
> get.. passt auch nicht hierhier, sondern in die classdef
>  
>
>>
>> >#Timer
>> >define AT_SchlafzimmerTemp at +*00:02 set SCHLAFZIMMER messen;; sleep
>> 10;; get SCHLAFZIMMER Temp_Schlafzimmer
>> >attr AT_SchlafzimmerTemp room Schlafzimmer
>> >define AT_HOFTemp at +*00:02 set HOF messen;; sleep 10;; get HOF Temp_Hof
>> >attr AT_HOFTemp room Hof
>> >define AT_LukasTemp at +*00:02 set LUKAS messen;; sleep 10;; get LUKAS
>> Temp_Lukas
>> >attr AT_LukasTemp room Lukas
>>  
>>
> Warum definierst Du mehrere gleichartige Timer, wo auch jedesmal für alle
> eine Messung iniziiert wird?. Eventuell kommen sich die Sachen dann in die
> Quere.
> Besser wäre ein:
> define AT_OnewireTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 2;; get
> SCHLAFZIMMER Temp_Schlafzimmer;; sleep 2;; get HOF Temp_Hof;; sleep 2;; get
> LUKAS Temp_Lukas
>
> Ein set messen cmd {"1w convert"} in der classdef fordert alle
> angeschlossenen Sensoren zum messen auf. Willst du das pro Sensor einzeln
> machen, muss set messen cmd {"1w convert %devID"} in die classdef schreiben.
>
> Gruß
> Micha
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[MichaS]

                                                       

Hallo Volker,

nein, da liegst du falsch.
Der Befehl 1w convert ist zum Auslösen der Messung zuständig. Dabei wir
speziell bei der parasitären Verkabelung (benötigt nur 2 Leitungen)
kurzzeitig über die Datenleitung der interne Kondensator geladen und die
Messung ausgeführt. Der Messwert steht danach in einem internen
Speicherbereich fest (bis zum nächsten 1w convert) und lässt sich über ein
1w get ### auslesen. Siehe auch Infos dazu hier
http://dokucode.de/index.php/Dallas_1-wire_Bus#Onewire_Befehle

Gruß
Micha

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,

ein

define AT_OnewireTemp at +*00:02 set SCHLAFZIMMER messen;; sleep 2;; get SCHLAFZIMMER Temp_Schlafzimmer;; sleep 2;; get HOF Temp_Hof;; sleep 2;; get LUKAS Temp_Lukas

müsste als Ergebnis im Log so aussehen:

OK
Temp1: temp
Temp2: temp
Temp3: temp

Das ist auch die ersten zig Messungen so und korrekt. Ab irgendeinem Zeitpunkt wandert aber das Ergebniss - siehe Log von oben. Es sieht aus als würde es ein Timeout geben. Das Ergebniss was dann kommt landet im Buffer nach dem Recive Und wird als ergebnis der nächsten Telnet Transaktion ausgegeben.

Das passiert aber scheinbar nur wenn das Log auf verbose 3 steht. Bei 5 scheint es seit einigenStunden stabilzu laufen. Ich stelle heute Abend mal zurüch und lasse da mal wireshark auf dem Monitoringport mitlaufen.

Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,

Nein 1w get ### liest den entspechenden Sensor aus.

Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich muss mich der oben vorgetragenen Kritik anschließen - Deine
Informationen sind nicht sehr erhellend.

"Siehe das Log von oben" - wo bitte sieht man das "Wandern" der
Temperaturwerte, was meinst Du damit ?

Wieso glaubst Du an ein Timeout ? - So etwas gibt es bei 1-Wire Devices
nicht. Die Temperaturmessung bei jedem einzelnen Sensor dauetr ca. 1
Sekunde - fragt man "vorher" an, ist der Wert einfach zu hoch


LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi, man Sieht ein wandern der Temperatur im Log
 

> 2012.03.31 09:15:32 3: messen: OK
> 2012.03.31 09:15:35 2: After sleep: Temp_Schlafzimmer: 19.4
> 2012.03.31 09:15:37 2: After sleep: Temp_Hof: 6.0
> 2012.03.31 09:15:39 2: After sleep: Temp_Lukas: 20.9
> 2012.03.31 09:25:31 1: Got
> http://www.google.com/ig/api?weather=Neubrandenburg&hl=de, length: 1425
> 2012.03.31 09:25:32 3: messen: OK
> 2012.03.31 09:25:35 2: After sleep: Temp_Schlafzimmer: 19.2
> 2012.03.31 09:25:37 2: After sleep: Temp_Hof: 6.0
> 2012.03.31 09:25:39 2: After sleep: Temp_Lukas: 19.9
> 2012.03.31 09:35:32 3: messen: OK
> 2012.03.31 09:35:35 2: After sleep: Temp_Schlafzimmer: 19.1
> 2012.03.31 09:35:37 2: After sleep: Temp_Hof: 6.0
> 2012.03.31 09:35:39 2: After sleep: Temp_Lukas: 19.4
> 2012.03.31 09:45:37 3: messen:
> 2012.03.31 09:45:43 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 09:45:50 2: After sleep: Temp_Hof:
> 2012.03.31 09:45:52 2: After sleep: Temp_Lukas: 19.5
> 6.2
> 2012.03.31 09:55:31 1: Got
> http://www.google.com/ig/api?weather=Neubrandenburg&hl=de, length: 1434
> 2012.03.31 09:55:32 3: messen: 19.9
> 2012.03.31 09:55:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 09:55:36 2: After sleep: Temp_Hof: 19.7
> 2012.03.31 09:55:38 2: After sleep: Temp_Lukas: 6.4
> 2012.03.31 10:05:32 3: messen: 20.0
> 2012.03.31 10:05:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 10:05:36 2: After sleep: Temp_Hof: 19.8
> 2012.03.31 10:05:38 2: After sleep: Temp_Lukas: 6.0
> 2012.03.31 10:15:32 3: messen: 20.1
> 2012.03.31 10:15:39 2: After sleep: Temp_Schlafzimmer:
> 2012.03.31 10:15:43 2: After sleep: Temp_Hof: OK
> 2012.03.31 10:15:49 2: After sleep: Temp_Lukas: 19.8
> 2012.03.31 10:25:31 1: Got
> http://www.google.com/ig/api?weather=Neubrandenburg&hl=de, length: 1423
> 2012.03.31 10:25:32 3: messen: 20.1
> 2012.03.31 10:25:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 10:25:36 2: After sleep: Temp_Hof: 19.9
> 2012.03.31 10:25:38 2: After sleep: Temp_Lukas: 5.9
> 2012.03.31 10:35:32 3: messen: 20.1
> 2012.03.31 10:35:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 10:35:36 2: After sleep: Temp_Hof: 19.9
> 2012.03.31 10:35:38 2: After sleep: Temp_Lukas: 5.6
> 2012.03.31 10:45:32 3: messen: 20.1
> 2012.03.31 10:45:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 10:45:36 2: After sleep: Temp_Hof: 19.9
> 2012.03.31 10:45:38 2: After sleep: Temp_Lukas: 5.7
> 2012.03.31 10:55:31 1: Got
> http://www.google.com/ig/api?weather=Neubrandenburg&hl=de, length: 1418
> 2012.03.31 10:55:32 3: messen: 20.1
> 2012.03.31 10:55:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 10:55:36 2: After sleep: Temp_Hof: 19.9
> 2012.03.31 10:55:38 2: After sleep: Temp_Lukas: 5.8
> 2012.03.31 11:05:32 3: messen: 20.1
> 2012.03.31 11:05:39 2: After sleep: Temp_Schlafzimmer:
> 2012.03.31 11:05:43 2: After sleep: Temp_Hof: OK
> 2012.03.31 11:05:50 2: After sleep: Temp_Lukas:
> 2012.03.31 11:15:32 3: messen: 19.9
> 20.1
> 2012.03.31 11:15:34 2: After sleep: Temp_Schlafzimmer: OK
> 2012.03.31 11:15:36 2: After sleep: Temp_Hof: 19.9
> 2012.03.31 11:15:38 2: After sleep: Temp_Lukas: 5.8
> 2012.03.31 11:25:31 1: Got
> http://www.google.com/ig/api?weather=Neubrandenburg&hl=de, length: 1448
> 2012.03.31 11:25:32 3: messen: 20.2
> 2012.03.31 11:25:39 2: After sleep: Temp_Schlafzimmer:
> 2012.03.31 11:25:43 2: After sleep: Temp_Hof: OK
> 2012.03.31 11:25:50 2: After sleep: Temp_Lukas:
> 2012.03.31 11:35:32 3: messen: 19.9
>
 
Das soll bedeuten, dass die Responses beim nächsten Command angezeigt
werden. Es kommt dann bei messen (1w convert) kein response. Das Response
kommt beim nächsten Command Temp_Schlafzimmer oder beim nächsten. Def
Fehler wandert.
 
Ja das Timeout für Onewire ist gering - das kann sich aber mit der AVR Net
IO ändern, wenn diese noch anderes zu tun hat wie z.B. das eigene
Webinterface zu füttern....das ist es aber nicht.
Wenn ich das Logging auf 5 stelle verschwindet der Fehler. Er tritt bei
Logging auf 3 auf. Daher vermute ich, dass dort in der ecmd.pl irgendetwas
falsch geparst wird.
Ich vermute, dass eine verspätete Response als Antwort auf den nächsten
Befehl gewertet wird. Der Fehler wandert wie mann im Log sieht über alle
ECMD-Befehle zur Onewire Messung.
 
Das hatte ich mit dem weiter oben geposteten Beispiel für das Log zu
erklären versucht. Wenn das zu unverständlich war kann ich mich nur
entschuldigen.
 
Gruß Andreas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Sehe ich eben nicht. Das kann genausogut die "normale"
Temperaturentwicklung sein.

An eine Drift der Werte glaube ich erst, wenn diese auch dann auftritt,
wenn die Sensoren für eine Zeitlang in Eiswasser sitzen.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com