SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

Begonnen von timtom, 20 Mai 2017, 14:35:24

Vorheriges Thema - Nächstes Thema

nagelreo

Hallo Ralf,

vielen Dank für das "fix".
Der MapleMini läuft bereits seit 9:20 damit. Bisher wurden ca. 300 Signale empfangen, alle perfekt.
Um auch ein paar Signale von den restlichen Sendern zu haben, will ich mindestens 7 Tage abwarten.

Gruß
Rolf

nagelreo

@Ralf9

Fragen zum fhem logfile.
Werden bei der MapleMini Definition
Verbose : 4
whitelist_IDs: 43
nur MC-Signale von Somfy Sender logged?
Was ist der trigger dafür?

Gruß
Rolf

Ralf9

ZitatWerden bei der MapleMini Definition
Verbose : 4
whitelist_IDs: 43
nur MC-Signale von Somfy Sender logged?
Mit verbose 4 werden alle empfangenen Raw Nachrichten ausgegeben.
Empfängst Du bei 433.42 noch andere Nachrichten als Somfy?

ZitatWas ist der trigger dafür?
Es wird auf einen Clockbereich (C=...) von 610 bis 680 getriggert.

Zitat
jetzt habe ich wie oben von Dir angegeben, die Routine ausgetauscht, aber jetzt werden gar keine Handsender mehr erkannt.
Stimmt das mit dem 00_SIGNALduiono.pm Model?
@Elektrolurch
kannst Du bitte mal die Orginalroutine, die in der 00_SIGNALduino.pm ist, posten?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Ich habe die Fixe für Somfy Nachrichten in den dev branch meiner Variante der 00_SIGNALduino.pm eingebaut
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900


Dieser Somfy Nachrichten fix, funktioniert mit dem offiziellen 00_SIGNALduino.pm von Sidey bis zur Version v3.4.4.
Dazu muß in der 00_SIGNALduino.pm die
sub SIGNALduino_SomfyRTS()
{
...
}

durch die folgende ersetzt werden und dann ein fhem restart gemacht werden
sub SIGNALduino_SomfyRTS()
{
my ($name, $bitData,$id,$mcbitnum) = @_;

my $flag = 0;
if (defined($mcbitnum)) {
Log3 $name, 4, "$name: Somfy bitdata: $bitData ($mcbitnum)";
if ($mcbitnum <= 60) {
if (substr($bitData, 0, 4) eq '1010') {
$flag = 1; # ok
}
elsif (($mcbitnum == 56 || $mcbitnum == 57) && substr($bitData, 0, 5) eq '01010') {
$bitData = substr($bitData, 1, $mcbitnum - 1);
if ($mcbitnum == 56) {
$bitData .= '0';
}
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). Bit am Anfang entfernt";
$flag = 1; # ok
}
elsif ($mcbitnum >= 52 && $mcbitnum <= 55) {
$bitData = substr($bitData, $mcbitnum - 52, 52);
$bitData = '1010' . $bitData;
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). 1010 am Anfang zugefuegt";
$flag = 1; # ok
}
}
else { # 80 Bit Nachrichten
if (substr($bitData, 0, 4) eq '1010' || substr($bitData, 0, 4) eq '1000') {
$flag = 1; # ok
}
elsif (($mcbitnum == 80 || $mcbitnum == 81) && (substr($bitData, 0, 5) eq '01010' || substr($bitData, 0, 5) eq '01000')) {
$bitData = substr($bitData, 1, $mcbitnum - 1);
if ($mcbitnum == 80) {
$bitData .= '0';
}
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). Bit am Anfang entfernt";
$flag = 1; # ok
}
elsif ($mcbitnum == 78 || $mcbitnum == 79) {
$bitData = substr($bitData, $mcbitnum - 78, 78);
$bitData = '10' . $bitData;
Log3 $name, 4, "$name: Somfy bitdata: _$bitData (" . length($bitData) . "). 10 am Anfang zugefuegt";
$flag = 1; # ok
}
}
}
return (-1,"Somfy check error!") if ($flag == 0);

