Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

[noansi]

Hallo Eckart,

Anscheinend senden mehrerer IT Geräte in der Umgebung.

Eher weniger IT Geräte, aber Du zeichnest so eben auch Rauschen auf.

Ich habe jetzt im log so viele Einträge dass ich sie nicht mehr Eindeutig meinem Handsender zuordnen kann. Gibt es da eine Möglichkeit?

Nun, Deine Uhr sekundengenau mit der Uhr Deines FHEM Servers synchronisieren und auf die Uhr schauen, wann Du den Taster an dem Handsender drückst, Zeit merken/notieren und mit der Zeit im Log vergleichen. Mehrfach wiederholen mit gleicher Taste und dann siehst Du ähnliche Blöcke.
Methode des mühsamen Hinschauens.

Kann man die Frequenz beim Somfy Device zuordnen?

Was meinst Du damit?
Beim Empfang gar nicht.

Gibt es eine Möglichkeit auch das Senden bei Somfy zu optimieren?

Die Sendefrequenz ist im CUL vorgegeben und wird so genau gesendet, wie der CUL Toleranzen hat.
Bei der tsculfw habe ich noch die Möglichkeit eingebaut, mit YoXX (XX = hex Frequenzoffset, vgl. cc1101 Doku) das Frequenzoffsetbyte zu ändern und somit kann man die Sendefrequenz in Grenzen anpassen. Das SOMFY Modul müsste darauf angepasst werden.
Das Optimum zu finden wäre dann Probieren. Messmittel vorraus gesetzt, wäre zumindest ein Angleich auf die Handsenderfrequenz schneller möglich.

Ich habe jetzt mal den CCA Mode 3 verwendet

Mehr als CCA Mode 1 macht bei Somfy keinen Sinn, weil die paket handling Funktionen des cc1101 dabei nicht zum Zuge kommen.
Damit (CCA Mode 1) schaut dann der CUL vor dem Senden, ob ein Trägersignal empfangen wird und wartet dann ggf., bis der Kanal frei ist.
csRelThr und csAbsThr bestimmen die Limits für die Signalerkennung. Wird der Kanal innerhalb von 2s nicht frei erkannt, wird gar nicht gesendet, sondern eine NOCCA Fehlermedung vom CUL zurück gegeben.
CCA Mode 0 sendet sofort ohne Prüfung.

Gruß, Ansgar.

[exocet01]

Hallo Ansgar,

OK, dann gehe ich mal den mühsamen Weg die IT clock zu bestimmen 

Mit dem Zuordnen einer Frequenz zu einem Device Typ meine ich, ob man die Sendefrequenz abhängig vom Gerät ändern kann. Dies habe ich bei den IT Geräten gesehen, bei denen die Frequenz mit dem Parameter ITfrequency zuordnen kann.
Da ich an dem gleichen CUL 2 Gerätearten habe (Somfy mit 433,42 MHz und IT mit 433,92) MHz, hatte ich mir eine automatische Umschaltung vorgestellt.
Wenn ich den Offset am CUL ändere, dann beeinflusst das ja wahrscheinlich auch wieder die IT Steckdose.

Den CCA Mode habe ich mal auf 0 gesetzt. Bei CCA Mode 1 und der Meldung NOCCA wird nicht versucht den Befehl erneut zu senden, oder?

Viele Grüße,
Eckart

[noansi]

Hallo Eckart,

Mit dem Zuordnen einer Frequenz zu einem Device Typ meine ich, ob man die Sendefrequenz abhängig vom Gerät ändern kann.

Bis jetzt nicht, mit dem angehängten Modul und tsculfw 0.40 schon. Mit Attribut SOMFYfreqOffs in kHz (Offset Bereich +/-202kHz) kann man damit die vorgegebene 433.42MHz Sendefrequenz per SOMFY device etwas fein tunen, wie bei IT mit ITfreqOffs.

Da ich an dem gleichen CUL 2 Gerätearten habe (Somfy mit 433,42 MHz und IT mit 433,92) MHz, hatte ich mir eine automatische Umschaltung vorgestellt.
Wenn ich den Offset am CUL ändere, dann beeinflusst das ja wahrscheinlich auch wieder die IT Steckdose.

