OWTHERM blockiert FHEM

[Joachim]

Moin pah,
nur um Missverständnissen vorzubeugen:
Ich finde Deine OWX-Module gut, und freue mich schon darauf, dass die asyncrone Variante vernünftig funktioniert.
Ich will auch nicht an den Modulen herummäkeln.
Allerdings bin ich immernoch der festen Überzeugung, dass es einen Designfehler in den Modulen gibt, und dass ist in meinen Augen konstruktive Kritik.
Übrigens tappt auch das OWDevice Modul in eine ähnliche Falle.

Nun zu Deiner Anwort:

Erstens stimmt es nicht, dass das bei zeitkritischen Modulen nicht funktioniert

Dem ist leider nicht so, bedingt durch das aktive Warten des OWX-Moduls verliert HM definitiv die Verbindung, da es zu spät an die Reihe kommt, und dann den HM Lan nicht mehr rechtzeitig streicheln kann, was zu einem disconnect des HM Lan führt. Das passiert nicht jedes mal, und hängt von der Menge der 1-Wire Sensoren ab, ist aber anhand von Logs nachzuweisen. Da ich mein Produktivsystem deshalb jetzt nicht zerpflücke, kan ich Dir im moment nicht die Logs mitliefern, bin aber bereit, das nachzuholen.

Mit einem aktiven Busmater beträgt die Blockade des Systems auch keine "1200 ms" - sondern gerade mal 100 ms, wenn nicht gerade eine Bussuche durchgeführt wird.

