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

[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"}

[lo4dro]

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?

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

[lo4dro]

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.

[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

 

[lo4dro]

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

[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

[Sturi2011]

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

[Sturi2011]

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.

[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

[lo4dro]

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.

[Sturi2011]

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

[Prof. Dr. Peter A. Henning]

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

[Sturi2011]

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

[Sturi2011]

Hallo,

 

gibt es schon irgendwelche Fortschritte bei der Umstellung der ecmd module?

 

Gruß Andreas

[MichaS]

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

[fhem-hm-knecht]

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

[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

[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

[Sturi2011]

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

[Willi]

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.

[Sturi2011]

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

[Prof. Dr. Peter A. Henning]

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

[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

[Prof. Dr. Peter A. Henning]

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

LG

pah

[fhem-hm-knecht]

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

>  66_ECMD.pm
> 15KAnzeigenHerunterladen

[Sturi2011]

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

[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

[fhem-hm-knecht]

Daumen hoch :)

Hary

[Sturi2011]

Hi,

 

Erkenntnisse?

 

Gruß Andreas

[MichaS]

Hallo zusammen,

ich habe mit meiner Debug Version ein dickes Logfile erhalten, in der das Problem auftaucht und wichtige Variablen mitgeschrieben sind. Es liegt definitiv ein Problem in der sub ECMD_ReadAnswer vor, wo es Prüfungen hinsichtlich Geräteverbindung/Timeout/Rückgabe gibt. Es kommt dort in unseren Problemfällen vor, das die Variable $nfound den Wert 0 enthält, welcher ein Abbruchkriterium darstellt bevor der der eigentliche Messwert von DevIo_SimpleRead rückgelesen wird. Das werde ich mal direkt mit Rudi/Boris in fhem-developers diskutieren.
Ich habe meine 66_ECMD.pm Testversion so umgestellt, das die Prüfungen umgangen werden und gleich der Rückgabewert gelesen wird. So läuft es bisher über 1,5 Tage völlig fehlerfrei.
Bitte tauscht hier wieder die angehangene Datei gegen die originale aus und berichtet mir das Ergebnis.

Grüße Micha

[NetIoR]

Hallo Micha

Danke für deine Arbeit! Habe dieselben Probleme.
Ich hab das mit der "angehangenen" Datei nicht begriffen. Wo kann ich die finden?
Möchte sehr gerne mittesten.

Gruss und Dank

ventscho

[MichaS]

Hallo ventscho,

an meinem Posting von gestern ist meine modifizierte Version der Datei 66_ECMD.pm als Datei angehangen. Bitte lade sie herunter und ersetze damit die originale Datei 66_ECMD.pm im FHEM Programmverzeichnis ../fhem/FHEM deiner originalen Installation. Bei einer Fritzbox ist das z.B. unter \\fritz.nas\FRITZ.NAS\fhem\FHEM zu finden.
Danach bitte ein reload 66_ECMD.pm in der fhem Befehlszeile ausführen oder komplett durchstarten mit shutdown restart in der Befehlszeile.

Da du die Probleme auch nachvollziehen kannst - Frage: Nutzt die auch eine Fritzbox als fhem Server ? Vielleicht doch ein spezielles Problem mit dieser Umgebung, wäre ja möglich.

Grüße Micha

[NetIoR]

Hallo Micha

Sorry, hat sich geklärt.

War mit dem Tablet im netz unterwegs und da zeigt es die Datei gar nicht an.

Werde die Datei nun ersetzen und dann mal schauen obs besser klappt.

Ich verwende eine QNAP NAS TS-112 als fhem HW.

Und bin absoluter Dan von Ethersex und fhem in Kombination.

Leider bin ich Perl nicht wirklich mächtig. 

Gruss und Dank für dein Feedback

[Sturi2011]

Hi Micha,

 

13 Stunden fehlerfrei....

 

Gruß Andreas 

[Sturi2011]

Hallo allerseits.

Gibt's hier schon neue Infos?

Gruß Andreas

[fhem-hm-knecht]

@MichaS
Bei mir läuft es jetzt ohne Fehler,

noch unschoen ist, das wenn die Verbindung abbricht, zum bsp wenn
netio neustartet nach stromausfall,
ecmd es merkt, geht auf disconnect,
dann aber kein reopen macht. das fehlt noch.
Dann wäre es perfekt

Hary

>  66_ECMD.pm
> 16KAnzeigenHerunterladen

[MichaS]

Hallo Hary,

bei mir läuft die Rückgabe der Messwerte mit der angepassten Testversion der 66_ECMD.pm seitdem auch fehlerfrei durch. Die Sache mit dem reopen schaue ich mir gerne mal an, momentan ist es zeitmäßig aber etwas eng.

Gruß Micha

[Dr. Boris Neubert]

Hallo, schickt Ihr mir bitte den Patch per PM? Danke, Boris

---

Von: MichaS <mschu...@googlemail.com>
Gesendet: Wed Oct 31 10:49:13 MEZ 2012
An: fhem-...@googlegroups.com
Betreff: [FHEM] Re: (ECMD) Re: beim auslesen von Messwerten wird oft der falscher Wert (vorgänger Wert) zurückgegeben.

Hallo Hary,

bei mir läuft die Rückgabe der Messwerte mit der angepassten Testversion der 66_ECMD.pm seitdem auch fehlerfrei durch. Die Sache mit dem reopen schaue ich mir gerne mal an, momentan ist es zeitmäßig aber etwas eng.

Gruß Micha

--
sent from my WePad - apologies for brevity

[Woody1507]

Hi Leute,
ich habe auch diesen Fehler, das nach einer gewissen Laufzeit die Abfragen stocken bzw die Ergebnisse nicht mehr stimmen. Im log steht dann nur noch "messen OK"
Sind die Änderungen der Testdatei in die originale eingeflossen?

Grüße

woody

[fhem-hm-knecht]

Nö,

kurz und knapp
hary

On 18 Nov., 16:58, Woody1507 <heiko.wittm...@gmx.de> wrote:
> Hi Leute,
> ich habe auch diesen Fehler, das nach einer gewissen Laufzeit die Abfragen
> stocken bzw die Ergebnisse nicht mehr stimmen. Im log steht dann nur noch
> "messen OK"
> Sind die Änderungen der Testdatei in die originale eingeflossen?
>
> Grüße
>
> woody
>
>
>
>
>
>
>
> On Wednesday, October 31, 2012 9:28:20 PM UTC+1, Boris wrote:
>
> > Hallo, schickt Ihr mir bitte den Patch per PM? Danke, Boris
>

> > ------------------------------
> > *Von:* MichaS <mschu...@googlemail.com <javascript:>>
> > *Gesendet:* Wed Oct 31 10:49:13 MEZ 2012
> > *An:* fhem-...@googlegroups.com <javascript:>
> > *Betreff:* [FHEM] Re: (ECMD) Re: beim auslesen von Messwerten wird oft

[Dr. Boris Neubert]

Am 18.11.2012 17:46, schrieb fhem-hm-knecht:
> N�,

>
> kurz und knapp
> hary
>
> On 18 Nov., 16:58, Woody1507 <heiko.wittm...@gmx.de> wrote:
>

> Sind die �nderungen der Testdatei in die originale eingeflossen?
>
>
>
tun sie auch nicht, bis ich die �nderungen zu sehen bekomme (in Form des
funktionierenden Moduls per PM).

Gr��e
Boris

[Sturi2011]

Hallo Boris,

Das funktionierende Modul ist oben an eines der Posts angehängt (letzte Version). Seit dem Update auf die 5.3 ist der Fehler jedoch verschwunden. Das Modul Schein beim Update einige Umbauten erfahren zu haben - dafür vielen Dank. Insgesamt läuft Fhem bei mir seit dem Update deutlich stabiler.

Gruß Andreas