Nein, bei IT wird ein andere Frequenzeinstellung und Offset verwendet.

Den CCA Mode habe ich mal auf 0 gesetzt. Bei CCA Mode 1 und der Meldung NOCCA wird nicht versucht den Befehl erneut zu senden, oder?

Korrekt.

Gruß, Ansgar.

[noansi]

tsculfw 0.39 Teil1

[noansi]

tsculfw 0.39 Teil2
Sorry aber Forum Limits erzwingen die Aufteilung.
perl module sind hier im Anhang: https://forum.fhem.de/index.php?msg=1167796

[exocet01]

Mit dem Zuordnen einer Frequenz zu einem Device Typ meine ich, ob man die Sendefrequenz abhängig vom Gerät ändern kann.
Bis jetzt nicht, mit dem angehängten Modul und tsculfw 0.40 schon. Mit Attribut SOMFYfreqOffs in kHz (Offset Bereich +/-202kHz) kann man damit die vorgegebene 433.42MHz Sendefrequenz per SOMFY device etwas fein tunen, wie bei IT mit ITfreqOffs.

Vielen Dank!
So komme ich ja zumindestens mal fast an die 433.42 MHz ran. Vielleicht reicht das ja schon

[noansi]

Hallo Eckart,

So komme ich ja zumindestens mal fast an die 433.42 MHz ran. Vielleicht reicht das ja schon

Möglicherweise hast Du mich nicht richtig verstanden.
Für Somfy wird in der Firmware 433.42 MHz Sendefrequent verwendet. Mit dem Offset kannst Du einen Frequenzfehler des Sendemoduls korrigieren.
Ohne Messmöglichkeit der Sendefrequenz allerdings nur ein Stochern im Nebel.

Gruß, Ansgar

[exocet01]

Hallo Ansgar,

OK, verstehe. Das habe ich wirklich falsch verstanden. Ich muss mal schauen ob ich so ein Messmittel irgendwo auftreiben kann.
Da ich einen Handsender von SOMFY habe: Ist es ggf. möglich mit dem CUL die Frequenz dieses Senders zu prüfen und dann so einen Offset zu ermitteln?

Viele Grüße,
Eckart

[noansi]

Hallo Eckart,

Da ich einen Handsender von SOMFY habe: Ist es ggf. möglich mit dem CUL die Frequenz dieses Senders zu prüfen und dann so einen Offset zu ermitteln?

Nicht wirklich gut, da keine direkte Frequenzinfo ausgegeben wird.
Also nur mit SlowRf Empfangsfrequenz auf 433.42MHz einstellen, Offset variieren und den Offset mit bestem RSSI zum Senden verwenden. Die Fehlereinflüsse sind aber groß: Abstand Handsender zu CUL, Deine eigene Position beim Senden mit Handsender oder auch anderer Personen, andere gleichzeitig empfangene Signale und und und.

Mit z.B. HDSDR und einem passenden DVBT-Stick mit RTL2832 Chip kannst Du den interessanten Frequenzbereich visualisieren.
Damit dann Handsender- und CUL-Sendesignale vergleichen und CUL auf gleiche Sendefrequenz mit Offset korrigieren.

Das bedeutet jedoch noch nicht zwingend, dass Du damit auch das Optimium des/der Empfänger triffst, da auch die Toleranzen unterliegen dürften.

Bei IT macht der Zustand der Handsenderbatterie einen deutlichen Frequenzeinfluss, daher der Hinweis zu frischen Batterien, falls dies auch auf Somfy Handsender zutrifft.

Gruß, Ansgar.

[Ralf9]

Hallo,

ich bin gerade dabei meine alternative Version des "00_SIGNALduino.pm" Moduls in "SIGNALduinoAdv.pm" umzubenennen.
Dadurch passt u.a. im 10_IT.pm Modul bei set die folgende Abfrage nicht mehr:

Code Auswählen Erweitern

