SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

[nagelreo]

Hallo zusammen, Hallo Ralf,

ich habe weitere 2 RTS und 2 Telis-4 Handsender bewertet, der Fehler tritt bei allen auf. Zudem habe ich den Einfluss vom Standort des Sduino nochmals untersucht und "optimiert". Der Fehler "1 Bit fehlt" tritt danach bei ca. 2 - 5 % der Nachrichten auf. In selten Fällen fehlen bis zu 3 Bits, geschätzt ist die Häufigkeit aber kleiner 0.1 %.

Wie erwartet können die fehlerhaften Nachrichten (1 Bit fehlt) über die Check-Summe prinzipiell korrigiert werden, das habe ich bei mehreren fehlerhaften Nachrichten gezeigt, nachfolgend exemplarisch ein Beispiel.

Code Auswählen Erweitern


2020.03.15 07:13:21 4: CUL1: Parse_MC, Found manchester Protocol id 43 clock 643 RSSI -37.5 -> Somfy RTS
2020.03.15 07:13:21 4: CUL1: Somfy bitdata: 01010110010111001101111110110100110100011110010101000100 (56)
2020.03.15 07:13:21 4: CUL1: Somfy RTS preprocessing check: A enc: 565CDFB4D1E544 dec: 560A836B6534A1
2020.03.15 07:13:21 1: SOMFY Unknown device A13465 (56 836B), please define it
2020.03.15 07:13:21 4: CUL1: Read, msg: MC;LL=-1271;LH=1298;SL=-635;SH=655;D=565CDFB4D1E544;C=643;L=56;R=72;
dec fhem:  56 0A 836B 6534A1      cks ist korrekt, Adresse ist falsch
berechnetes cks: A
Bit 1 entfernt und Bit "0" angehängt
_10101100101110011011111101101001101000111100101010001000
dec Excel: AC 15 06D6 4269CA       cks und Adresse sind korrekt
berechnetes cks: 5
Bit 1 entfernt und Bit "1" angehängt
_10101100101110011011111101101001101000111100101010001001
dec Excel: AC 15 06D6 4369CA      cks und Adresse sind falsch
berechnetes cks: 4


Leider ist in diesem Beispiel die Checksumme mit dem aktuellen 10_SOMFY Protokoll (zufällig) korrekt, obwohl 1 Bit fehlt und die Adresse falsch ist. Ich habe auch Beispiele, bei denen die Checksumme auch falsch ist.

Ich habe mir die Protokolle 00_SIGNALduino.pm und 10_SOMFY.pm angeschaut.
In 00_SIGNALduino wird in der Sub SIGNALduino_SomfyRTS das erste Bit nur entfernt, wenn die Anzahl 57 Bits ist.
Die Dekodierung und anschließende Prüfung der Checksumme erfolgt im Protokoll 10_SOMFY.
Damit müssten beide Protokolle angepasst werden.

Zum "Entfernen des ersten Bits" habe ich eine prinzipielle Frage.
Ich habe mir (gefühlt) 2000 Nachrichten angeschaut, bei allen korrekten war das erste Byte "A".
Gibt es bei den SOMFY Sendern Nachrichten welche nicht mit dem Byte "A" beginnen?
Wenn nein, könnte die Abfrage und das "entfernen vom ersten Bit"nicht mit der Bedingung "erstes Byte muss A sein" erfolgen?

Zudem würde ich mich über Rückmeldungen zur Erfahrung mit dem Abgleich von Handsender freuen.
Übrigens, mit Ausnahme des "fehlenden Bits" und dadurch Probleme mit dem rolling code funktioniert der Abgleich der Handsender sehr gut. Das mit dem aktuellen 10_SOMFY Protokoll, Handsender definded mit Attribut "associated-devices" und zusätzlich "notify-device".

Vielen Dank und Gruß
Rolf

[nagelreo]

Hallo Ralf,

beim Sichten meiner Daten fiel mir auf, dass bei den fehlerhaften Nachrichten das fehlende Bit am Ende immer eine "0" ist und nie eine "1" (letzte Daten siehe Excel Datei). Dies ist auch bei Bit-Folgen mit mehreren Nullen vor der fehlenden "0".

Daher glaube ich nicht mehr, dass es an meinen Handsendern liegt. Zwischenzeitlich habe ich 6 Stück bewertet.
Kann es sein, dass beim Demodulieren die "0" verloren geht?

Gruß
Rolf

[Ralf9]

beim Sichten meiner Daten fiel mir auf, dass bei den fehlerhaften Nachrichten das fehlende Bit am Ende immer eine "0" ist und nie eine "1"

