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

[Guest]

Originally posted by: <email address deleted>

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>

Ich hole den Beitrag noch mal nach vorne.
Auch mit dem neuesten ECMD habe ich das Problem.
Gibt es keinen Möglichkeit den Fehler einzuschränken oder gar zu beseitigen?


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

[Tobias]

                                                   

Was mir auffällt das du überall ONEWIRE deklarierst. Probier mal bitte nur
mit einer(!) ECMD Installation. Wenn das dann alles klappt nimm die nächste
mit aus, aber bitte keine doppelten classdef deklarationen.

ICh kann den Fehler nicht ganz nachvollziehen, bei mir mit 5 1Wire
Sensoren, einem LCD-Modul und 3 Analogen Sensoren an einem ECMD
(AVR_NET_IO) funktioniert alles bestens.

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

[Guest]

Originally posted by: <email address deleted>

Am Montag, 16. Juli 2012 08:20:35 UTC+2 schrieb tobias.faust:
>
> Was mir auffällt das du überall ONEWIRE deklarierst. Probier mal bitte nur
> mit einer(!) ECMD Installation. Wenn das dann alles klappt nimm die nächste
> mit aus, aber bitte keine doppelten classdef deklarationen.
>
> ICh kann den Fehler nicht ganz nachvollziehen, bei mir mit 5 1Wire
> Sensoren, einem LCD-Modul und 3 Analogen Sensoren an einem ECMD
> (AVR_NET_IO) funktioniert alles bestens.
>

Ich werde es testen.
Ich habe zwei ECMD Geräte, und ich dachte jedes ECMD Gerät benötigt einen
classdefs die auf das Onewire Script zeigt.
Ich kann auch versuchen für jedes ECMD Gerät ein eigenes One-Wire Script
bei classdefs einzutragen.

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

[Guest]

Originally posted by: <email address deleted>

Hi,
 
das Problem habe ich hier vor einigen Monaten schon mal angesprochen -
leider ohne Ergebnis.
Ich habe mir damals die Mühe gemacht, die Kommunikation zwischen der NET-IO
und der Fritz mitzusniffen.
Was von der Net-IO kommt ist korrekt.
 
Das war auch der Grund, warum ich den ECMD Simulator geschrieben habe.
https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/ecmd/fhem-users/wSSieNZu2o0/8RjdP5tvHjgJ
 
Auch damit lässt sich das Problem nachvollziehen.
Es sieht nach einem Pufferüberlauf in FHEM aus. Der Fehler wandert alle
Paar Stunden weiter.
So zeigt dann das Plot vom Kinderzimmer z.B.  die Temperatur vom Hof oder
ein Schaltbefehl über RFM12 gibt als Antowort in FHEM eine Temperatur eines
Raumes.
 
Die Diskusion mit PAH damals dazu liegt hier:
https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/ecmd/fhem-users/TB85KxjredA/l8bUd6zZWUIJ
 
Das war damals der Auslöser, das Projekt FHEM erst mal bei Seite zu legen.
 
Gruß Andreas

>  
>

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

[Guest]

Originally posted by: <email address deleted>

In dem anderen Beitrag hast du etwas von LOG 5 geschrieben.
Kannst du mir genau sagen wo ich das eintragen muss.

Vielleicht kann der Autor uns hier weiterhelfen.

Gruß und schönes Wochenende

Am Freitag, 20. Juli 2012 12:31:32 UTC+2 schrieb Sturi2011:
>
> Hi,
>  
> das Problem habe ich hier vor einigen Monaten schon mal angesprochen -
> leider ohne Ergebnis.
> Ich habe mir damals die Mühe gemacht, die Kommunikation zwischen der
> NET-IO und der Fritz mitzusniffen.
> Was von der Net-IO kommt ist korrekt.
>  
> Das war auch der Grund, warum ich den ECMD Simulator geschrieben habe.
>
> https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/ecmd/fhem-users/wSSieNZu2o0/8RjdP5tvHjgJ
>  
> Auch damit lässt sich das Problem nachvollziehen.
> Es sieht nach einem Pufferüberlauf in FHEM aus. Der Fehler wandert alle
> Paar Stunden weiter.
> So zeigt dann das Plot vom Kinderzimmer z.B.  die Temperatur vom Hof oder
> ein Schaltbefehl über RFM12 gibt als Antowort in FHEM eine Temperatur eines
> Raumes.
>  
> Die Diskusion mit PAH damals dazu liegt hier:
>
> https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/ecmd/fhem-users/TB85KxjredA/l8bUd6zZWUIJ
>  
> Das war damals der Auslöser, das Projekt FHEM erst mal bei Seite zu legen.
>  
> Gruß Andreas
>
>>  
>>
>

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

[Guest]

Originally posted by: <email address deleted>

Der Simulator mag ja ganz nett sein, aber ohne eine Dokumentation, mit der
man ihm beispielsweise eine andere IP-Adresse zuweisen kann etc. nutz er
leider nicht sehr viel. Wo steht die denn ?
LG

pah

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

[Guest]

Originally posted by: <email address deleted>

Hi,

attr global verbose 5

Löst das Problem aber auch nicht endgültig. Es verschiebt das Auftreten des Problems nur einige Zig Abfragen nach hinten.

Gruß Andreas

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

[Guest]

Originally posted by: <email address deleted>

Hallo,