if ($io->{TYPE} ne "SIGNALduino") {eine Möglichkeit wäre

Code Auswählen Erweitern

if ($io->{TYPE} !~ m/^SIGNALduino/) {
Ich habe gesehen, daß es für TSCUL ein angepasstes IT Modul gibt.
Wird auch das IT Modul vom fhem update für TSCUL verwendet?
Falls für TSCUL nur das angepasstes IT Modul verwendet wird, kann ich die Abfrage im IT Modul wie folgt ändern:

Code Auswählen Erweitern

if ($io->{TYPE} eq "CUL") {Bei Bedarf kann ich noch folgendes einfügen und dann eine log Ausgabe und Rückmeldung machen, daß für TSCUL nicht die passende Version des IT MODUL verwendet wird

Code Auswählen Erweitern

elsif ($io->{TYPE} eq "TSCUL") {
Gruß Ralf

[noansi]

Hallo Ralf,

verdammt lang her... aber danke der Nachfrage!

Wird auch das IT Modul vom fhem update für TSCUL verwendet?

Zunächst nein, ich hatte extra eine angepasste Version unter meine Module gepackt.

Auf die Schnelle und ohne Anspruch auf Vollständigkeit mal wesentliche Änderungen. Vielleicht möchtest Du auch mehr übernehmen. 

Folgende Attributsfunktionalität kann bei Set ganz nützlich sein

Code Auswählen Erweitern

# erstes aktives IODev ermitteln
  my @ionames = split(/,/, AttrVal($name, 'IODevList', ''));
  my $ioh;
  foreach my $ioname (@ionames) {
    $ioh = $defs{$ioname};
    if (   defined($ioh)
        && DevIoTS_getState($ioh) ne 'disconnected'
        && !IsDummy($ioname)) {
      AssignIoPort($hash, $ioname) if (   !defined($hash->{IODev})
                                       || ($hash->{IODev}->{NAME} ne $ioname));
      last if (defined($hash->{IODev}));
    }
  }

  my $io = $hash->{IODev};
  return 'no IODev available, adapt attribute IODevList' if (!defined($io));

Statt DevIoTS_getState geht auch DevIo_getState.

Attribute zur Ergänzung:

Code Auswählen Erweitern

  $hash->{AttrList}  = 'IODevList dummy:1,0 '.
                       'ITfrequency '.
                       'ITfreqOffs '.
                       'ITrepetition '.
                       'ITclock '.
                       'protocol:V1,V3,HE_EU,SBC_FreeTec,HE800 '.
                       'userV1setCodes '.
                       'switch_rfmode:1,0 '.
                       'do_not_notify:1,0 '.
                       'ignore:0,1 '.
                       'SIGNALduinoProtocolId '.
                       'unit '.
                       'group '.
                       'model:'.join(',', sort keys %models).' '.
                       $readingFnAttributes;


Code Auswählen Erweitern

    <a id="IT-attr-IODevList"></a>
    <li>IODevList<br>
        Sets a ',' seperated list of usable IOs or physical devices
        which should be used for sending signals for this "logical" device.
        The first active from the list is used. An example for the physical device is a CUL.<br>
        Note: On startup, fhem DOES NOT assign an InterTechno device to an
        IO-Device! The attribute IODevList needs to be used ALWAYS!</li><br>



Code Auswählen Erweitern

    <a id="IT-attr-IODevList"></a>
    <li>IODevList<br>
        Spezifiziert eine ',' sparierte Liste von physischen Ger&auml;ten, die die Ausstrahlung der Befehle f&uuml;r das
        "logische" Ger&auml;t ausf&uuml;hren. Das erste aktive aus der Liste wird genutzt.
        Ein Beispiel f&uuml;r ein physisches Ger&auml;t ist ein CUL.<br>
        Anmerkung: Beim Start weist fhem einem InterTechno-Ger&auml;t kein IO-Ger&auml;t zu.
        Das Attribut IODevList ist IMMER zu setzen.</li><br>


tscul unterstützt auch ITfreqOffs in kHz, also einen Offset zur Sendefrequenz entsprechend dem cc1101 Offset Register.
Vor dem Senden sieht es bei mir so aus:

Code Auswählen Erweitern

    ## Do we need to change RFMode to SlowRF??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      $oldIOMode = $attr{$io->{NAME}}{rfmode} ? $attr{$io->{NAME}}{rfmode} : 'SlowRF';
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', 'SlowRF'));
    }

    ## Do we need to change ITClock ??
    if (defined($sndmsg = AttrVal($name, 'ITclock', undef))) {
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'ITClock', $sndmsg));
#      Log3 $name, 1, "IT set ITclock: $sndmsg for $io->{NAME}";
    }

    ## Do we need to change ITrepetition ??
    if (   ($sndmsg = AttrVal($name, 'ITrepetition', 0))
        || $dimrep) {
      my $itrep = $dimrep ? $dimrep+3 : $sndmsg;
      $itrep = 144 if ($itrep > 144); # tsculfw sends ITrepetition+1 times, 8-bit value, 144 max.
      $sndmsg = "isr$itrep";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', $sndmsg)); # if not set before send the tsculfw default is 3 and reverts to it after send
#      Log3 $name,1, "IT set ITrepetition: $sndmsg for $io->{NAME}";
    }

    ## Do we need to change ITfrequency ??
    if (defined($sndmsg = AttrVal($name, 'ITfrequency', undef))) {
      my $f = int($sndmsg*65536/26+0.5);
      my $f2 = sprintf('%02x', int($f / 65536));
      my $f1 = sprintf('%02x', int(($f % 65536) / 256));
      my $f0 = sprintf('%02x', $f % 256);

      #my $arg = sprintf('%.3f', (hex($f2)*65536+hex($f1)*256+hex($f0))*26/65536*26);
      #Log3 $name, 3, "Setting ITfrequency (0D,0E,0F) to 0x$f2 0x$f1 0x$f0 = $arg MHz";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "if$f2$f1$f0"));
    }

    ## Do we need to change ITfreqOffs ??
    if (defined($sndmsg = AttrVal($name, 'ITfreqOffs', undef))) {
      my $o = int(($sndmsg * (1 << 14) / 26000) + (($sndmsg >= 0)?0.5:-0.5));
      $o += 256 if ($o < 0);
      $o = 0   if ($o < 0);
      $o = 255 if ($o > 255);
      $o = sprintf('%02x', $o);

#      my $arg = hex($o);
#      $arg -= 256 if ($arg >= 128);
#      $arg *= 26000 / (1 << 14);
 #     Log3 $name, 1, "Setting ITfreqOffs (0C) to 0x$o = $arg kHz";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "io$o"));
    }
  }