my $encData = SIGNALduino_b2h($bitData);

#Log3 $name, 4, "$name: Somfy RTS protocol enc: $encData";
return (1, $encData);
}


Damit auch die Nachrichten, bei denen die ersten 4 Bit (A) fehlen, korrigiert werden,
muß noch in der SD_ProtocolData.pm beim Eintrag "43 Somfy RTS" die  length_min auf 52 geändert werden.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Elektrolurch

Hallo Ralf,

habe das Code-Stück in die 00_SIGNALduino.pm, aber nach dem reload kein Empfang mehr von Somfy - RTS.

Elektrolurch
configDB und Windows befreite Zone!

Ralf9

Ich habe es mal auf einem Testsystem getestet. Ich habe ein fhem update gemacht und dann die folgende SIGNALduino Version erhalten:

00_SIGNALduino.pm        22409 2020-07-16 20:04:45Z Sidey
versionProtocols  1.20
versionmodul v3.4.4


Habe in der 00_SIGNALduino.pm die
sub SIGNALduino_SomfyRTS()
{
...
}

ersetzt, ein fhem restart gemacht und dann mit einem Dummysduino getestet

2020.08.23 12:17:31.699 5 : sduinoD: msg adding start and endmarker to message
2020.08.23 12:17:31.700 4 : sduinoD: msg get raw: MC;LL=-1327;LH=1242;SL=-681;SH=597;D=5559DFCD365044;C=641;L=56;R=52;
2020.08.23 12:17:31.700 4 : sduinoD: Parse_MC, Found manchester protocol id 43 clock 641 RSSI -48 -> Somfy RTS
2020.08.23 12:17:31.700 5 : sduinoD: Parse_MC, extracted data 01010101010110011101111111001101001101100101000001000100 (bin)
2020.08.23 12:17:31.700 4 : sduinoD: Somfy bitdata: 01010101010110011101111111001101001101100101000001000100 (56)
2020.08.23 12:17:31.700 4 : sduinoD: Somfy bitdata: _10101010101100111011111110011010011011001010000010001000 (56). Bit am Anfang entfernt
2020.08.23 12:17:31.700 5 : sduinoD: Dispatch, YsAAB3BF9A6CA088, test ungleich: disabled
2020.08.23 12:17:31.700 5 : sduinoD: Dispatch, YsAAB3BF9A6CA088, -48 dB, dispatch
2020.08.23 12:17:31.700 5 : sduinoD: dispatch YsAAB3BF9A6CA088
2020.08.23 12:17:31.700 4 : sduinoD: Somfy RTS preprocessing check: 9 enc: AAB3BF9A6CA088 dec: AA190C25F6CC28
2020.08.23 12:17:31.700 1 : SOMFY Unknown device 28CCF6 (AA 0C25), please define it
2020-08-23 12:17:31.702 Global global UNDEFINED SOMFY_28CCF6 SOMFY 28CCF6 AA 0C25


Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

nagelreo

Hallo Ralf,

ZitatEmpfängst Du bei 433.42 noch andere Nachrichten als Somfy?

Von meinen Sendern sicher nicht, aus der Nachbarschaft war ich mir nicht sicher. Zur Beurteilung von unbekannten und/oder "unvollständigen" Signalen wollte ich die Kriterien kennen.
Da mein MapleSduino relativ mittig im Haus platziert ist, halte ich die Anzahl der Nachbar-Signale für vernachlässigbar.

Bisher habe ich ca. 5200 MC-Signale empfangen und ausgewertet.
Testbedingungen:
- Raspberry 4.0 und Fhem mit aktueller Sofware.
   00_SIGNALduino.pm 345 2020-08-04 10:00:00Z v3.4.5-dev-Ralf9, ersetzte "sub SIGNALduino_SomfyRTS « Antwort #147 am: 19 August 2020,
   00:31:39 »"   
- MapleSduino (mini)
  Fw V 4.1.1-dev200627 SIGNALduino cc1101 (R: B0*) - compiled at Jun 28 2020 13:30:04
  b_ccconf b=0 rx=0 freq:433.450MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000*]c
  verbose 4
  whitelist_IDs 43  (Somfy)