Da ich das Ganze nur so nebenbei gecodet habe, gibt es noch keine Dokumentation.
Als nächstes erwarte ich die Frage nach der Source....

Ich bin z.Zt. Im Urlaub. Habe danach aber Zeit die Doku auf der Webseite online zu stellen.
Das Progrämmchen ist ganz nützlich wenn man eine Fhem Konfiguration entwickeln will,
ohne die Hardware zu haben (Sensoren, Rfm Module, Pcf Chips usw.) oder die Programmierung
in C6 hinten anstellen will oder eben nur einfach Fehler in der Net-Io ausschließen will.

Wer es nicht verwenden möchte, dem steht es sicher frei, einen Telnet Server unter xxxux aufzusetzen
und diesen mit eigenen Scripten zu füttern.

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

[Dr. Boris Neubert]

                                             

~~~

Achtung: Crosspost! Antworten bitte nur in eine der Gruppen!

~~~

Hallo,

Am 20.07.2012 12:31, schrieb Sturi2011:
> Es sieht nach einem Pufferüberlauf in FHEM aus. Der Fehler wandert alle
> Paar Stunden weiter.

in 66_ECMD.pm gibt es in EMCD_SimpleRead den sysread-Befehl, der maximal
1024 Zeichen liest. Kann mir aber nicht vorstellen, daß das die Ursache ist.

Würde mich freuen, wenn jemand 66_ECMD.pm so anpaßt, daß die zentralen
Routinen in DevIO.pm benutzt werden. Das spart zum einen Code und zum
anderen profitiert dann das Modul von Verbesserungen an zentraler
Stelle. Ich komme zeitlich b.a.w. nicht dazu, mich darum zu kümmern.
Außerdem kann ich die berichteten Probleme auch nicht nachstellen.

Viele Grüße
Boris

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

[Guest]

Originally posted by: <email address deleted>

Außerdem kann ich die berichteten Probleme auch nicht nachstellen.

>
> Viele Grüße
>

Ich habe die ständig nachvollziehbar.
Vor allem bei der DACHS abfrage.

ich stelle Boris gerne ein VPN Verbindung zum fhem her.

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

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 20. Juli 2012 16:59:42 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Der Simulator mag ja ganz nett sein, aber ohne eine Dokumentation, mit der
> man ihm beispielsweise eine andere IP-Adresse zuweisen kann etc. nutz er
> leider nicht sehr viel. Wo steht die denn ?
> LG
>
> pah
>
So,
 
ich bin wieder zu hause. Die von Ihnen Immer und bei jedem Post von Usern
geforderte Dokumentation ist auf meiner Webseite verfügbar. Viel Spass
damit.
Die IP, die in dem Programm angezeigt wird, ist natürlich die bevorzugte IP
des Windows PCs auf dem der Simulator ausführt wird....ändern kann man sie
über:
Systemsteuerung, Netwerkeinstellungen usw. (je nach Windows Version). Wie
in meinem anderen Post geschrieben - wenn Ihnen der Simulator nicht viel
nützt
oder zu starr programmiert ist können Sie auch gerne irgendwo einen Telnet
Daemon aufsetzen und mit eigenen Scripts bestücken.
 
Mir hat er beim Debuggen gute Dienste geleistet - Thema durch.
 
Gruß Andreas

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

[Guest]

Originally posted by: <email address deleted>

Gut, dass die Dokumentation jetzt zur Verfügung steht.
Allerdings eher für andere - denn ich wollte das nicht selbst verwenden und
werde deshalb auch nicht nach "der source" fragen.

Ohne die Leistung des Erstellers schmälern zu wollen: Das ist zwar ein
generischer telnet-"Anrufbeantworter", aber ein ECMD-Simulator deshalb eben
(noch) nicht.

LG

pah

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

[Guest]

Originally posted by: <email address deleted>

>
> Hi,
>  
>
nach Test liegt es vermutlich nicht am Simpleread. Ich habe die Wariiable
mitdebugt. Sie ist annährend leer.
Als zweiten Test habe ich die Variabe $buf in der Funktion explizit mit
undef gelöscht. Auch dies brachte keine Änderung.
 
*Es scheint so*, das der Fehler erst auftritt wenn zufällig zwei AT
Commands in die gleiche Zeit fallen.
Also Quasi alle 10 Minuten Temperatur mit convert messen, 10 Sekunden
warten, Ersten Sensor lesen,
10 Sekunden warten 2en Sensor lesen usw. überlappt sich zu einem Zeitpunkt
X mit einer anderen Aktion wie Aquarienlicht an.
Dann werden annährend zeitgleich 2 Aufrufe getätigt. Die erste Antwort
scheint zur letzten Abfrage zugeordnet zu werden.
Danach kommen zwar die richtigen Antworten werden aber falsch zu geordnet.
Das wandert dadurch,
dass sich die Zeiten mit der oben genannten Schleife verschieben.
 
 
Wird das ECMD Modul konkurierend aufgerufen?
 
 
Wenn ja kann ich das dieser Tage mal mit 2 AT Commands und einem
Netzwerksniffer  sowie verbose=5 versuchen nachzustellen.
 
Gruß Andreas

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

[Guest]

Originally posted by: <email address deleted>

Hallo,
 
gibt es schon irgendwelche Fortschritte bei der Umstellung der ecmd module?
 
Gruß Andreas

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