nach dem Senden schrumpft es zusammen zu:

Code Auswählen Erweitern

    # das IODev ist kein SIGNALduino
    ## Send Message to IODev
    CallFn($io->{NAME}, 'SetFn', $io, (' ', 'raw', $sndmsg));  # tsculfw VTS0.32+ resets frequency, offset, ITrepetition and ITclock back to firmware default values after send

    ## Do we need to change RFMode back to HomeMatic??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', $oldIOMode));
    }
Die Rückmeldung wird nicht ausgewertet.

Dein Vorschlag zu einem Hinweis auf falsches Modul ist natürlich auch schon hilfreich. 

Viele Grüße, Ansgar.

[Ralf9]

Ich habe beim Senden anpassungen für TSCUL eingebaut
https://github.com/Ralf9/10_IT/commit/e1220e96139dc90e05d08b6643a13289ee5ba6a3
https://github.com/Ralf9/10_IT/blob/master/FHEM/10_IT.pm
bitte mal drüber schauen und testen ob damit das IT Modul auch mit dem TSCUL verwendet werden kann.

tscul unterstützt auch ITfreqOffs in kHz, also einen Offset zur Sendefrequenz entsprechend dem cc1101 Offset Register.

Code Auswählen Erweitern

Log3 $name, 1, "Setting ITfreqOffs (0C) to 0x$o = $arg kHz";
CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "io$o"));

Wird der raw Befehl "io" auch von der a-culw und culw Firmware unterstützt?

Gruß Ralf

[noansi]

Hallo Ralf,

Wird der raw Befehl "io" auch von der a-culw und culw Firmware unterstützt?

Nicht, dass es mir bekannt wäre.

bitte mal drüber schauen ob damit das IT Modul auch mit dem TSCUL verwendet werden kann.

Code Auswählen Erweitern

    return 'IODev does not support IT' if (defined($io->{CMDS}) && $io->{CMDS} !~ m/i/); #CUL muss das i Kommando kennen
war korrekter, da sowohl bei CUL (culfw und a-culfw), als auch bei TSCUL das 'i' Kommando optional zu compilieren ist.

Code Auswählen Erweitern