Ohne fehlerhafte MC-Nachrichten die als MU-Nachrichten ausgegeben werden, kann ich dies nicht nachprüfen.

Du kannst mal die Firmware in der Anlage testen, da wird zusätzlich zur MC Nachricht auch die MU Nachricht (DMC) ausgegeben

Gruß

[nagelreo]

Hallo Ralf,

einfach super, 100 % Erkennung bei 2 Handsender (RTS und TELIS 4) in 3 Testreihen mit je 20 mal tasten.
Auffällig ist auch, dass nur noch vereinzelt "Bit 57" mit "Bit am Anfang entfernt" ausgegeben wird.
Details siehe Excel-Datei.

Beim Testen habe ich immer die selbe Taste gedrückt, um unnötige Fahrbewegungen der Rollos zu vermeiden. Das sollte aber kein Einfluss haben. Die Änderung der Anzeige der Rollo-Position funktioniert auch, jedoch mit Ausnahme bei der my-Taste. Das schaue ich mir aber nochmals an.
Ich bin gespannt wie der Langzeittest ausfällt, bin aber sehr optimistisch.

Kannst Du verraten, was an der Firmware verändert ist?

Vielen Dank und Gruß
Rolf

[Ralf9]

Hallo Rolf,

Kannst Du verraten, was an der Firmware verändert ist?

schön zu sehen, daß es sich gelohnt hat, den MC Decoder zu überarbeiten und komplett neu zu schreiben.
Der MC Decoder bei mir und bei der Firmware von Sidey funktioniert nach dem selben Prinzip, aber Sidey hat es anders programmiert.

Durch die Debug Ausgaben (DMC) lässt sich erkennen, daß der Anfang nicht richtig erkannt wird, wenn der sync 4800 fehlt oder zu kurz ist.

Leider ist in diesem Beispiel die Checksumme mit dem aktuellen 10_SOMFY Protokoll (zufällig) korrekt, obwohl 1 Bit fehlt und die Adresse falsch ist.

Ja, es wird leider nur eine sehr einfache Checksumme verwendet.

Gibt es bei den SOMFY Sendern Nachrichten welche nicht mit dem Byte "A" beginnen?

Es gibt welche die mit 8 anfangen

und solche
https://forum.fhem.de/index.php/topic,53319.msg764241.html#msg764241

Please note that the "Somfy Telis RTS 1" (vanilla color with 3 grey buttons) remotes I own do NOT have 0xA in the MSB of the 1st byte, but is seemingly random. I also have a Somfy Telis 1 PURE (with the MY center button), that HAS the 0xA in the MSB.

Gruß Ralf

[nagelreo]

Hallo Ralf,

vielen Dank für die Infos. Damit einige meiner Fragen geklärt.

Zwischenzeitlich habe ich alle meine FB's (RTS, TELIS 4 inklusive Gruppen) zum Abgleich der Position eingerichtet und getestet.
DIE ERKENNUNG DER NACHRICHTEN LIEGT BEI 100 %.

Übrigens, beim Abgleich der Position mit dem FB Attribut associated-devices (+ notifydev) muss der rolling code nicht aktuell sein. Dies hatte ich im Rahmen der Probleme bei der Erkennung falsch interpretiert.

Ich nehme an. dass die überarbeitet MC Dekodierung in den nachfolgenden Firmware Versionen erhalten bleibt.

Damit sollte das Problem gelöst sein. Nochmals vielen Dank für die Geduld und Problemlösung.

Gruß
Rolf

[Ralf9]

Ich nehme an. dass die überarbeitet MC Dekodierung in den nachfolgenden Firmware Versionen erhalten bleibt.

Die komplett überarbeitete MC Dekodierung ist schon seit Ende Dezember 2017 drin.

[nagelreo]

Hallo Ralf,

d.h. die überarbeitete MC Dekodeierung ist in allen Firmware Versionen ab Ende 2017.
Muss dazu die Firmware mit der Debug Ausgabe geflasht werden?
Denn ich hatte mehrere Versionen getestet und alle verhielten gleich.
Gruß Rolf

[Ralf9]

Hallo Rolf,

dies sollte mit allen meinen Firmware Versionen ab Ende 2017/Anfang Januar 2018 funktionieren.
Dies ist unabhängig von der Debug Ausgabe, wichtig ist nur ein guter Empfang.

Gruß Ralf

[nagelreo]

Hallo Ralf,

? dann weiß ich nicht warum seit der Umstellung auf die Version SIGNALduino_nanoCC1101_3322rc10DMC.hex die Erkennung 100 % ist. Bei meinen Testreihen ändere ich prinzipiell nur einen Parameter, dies war auch bei der Umstellung auf diese Version.

