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
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
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
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
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
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
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
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
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
~~~
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
On Wednesday, October 17, 2012 9:22:13 PM UTC+2, MichaS wrote:
>
> 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Hi Micha,
13 Stunden fehlerfrei....
Gruß Andreas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
@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
On 16 Okt., 21:50, MichaS wrote:
> 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
>
> 66_ECMD.pm
> 16KAnzeigenHerunterladen
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo, schickt Ihr mir bitte den Patch per PM? Danke, Boris
-------- Original-Nachricht --------
Von: MichaS
Gesendet: Wed Oct 31 10:49:13 MEZ 2012
An: fhem-users@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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
--
sent from my WePad - apologies for brevity
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 >
> *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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Nö,
kurz und knapp
hary
On 18 Nov., 16:58, Woody1507 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 >
> > *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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 18.11.2012 17:46, schrieb fhem-hm-knecht:
> Nö,
>
> kurz und knapp
> hary
>
> On 18 Nov., 16:58, Woody1507 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
Originally posted by: <email address deleted>
Hallo allerseits.
Gibt's hier schon neue Infos?
Gruß Andreas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com