CUL speed change

[martinp876]

Hallo Rudi,

mit der Version 1.58 ist es möglich die Datenrate der CUL zu aendern - HM braucht so etwas zum FW update.
Die hohe Rate erhält man mit "AR", die niedrige mit "Ar".
Es wäre eine Methode notwendig, aus CUL_HM die Datenrate zu schalten. Insbesondere kritisch ist natürlich das 'A', was eine Interpretation der Message startet.
Ich habe eine Lösung, aber ich denke du willst eine eigene einbauen. Schön wäre etwas high-level. Nicht ganz einfach ist die Frage des Sequencing. CUL sollte das Umschalten nach der letzten message in der Queue machen, nicht vorher. Dennoch will man eine Rückmeldung, ob die CUL die das Kommando akzeptiert (also V1.57 eben nicht).
Eine entsprechende Methode werde ich dann auch in HMLAN einbauen
Gruss Martin

[rudolfkoenig]

Hallo Martin,

bau bitte du ein Patch, sonst musst du (zu) lange auf die Aenderung warten.

Gruss,
  Rudi

[martinp876]

hier ein Versuch.

Function "cmd" ist für Steuerung vorgesehen
Message für Steuerung sind
speed100
speed10
alles andere sendet den Init string.

Nicht eingebaut ist die Prüfung, ob speed100 unterstützt wird. Müsste man mit der Version abgleichen.

Gruss Martin

[betateilchen]

Ich stelle einfach mal die Diskussion in den Raum, ob die Unterstützung von Homematic durch den CUL auf lange Sicht überhaupt noch Sinn macht,
denn es treten ja doch auch noch einige Problemchen an anderen Stellen auf (z.B. wegen fehlender Timestamps zur Kontrolle des Timings in der gesamten Datenübertragung)

[justme1968]

dann muss ich aber anmerken das mein cul deutlich stabiler und mit sehr viel besserer reichweite arbeitet als mein hmlan.

ja ich weiß es gibt sich noch den config usb.

gruss
  andre

[betateilchen]

Dein CUL hat auch eine Antenne, der HMLAN nur ein Stück Draht. Wenn Du dem HMLAN eine ordentliche Antenne verpaßt, fällt der Unterschied in diesem Punkt weg (Das gilt übrigens auch für den HM-USB)

[martinp876]

a) aus der Applikation Einstellungen un der CUL ändern zu können ist erst einmal kein Fehler. Der Mechanismus ist unabhängig von HM. Der jetzige Einbau zur Geschwindigkeitsänderung ist speziell. ok
b) einen Timestamp in die CUL einzubauen sollte kein Problem sein. Prinzipiell ist es nur ein Zähler in msec der auch bei HMLAN ständig und erheblich driftet. Hat ein paar Kniffe gekostet, den Delay zu berechnen und würde hier ähnlich laufen. Immerhin soll es so etwas schon geben, leider nur im Monitoring Mode.

Es ist die Entscheidung eines Users, das IO zu wählen. Windows als server ist auch nicht verboten  -und das erzeugt mindestens so grosse Timing Schwankungen

Gruss Martin

[betateilchen]

Windows als server ist auch nicht verboten

schlimm genug. Bloß gut, dass Windows nicht auf Fritzbox funktioniert...

[martinp876]

Hallo Rudi,

zufrieden mit den Vorschlag?
Gruss Martin

[rudolfkoenig]

Hallo Martin,

hatte bisher keine Zeit dafuer. War beim Erstlesen des Patches ueberrascht, habe mich aber inzwischen dran gewoehnt

Ich hoffe dass du nur speed10 und speed100 verwendest, da der default Fall fuer die gestern eingebauten Stackable_CC Module von busware nicht funktionieren wird. Ursache: initString enthaelt bei Max&HM ein NL, und fuer SCC Module muss _jede_ Zeile mit einem oder mehreren * prefixed werden, deswegen gibt es seit gestern CUL_WriteInit().

Sonst finde ich es ok, und ich habe es eingecheckt. Kannst du bitte kurz feedback geben, ob es tut, da ich es nicht getestet habe.

Gruss,
  Rudi

[martinp876]

Hallo Rudi,

kein Problem, wollte nur wissen, wo wir stehen.

a) CUL_Parse($$$$;$)
führt zu problemen, zumindest bei meiner Perl-version.
Not enough arguments for main::CUL_Parse at ./FHEM/00_CUL.pm line 522, near "$mculdata)"
Not enough arguments for main::CUL_Parse at ./FHEM/00_CUL.pm line 758, near "$rmsg) "
vielleicht könntest du doch
CUL_Parse($$$$@)
nutzen?

b) CUL_AddSendQueue
funktioniert nicht komplett (mein Fehler) da das Schaltkommando keinem HM device zugeordnet ist, somit keine Q verwendet werden kann.

um das queuen in CUL_Write($$$) zu umgehen könnte man in CUL_WriteTranslate($$$)

Code Auswählen Erweitern

  } elsif($fn eq "cmd") {                                  # internal command
    $fn = "";
    if($msg eq "speed100") {
      $msg = "AR";
    } elsif($msg eq "speed10") {
      $msg = "Ar";
    } else {                                        # by default rewrite init
      $msg = $hash->{initString};
    }

Ändern in

Code Auswählen Erweitern

  } elsif($fn eq "cmd") {                                  # internal command
    if($msg eq "speed100") {
      $fn = "AR";
    } elsif($msg eq "speed10") {
      $fn = "Ar";
    } else {                                        # by default rewrite init
      $fn = $hash->{initString};
    }
  $msg = "";



Gruss Martin

[rudolfkoenig]

a) und b) Geaendert und eingecheckt.

[martinp876]

almost.

Code Auswählen Erweitern

  $msg = "";
muss auch mit.
Sieht seltsam aus, aber da hier 'in-message-decoding' betrieben wird mit schwer/nicht eindeutigen Kontrollbytes... sind die Maßnahmen auch etwas gebastelt?


Gruss Martin

[rudolfkoenig]

Eigecheckt.

[martinp876]

Hallo Rudi,

du hast $msg vor dessen Abfrage auf 'empty' gesetzt. Das darf erst nach der Abfrage passieren.
Sorry, dass ich es nicht gleich gesehen habe.

    $msg = "";
    if($msg eq "speed100") {
      $fn = "AR";
    } elsif($msg eq "speed10") {
      $fn = "Ar";
    } else {                                        # by default rewrite init
      $fn = $hash->{initString};
    }
    $msg = "";
danke
Martin