[ECMD] beim auslesen von Messwerten wird oft der falscher Wert (vorgänger Wert) zurückgegeben.

[LuckyDay]

                                         

das problem mit dem vorgängerwert habe ich auch.
passiert so nach ca 5 std.

werde jetzt auch erst ein reopen machen und dann erst messen.

hary

On 9 Okt., 12:06, MichaS wrote:
> Hallo zusammen,
>
> nachdem es bei mir monatelang problemlos lief und ich das beschriebene
> Verhalten nicht nachvollziehen konnte, hat es mich jetzt auch erwischt
>
> Ich habe kürzlich auf die aktuelle Laborfirmware der FB7390 aktualisiert
> und updatefhem auf die aktuelle Version hochgezogen, jedoch an der
> bestehenden Hardwareumgebung nichts geändert. Ja Ja - ich weiss - never
> change an running system ...
>
> Jedenfalls kann ich das fehlerhafte Verhalten jetzt auch bei mir beobachten
> und jederzeit nachstellen. Die Temperaturwerte der 1-Wire Sensoren sind
> nach einem Neustart immer so 3 bis 6mal in Ordnung, danach werden sie
> lustig durcheinandergeworfen, fehlen ganz oder der Rückgabewert des
> Messbefehls OK steht im Temperaturstate - als wenn ein Puffer überläuft
> bzw. nicht gelöscht wird. Selbst ein aktuell im FHEM Befehlsfenster
> eingegebenes get WZ_Temp T gibt nicht den aktuellen Wert des Sensors,
> sondern den falschen Wert aus Puffer zurück.
>
> Momentan behelfe ich mir mit dem setzen von set reopen NETIO_01 vor jedem
> Onewire-Messvorgang alle 15min, aber das kanns ja nicht sein.
>
> Ich würde mich auch riesig freuen, wenn der Modulbetreuer oder ein anderer
> Wissender dem Problem mal nachgehen könnte. Ich stehe als Tester jedenfalls
> gerne bereit.
>
> Grüße
> Micha

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

[MichaS]

                                                       

Hallo Hary,