Du kannst mal die Firmware in der Anlage testen, da wird zusätzlich zur MC Nachricht auch die MU Nachricht (DMC) ausgegeben

Man muss nicht alles verstehen, Hauptsache es funktioniert. Vorerst bleibe ich bei der aktuellen Einstellung und kümmere mich um die restlichen Themen zu meiner Rollo-Steuerung.

Gruß Rolf

[Kawaci]

Hallo!
Ich wollte heute wiedermal versuchen meinen Handsender in fhem mit der Somfy Markise zu synchronisieren! irgendwie funktioniert es nicht!
Der signalesp bekommt keine informationen von dem handsender (Telis 1) wenn ich autocreate abgeschaltet habe, wenn ich autocreate eingeschaltet habe bekommt er die fb mit aber auch unzählige andere devices die er anlegt! Wie krieg ich das gefixt?

Hier meine list:

autocreate:

Code Auswählen Erweitern

Internals:
   FUUID      5c4ffa2d-f33f-f967-ea32-23e6ec4debaca90d
   NAME       autocreate
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-autocreate
   STATE      disabled
   TYPE       autocreate
   received:
Attributes:
   alias      autocreate
   autosave   1
   device_room %TYPE
   disable    1
   filelog    ./log/%NAME-%Y.log
   ignoreTypes (Revolt_.*| SD_.*| ABS_.*| SOMFY.*| CUL_.*| Unknow_.*| CUL_TCM97001.*|)
   room       System
   verbose    0
   weblink    1
   weblink_room Plots

sduino

Code Auswählen Erweitern

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
   DEF        192.168.178.33:23
   DMSG       s316C43689000
   DevState   initialized
   DeviceName 192.168.178.33:23
   FD         10
   FUUID      5c4ffa50-f33f-f967-bdb1-f5f187dcbff9e4ec
   LASTDMSG   s316C43689000
   LASTDMSGID 0.3
   MSGCNT     1325
   NAME       sduino
   NR         41
   NR_CMD_LAST_H 5
   PARTIAL   
   RAWMSG     MS;P1=467;P3=-2027;P4=-4056;P5=-9070;D=15131314141313131413141413141413131314131313131414131414131413131314131314;CP=1;SP=5;R=240;O;m2;
   RSSI       -82
   STATE      opened
   TIME       1594717934
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   unknownmessages
   version    V 3.4.0-dev+20200216 SIGNALESP cc1101 (chip CC1101) - compiled at Feb 15 2020 23:26:10
   versionProtocols 1.17
   versionmodul v3.4.3
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2020-07-14 09:12:50   cc1101_config   Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
     2020-07-14 09:12:50   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2020-07-14 09:12:50   cc1101_patable  C3E = 00 84 00 00 00 00 00 00 => 5_dBm
     2020-03-27 00:11:50   ccconf          freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:8dB  (DataRate:5603.79Baud)
     2020-03-22 18:28:39   ccpatable       C3E = 00 C8 00 00 00 00 00 00  => 7_dBm
     2020-06-24 18:29:10   cmds            V R t X S P C r W s x e
     2020-06-24 18:29:15   config          MS=1;MU=1;MC=1;Mred=1
     2020-06-24 18:29:20   freeram         41496
     2020-07-14 09:10:55   ping            OK
     2019-01-29 08:27:27   raw             Unsupported command -> 0x73 s
     2020-07-13 22:33:52   state           opened
     2020-04-17 22:12:46   version         V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:45:03
   XMIT_TIME:
     1594716546
     1594717603
     1594717605
     1594717643
     1594717651
   additionalSets:
     flash      3.3.1
   helper:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     23
     25
     33
     33.1
     33.2
     35
     41
     49
     51
     53
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
Attributes:
   alias      sduino
   devStateIcon opened:WLAN_Status.1 disconnected:WLAN_Status.0
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      Gateway
   hardware   nanoCC1101
   longids    1
   room       Gateways
   verbose    3
   whitelist_IDs 0,0.1,0.2,0.3,0.4,1,3,3.1,4,6,7,8,9,10,11,12,13,13.1,13.2,14,15,16,17,17.1,18,19,21,22,23,24,25,26,27,28,29,30,31,32,33,33.1,33.2,34,35,36,37,38,39,40,41,42,43,44,44.1,45,46,47,48,49,50,51,52,53,55,56,57,58,59,60,61,62,64,65,66,67,68,69,70,71,72,73,74,74.1,76,79,80,81,83,84,85,86,87,88,89,90,91,91.1,92,93,94,95,96

Markise

Code Auswählen Erweitern