return 'IODev does not support IT' if ($io->{TYPE} !~ m/^(?:TS)?CUL$/ || (defined($io->{CMDS}) && $io->{CMDS} !~ m/i/)); # TSCUL/CUL wird unterstützt und muss das i Kommando kennenwürde es wohl besser treffen?

Für ITrepetition gibt es bei tsculfw eine Einschränkung bei der Anzahl und es gibt kein feedback, also nur set statt get (hier hakt es dann mangels feedback):

Code Auswählen Erweitern

    ## Do we need to change ITrepetition ??
    if (   ($message = AttrVal($name, 'ITrepetition', 0))
        || $dimrep) {
      my $itrep = $dimrep ? $dimrep+3 : $message;
      $itrep = 144 if ($itrep > 144); # tsculfw sends ITrepetition+1 times, 8-bit value, 144 max.
      $message = "isr$itrep";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', $message)); # if not set before send the tsculfw default is 3 and reverts to it after send
#      Log3 $name,1, "IT set ITrepetition: $message for $io->{NAME}";
    }Einen Wert > 144 bis 255 kannst Du aber setzen, jedoch begrenzt die Firmware intern auf 144.

auch beim setzen der Frequenz gibt es kein feedback von der tsculfw, wozu auch? Also hakt es auch hier.

Code Auswählen Erweitern

    ## Do we need to change ITfrequency ??
    if (defined($sndmsg = AttrVal($name, 'ITfrequency', undef))) {
      my $f = int($sndmsg*65536/26+0.5);
      my $f2 = sprintf('%02x', int($f / 65536));
      my $f1 = sprintf('%02x', int(($f % 65536) / 256));
      my $f0 = sprintf('%02x', $f % 256);

      #my $arg = sprintf('%.3f', (hex($f2)*65536+hex($f1)*256+hex($f0))*26/65536*26);
      #Log3 $name, 3, "Setting ITfrequency (0D,0E,0F) to 0x$f2 0x$f1 0x$f0 = $arg MHz";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "if$f2$f1$f0"));
    }

rfMode setzen habe ich allgemeiner gehalten, da es nicht nur homematic als mode gibt:

Code Auswählen Erweitern

  my $oldIOMode;...

Code Auswählen Erweitern

    ## Do we need to change RFMode to SlowRF??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      $oldIOMode = $attr{$io->{NAME}}{rfmode} ? $attr{$io->{NAME}}{rfmode} : 'SlowRF';
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', 'SlowRF'));
    }...

Code Auswählen Erweitern

    ## Do we need to change RFMode back to HomeMatic??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', $oldIOMode));
    }
ist das Ergebnis des "Trockenlaufs", also Code anschauen.

Gruß, Ansgar.

[Ralf9]

Einen Wert > 144 bis 255 kannst Du aber setzen, jedoch begrenzt die Firmware intern auf 144.

So hohe Werte machen aber sowiso keinen Sinn

Für ITrepetition ... und es gibt kein feedback, also nur set statt get (hier hakt es dann mangels feedback):
auch beim setzen der Frequenz gibt es kein feedback von der tsculfw, wozu auch? Also hakt es auch hier.

Dann muß ich da wo es ein "CallFn($io->{NAME}, "GetFn"" gibt, eine Abfrage machen:

Code Auswählen Erweitern

if (Type gleich Cul) {
 CallFn($io->{NAME}, "GetFn"...
else
 CallFn($io->{NAME}, "SetFn"...

[noansi]

Hallo Ralf,

wenn ich es richtig gesehen und verstanden habe, dann hast Du HE800 und HE_EU zum Senden mit SIGNALduino ergänzt, richtig?

Ich habe mal meine Variante dahingehend angepasst und CUL als CUL behandelt, wie Du es machen willst inklusive SIGNALduinoadv Toleranz, siehe Anhang.

Code Auswählen Erweitern

So hohe Werte machen aber sowiso keinen SinnKommt drauf an. es gibt auch Dimmer, die während gedrückter Taste Dimmen. Wenn man damit spielen will, dann werden mehr Wiederholungen gebraucht. Automatisiert vernüftig dimmen läßt sich damit leider nicht wirklich, aber da kommt das 144er Limit bei mir her.

Gruß, Ansgar.