- Device
  Somfy Soliris Sensor RTS, sendet ca. 80 Signale / Stunde. Somfy 56 bit MC Signale mit fix Code. Abhängig von der Helligkeit und Wind gibt es
  3 unterschiedliche Signale (A0xxxx459CBF22). Damit ist der Sensor zur Zurodnung von unvollständigen Signalen bestens geeignet
  (kein rolling code).
  17 RTS-1 / RTS-4 Fernbedienungen.

Auswertung:
- clock time aller MC logs
- bitdata Länge aller MC logs
- Found manchester Protocol id 43 aller MC logs
- Meldungen "please define it" und "checksum error"....
- Device Adressen; bei unvollständigem MC-Signal versucht dieses über das Bruchstück des MC-Signals (Soliris Sensor) oder das Bruchstück
   in bitdata (FB's) umwandeln und zuzuordnen.   

Ergebnis:

Durch das "modifizierte sub Somfy" wurden 11 Signale (ca. 0.2 %) ergänzt und alle korrekt zugeordnet. Signale, bei denen die ersten 4 bit (A) fehlen, werden dagegen nicht korrigiert (15)!.
2020.08.19 13:11:26 4: MapleSduino1/msg READ: MC;LL=-1281;LH=1282;SL=-635;SH=639;D=04747459CBF22;C=639;L=52;R=1;s11;b2;w;
2020.08.19 13:11:26 4: MapleSduino1/msg READ: MC;LL=-1281;LH=1282;SL=-635;SH=639;D=A04747459CBF22;C=639;L=56;R=1;s17;b17;w;
2020.08.19 13:11:26 4: MapleSduino1: Found manchester Protocol id 43 clock 639 RSSI -73.5 -> Somfy RTS
2020.08.19 13:11:26 4: MapleSduino1: Somfy bitdata: 10100000010001110100011101000101100111001011111100100010 (56)
2020.08.19 13:11:26 4: MapleSduino1 Dispatch: YsA04747459CBF22, -73.5 dB, dispatch
2020.08.19 13:11:26 4: MapleSduino1: Somfy RTS preprocessing check: 7 enc: A04747459CBF22 dec: A0E70002D9239D


Die Anzahl der Signale mit der Meldung "please define it" oder "checksum error" ist mit ca. 0.5 % relativ gering.
Die Anzahl der Signale mit einer Länge < 56 bit ist mit 3.6 % sehr hoch und zu 75 % durch fehlende bits am Ende verursacht. Die teilweise sehr kurzen Signale standen bisher nicht im Fokus bzw. wurden als Signale vom Nachbar interpretiert.
Details siehe Anhang.

Ralf, hast Du außer der Korrektur zur Ergänzung der 4 bits am Anfang noch weiter Ideen?
Die würde ich auch testen.
Vorerst werde ich mit meinem optimierten Testbedingungen und Auswertung nochmals die Einstellung (sens, bWidth) vom MapleSduino überprüfen.

Gruß
Rolf

Ralf9

ZitatSignale, bei denen die ersten 4 bit (A) fehlen, werden dagegen nicht korrigiert (15)!
Wenn Du in der "signalduino_protocols.pm" (bei Sidey ist es die SD_ProtocolData.pm), beim Eintrag "43 Somfy RTS" die  length_min auf 52 änderst, dann werden auch diese korrigiert:
2020.08.23 22:14:03.090 4 : sduinoD/msg get raw: MC;LL=-1281;LH=1282;SL=-635;SH=639;D=04747459CBF22;C=639;L=52;R=1;s11;b2;w;
2020.08.23 22:14:03.090 4 : sduinoD: Found manchester Protocol id 43 clock 639 RSSI -73.5 -> Somfy RTS
2020.08.23 22:14:03.090 4 : sduinoD: Somfy bitdata: 0000010001110100011101000101100111001011111100100010 (52)
2020.08.23 22:14:03.090 4 : sduinoD: Somfy bitdata: _10100000010001110100011101000101100111001011111100100010 (56). 1010 am Anfang zugefuegt
2020.08.23 22:14:03.090 5 : sduinoD: dispatch YsA04747459CBF22
2020.08.23 22:14:03.090 4 : sduinoD: Somfy RTS preprocessing check: 7 enc: A04747459CBF22(14) dec: A0E70002D9239D
2020.08.23 22:14:03.090 1 : SOMFY Unknown device 9D23D9 (A0 0002), cmd=E0 please define it


ZitatRalf, hast Du außer der Korrektur zur Ergänzung der 4 bits am Anfang noch weiter Ideen?
Ideen schon, aber bei weiteren Fixen wird der Aufwand zu groß.

So wies aussieht werden die Somfy Nachrichten ca 1-3 mal gesendet
ZitatDie Anzahl der Signale mit einer Länge < 56 bit ist mit 3.6 % sehr hoch und zu 75 % durch fehlende bits am Ende verursacht.
Dies dürfte aber egal sein, solange eine andere der mehrfach gesendeten Nachrichten ok ist.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

capo

Zitat von: nagelreo am 13 August 2020, 16:10:08
Hallo,
Genau so ist es, der Abgleich vom Somfy device mit der Fernbedienung funktioniert mit der aktuellen 10_SOMFY.pm. Für die Fernbedienung ein device definieren (z. B. autocreate) und in userattribut associated-devices eintragen. Mit dem "InternalVal STATE" des device der Fernbedienung kann man zusätzlich den Status im Rollo device abgleichen (über ein Notify mit parsestate....).
Im Prinzip funktioniert das sehr gut. Probleme gibt es aber mit der Zuverlässigkeit beim Erkennen der Fernbedienung und führt zum Eintrag "Somfy RTS checksum error!" oder "SOMFY Unknown device 2ECE1D (AE 04EF), please define it" im logfile. Wenn autocreate aktiviert ist, wird im letzteren Fall ein neues device angelegt. Ich habe die Signale zahlreicher "unknown device" analysiert und konnte diese als unvollständige Signale identifizieren. Beispiel siehe Kommunikation mit Ralf99 vom 01 August 2020, 19:46:26.
Die Zuverlässigkeit des Empfangs konnte ich im Wesentlichen durch folgende Maßnahmen deutlich verbessern, aktuell >= 98 %.
- update der FW Signalduino
- Positionierung des Signalduino
Dennoch wünsche ich mir eine Verbesserung der Zuverlässigkeit, siehe Kommunikation mit Ralf99.

Gruß
Rolf



Nach etwas Reverse Engineering ist das der Stand:
In 10_SOMFY.pm gibt es SOMFY_DispatchRemoteCmd.
Das nutzt man wie folgt:
1. model vom Handsender umstellen auf: "somfyremote"
2. beim Handsender das Attribut rawDevice mit ADDRESS vom SIGNALduino-Device pflegen
Das war's ohne associated-devices oder zusätzliche notify. Funktioniert gut, wenn die Signale vom Handsender zuverlässig erkannt würden.
Auch bei mir gibt es noch UNKNOWNCODE Ys....

nagelreo

Hallo capo,

ZitatIn 10_SOMFY.pm gibt es SOMFY_DispatchRemoteCmd.
Das nutzt man wie folgt:
1. model vom Handsender umstellen auf: "somfyremote"
2. beim Handsender das Attribut rawDevice mit ADDRESS vom SIGNALduino-Device pflegen

Ich habe mein "Remote-Device" bei einer Markise entsprechend geändert, d. h.  associated-devices gelöscht und notify deaktiviert.
Im "Device Handsender" ändert sich das devStateIcon, im "SIGNALduino-Device" nicht.
Kannst du ein Beispiel posten?

Wenn das so funktioniert, wäre ja genial.
Ich wundere mich nur, warum das nicht im Somfy Wiki und im commandref erwähnt ist.

Zitat.....wenn die Signale vom Handsender zuverlässig erkannt würden.
Auch bei mir gibt es noch UNKNOWNCODE Ys....
Ralf hat ja ein fix für die Somfy Nachrichten geschrieben. Bei fehlenden bits (52-55) am Anfang funktioniert das sehr gut, dennoch werden noch relativ viele Signale wegen fehlenden bits am Ende nicht richtig erkannt. Ich habe das mit diversen Einstellungen (rAmpl, sens, bWidth) mit sehr vielen Signalen bewertet. Leider bin ich mit der Auswertung noch nicht fertig.

Gruß
Rolf

Ralf9

ZitatRalf hat ja ein fix für die Somfy Nachrichten geschrieben. Bei fehlenden bits (52-55) am Anfang funktioniert das sehr gut, dennoch werden noch relativ viele Signale wegen fehlenden bits am Ende nicht richtig erkannt.
Konntest Du inzwischen herausfinden wie oft die Nachricht beim kurzen drücken einer Taste gesendet wird?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

nagelreo

Hallo Ralf,

ZitatKonntest Du inzwischen herausfinden wie oft die Nachricht beim kurzen drücken einer Taste gesendet wird?
Sorry, deine Frage zur Anzahl der Signale bei kurzem Tastendruck habe ich vergessen.
Bei sehr kurzem Tastendruck (Telis 4 Solaris, Telis 4 RTS und RTS) wird jeweils nur ein Signal empfangen, bei langem Tastendruck ca. 5 Signale pro Sekunde.


Mit deiner modifizierten "sub Somfy" habe ich nochmals die Erkennung der Signale in Abhängigkeit der Parameter "rAmpl, sens und bWidth" bewertet.
Wie bereits beschrieben, kommen die Signale überwiegend vom Somfy Sonnen-Wind-Sensor (ca. 99 %). Dieser sendet ca. 80 Signale (fix-code) pro Stunde. Abhängig von Sonne und Wind werden nur 3 unterschiedliche Signale gesendet. Daher konnte ich auch unvollständige Signale zuordnen.
Testbedingungen:
- Raspberry 4.0 und Fhem mit aktueller Sofware.
   00_SIGNALduino.pm 345 2020-08-04 10:00:00Z v3.4.5-dev-Ralf9, ersetzte "sub SIGNALduino_SomfyRTS « Antwort #147 am: 19 August 2020, 00:31:39 »"   

- MapleSduino (mini)
  Fw V 4.1.1-dev200627 SIGNALduino cc1101 (R: B0*) - compiled at Jun 28 2020 13:30:04
  b_ccconf b=0 rx=0 freq:433.450MHz bWidth:xxKHz rAmpl:xxdB sens:xxdB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000*]c
  verbose 4
  whitelist_IDs 43  (Somfy)
  bWidth   :  325, 232 und 541
  rAmpl    :  42 und 38
  sens      :  4, 8 und 12
