Signalduino Entwicklung

[Sidey]

Bezüglich senden muss das noch im 00_Signalduino.pm eingebaut werden, dass man auch Manchester Signale senden kann.

Dann kann man dann direkt den HEX Wert übergeben.
Wird spannend, wie das mit der Sync Phase ist. Habe gelesen, dass man die nicht braucht. Wenn das stimmt, vereinfacht das die Sache.

Grüße Sidey

[habeIchVergessen]

in somfy_rts.c

Code Auswählen Erweitern


static void somfy_rts_send(char *in) {
...
// send the whole frame several times
for(i = 0; i < somfy_rts_repetition; i++) {
send_somfy_rts_frame(airdata, (i == 0) ? 2 : 7); // send 2 hw Sync pulses at first, and 7 for repeated frames
}
...
}

static void send_somfy_rts_frame(somfy_rts_frame_t *frame, int8_t hwPulses) {
// send hardware sync (pulses of ca. double length)
for (int8_t i = 0; i < hwPulses; i++) {
CC1100_OUT_PORT |= _BV(CC1100_OUT_PIN); // High
my_delay_us(2550);
CC1100_OUT_PORT &= ~_BV(CC1100_OUT_PIN);// Low
my_delay_us(2550);
}
...
}


sieht für mich nach sync aus.
Vor der 1. Nachricht 2 und jeder weiteren 7 ("// send hardware sync (pulses of ca. double length)") was auch immer für Zeitscheiben. Auf alle Fälle eine logische 0 (nach Variante 2 aus WikiPedia).

@Ralf:
Kannst du bitte noch die geänderte Funktion einchecken? Habe die Prüfung der encrypteten Nachricht und Checksumme eingebaut, sowie den Vorspann "Ys".

Code Auswählen Erweitern


sub SIGNALduino_SomfyRTS()
{
my ($name, $bitData, $rawData) = @_;

my $negBits = $bitData =~ tr/10/01/r;
my $encData = SIGNALduino_b2h($negBits);

## no Somfy RTS message
return (-1, "not a valid Somfy RTS message!") if ($encData !~ m/A[0-9A-F]{13}/);

## decode message
my $decData = substr($encData, 0, 2);
for (my $idx=1; $idx < 7; $idx++)
{
my $high = substr($encData, $idx * 2, 2);
my $low = substr($encData, ($idx - 1) * 2, 2);

my $val = hex("0x" . $low) ^ hex("0x" . $high);
$decData .= sprintf("%02X", $val);
}

## checksum
my $checkSum = 0;
for (my $idx=0; $idx < 7; $idx++)
{
my $val = hex("0x" . substr($decData, $idx * 2, 2));
$val &= hex("0xF0") if ($idx == 1);
$checkSum = $checkSum ^ $val ^ ($val >> 4);
##Log3 $name, 4, "$name: Somfy RTS check: " . sprintf("%02X, %02X", $val, $checkSum);
}
return (-1, "not a valid Somfy RTS message (checksum error)!") if (($checkSum & hex("0x0F")) != hex("0x" . substr($decData, 3, 1)));

##Log3 $name, 4, "$name: Somfy RTS protocol \nraw: " . SIGNALduino_b2h($bitData) . "\nenc: $encData\ndec: $decData\ncheck: " . sprintf("%X", $checkSum & hex("0x0F")) . "\n";
return (1, "Ys" . $decData);
}


[Sidey]

Hi,

ich habe den somfy code aktualisiert, aber etwas angepasst.
Die Checksumme funktioniert bei mir nicht, ich habe es erst mal auskommentiert.

Bezüglich Senden ist es so, dass das somfy Modul folgenden Befehl sendet:

In SOMFY_SendCommand wird mittels IOWrite gesendet. Dabei wird folgendes übergeben:  sA3400003389A00
Das wird dann letztendlich raw an den SIGNALduino übermittelt. Der kann natürlich nichts damit anfangen.

Man könnte das Somfy Modul patchen und den Sendebefehl abändern, wenn ein SIGNALduino verwendet wird:

In etwa so:

Code Auswählen Erweitern


$message = 'P43#' . substr($message,1). '#R' . $SignalRepeats;
Log3 $io, 4, "SOMFY_sendCommand: $name -> message :$message: ";
IOWrite($hash, 'sendMsg', $message);