Da ich mit Deiner letzten OWX-Version arbeite, also wahrscheinleich die gleiche Version, die Du auch benutzt, widerspreche ich dir hier, 100ms sind ein Traumwert, der nicht eingehalten werden kann, wie man an dieser mit zusätzlichen Logeinträgen gewürzten OWTHERM Abfrage hervorragend erkennt (es ist  jeweils vor und hinter select(undef,undef,undef ein Logeintrag):

17:59:09.225 3: Beginn OWXTHERM_GetValues
17:59:09.227 3: OWX: Sending out        0xe3 0xc5
17:59:09.227 3: Pause anfang
17:59:09.267 3: Pause ende                                                                                                     # 40ms Pause
17:59:09.269 3: Pause anfang
17:59:09.289 3: Pause ende                                                                                                     # 20ms Pause
17:59:09.289 3: OWX: Receiving in loop no. 1 0xdd
17:59:09.290 3: Pause anfang
17:59:09.300 3: Pause ende                                                                                                     # 10ms Pause
17:59:09.302 3: OWX: Sending out        0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
17:59:09.302 3: Pause anfang
17:59:09.343 3: Pause ende                                                                                                     # 40ms Pause
17:59:09.344 3: Pause anfang
17:59:09.364 3: Pause ende                                                                                                     # 20ms Pause
17:59:09.365 3: Pause anfang
17:59:09.375 3: Pause ende                                                                                                     # 10ms Pause
17:59:09.375 3: OWX_Complex_SER: Receiving   0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
17:59:09.375 3: Beginn OWXTHERM_GetValues Pause anfang
17:59:10.176 3: Beginn OWXTHERM_GetValues Pause ende                                                       # 800ms Pause
17:59:10.178 3: OWX: Sending out        0xe3 0xc5
17:59:10.178 3: Pause anfang
17:59:10.218 3: Pause ende                                                                                                     # 40ms Pause
17:59:10.220 3: Pause anfang
17:59:10.240 3: Pause ende                                                                                                     # 20ms Pause
17:59:10.240 3: OWX: Receiving in loop no. 1 0xdd
17:59:10.240 3: Pause anfang
17:59:10.251 3: Pause ende                                                                                                     # 10ms Pause
17:59:10.253 3: OWX: Sending out        0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
17:59:10.253 3: Pause anfang
17:59:10.293 3: Pause ende                                                                                                     # 40ms Pause
17:59:10.295 3: Pause anfang
17:59:10.315 3: Pause ende                                                                                                     # 20ms Pause
17:59:10.315 3: Pause anfang
17:59:10.326 3: Pause ende                                                                                                     # 10ms Pause
17:59:10.326 3: OWX_Complex_SER: Receiving   0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49
17:59:10.326 3: Ende OWXTHERM_GetValues
                                                            # gesamt durch select(undef,undef,undef genutzte Zeit: 1080 ms Pause

Man sieht hier sehr gut, das FHEM für 1,08 Sekunden angehalten wird, und das ist inakzeptabel, wenn andere Zeitkritische Module zusätzlich in FHEM arbeiten. Wenn ich mich recht entsinne, muß ein ack in HM innerhalb von 60 bis 100 ms gesendet werden. Und das ist dann ein Designfehler, den man auf mehrere Arten lösen kann.

Zweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen

hier hat Dir Norbert gerade widersprochen, und ich widerspreche hier auch, es ist allerdings nicht trivial das richtig zu programmieren. Wenn ich kein Perl-Anfänger wäre, und mehr Zeit hätte, würde ich es Dir auch gerne beweisen.

lies mal Deinen Popper nach

Wer ist das?

Und dann lass Dir sagen, dass die schöne Theorie, das alles über DevIO ganz einfach zu machen sei, eben falsifiziert worden ist.

Bisher ist das noch nicht widerlegt worden.

Gruß Joachim

[dan1180]

Hallo ntruchsess,

klar mache ich das, sofern die hier anweseden Profis einigermaßen gute Chancen für einen Erfolg einräumen. Ich möchte von niemandem Brief und Siegel nur wenn mir hier jemand sagt: "lass es, wird nicht besser", dann lass ich es. Ich verstehe die Aussagen zu meinem Problem so, dass ich mit einem aktiven Busmaster und dem asynchronen Modul meine 19 Sensoren abfragen können müsste, ohne meine HM Komponenten auszuhebeln?!?

Und noch eine Frage an alle:
Kann es sein, dass ich meinen DS9097 durch einen Reboot oder eine andere Aktion von FHEM kaputt gemacht habe? Über die Software digitemp werden all meine Sensoren erkannt. Ich kann jedoch keine Temoeraturen mehr abfragen. Auch eine Verbindung über OWX funktioniert nicht mehr "failed".

Danke, Dan

[Joachim]

Ich verstehe die Aussagen zu meinem Problem so, dass ich mit einem aktiven Busmaster und dem asynchronen Modul meine 19 Sensoren abfragen können müsste, ohne meine HM Komponenten auszuhebeln?!?

OWX_ASYNC ist noch in der Testphase, aber es sieht schon recht gut aus.
Ansonsten bleibt immer noch die Variante, die ich Die im anderen Tread geschrieben habe.

Gruß Joachim

[Joachim]

Moin pah,
hat zwar etwas gedauert, bis ich Das Buch "Karl Popper Logik der Forschung" durch hatte, war sehr interessant.

hier mal ein unkommentiertes Zitat für Dich:

Karl Popper Logik der Forschung 11. Auflage
II. Kapitel
Zum Problem der Methodenlehre
"Denn wer an einem System, und sei es noch so 'wissenschaftlich' dogmatisch festhält (z.B. an dem der klassischen Mechanik),
wer seine Aufgabe etwa darin sieht, ein System zu verteidigen, bis seine Unhaltbarkeit logisch zwingend bewiesen(bewiesen hervorgehoben, Anm. d. Verf.) ist,
der verfährt nicht als empirischer Forscher in unserem Sinn;
denn ein zwingender logischer Beweis für die Unhaltbarkeit eines Systems kann ja nie erbracht werden,
da man ja stets experimentelle Ergebnisse als nicht zuverlässig bezeichnen oder etwa behaupten kann,
der Widerspruch zwischen diesen und dem System sei nur ein scheinbarer und werde sich mit Hilfe neuer Einsichten beheben lassen...
Wer in den empirischen Wissenschaften strenge Beweise verlangt [oder strenge Widerlegungen],
wird nie durch Erfahrung eines Besseren belehrt werden können."

Gruß Joachim

[Prof. Dr. Peter Henning]

Nicht doch. Möglicherweise solltest Du um 1:40 in der Frühe keine Mails mehr schreiben, da verwechselst Du dann Ursache und Wirkung. Zum Trost: passiert manchmal auch den Studenten, bei denen ich Wissenschaftstheorie lehre ...

Die Hypothese, dass das alles asynchron über DevIO laufen würde, stammt von Dir. Ich habe geschrieben: "Nein, das ist nicht so. Widerlegt durch ein Experiment". Norbert Truchsess widerspricht mir nicht, sondern sagt ganz eindeutig genau dasselbe: "Das geht nicht mit den DS2480 Busmastern".

Also ist nach Poppers (und meiner) Sicht derjenige, der an seinem System (in Popperschem Sinne) festhält: Joachim. Nicht pah  .

LG

pah

[ntruchsess]

Joachim, Pah,

ich glaube Ihr redet einfach aneinander vorbei. Pah benutzt OWTHERM vermutlich mit 'doKick=1', Joachim vermutlich nicht. Deshalb gibt's bei Joachim auch die synchronen Pausen >= 1 Sek (mal Anzahl OWTHERM-devices). Bei Pah sind die nur 500ms lang und treten nur einmal pro Kick-interval auf, das schmerzt rein statistisch natürlich viel weniger.

Diese Art von Pausen (längeres synchrones Warten per select) läßt sich mit asynchroner Verarbeitung über DevIO komplett vermeiden. Nicht vermeiden läßt sich, dass das Absenden einer 1-Wire-Kommandfolge mit einem DS2480 ca. 70-80ms Zeit braucht, auch wenn der Empfang der zugehörigen Daten asynchron über DevIO erfolgt.

Irgendwie passt das Poppers-zitat für Euch alle Beide, natürlich mit der jeweils eigenen Hypothese.

Hier übrigens die aktuelle asynchrone Implementierung dieser berüchtigten 1-Sekunden Pause basierend auf Protothreads.
(Die eher sperrige API über OWX_Execute -> AfterExecuteFn ist damit obsolet geworden, jetzt läuft der Code nach der über DevIO empfangenen Antwort dort weiter, wo er beim Absenden des 1-Wire Befehls aufgehört hat).

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Nee, da lass ich auch nicht locker, das ist gegen meine Berufsehre: Ich habe keine Hypothese formuliert und halte an gar nichts fest.

LG

pah

[Joachim]

Moin pah,

Ich bin immer wieder traurig, wenn ich mitansehen muss, wie gute Leute, die großartiges geleistet haben, sich irgendwann selbst demontieren.
Allerdigs bin ich auch erwachsen genug, um mich nicht wie einen dummen Jungen behandeln zu lassen.
Und solche Kommentare:

Nicht doch. Möglicherweise solltest Du um 1:40 in der Frühe keine Mails mehr schreiben, da verwechselst Du dann Ursache und Wirkung. Zum Trost: passiert manchmal auch den Studenten, bei denen ich Wissenschaftstheorie lehre ...

kannst Du Dir sparen, denn sie tragen nicht zur Lösungsfindung bei.
Wenden wir uns jetzt doch mal den Fakten zu:
Du behauptest:

Die Hypothese, dass das alles asynchron über DevIO laufen würde, stammt von Dir.

Wenn Du meinen Beitrag gelesen hättest, wüsstest Du, dass ich das nie behauptet habe, meine Aussage war:

komplette serielle Verarbeitung mit DevIO.pm und Freigabe der fhem-Schleife nach Schreiben in DevIO, wenn DevIO Daten meldet, Kontrolle und Verarbeitung.

asyncron != seriell
Du sprichst von:

Widerlegt durch ein Experiment

wo in diesem oder einem anderen Tread kann ich mir dieses Experiment ansehen?
Du behauptest:

Mit einem aktiven Busmater beträgt die Blockade des Systems auch keine "1200 ms" - sondern gerade mal 100 ms,

Da Du dieses Modul geschrieben hast, gibt es nur die Erklärung, dass Du unter Annesie leidest (damit solltest Du zum Arzt gehen), denn die Alternative wäre, dass Du bewußt die Tatsachen verdreht hast, und das würdest Du als Wissenschaftler sicherlich nicht machen. Den Gegenbeweis zu Deiner Behauptung es dauert nur 100 ms habe ich hier vorgestern um 18:47 gepostet. Die Gesamtblockade von FHEM durch OWX/OWTHERM beträgt 1101 ms, davon 1080ms bedingt duch Blockieren der FHEM Hauptschleife, oder anders ausgedrückt, 98,09 % der Zeit werden damit verschwendet, dass FHEM schläft. Und dabei ist es egal, ob FHEM auf einem 386 DX 100 läuft, oder auf einem modernen Mehrkernprozessor.
Hier behaupte ich, das ist ein Designfehler, und habe 2 mögliche Lösungswege aufgezeigt.
Einer der beiden Lösungswege wird durch die asyncrone Implementierung von Norbert beschritten. Schon alleine damit wäre nach Popper, den übrigens Du ins Spiel gebracht hast, durch Falsifikation dargelegt, dass es diesen Designfehler gibt, denn sonst wäre es nicht nötig, Dein OWX-Modul umzubauen.
Der andere Lösungsweg wird von Dir mit:

Zweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen

abgelehnt. Gerade als Wissenschaftler sollte Dir bewusst sein, dass diese Aussage so nicht haltbar ist.
Dass die Umsetzung nicht trivial ist, ist mir durchaus bewusst,da hier diverse Parameter zusammenspielen müssen, und man auf die Besonderheiten eines Singlethreadet Programms Rücksicht nehmen muss. Aber es ist nicht nur möglich, sondern, wenn es richtig programmiert ist, sogar machbar, die Conversions Pause dafür zu nutzen, weitere Sonsoren anzusprechen. Vorraussetzung dafür ist, dass folgende Sequenzen:

Code Auswählen Erweitern


17:59:09.227 3: OWX: Sending out        0xe3 0xc5
17:59:09.289 3: OWX: Receiving in loop no. 1 0xdd
17:59:09.302 3: OWX: Sending out        0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
17:59:09.375 3: OWX_Complex_SER: Receiving   0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44

hier wären mindestens 800 ms Zeit, in denen man einen weiteren Sensor abfragen könnte oder z.B. eine weitere Conversion starten könnte.

Code Auswählen Erweitern


17:59:10.178 3: OWX: Sending out        0xe3 0xc5
17:59:10.240 3: OWX: Receiving in loop no. 1 0xdd
17:59:10.253 3: OWX: Sending out        0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
17:59:10.326 3: OWX_Complex_SER: Receiving   0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49

nicht durch andere Sequenzen unterbrochen werden.
Sowohl nach dem Senden von 0xe3 0xc5 als auch nach dem Senden von 0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff und anderen
kann der Ablauf wieder an die FHEM-Hauptschleife abgegeben werden, da DevIO selbsttätig die Empfangenen Daten an OWX liefert, wenn in OWX_Initialze ein $hash->{ReadFn} definiert ist. In OWX muss das ganze dann nur noch aufbereitet, auf Plausiblität überprüft und an den richigen Empfänger weitergeleitet werden.
Selbst, wenn man nur die 800 ms Pause entfernen würde, wären dass statt 98,09 % nur noch 25,43 % "sleep-Zeit" also eine signifikante Verbesserung.
Ich weiß, dass ich den Beweis nur dann endgültig ( und nach Popper nicht mal dass) erbringen kann, wenn ich Dir ein Modul schreibe, dass genau das leistet. Aber dazu fehlen mir z.Z. noch die Perl Kenntnisse, außerdem würde ich Dich dann komplett demontieren, was ich nicht wirklich möchte.
Es würde mir volkommen reichen, wenn Du über Deinen Schatten springst, und einräumst, dass hier ein Designproblem (nicht Fehler) vorhanden ist, welches Du so heute nicht mehr machen würdest.
Ich appelliere hier mal an Deine Berufsehre als Naturwissenschaftler, denn wir wissen alle, die Erde ist keine Scheibe, oder in anderen Worten:  ,,Eppur si muove"

Gruß Joachim

@ Norbert,
habe mir Deine asyncrone Variante schon mal kurz angesehen, sieht gut aus. Wenn ich dann wieder mehr Zeit habe, teste ich nocheinmal ausführlicher.
Ich glaube auch nicht, dass wir, pah und ich, aneinander vorbeireden, es will nur keiner nachgeben

@ dan1180,
sorry, dass wir Deinen Tread gekapert haben, aber ich befürchte, dass wird hier noch etwas dauern, von daher für Dich der Anhang.

[Prof. Dr. Peter Henning]

@Joachim: Drei Vorschläge.

Fangen wir doch mal hinten an: Bitte, gerne, schreibe ein Frontendmodul, das alles besser macht. Da ich weder mein Selbstbewusstsein, noch meine Identität aus ein paar FHEM-Modulen ziehe, "demontiert" mich das sicher nicht. Das kann auch nicht an Perl-Kenntnissen liegen - wenn man eine Programmiersprache kann, geht das auch mit anderen innerhalb kürzester Zeit - also, nur zu ! Und bitte sieh dies nicht als Sarkasmus, sondern als ernsthafte Ermunterung. Erster Vorschlag also: "Designe" selbst, und lass die offensive Sprechweise vom "Demontieren" sein.

Zweitens: OWX ist das Backendmodul, das kennt, wenn man nicht gerade den etwas kryptischen DoKick-Mechanismus verwendet, gar keine Warteschleifen (die übrigens alle nicht mit sleep, sondern mit select realisiert sind).  Du kannst dich also höchstens auf eines der Frontendmodule beziehen - z.B. OWTHERM. Dieses Modul hat keinen "Designfehler", Punkt. Dass darin eine Verzögerung auftritt, wenn man einen Sensor direkt abfragt, war 2011 vollständig gewollt. Will man diese herausnehmen, muss aber eine komplette Warteschlange für den 1-Wire-Bus geschrieben werden, da eine vollständig asynchrone Behandlung sonst zur Kollision mit anderen Busbefehlen führen würde. Das genau ist, was Norbert Truchsess gerade gemacht hat.
Es ist unbenommen, dass die Vielzahl von neuen Modulen und gestiegene Anforderungen an FHEM die asynchrone Verarbeitung sinnvoll machen. Das macht die alten Versionen aber nicht "fehlerhaft". Ein kurzer Check zeigt vielmehr, dass "select"-Befehle noch in einer Vielzahl von Modulen auftauchen, die auch breite Verwendung finden - und die sind sicher auch nicht "fehlerhaft". Zweiter Vorschlag also:  lass einfach die offensive und herabsetzende Wortwahl vom "Designfehler" weg. Von mir aus sprich von "veraltet" - damit kann jeder gut leben.

Schließlich: Ich freue mich ehrllich, wenn jemand innerhalb von zwei Tagen von "Popper - wer ist das ?" dazu übergeht, Popper zu zitieren. Allerdings glaube ich, dass da noch ein paar Missverständnisse vorliegen - nicht zwischen uns beiden, sondern zwischen Deinem Verständnis von Popper und dem, was die akademische Welt darüber denkt. Ich halte allerdings einerseits dieses Forum nicht für den geeigneten Platz für eine Diskussion über Wissenschaftstheorie. Und andererseits: Hätte ich selbst gerade mal ein Werk dazu gelesen, würde ich in eine solche Diskussion nicht einsteigen.

LG

pah

[ntruchsess]

keine Warteschleifen (die übrigens alle nicht mit sleep, sondern mit select realisiert sind).

Nur mal ne kurze Anmerkung für alle Mitleser: der Unterschied zwischen einem sleep(x) und einem select(undef,undef,undef,xxx) ist die zeitliche Auflösung. Beide halten den aktuellen Thread einfach an.

[Joachim]

Moin pah,
wir nähern uns an, das finde ich gut. Ich möcht hier dann auch nocheinmal betonen, dass ich weder Dich persönlich angreifen wollte, noch Dein Modul schlecht machen will.
Dein Modul läuft bei mir seit über einem Jahr, allerdings mt der Einschränkung, dass es Probleme gibt, wenn andere Module im Spiel sind, die zeitkritisch sind. Deshalb ist z.B. das Modul cloneDummy entstanden, und OWX in einer seperaten Instanz laufen zu lassen, dort macht es fast nichts aus, dass FHEM regelmäßig schläft, es sei denn, dass genau zu diesem Zeitpunkt FHEM2FHEM über telnet Daten abgreifen will, da findet dann auch wider eine Verzögerung eines eigentliche unbeteiligten FHEM durch den Designfehler in de OW-Modulen statt.
Jetzt zu Deinem letzten Post:

Zweiter Vorschlag also:  lass einfach die offensive und herabsetzende Wortwahl vom "Designfehler" weg.

Ich habe ganz bewußt den Begriff "Designfehler", und nicht Fehler (Bug) verwendet. Denn Dein Programm ansich ist nicht fehlerhaft!
Ich sehe in der Wortwahl "Designfehler" auch keine offensive oder herabsetzende Wortwahl. Sollte das bei Dir so angekommen sein, entschuldige ich mich dafür.
Für mich ist ein "Designfehler" ein Fehler im Grundkonzept der Software (Deines Moduls), der unter bestimmten Bedingungen Nebenwirkungen zeigt, die so nicht gewünscht sind, oder die zum Zeitpunkt der Erstellung des Moduls so nicht absehbar waren, und zu einem späteren Zeitpunkt nur sehr aufwendig zu ändern sind.
Hier stimmst Du mir ja auch zu:

Dass darin eine Verzögerung auftritt, wenn man einen Sensor direkt abfragt, war 2011 vollständig gewollt.

Daran war 2011 auch nichts auszusetzen, da es hier diese Probleme noch nicht gab. Mittlerweile sind wir im Jahr 2014 und es gibt viele neue Module, die auf ein einigemaßen genaues Timing angewiesen sind, oder die in festgelegten Abständen gestrichelt werden wollen. Und jetzt zeigt sich, das das Design, das Du 2011 gewählt hast, mit diesen Anfordungen nicht mehr mithalten kann, und das ist, ohne Deine Module abwerten zu wollen, ein Fehler im Design, der sich jetzt in schwer nachvollziehbaren Problen zeigt. Deshalb ist z.B. dieser Tread von dan1180 überhaupt erst entstanden, und vorher in einem ganz anderen Forum diskutiert worden:
http://forum.fhem.de/index.php/topic,22223.0.html Antwort 34 von Martin876
und es hat sehr lange gedauert, bis der Verursacher OWX ausgemacht wurde.
Ein Blick in den Quellcode Deines Moduls zeigt dann auch, wodurch das Problem ausgelöst wird.
Hier verweise ich dann auch nochmal auf die von mir in diesem Tread desöfteren gemachten Aussagen und Versuche.
Exemplarisch an der Kombination OWTHERM in Verbindung mit OWX und einer einfachen Temperaturabfrage eines DS18B20 sieht man, dass von 100 % Rechenzeit gerade mal 2 % verwendet werden, und 98 % verwendet werden, um FHEM anzuhalten (select(undef,undef,undef,xxx), ich gebe zu, dass ich heute morgen aus Faulheit "sleep-Zeit" geschrieben habe, das war sicherlich wissenschaftlich nicht korrekt, aber deshalb auch bewußt in "".
Für mich ist allerdings Deine Behauptung:

Zweitens: OWX ist das Backendmodul, das kennt, wenn man nicht gerade den etwas kryptischen DoKick-Mechanismus verwendet, gar keine Warteschleifen (die übrigens alle nicht mit sleep, sondern mit select realisiert sind).

nicht nachvollziebar, wie einfach am Quellcode zu zeigen ist:

Code Auswählen Erweitern

sub OWX_Query_2480 ($$$) {

  my ($hash,$cmd,$retlen) = @_;
  my ($i,$j,$k,$l,$m,$n);
  my $string_in = "";
  my $string_part;
 
  #-- get hardware device
  my $owx_hwdevice = $hash->{HWDEVICE};
 
  $owx_hwdevice->baudrate($owx_baud);
  $owx_hwdevice->write_settings;

  if( $owx_debug > 2){
    my $res = "OWX: Sending out        ";
    for($i=0;$i<length($cmd);$i++){ 
      $j=int(ord(substr($cmd,$i,1))/16);
      $k=ord(substr($cmd,$i,1))%16;
  $res.=sprintf "0x%1x%1x ",$j,$k;
    }
    Log 3, $res;
  }
 
  my $count_out = $owx_hwdevice->write($cmd);
 
  if( !($count_out)){
    Log 3,"OWX_Query_2480: No return value after writing" if( $owx_debug > 0);
  } else {
    Log 3, "OWX_Query_2480: Write incomplete $count_out ne ".(length($cmd))."" if ( ($count_out != length($cmd)) & ($owx_debug > 0));
  }
  #-- sleeping for some time <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  select(undef,undef,undef,0.04);<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

  #-- read the data - looping for slow devices suggested by Joachim Herold
  $n=0;                                               
  for($l=0;$l<$retlen;$l+=$m) {                           
    my ($count_in, $string_part) = $owx_hwdevice->read(48); 
    $string_in .= $string_part;                           
    $m = $count_in;
  $n++;
if( $owx_debug > 2){
  Log 3, "Schleifendurchlauf $n";
  }
if ($n > 100) {                                       
  $m = $retlen;                                         
}
select(undef,undef,undef,0.02);<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    if( $owx_debug > 2){
      my $res = "OWX: Receiving in loop no. $n ";
      for($i=0;$i<$count_in;$i++){
    $j=int(ord(substr($string_part,$i,1))/16);
        $k=ord(substr($string_part,$i,1))%16;
        $res.=sprintf "0x%1x%1x ",$j,$k;
  }
      Log 3, $res
        if( $count_in > 0);
}
  }

  #-- sleeping for some time<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  select(undef,undef,undef,0.01);<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  return($string_in);
}
Ich hoffe, Du hast Verständniss dafür, dass ich mich hier, vorsichtig gesagt, auf den Arm genommen fühle, denn das sind eindeutig Warteschleifen!
Die Du allerdings 2011 so für nötig erachtet hast, und die 2011 keine Probleme verurscht haben.
Deine Behauptung:

Dieses Modul hat keinen "Designfehler", Punkt. Dass darin eine Verzögerung auftritt, wenn man einen Sensor direkt abfragt, war 2011 vollständig gewollt.

ist leider ein Widerspruch in sich. Es war vom Design her 2011 von Dir so gewollt, Du hast Dich also 2011 ganz bewußt für diesen Weg entschieden, der sich jetzt, 2014, als "ungeschickt" herausstellt. Man könnte auch sagen, im nachhinein betrachtet war es ein Designfehler, den Du heute so nicht mehr machen würdest.
Zu Deinem Vorschlag:

Fangen wir doch mal hinten an: Bitte, gerne, schreibe ein Frontendmodul, das alles besser macht. Da ich weder mein Selbstbewusstsein, noch meine Identität aus ein paar FHEM-Modulen ziehe, "demontiert" mich das sicher nicht. Das kann auch nicht an Perl-Kenntnissen liegen - wenn man eine Programmiersprache kann, geht das auch mit anderen innerhalb kürzester Zeit - also, nur zu ! Und bitte sieh dies nicht als Sarkasmus, sondern als ernsthafte Ermunterung. Erster Vorschlag also: "Designe" selbst, und lass die offensive Sprechweise vom "Demontieren" sein.

Meine Programmierkenntnisse stammen aus dem Jahr 1984, Informatikgrundkurs in der Schule auf Apple 2 mit Basic, ich habe weder einen akademischen Abschluss, noch eine Ausbildung im Bereich Elektrotechnik, Elektronik, Informatik o.ä., sondern arbeite im Gesundheitswesen. Damit behaupte ich, das meine Programmierkenntnisse gen 0 tendieren.
Gerne würde ich ein entsprechendes Modul schreiben, wenn ich es dann könnte, und ich verstehe das auch nicht als Sarkasmus, denn ich weiß, das schöne an open source ist, dass man Dinge, die einem nicht gefallen verändern kann.

Ansonsten, Danke für die Blumen:

Schließlich: Ich freue mich ehrllich, wenn jemand innerhalb von zwei Tagen von "Popper - wer ist das ?" dazu übergeht, Popper zu zitieren.

Und andererseits: Hätte ich selbst gerade mal ein Werk dazu gelesen, würde ich in eine solche Diskussion nicht einsteigen.

Gruß Joachim

PS.:Dieses select (Zeile 1541ff) ist übrigens vollkommen unnötig, da zu diesem Zeitpunkt schon alle Daten vom DS2480 angekommen sind:

Code Auswählen Erweitern


  #-- sleeping for some time
  select(undef,undef,undef,0.01);
  return($string_in);
}

[ntruchsess]

weil es hier so gut passt, Someone is wrong on the internet 

[Joachim]

Moin Norbert,
mein Englisch ist leider grottenschlecht, von daher weiß ich nicht, ob ich das jetzt richtig verstanden habe.
Meinst Du, dass ich zu grob mit pah umgehe?

Gruß Joachim

[ntruchsess]

nein, eigentlich wollte ich nur das Bild verlinken, der Text passt nicht. Hab grade das Original wiedergefunden (und meinen Post korrigiert)....
Einfach mal einen Schritt zurücktreten und sich vom 'SIWOTI syndrome' befreien...
(Und auch diesen Post nicht zu ernst nehmen).

Gruß,

Norbert

[Joachim]

Norbert,
ich fühle mich wie Rudi Carrell, der hat allergings deutsche Wortspiele nicht verstanden.