OWX.pm Timingproblem an langsamen oder mit anderen Aufgaben beschaeftigten Rechnern Rechnern

271 views
Skip to first unread message

joachim herold

unread,
Nov 13, 2012, 6:34:53 AM11/13/12
to fhem-de...@googlegroups.com
Moin @ all,
Ich glaube, die nachfolgende Diskussion ist bei FHEM developers besser aufgehoben. wenn nicht, dann sagt es.
Kurz zu mir, ich habe eine FB 7570, auf der FHEM mit 1-Wire rennt, der Adapter ist ein LinkUSB-Adapter, meine Perlkenntnisse sind gering bis gernicht vorhanden, und ich habe scheinbar Timingprobleme die unerwünschte Nebeneffekte bei 1-Wire haben. siehe Diskussion 1-Wire Timingprobleme.
Nach meiner Analyse der OWX.pm glaube ich, den Fehler gefunden zu haben.
Ich möchte allerdings nicht in ein fremdes Modul hineinpfuschen, und tue mich aufgrund meiner geringen Perlkenntnisse auch schwer, die Loesung richtig hinzubekommen.

Das Problem liegt meiner Meinung nach hier: OWX.pm Zeile 475 ff

 #-- here we treat the directly connected serial interfaces          # hier wird der Adapter initialisiert, und ein Datenpaket zusammengestellt,
  if($owx_interface eq "serial"){                                               #
dass dann ueber OWX_Query_2480
    #-- timing byte for DS2480                                                 #
gesendet wird, diese Antwort wird zuwar abgewartet, aber nicht ausgewertet.
    OWX_Query_2480($hash,"\xC1");                                      #
                                                                                           #
    #-- Max 4 tries to detect an interface                                  # hier wird ein Datenpaket zusammengestellt,
    for($l=0;$l<4;$l++) {                                                          # das den Adapter fragt, wie er "heisst"
      #-- write 1-Wire bus (Fig. 2 of Maxim AN192)                    #
      $res = OWX_Query_2480($hash,"\x17\x45\x5B\x0F\x91");# im folgendem Log sieht man das Problem

2012.11.12 23:47:32.540 3: OWX: Sending out 0xc1 # Datenpaket wird gesendet
2012.11.12 23:47:32.551 3: OWX: Receiving # Adapter ist zu langsam, oder der Rechner mit einem anderen Prozess beschaeftigt und es kommt keine Antwort
2012.11.12 23:47:32.595 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91 # stoert OWX.pm nicht, es wird das naeste Paket gesendet
2012.11.12 23:47:32.603 3: OWX: Receiving 0xc1 0x17 0x45 # jetzt kommt das Problem, =0xc1 ist die Antwort auf die voherige Frage, und
0x17 0x45 ist eine noch
2012.11.12 23:47:32.641 1: OWX: 1-Wire bus 1_Wire: interface not found, answer was 0xc1 0x17 0x45 # nicht komplette Antwort
2012.11.12 23:47:33.144 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91 # da 4mal abgefragt wird, gibt es einfach eine neue Abfrage
2012.11.12 23:47:33.152 3: OWX: Receiving 0x5b 0x0f 0x91 #leider hängt noch der rest der vorherigen Frage im Speicher
2012.11.12 23:47:33.191 1: OWX: 1-Wire bus 1_Wire: interface not found, answer was 0x5b 0x0f 0x91 # und das Interfache wird nicht erkannt
2012.11.12 23:47:33.696 3: OWX: Sending out 0x17 0x45 0x5b 0x0f 0x91 # bei dieser Abfrage haben wir Glueck, denn
2012.11.12 23:47:33.703 3: OWX: Receiving 0x17 0x45 0x5b 0x0f 0x91 # hier bekommt er die Antwort der vorherigen Frage, die glücklicherweise auch auf diese
2012.11.12 23:47:33.740 1: OWX: 1-Wire bus 1_Wire: interface master DS2480 re-detected # Frage passt, und erkennt den Adapter

Dieses Problem zieht sich durch die ganze OWX.pm, und ist auch nur nicht zufriedenstellend durch heraufsetzen des Sleepbefehls in Zeile 1319 ff zu loesen.
Die Loesung muesste ungefaehr so aussehen:

  #-- here we treat the directly connected serial interfaces
  if($owx_interface eq "serial"){
    #-- timing byte for DS2480
    OWX_Query_2480($hash,"\xC1");
    Kontrolliere, ob die Antwort richtig ist ( nach meinen Versuchen wird hier immer 0xc1 zurueckgesendet), wenn nicht schlafe ein weilchen,
    und lese dann nocheinmal die Antwort. Wenn die Antwort jetzt richtig ist, mach weiter, sonst gib eine Logeintrag.

    #-- Max 4 tries to detect an interface
    for($l=0;$l<4;$l++) {
      #-- write 1-Wire bus (Fig. 2 of Maxim AN192)
      $res = OWX_Query_2480($hash,"\x17\x45\x5B\x0F\x91");
      Kontrolliere, ob die Laenge richtig ist (5 hex-Werte 0x??) wenn nicht schlafe ein weilchen und lese nocheinmal die Antwort.
      Wenn die Antwort jetzt richtig ist, mach weiter, sonst gib eine Logeintrag.
      #-- process 4/5-byte string for detection
      if( !defined($res)){
        $res="";
        $ret=0;
      }elsif( ($res eq "\x16\x44\x5A\x00\x90") || ($res eq "\x16\x44\x5A\x00\x93")){
        $ress .= "master DS2480 detected for the first time";
        $owx_interface="DS2480";

So, ich hoffe das war verstaendlich.
Diese Loesung koennte bei allen anderen schreib/lesezugriffen analog angewendet werden.
leider habe ich bisher keine Logs von anderen Usern, die z.B. Probleme mit dem Rapsberry oder CUL/Cuno haben. Denn hier Koennte das gleiche Problem vorliegen.
Ich meine damit folgende Treads:
https://groups.google.com/forum/#!topic/fhem-users/j62lraA7f-w
https://groups.google.com/forum/#!topic/fhem-users/N2MPiEXTOqs
https://groups.google.com/forum/#!searchin/fhem-users/1-Wire/fhem-users/as2p3ZG7Rf4/UPBhOP8E1d8J
https://groups.google.com/forum/#!searchin/fhem-users/1-Wire/fhem-users/63YoeFIfeDk/p14G0NxvlWMJ
https://groups.google.com/forum/#!searchin/fhem-users/1-Wire/fhem-users/nVPNxzclcIs/WN0kyoFclMkJ
https://groups.google.com/forum/#!searchin/fhem-users/1-Wire/fhem-users/qU9YqUKV2DI/vBWG6NSPNdUJ
https://groups.google.com/forum/#!searchin/fhem-users/1-Wire/fhem-users/niYcEd4bfVQ/9p6LlXz1FKcJ

MfG
Joachim

tobias.faust

unread,
Nov 13, 2012, 9:31:08 AM11/13/12
to fhem-de...@googlegroups.com
Ich habe jetzt auch mal meinen LinkUSBi Adapter angeschlossen, statt dem MP00202 von Kristech.
1Wire Netz ist Linientopologie, ca 20m CAT5 FTP Kabel mit 2x DS18B20, 5x DS2406, 1x2450.
Nach 3h noch keine Fehler im Log.

Ich lasse es jetzt weiter laufen und beobachte....

joachim herold

unread,
Nov 13, 2012, 9:54:58 AM11/13/12
to fhem-de...@googlegroups.com
Hallo tobias,
ich glaube auch nicht, dass es am LinkUSB adapter liegt, denn an meinem Notebook rennt es bis auf ganz seltene Aussetzer, die sich aber hiermit erklaehrenlassen, auch sauber.
Auf meiner FB7570 dagegen gibt es massenhaft die Probleme die ich oben geschildert habe.
Mein Verdacht ist, der, dass ein langsamer Rechner, hier die Fritzbox, in Verbindung mit weiteren laufenden Programmen die ja alle Rechenzeit benötigen ab und an das oben genannte Problem erzeugt. Die Zeitkritische Anfrage wird zu spät abgearbeitet, wenn dem so waere, koennte das eben auch die Rapsberry und andere Probleme erklaeren.

MfG
Joachim

Prof. Dr. Peter A. Henning

unread,
Nov 14, 2012, 1:59:00 AM11/14/12
to fhem-de...@googlegroups.com
C1 ist ein Timing Byte, das dem 2480 mitteilt, welchen Takt er zu erwarten hat. Gemäß 1-Wire Spezifikation wird eine Rückgabe nicht ausgewertet.

Ich vermute, dass in der Tat die 7570 die serielle Schnittstelle zu langsam bedient, so dass immer die Hälfte der Returnwerte noch nicht im Puffer ist. Wie man im Header der Unterprogramms OWX_Detect lesen kann, verwende ich bisher eine sehr grobe Methode, um den Adapter festzustellen. Darin könnte man alle Aufrufe von OWX_Query_2480($hash,string) ersetzen durch OWX_Complex_SER($hash,undef,string, ANZAHL DER ZU ERWARTENDEN BYTES). Achtung: Dann muss vorher $owx_interface probehalber auf DS2480 gesetzt werden.

Ich kann  nicht garantieren, dass dies tut - denn es werden hier einfach weitere FF-Bytes auf den Bus ausgesendet. Das Lesen des returns also verzögert.

Falls das nicht geht, müsste man die Funktion OWX_Query_2480 umschreiben und auf die Anzahl der erwarteten Bytes warten. Das zieht sich aber durch ziemlich viele andere Unterprogramme, und dafür hab eich im Moment leider zu wenig Zeit (bin heute schon wieder auf dem Weg nach London).

LG

pah

joachim herold

unread,
Nov 14, 2012, 2:50:01 AM11/14/12
to fhem-de...@googlegroups.com
Moin Prof,

das ist doch mal eine Antwort.
Wenn Du nichts Dagegen hast, dann werde ich das mal versuchen, testen, und dann hier als Diff reinstellen.
Aber erwarte nicht, dass es huebsch Programmiert ist.

Gruss und schoenen Tag in London

Prof. Dr. Peter A. Henning

unread,
Nov 14, 2012, 10:30:32 AM11/14/12
to fhem-de...@googlegroups.com
Ich habe noch mal überlegt: Wäre gar nicht so schwer, wie gedacht. Die Query_2480-Routine könnt eman darauf trimmen, immer genausoviel Bytes abzuwarten, wei sie gesendet hat. Das würde nur erfordern, dass man für jedes weitere erwartete Byte ein FF absendet.

Gruss aus dem sonnigen London

pah

joachim herold

unread,
Nov 14, 2012, 10:57:42 AM11/14/12
to fhem-de...@googlegroups.com
Fängt man sich dann nicht an dieser Stelle Probleme ein?

2012.11.09 15:36:21 3: OWX: Sending out 0xe3 0xc5
2012.11.09 15:36:21 3: OWX: Receiving 0xdd
2012.11.09 15:36:22 3: OWX: Sending out 0xe1 0xf0 0xe3 0xb5
2012.11.09 15:36:22 3: OWX: Receiving 0xf0

Prof. Dr. Peter A. Henning

unread,
Nov 15, 2012, 6:36:14 AM11/15/12
to fhem-de...@googlegroups.com
Hm, Jein. Die Sequenzen des Command Mode müssen natürlich erkannt und aus der Zählung herausgenommen werden. Diese werden aber auch erst nachträglich eingefügt, das könnte man in einer Variablen mitführen.

pah

joachim herold

unread,
Dec 1, 2012, 6:28:15 AM12/1/12
to fhem-de...@googlegroups.com
Moin Professor,

hat zwar etwas gedauert, aber mit try and error habe ich es jetzt geschafft, die 00_OWX.pm so anzupassen, dass mein 1-Wire auf der Fritzbox 7570 mit dem LinkUSBi sauber rennt.
Der Code ist sicherlich verbesserungswuerdig, aber ich hoffe, Du kannst es entsprechend angepasst in Dein Modul uebernehmen.
Im Anhang die geaenderte 00_OWX.pm und ein Log, an dem man gut erkennt, wo das Problem war und wie es geloest ist.

MfG Joachim
OWX.zip

Prof. Dr. Peter A. Henning

unread,
Dec 1, 2012, 1:41:50 PM12/1/12
to fhem-de...@googlegroups.com
Hallo,

Ich habe das gerade mal überflogen. Die Änderung besteht also darin, dass

- jedesmal vor OWX_Query_2480 die globale Variable laenge gesetzt wird
- in OWX_Query_2480 so lange geloopt wird, bis die gewünschte Anzah Bytes angekommen ist.

Ist das richtig ? Denn beim Vergleich mit dem _aktuellen_ Code ergeben sich auf Grund des gerade im Gange befindlichen Umbaus von OWX.pm so viele Abweichungen, dass man den Wald vor lauter Bäumen nicht mehr sieht.

LG

pahl

joachim herold

unread,
Dec 1, 2012, 2:50:13 PM12/1/12
to fhem-de...@googlegroups.com
Im groben und ganzen ja,

Ich habe an den Stellen, die ich gefunden habe, wo also das schreiben und lesen vorbereitet wird, die globale Variable $laenge befuellt, die Vorbereitungen dafuer gab es ja schon,
und beim lesen mit $count_in verglichen, und so lange geloopt, bis die gewünschte Anzah Bytes angekommen ist. Wichtig ist der Zaehler $n der eine Endlosschleife verhindert.
Mangels anderer Hardware konnte ich es nicht fuer andere 1-Wire-Devices testen, und ich weiss auch nicht, ob ich alle Aufrufe getroffen habe.
Wie man an meinem angehaengten Log aber sehr schoen sehen kann, braucht es ab und zu sehr lange, bis der komplette Rueckgabestring da ist.
Bei mir ist damit jetzt ein sehr sauber laufender 1-Wire-Bus mit z.Z. 9 Tempsensoren und ca. 90 m Laenge entstanden. Seit dieser Aenderung sind jedes mal alle Sensoren gefunden worden, und es werden auch jedesmal alle Temp. Messungen durchgefuehrt, vorher waren max. 4 Sensoren moeglich. ggf. koennten damit auch beim Cuno Probleme verringert werden.
Fuer die genauen Aenderungen mach doch ein diff gegen OWX aus dem SVN.

gruss Joachim

Prof. Dr. Peter A. Henning

unread,
Dec 1, 2012, 3:58:16 PM12/1/12
to fhem-de...@googlegroups.com
Hm,

erst einmal hat der CUNO etwas andere Probleme (siehe 1-Wire Update von heute).

Zweitens wird der ganzs anders abgefragt.

Außerdem eine Bitte: erzeuge mit Deinen Änderungen ein patch-File und poste es hier.

LG

pah

joachim herold

unread,
Dec 1, 2012, 4:21:04 PM12/1/12
to fhem-de...@googlegroups.com
Patchfile gibt es morgen, bin auf der Arbeit

joachim herold

unread,
Dec 2, 2012, 1:06:54 AM12/2/12
to fhem-de...@googlegroups.com
Guten Morgen Professor,

in der Anlage das Patchfile.

MfG
Joachim
OWXpatchfile.patch

Prof. Dr. Peter A. Henning

unread,
Dec 2, 2012, 1:09:42 AM12/2/12
to fhem-de...@googlegroups.com
Danke !

Ich seh mal, ob ich das einbauen kann.

LG

pah

joachim herold

unread,
Dec 2, 2012, 1:14:18 AM12/2/12
to fhem-de...@googlegroups.com
Waere Super,
erspart mir das rumfrickeln.
Evtl kontrollieren, ob ich alle relevanten Write/rRead Aufrufe getroffen habe.

gruss Joachim

Prof. Dr. Peter A. Henning

unread,
Dec 2, 2012, 2:47:42 AM12/2/12
to fhem-de...@googlegroups.com
Sicher nicht - den beim 9097-Interface wäre dies ebenfalls einzubauen.

LG

pah
Reply all
Reply to author
Forward
0 new messages