Dann bleibt aber immer noch das Thema mit dem encrypten. Das sehe ich eher im Logischen Modul und weniger im SIGNALduino. Das müsste dann noch eingebaut werden.

Grüße Sidey

[habeIchVergessen]

Soweit ich es verstanden habe, bildet SOMFY heute eine Fernbedienung ab und nicht das eigentliche Endgerät (Rollo/Markise).
Somit müsste SOMFY generell mehrere Fernbedienungen (CODES) verwalten können, um den echten Status des Endgeräts darstellen zu können.

Senden die Endgeräte auch Nachrichten (z.B. beim Anlernen)?

Bzgl. der aktuellen Implementierung in SOMFY könnte ich mir vorstellen, dass SendCommand in SOMFY prüft, ob es eine Funktion <Klasse IO-Device>_SendCommand_SomfyRTS im IODev gibt (habe thdankert involviert). Wenn ja, dann rufe diese auf. Wenn Nein dann benutze IOWrite wie bisher.
Natürlich muss der Frequenz-Toggle-Kram auch weggelassen werden.

[Jarnsen]

Soweit ich es verstanden habe, bildet SOMFY heute eine Fernbedienung ab und nicht das eigentliche Endgerät (Rollo/Markise).
Somit müsste SOMFY generell mehrere Fernbedienungen (CODES) verwalten können, um den echten Status des Endgeräts darstellen zu können.

Senden die Endgeräte auch Nachrichten

Das Modul bildet eine virtuelle Fernbedienung... Du kannst mehrere Fernbedienungen erstellen... Es ist quasi ne Software Fernbedienung... Das Problem bei SOMFY ist das es mit nem Rolingcode arbeitet der aufwärts zählt... Wenn du also die reale Fernbedienung und das Modul gleichzeitig nutzen willst wirst du zwei Fernbedienung am Rollo anlernen müssen... Da du das zählen der echten Fernbedienung nicht beeinflussen kannst... Anderer Seite muss das Modul mitbekommen wenn die echte Fernbedienung das Rollo ändert... Wie gesagt schau dir mal Dooya an und lies den Anhang... Für den Ablauf von nem Rollomodul her denke ich verständlich gehalten...


Hoffe konnte helfen...


Gruß Jarnsen

[Ralf9]

Bzgl. der aktuellen Implementierung in SOMFY könnte ich mir vorstellen, dass SendCommand in SOMFY prüft, ob es eine Funktion <Klasse IO-Device>_SendCommand_SomfyRTS im IODev gibt (habe thdankert involviert). Wenn ja, dann rufe diese auf. Wenn Nein dann benutze IOWrite wie bisher.
Natürlich muss der Frequenz-Toggle-Kram auch weggelassen werden.

Eine Unterscheidung ist auch über den $io->{TYPE} möglich:

Code Auswählen Erweitern


if ($io->{TYPE} ne "SIGNALduino") {
# das IODev ist kein SIGNALduino
Log3($name,5,"SOMFY_sendCommand: $name -> message :$message: ");
IOWrite( $hash, "Y", $message );
} else {  # SIGNALduino
my $SignalRepeats = AttrVal($name,'repetition', '6');
$message = 'P43#' . substr($message,1). '#R' . $SignalRepeats;
Log3 $hash, 4, "$io->{NAME} SOMFY_sendCommand: $name -> message :$message: ";
IOWrite($hash, 'sendMsg', $message);
}


Gruß Ralf

[Burny4600]

@Sidey

Anbei ein Log mit der aktuellen Firmware V 3.2.0-b23 SIGNALduino - compiled at May 8 2016 01:24:34.

Solltest du die Sensoren für Testzwecke dennoch benötigen kann ich sie dir für eine Weile borgen.

[habeIchVergessen]

Eine Unterscheidung ist auch über den $io->{TYPE} möglich:

Code Auswählen Erweitern


...
IOWrite($hash, 'sendMsg', $message);
}


Hier fehlt dann noch die Checksumme, das Encrypt und Negieren der Nachricht.
Ist IOWrite äquivalent zu set <SIGNALduino-Name> sendMsg? Wenn ja, dann könnte man über das Protokoll eine entsprechende Handler-Funktion aufrufen (ähnlich zum Empfangen) .