habe es heute Nacht nochmal testweise im Originalzustand laufen lassen und
komme durch meinen Abfragetimer alle 15min auf fast exakt 5 Std Laufzeit
ohne Fehler, danach verschluckt ECMD sich - Zufall ?
Hier mal mein ein Teil des Logs aus dem man das Problem schön sehen kann
(bis 03:24 alles gut, 03:39 dann der ominöse Fehler und ab 3:54 und
folgende eine Versatz der Rückgabewerte:
2012.10.10 03:24:27 3: set DB_Temp messen : messen OK
2012.10.10 03:24:29 3: get DB_Temp T : T 15.3
2012.10.10 03:24:32 3: get WZ_Temp T : T 21.2
2012.10.10 03:24:34 3: get SZ_Temp T : T 22.3
2012.10.10 03:24:36 3: get AQ_Temp T : T 25.1
2012.10.10 03:24:38 3: get AN_Temp T : T 20.9
2012.10.10 03:24:40 3: get HA_Temp T : T 20.3
2012.10.10 03:24:42 3: get OL_Temp T : T 21.0
2012.10.10 03:24:42 3: T 21.0
2012.10.10 03:39:30 3: set DB_Temp messen : messen
2012.10.10 03:39:35 3: get DB_Temp T : T
2012.10.10 03:39:37 3: get WZ_Temp T : T OK
2012.10.10 03:39:42 3: get SZ_Temp T : T
2012.10.10 03:39:45 3: get AQ_Temp T : T 15.3
2012.10.10 03:39:47 3: get AN_Temp T : T 22.4
2012.10.10 03:39:49 3: get HA_Temp T : T 21.0
2012.10.10 03:39:51 3: get OL_Temp T : T 20.3
2012.10.10 03:39:51 3: T 20.3
2012.10.10 03:54:27 3: set DB_Temp messen : messen 21.0
2012.10.10 03:54:29 3: get DB_Temp T : T OK
2012.10.10 03:54:31 3: get WZ_Temp T : T 15.3
2012.10.10 03:54:33 3: get SZ_Temp T : T 21.1
2012.10.10 03:54:35 3: get AQ_Temp T : T 22.4
2012.10.10 03:54:37 3: get AN_Temp T : T 25.1
2012.10.10 03:54:39 3: get HA_Temp T : T 20.9
2012.10.10 03:54:41 3: get OL_Temp T : T 20.2

Grüße
Micha

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

[LuckyDay]

                                         

seit mehr als 24 std läuft es, nicht

trotz reopen habe ich leere temp

die erste nach ca 18std. dann 3 std, des ist blöd.

timeout ist bei ECMD 3 sec, ich frage immer erst den wert nach 5 sec
ab.

pollen ist doch echt dooof

Hary

ich mache erst ein reopen, warte 5 sec , dann

On 10 Okt., 07:01, MichaS wrote:
> Hallo Hary,
>
> habe es heute Nacht nochmal testweise im Originalzustand laufen lassen und
> komme durch meinen Abfragetimer alle 15min auf fast exakt 5 Std Laufzeit
> ohne Fehler, danach verschluckt ECMD sich - Zufall ?
> Hier mal mein ein Teil des Logs aus dem man das Problem schön sehen kann
> (bis 03:24 alles gut, 03:39 dann der ominöse Fehler und ab 3:54 und
> folgende eine Versatz der Rückgabewerte:
> 2012.10.10 03:24:27 3: set DB_Temp messen : messen OK
> 2012.10.10 03:24:29 3: get DB_Temp T : T 15.3
> 2012.10.10 03:24:32 3: get WZ_Temp T : T 21.2
> 2012.10.10 03:24:34 3: get SZ_Temp T : T 22.3
> 2012.10.10 03:24:36 3: get AQ_Temp T : T 25.1
> 2012.10.10 03:24:38 3: get AN_Temp T : T 20.9
> 2012.10.10 03:24:40 3: get HA_Temp T : T 20.3
> 2012.10.10 03:24:42 3: get OL_Temp T : T 21.0
> 2012.10.10 03:24:42 3: T 21.0
> 2012.10.10 03:39:30 3: set DB_Temp messen : messen
> 2012.10.10 03:39:35 3: get DB_Temp T : T
> 2012.10.10 03:39:37 3: get WZ_Temp T : T OK
> 2012.10.10 03:39:42 3: get SZ_Temp T : T
> 2012.10.10 03:39:45 3: get AQ_Temp T : T 15.3
> 2012.10.10 03:39:47 3: get AN_Temp T : T 22.4
> 2012.10.10 03:39:49 3: get HA_Temp T : T 21.0
> 2012.10.10 03:39:51 3: get OL_Temp T : T 20.3
> 2012.10.10 03:39:51 3: T 20.3
> 2012.10.10 03:54:27 3: set DB_Temp messen : messen 21.0
> 2012.10.10 03:54:29 3: get DB_Temp T : T OK
> 2012.10.10 03:54:31 3: get WZ_Temp T : T 15.3
> 2012.10.10 03:54:33 3: get SZ_Temp T : T 21.1
> 2012.10.10 03:54:35 3: get AQ_Temp T : T 22.4
> 2012.10.10 03:54:37 3: get AN_Temp T : T 25.1
> 2012.10.10 03:54:39 3: get HA_Temp T : T 20.9
> 2012.10.10 03:54:41 3: get OL_Temp T : T 20.2
>
> Grüße
> Micha

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

[Guest]

Originally posted by: <email address deleted>

Hi,
 
Ich hab es jetzt so:
 
define AT_OnewireTemp at +*00:05 set reopen AVRNETIO;; sleep 5;; set OWDM
messen;; sleep 5;; get SCHLAF Temp;; sleep 5;; get HOF Temp;; sleep 5;; get
LUKAS Temp
 
das scheint meist zu funktionieren - ist für kritische Systeme aber nicht
geeignet. Da ich damit die Heizungssteuerung realisieren wollte  ist es
halt blöd wenn im Kinderzimmer ab und zu die Temperatur des Außensensors
auftaucht oder beim Vorlauf oder beim Rücklauf oder auch bei der
Aquarientemperatur. Das führt zum Todheizen. Auch die Temperatur des
Vorlauf Sensors als Ergebnis für den Außensensor ist bescheiden, da dann
die Heizung heruntergefahren wird.
 
Gruß Andreas
 

Am Donnerstag, 11. Oktober 2012 00:36:38 UTC+2 schrieb fhem-hm-knecht:

> seit mehr als 24 std läuft es, nicht
>
> trotz reopen habe ich leere temp
>
> die erste nach ca 18std. dann 3 std, des ist blöd.
>
> timeout ist bei ECMD 3 sec, ich frage immer erst den wert nach 5 sec
> ab.
>
> pollen ist doch echt dooof
>
> Hary
>
> ich mache erst ein reopen, warte 5 sec , dann
>
> On 10 Okt., 07:01, MichaS wrote:
> > Hallo Hary,
> >
> > habe es heute Nacht nochmal testweise im Originalzustand laufen lassen
> und
> > komme durch meinen Abfragetimer alle 15min auf fast exakt 5 Std Laufzeit
> > ohne Fehler, danach verschluckt ECMD sich - Zufall ?
> > Hier mal mein ein Teil des Logs aus dem man das Problem schön sehen kann
> > (bis 03:24 alles gut, 03:39 dann der ominöse Fehler und ab 3:54 und
> > folgende eine Versatz der Rückgabewerte:
> > 2012.10.10 03:24:27 3: set DB_Temp messen : messen OK
> > 2012.10.10 03:24:29 3: get DB_Temp T : T 15.3
> > 2012.10.10 03:24:32 3: get WZ_Temp T : T 21.2
> > 2012.10.10 03:24:34 3: get SZ_Temp T : T 22.3
> > 2012.10.10 03:24:36 3: get AQ_Temp T : T 25.1
> > 2012.10.10 03:24:38 3: get AN_Temp T : T 20.9
> > 2012.10.10 03:24:40 3: get HA_Temp T : T 20.3
> > 2012.10.10 03:24:42 3: get OL_Temp T : T 21.0
> > 2012.10.10 03:24:42 3: T 21.0
> > 2012.10.10 03:39:30 3: set DB_Temp messen : messen
> > 2012.10.10 03:39:35 3: get DB_Temp T : T
> > 2012.10.10 03:39:37 3: get WZ_Temp T : T OK
> > 2012.10.10 03:39:42 3: get SZ_Temp T : T
> > 2012.10.10 03:39:45 3: get AQ_Temp T : T 15.3
> > 2012.10.10 03:39:47 3: get AN_Temp T : T 22.4
> > 2012.10.10 03:39:49 3: get HA_Temp T : T 21.0
> > 2012.10.10 03:39:51 3: get OL_Temp T : T 20.3
> > 2012.10.10 03:39:51 3: T 20.3
> > 2012.10.10 03:54:27 3: set DB_Temp messen : messen 21.0
> > 2012.10.10 03:54:29 3: get DB_Temp T : T OK
> > 2012.10.10 03:54:31 3: get WZ_Temp T : T 15.3
> > 2012.10.10 03:54:33 3: get SZ_Temp T : T 21.1
> > 2012.10.10 03:54:35 3: get AQ_Temp T : T 22.4
> > 2012.10.10 03:54:37 3: get AN_Temp T : T 25.1
> > 2012.10.10 03:54:39 3: get HA_Temp T : T 20.9
> > 2012.10.10 03:54:41 3: get OL_Temp T : T 20.2
> >
> > Grüße
> > Micha
>

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

[Guest]

Originally posted by: <email address deleted>

Könnte es sein, dass das Problem bei der 1-Wire-Implementierung bei
Ethersex liegt und diese keine zwei 1-Wire Abfragen gleichzeitig fehlerfrei
erlaubt?

Das könnte evtl. passieren, wenn ein 1-Wire-Sensor nicht in der
ECMD-Timeoutzeit von 3-Sekunden antwortet.

Wenn ich es richtig verstehe, erlaubt Ethersex normalerweise 3
gleichzeitige ECMD-Verbindungen.
In  /protocols/uip/uip-conf.h ist das definiert:
#define UIP_CONF_MAX_CONNECTIONS 3

Ihr könntet probieren eine neue Firmware zu compilieren, bei der die Anzahl
der Connections auf 1 gesetzt wird.
In diesem Fall könnt Ihr garantieren, dass keine zwei 1Wire-Abfragen
gleichzeitig laufen.
Oder zwei weitere telnets zu Port 2701 gleichzeitig laufen lassen.

Mag sein, dass es aber auch nichts damit zu tun hat.

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

[Guest]

Originally posted by: <email address deleted>

Hi Willi,
 
unwarscheinlich weil:
 
define AT_OnewireTemp at +*00:05 set reopen AVRNETIO;; sleep 5;; set OWDM
messen;; sleep 5;; get SCHLAF Temp;; sleep 5;; get HOF Temp;; sleep 5;; get
LUKAS Temp
 
Das hatte ich vorher sogar schon auf 20 stehen. Es führte aber zum gleichen
Fehler. Wenn man mit Hub und Wireshark bewaffnet mitsnifft kommen auch die
richtigen Antworten von der Net IO. Das interessiert FHEM aber nicht.
 
Gruß Andreas
 
 

Am Freitag, 6. Juli 2012 20:00:03 UTC+2 schrieb lo4dro:

> Beim ECMD habe ich das Problem, das der Rückgabewert von z.B. Temperaturen
> oft der vorherigen Messwert zurück gibt.
>
> z.B. zuerst sende ich ein "set Abgas_kalt messen" erhalte als Antwort ein
> "OK"
> Dann sende ich ein "get Abgas_kalt temp" und erhalte auch ein "OK"
> Wenn ich jetzt nocheinmal ein "get Abgas_kalt temp" sende erhalte ich den
> korrekten Wert.
>
> Anbei drei Bild die das vielleicht Verdeutlichen.
> Im Plot sieht man den Sägezahn und einen Sprung
>
> Wenn ich die Werte für den Dachs abfrage kommt bei jedem ersten Versuch
> ein falscher Wert.
> Da ich meine Konfiguration nicht ausschließen kann, anbei die zwei
> classdef und die Konfiguration im fhem.
>
> FHEM Konfiguration:
> #Ethersex Schopf
> define Schopf ECMD telnet 192.168.255.91:2701
> attr Schopf classdefs ONEWIRE=/etc/fhem/onewire.classdef
> attr Schopf room interface
>
> define Schopf_Temp ECMDDevice ONEWIRE 10799d70010800db
> attr Schopf_Temp group Raum Temp
> attr Schopf_Temp room Heizung
>
> #Ethersex Dachs
> define DACHS ECMD telnet 192.168.255.90:2701
> attr DACHS classdefs
> ONEWIRE=/etc/fhem/onewire.classdef:DACHSR=/etc/fhem/dachs.classdef
> attr DACHS room interface
>
> define DachsS ECMDDevice DACHSR 0
> attr DachsS room Heizung
> attr DachS group Dachs
>
> define HZ_Raum ECMDDevice ONEWIRE 1076b470010800f4
> attr HZ_Raum group Raum Temp
> attr HZ_Raum room Heizung
>
> define RL_Dachs_kalt ECMDDevice ONEWIRE 1076b470010800f4
> attr RL_Dachs_kalt group Heizung
> attr RL_Dachs_kalt room Heizung
>
> .... weitere 3 1Wire Sensoren ....
>
> Hier die zwei classdef
> dachs.classdef:
> # Uebergabeparameter DACHs abfragen es gibt 4 Modis
> params a
> # Umsetzung in ECMD Befehle
> # get 0 Modus e8
> # get 1 Modus c0
> # get 2 Modus 48
> # get 3 Modus 50
> #
> get c0 cmd {"msr1 get 1"}
> get e8 cmd {"msr1 get 0"}
> get 48 cmd {"msr1 get 2"}
> get 50 cmd {"msr1 get 3"}
>
> onewire.classdef:
> # Uebergabeparameter Onewire Geräte ID
> params devID
> # Umsetzung in ECMD Befehle 1w convert = Messung auslösen, 1w get =
> Tempwert lesen
> set messen cmd {"1w convert"}
> get temp cmd {"1w get %devID"}
>
>
>

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

[Guest]

Originally posted by: <email address deleted>

Hi Willi,
unwarscheinlich weil:
define AT_OnewireTemp at +*00:05 set reopen AVRNETIO;; sleep 5;; set OWDM
messen;; sleep 5;; get SCHLAF Temp;; sleep 5;; get HOF Temp;; sleep 5;; get
LUKAS Temp
Das hatte ich vorher sogar schon auf 20 stehen. Es führte aber zum gleichen
Fehler. Wenn man mit Hub und Wireshark bewaffnet mitsnifft kommen auch die
richtigen Antworten von der Net IO. Das interessiert FHEM aber nicht.
Gruß Andreas

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

[Guest]

Originally posted by: <email address deleted>

Erstens ist es natürlich so, dass der 1-Wire bus keine parallele
Adressierung verschiedener Devices für die Abfrage erlaubt.

Zweitens aber spricht hier das Experiment gegen diese Interpretation. Denn
es ist ja keine zufällige Durchmischung der Abfrageresultate - sondern die
Werte rücken immer einen Client weiter.

Mit dem Daumen im Wind: Sieht so aus, als ob ein Index in einem Ringpuffer
imme rmal wieder (z.B. bei einer fehlgegegangenen Abfrage) einen "Kick"
zuviel bekommt.

LG

pah

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

[MichaS]

                                                       

Hallo zusammen,

ich habe mich mal intensiver mit dem Coding befasst und die meiner
bescheidenen Meinung nach betroffenen Zeilen angepasst. Darüber hinaus habe
ich wie von Boris gewünschen Anpassungen an die zentrale DevIo.pm begonnen
einzupflegen.
Mit diesen Maßnahmen jedenfalls bringen die 1-Wire Temperatursensoren jetzt
seit über 14 Stunden die korrekten Werte und auch alles andere (Relais,
Funk) funktioniert normal.
Deshalb wage ich hier mal die Veröffentlichung meiner angepassten
66_ECMD.pm für Tests von euch
Bitte ersetzt die originale Datei mit der hier angehangenen und macht ein
reload 66_ECMD.pm oder shutdown restart

Gruß
Micha

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

[Guest]

Originally posted by: <email address deleted>

Würde mich interessieren, ob meine Vermutung richtig war.

LG

pah

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

[LuckyDay]

                                         

Leider tut das auch noch nicht

die Verschiebungen nach unten sind immer noch da,
was mir noch auffallt ist, wenn es anfängt , mit den Veschiebungen ist
meine Prozessorlast bei 100 %,7390,
alte wie neue Version.

Hary

On 12 Okt., 21:53, MichaS wrote:
> Hallo zusammen,
>
> ich habe mich mal intensiver mit dem Coding befasst und die meiner
> bescheidenen Meinung nach betroffenen Zeilen angepasst. Darüber hinaus habe
> ich wie von Boris gewünschen Anpassungen an die zentrale DevIo.pm begonnen
> einzupflegen.
> Mit diesen Maßnahmen jedenfalls bringen die 1-Wire Temperatursensoren jetzt
> seit über 14 Stunden die korrekten Werte und auch alles andere (Relais,
> Funk) funktioniert normal.
> Deshalb wage ich hier mal die Veröffentlichung meiner angepassten
> 66_ECMD.pm für Tests von euch
> Bitte ersetzt die originale Datei mit der hier angehangenen und macht ein
> reload 66_ECMD.pm oder shutdown restart
>
> Gruß
> Micha
>
>  66_ECMD.pm
> 15KAnzeigenHerunterladen

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

[Guest]

Originally posted by: <email address deleted>

Hi,

Bei mir das selbe. Problem tritt scheinbar auf sobald irgendwie in der Nähe der Abfragen ein Schaltbefehl gesendet wird. (rfm12 - 2272)

Gruß Andreas

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

[MichaS]

                                                       

Hallo zusammen,

ich kann leider auch bestätigen, das es das noch nicht war. Der Fehler
kommt bei mir aber jetzt viel später als sonst zustande als vorher
(erstmalig bei ca.21 Std Laufzeit). Ich habe jetzt eine angepasste Version
mit vielen Debug Ausgabezeilen versehen und werde berichten, wenn ich
weiter bin.

Grüße Micha

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

[LuckyDay]

                                         

Daumen hoch

Hary

On 14 Okt., 22:09, MichaS wrote:
> Hallo zusammen,
>
> ich kann leider auch bestätigen, das es das noch nicht war. Der Fehler
> kommt bei mir aber jetzt viel später als sonst zustande als vorher
> (erstmalig bei ca.21 Std Laufzeit). Ich habe jetzt eine angepasste Version
> mit vielen Debug Ausgabezeilen versehen und werde berichten, wenn ich
> weiter bin.
>
> Grüße Micha

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

[Guest]

Originally posted by: <email address deleted>

Hi,
 
Erkenntnisse?
 
Gruß Andreas
 

Am Montag, 15. Oktober 2012 01:27:05 UTC+2 schrieb fhem-hm-knecht:

> Daumen hoch
>
> Hary
>
> On 14 Okt., 22:09, MichaS wrote:
> > Hallo zusammen,
> >
> > ich kann leider auch bestätigen, das es das noch nicht war. Der Fehler
> > kommt bei mir aber jetzt viel später als sonst zustande als vorher
> > (erstmalig bei ca.21 Std Laufzeit). Ich habe jetzt eine angepasste
> Version
> > mit vielen Debug Ausgabezeilen versehen und werde berichten, wenn ich
> > weiter bin.
> >
> > Grüße Micha
>

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