- Device
  Somfy Soliris Sensor RTS, sendet ca. 80 Signale / Stunde. Somfy 56 bit MC Signale mit fix Code. Abhängig von der Helligkeit und Wind gibt es 3 unterschiedliche Signale (A0xxxx459CBF22). Damit ist der Sensor zur Zurodnung von unvollständigen Signalen bestens geeignet (kein rolling code).
  17 RTS-1 / RTS-4 Fernbedienungen.


In Summe habe ich 25 000 Signale empfangen und ausgewertet. Im Rahmen der Streuung sehe ich keinen signifikanten Einfluss der Parameter auf die Erkennung. Auffällig ist aber, dass die Erkennung der Signale über den Tag relativ stark schwankt, aber keiner Tageszeit zugeordnet werden kann.
Gezählt habe ich die Anzahl der empfangen MC-Signale gesamt, in Abhängigkeit der Signale-Länge und nach Zuordnung zum Device, Sonnen-Wind-Sensor, Handsender und Nachbar.

Anzahl gesamt    :  25016
Somfy id 43         :     94.7 %
Länge 52 - 55 bit :      1.0 %  bit am Anfang fehlen, bis auf 2 Signale waren nach dem Zufügen der fehlenden bits alle Signale korrekt. Bei den beiden ist zusätzlich ein bit am Ende falsch.
Länge 52 -55 bit  :      0.5 %  bit am Ende fehlen
please define it    :      0.10 %
checksum error   :       0.14 %
Signal Nachbar    :      0.03 %
Die fehlenden ca. 5 % der Signale sind unvollständige MC-Signale (17 bis 55 bit) und konnten überwiegend dem Sonnen-Wind-Sensor zugeordnet werden.
Die Modifikation der sub Somfy ist aus meiner Sicht ok und hilft die Erkennung zu verbessern.