[Ralf9]

Hier fehlt dann noch die Checksumme, das Encrypt und Negieren der Nachricht.
Ist IOWrite äquivalent zu set <SIGNALduino-Name> sendMsg? Wenn ja, dann könnte man über das Protokoll eine entsprechende Handler-Funktion aufrufen (ähnlich zum Empfangen) .

Die Handler-Funktion könnte ab Zeile 1116 eingebaut werden:

Code Auswählen Erweitern


if ($protocol == 3) {
$data = SIGNALduino_ITV1_tristateToBit($data);
Log3 $name, 5, "$name: sendmsg IT V1 convertet tristate to bits=$data";
} elsif ($protocol == 43) {

}


Gruß Ralf

[habeIchVergessen]

mach ich später.
Wie bekomme ich die aktuelle Version von 00_SIGNALduino.pm? normales Update?

[Ralf9]

Wie bekomme ich die aktuelle Version von 00_SIGNALduino.pm? normales Update?

Steht im SIGNALduino wiki
http://www.fhemwiki.de/wiki/SIGNALduino#Einbinden_in_FHEM

Gruß Ralf

[Ellert]

Wenn ich mit dem SOMFY Modul über nanoCUL433 sende und über SIGNALduino empfange, legt autocreate ein falsches Gerät an.
Das von mir angelegte Gerät (Testfernbedienung)

Code Auswählen Erweitern


define somfy1 SOMFY 12389A
sendet mit

Code Auswählen Erweitern

key A0
cmd stop
rolingcode  0000
RAWMSG YsA01000009A3812

mit autocreate wird auf meinem Testrechner

Code Auswählen Erweitern

define SOMFY_389A00 SOMFY 389A00
angelegt, richtig wäre

Code Auswählen Erweitern

define SOMFY_12389A SOMFY 12389A

Der SD zeigt folgende Werte

DMSG YsA0A01000009A3812

RAWMSG MC;LL=-1287;LH=1289;SL=-681;SH=685;D=5F4F4F4FD5EDFF;C=657;L=56;

[habeIchVergessen]

@Ellert: das ist ein Bug in 10_SOMFY.pm

Code Auswählen Erweitern


YsA0A01000009A3812

sub SOMFY_Parse($$) {
...
if (substr($msg, 0, 2) eq "Yr" || substr($msg, 0, 2) eq "Yt") {
# changed time or repetition, just return the name
return $hash->{NAME};
}

    # get address
    my $address = uc(substr($msg, 14, 2).substr($msg, 12, 2).substr($msg, 10, 2));
...
}


In der Zeile my $address müssen die Offsets um 2 erhöht werden.

@Sidey: die Checksummen wurden richtig berechnet. Jedoch begann die for-Schleife vom decode bei 0 anstatt bei 1. Habe ich gleich mit in meinem commit erledigt. Pull-Request habe ich auch angelegt.

Kann jemand das Senden via SIGNALduino testen (inkl. Empfang). Dazu wird der Patch von Ralf9 in 10_SOMFY.pm benötigt. Habe leider nur einmal Hardware.

[Ellert]

@habeIchVergessen:

In der Zeile my $address müssen die Offsets um 2 erhöht werden.

Ist es nicht so, dass in
DMSG YsA0A01000009A3812
A0 doppelt drin ist?
Es sind 16 statt 14 hex-Digits

Das hat sich  hiermit erledigt.

Jedoch begann die for-Schleife vom decode bei 0 anstatt bei 1.

Ich habe in der 00_SIGNALduino.pm den Schleifenstart auf 1 gesetzt.
Dannn habe ich von

Code Auswählen Erweitern

define somfy1 SOMFY 12389A gesendet.

Code Auswählen Erweitern

DMSG YsA21000029A3812 ist im SD korrekt dargestellt.
Auf dem Testrechner wurde mit dem SD empfangen und per autocreate folgendes angelegt:

Code Auswählen Erweitern

define SOMFY_12389A SOMFY 12389A
Das ist korrekt.
Die Datei 10_SOMFY.pm muss nicht angepasst werden.

[habeIchVergessen]

@Ellert: Bold hat nicht gereicht. Zufälligerweise habe ich die eigentliche Ursache erwähnt.