Internals:
   ADDRESS    12345F
   DEF        12345F
   FUUID      5c4ffa53-f33f-f967-516a-4eef61b02fbe4da4
   IODev      sduino
   NAME       Markise
   NR         88
   STATE      20
   TYPE       SOMFY
   move       stop
   CODE:
     1          12345F
   READINGS:
     2020-07-14 11:07:31   enc_key         AC
     2020-07-14 11:07:31   exact           24
     2020-07-14 11:07:31   position        20
     2020-07-14 11:07:31   rolling_code    01EC
     2020-07-14 11:07:31   state           20
     2020-07-14 11:07:31   userposition    0
Attributes:
   IODev      sduino
   alias      Markise
   devStateIcon open:sunblind_0@green closed:sunblind_100@red go-my:sunblind_50@orange
   drive-down-time-to-100 34
   drive-down-time-to-close 34
   drive-up-time-to-100 36.38
   drive-up-time-to-open 36.38
   eventMap   on:ausfahren off:einfahren go-my:my on:close off:open
   genericDeviceType blind
   homebridgeMapping clear CurrentPosition=userposition,minValue=0,maxValue=100,minStep=50 TargetPosition=userposition,minValue=0,maxValue=100,minStep=50,cmds=0:close;;50:my;;100:open
   model      somfyblinds
   room       17_Terrasse,Homekit
   userReadings userposition {(ReadingsVal($NAME,"state","open") eq "open")?100:(ReadingsVal($NAME,"state","open") eq "go-my")?50:0}
   verbose    3
   webCmd     einfahren:my:ausfahren

Handsender

Code Auswählen Erweitern

Internals:
   ADDRESS    28CCF6
   CFGFN     
   DEF        28CCF6 AA 0B95
   FUUID      5f0d5ccc-f33f-f967-906c-7c3785260b2326bd
   IODev      sduino
   LASTInputDev sduino
   MSGCNT     9
   NAME       Markise_FB
   NR         5856
   STATE      ???
   TYPE       SOMFY
   move       stop
   sduino_DMSG YsABBEB503F53911
   sduino_MSGCNT 9
   sduino_Protocol_ID 43
   sduino_RAWMSG MC;LL=-1356;LH=1224;SL=-723;SH=552;D=55DF5A81FA9C888;C=642;L=57;R=232;
   sduino_RSSI -86
   sduino_TIME 2020-07-14 09:55:57
   CODE:
     1          28CCF6
   READINGS:
     1970-01-01 01:00:00   enc_key         AA
     2020-07-14 09:55:57   parsestate      stop
     1970-01-01 01:00:00   rolling_code    0B95
Attributes:
   IODev      sduino
   associated-devices Markise
   room       17_Terrasse,SOMFY
   userattr   associated-devices

wenn noch was gebraucht wird bitte sagen!

[nagelreo]

Hallo Kawaci,

mit dem Signalesp kenne ich mich zwar nicht aus, das Reading kommt mir aber suspekt vor. Der Telis Handsender sendet bei 433.42 MHz, im Reading vom Sduino stehen aber 868, 433.42 und 433.92 MHz.

2020-04-17 22:12:46   version         V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:45:03
2020-03-27 00:11:50   ccconf          freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:8dB  (DataRate:5603.79Baud)
2020-07-14 09:12:50   cc1101_config   Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud

Bei 433.92 MHz wird der Signalesp so gut wie kein Signal mehr empfangen.

Gruß
Rolf

[stef1938]

Hallo Ralf,

habe deine Firmware SIGNALduino_nanoCC1101_3322rc10DMC.hex auf meinen Signalduino (https://www.amazon.de/gp/product/B07TCSCL41/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=) raufgespielt und die Handsender werden (nach ersten kurzen Tests) zu 100% erkannt.
Ich hatte zuvor die vorinstallierte FW und dann auf die FW 3.4.0 geupdated. Bei beiden FW hat der Signalduino erst nach ca. 30 mal drücken am Handsender was erkannt.

Jetzt mit deiner FW scheint es als wäre ich bei 100% Erkennungsquote. Würde mich interessieren, was bei den FW so den großen Unterschied ausmacht?

Danke jedenfalls!!

BG, Stefan

[Elektrolurch]

Hallo Bernd und Ralf,

leider werden bei mir die Somfy - Handsender nicht gut erkannt.
Firmware habe ich:
version
V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

Gibt es da etwas Neueres? Bei update steht bei Singanlduio "nothing to do".
Muss ich da eine andere Quelle angeben?

Elektrolurch

[Ralf9]

Code Auswählen Erweitern

V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Ja, die firmware ist schon recht alt, in den aktuelleren firmwaren wurde einiges optimiert und einige Bugs beseitigt.
Wichtig sind bei Somfy auch ein gute Empfangsverhältnisse

Gruß Ralf