Gruß
Rolf

capo

Zitat von: nagelreo am 03 September 2020, 22:40:27
Hallo capo,

Ich habe mein "Remote-Device" bei einer Markise entsprechend geändert, d. h.  associated-devices gelöscht und notify deaktiviert.
Im "Device Handsender" ändert sich das devStateIcon, im "SIGNALduino-Device" nicht.
Kannst du ein Beispiel posten?

Wenn das so funktioniert, wäre ja genial.
Ich wundere mich nur, warum das nicht im Somfy Wiki und im commandref erwähnt ist.
Ralf hat ja ein fix für die Somfy Nachrichten geschrieben. Bei fehlenden bits (52-55) am Anfang funktioniert das sehr gut, dennoch werden noch relativ viele Signale wegen fehlenden bits am Ende nicht richtig erkannt. Ich habe das mit diversen Einstellungen (rAmpl, sens, bWidth) mit sehr vielen Signalen bewertet. Leider bin ich mit der Auswertung noch nicht fertig.

Gruß
Rolf

Hi Rolf,
gerne, was brauchst Du?
Einer meiner Handsender sieht so aus:
Attributes
IODev=RTS
model=somfyremote
rawDevice=09ABCD 15ABCD 0BABCD

Damit übertrage ich dessen Signale an 3 Devices, die nach der Anleitung https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino angelegt wurden.
Das erste sieht so aus:
Internals:
   ADDRESS=09ABCD

Im Log sieht das dann so aus:
2020.09.07 21:14:58 1: SOMFY_DispatchRemoteCmd SENDEROST found dispatch SOMFY device R09 sent command :on:
2020.09.07 21:14:58 1: SOMFY_DispatchRemoteCmd SENDEROST found dispatch SOMFY device R06O sent command :on:
2020.09.07 21:14:58 1: SOMFY_DispatchRemoteCmd SENDEROST found dispatch SOMFY device R15 sent command :on:

Das macht dieses Modul in der Standard 10_SOMFY.pm
#############################
sub SOMFY_DispatchRemoteCmd($$) {
        my ($hash, $cmd) = @_;
        my $name = $hash->{NAME};
        if ($cmd eq "10") {
                $cmd = "11"; # use "stop" instead of "go-my"
  }
        my $txtcmd = $somfy_codes{ $cmd };
  return if ( ! $txtcmd );
        my $rawdAttr = AttrVal($name,'rawDevice',undef);
        # check if rdev is defined and exists
  if( defined($rawdAttr) ) {
                # normalize address in rawdev
                $rawdAttr = uc( $rawdAttr );
    my @rawdevs = split( /\s+/, $rawdAttr );
    foreach my $rawdev ( @rawdevs ) {

.... etc ....

capo

Habe die fixes von Ralf in SD_ProtocolData.pm und 00_SIGNALduino.pm eingebaut und bin begeistert  :)

nagelreo

Hallo capo,

ZitatHabe die fixes von Ralf in SD_ProtocolData.pm und 00_SIGNALduino.pm eingebaut und bin begeistert[/quote
Auch wenn bei mir nicht alle Signale erkannt werden, bin ich von Ralf seinem fix begeistert.
Werden bei dir alle Signale erkannt?

ZitatIm "Device Handsender" ändert sich das devStateIcon, im "SIGNALduino-Device" nicht.
Ich konnte das Problem lösen, ich hatte das stateFormat nicht gelöscht. D.h. das Attribut "model=somfyremote" funktioniert, die Position vom Rollo wird im devStateIcon korrekt angepasst, selbst wenn zwischen 2 mal down ein mal stop gedrückt wird.

Gruß
Rolf