SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

[Ralf9]

Code Auswählen Erweitern

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?

Die "SIGNALduino_nanoCC1101_3322rc10DMC.hex" enthält für den normalen Betrieb nicht nötige Debugausgaben.
Bitte teste auch mal meine V 3.3.2.1-rc9 die sollte bei SOMFY eigentlich genauso gut funktionieren
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Ich habe die Erkennung vom Anfang des SOMFY Signals etwas anders programmiert als in der offiziellen Version von Sidey, dies hat evtl Vorteile bei nicht optimalen Empfangsbedingungen.

Gruß Ralf

[nagelreo]

Hallo Elektrolurch, Hallo Ralf,

Bitte teste auch mal meine V 3.3.2.1-rc9 die sollte bei SOMFY eigentlich genauso gut funktionieren
Ich habe die Erkennung vom Anfang des SOMFY Signals etwas anders programmiert als in der offiziellen Version von Sidey, dies hat evtl Vorteile bei nicht optimalen Empfangsbedingungen.

Anfang des Jahres habe ich mich intensiv mit dem Empfang meiner SOMFY Handsender beschäftigt.
Mit der Umstellung auf die FW SIGNALduino_nanoCC1101_3321rc9.hex hatte ich anfangs 100 % Erkennung der Signale meiner Handsender, im Langzeittest aber "nur" ca. 98 - 99 %.
Zwischenzeitlich habe ich die SOMFY's auf den MapleMini migriert und ca. 3 Wochen im Langzeittest, zuvor den Empfang mit dem SIGNALduino (SIGNALduino_nanoCC1101_3321rc9.hex) und dem MapleMini (Maple_sduino_USB_411dev200627.bin) parallel getestet.
- mit dem SIGNALduino und dem MapleMini ist der Empfang im Parallelbetrieb identisch
- im Langzeittest werden die Signale mit dem MapleMini auch nur zwischne 98-99 % erkannt.
- eine Abhängigkeit von der Sender-Positionierung konnte ich nach der Optimierung (Einstellung, Position Raspberry/Empfänger) nicht erkennen.

Zum Vergleich habe ich den billigen Funksender vom Türgong (GEA-028DB) seit Mai 2020 in Betrieb und alle Signale empfangen.

Ich hätte starkes Interesse an der weiteren Verbessrung des Empfangs und würde beim Testen sehr gerne unterstützen. 

Gruß
Rolf

[Ralf9]

Hallo Rolf,

bei den nicht erkannten Signalen der Handsender, steht da normalerweise im log eine Fehlermeldung in der Art: "Somfy RTS message format error" oder "Somfy RTS checksum error"
Kannst Du mal einige von diesen MC-Nachrichten, die eine solche Fehlermeldung erzeugen, posten?

Mit wie vielen Wiederholungen werden die Signale der Handsender gesendet?

Zum Vergleich habe ich den billigen Funksender vom Türgong (GEA-028DB) seit Mai 2020 in Betrieb und alle Signale empfangen.

Hast Du mal geschaut mit wie vielen Wiederholungen der Funksender vom Türgong sendet? Dies sind wahrscheinlich recht viele Wiederholungen.

Gruß Ralf

[nagelreo]

Hallo Ralf,

vielen Dank für die schnelle Antwort.

bei den nicht erkannten Signalen der Handsender, steht da normalerweise im log eine Fehlermeldung in der Art: "Somfy RTS message format error" oder "Somfy RTS checksum error"
Kannst Du mal einige von diesen MC-Nachrichten, die eine solche Fehlermeldung erzeugen, posten?

Bisher habe ich nur "keine Fehlermeldung",  "checksum error" und "unknown device, plase define it" beobachtet. Zufällig habe ich heute alle 3 Fehler erhalten und etwas aufbereitet.

Meine beiden Markisen habe ich mit der Somfy Telis 4 Fernbedienung vom identischen Standort innerhalb 5 Sekunden angesteuert. Das Signal für die Markise_1 (CBCC73) wurde nicht, das der Markise_2 (CBCC74) korrekt erkannt. Im logfile (Verbose 4) war ein Hex-Code mit 12 Bytes ohne Fehlermeldung gelogt. Anhand vom Zeitstempel vermutete ich, dass es das Signal der Markise_1 sein muss und das die ersten 8 Bits fehlen. Dies hat sich durch iteratives Ergänzen der Bits bestätigt.

Code Auswählen Erweitern


2020.08.01 16:18:55 4: MapleSduino1: Read, msg: MC;LL=-1332;LH=1243;SL=-700;SH=596;D=EBEEB8CB07CC;C=645;L=48;R=48;s9;b4;
EBEEB8CB07CC: nach dem Bit-Muster fehlen die ersten 8 Bits
Bit 1-8 ergänzt ergibt den korrekten Code 10101010111010111110111010111000110010110000011111001100 =  AA410556CBCC73 = CBCC73

2020.08.01 16:19:00 4: MapleSduino1: Read, msg: MC;LL=-1328;LH=1254;SL=-675;SH=603;D=A8E8EB8CF834FF;C=643;L=56;R=51;s6;b6;
2020.08.01 16:19:00 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 643 RSSI -48.5 -> Somfy RTS
2020.08.01 16:19:00 4: MapleSduino1: SomfyRTS, bitdata: 10101000111010001110101110001100111110000011010011111111 (56)
2020.08.01 16:19:00 4: MapleSduino1: Somfy RTS preprocessing check: 0 enc: A8E8EB8CF834FF dec: A840036774CCCB


Mein wind_sun sensor sendet alle 15 Minuten 4 Signale à 5 Wiederholungen, der Sensor verwendet einen fix-Code, d.h. bei konstanter Helligkeit wird immer der gleiche Code gesendet.
Aufgrund der vielen Wiederholungen sind die Fehler im Prinzip nicht relevant. Da die gleichen Fehler auch bei den Handsendern vorkommen aber repräsentativ.
Beim ersten Signal fehlen Bit 1 und 2 mit der Fehlermeldung "unknown device...". Werden die Bits ergänzt, ist der Code korrekt enc. YsA04747459CBF22.
Das Signal 2 ist fehlerfrei und liefert das korrekte Signal, enc. YsA04747459CBF22.
Beim Signal 3 fehlen die letzten 3 Bits und die Fehlermeldung "checksum error". Werden die Bits ergänzt, ist der Code korrekt YsA04747459CBF22. Zudem wird die Anzahl der Bit 53 gelogt, die fehlenden Bits im Bitmuster aber mit 0 aufgefüllt.

Code Auswählen Erweitern


2020.08.01 16:52:59 4: MapleSduino1: Read, msg: MC;LL=-1292;LH=1267;SL=-640;SH=638;D=811D1D1672FC88;C=639;L=54;R=7;s1;b1;w;
2020.08.01 16:52:59 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 639 RSSI -70.5 -> Somfy RTS
2020.08.01 16:52:59 4: MapleSduino1: SomfyRTS, bitdata: 10000001000111010001110100010110011100101111110010001000 (54)
2020.08.01 16:52:59 4: MapleSduino1: Somfy RTS preprocessing check: C enc: 811D1D1672FC88 dec: 819C000B648E74
2020.08.01 16:52:59 1: SOMFY Unknown device 748E64 (81 000B), please define it
Bit 1 und 2 ergänzt  ergibt den korrekten Bitmuster : 10100000010001110100011101000101100111001011111100100010

2020.08.01 16:53:07 4: MapleSduino1: Read, msg: MC;LL=-1278;LH=1286;SL=-640;SH=638;D=A04747459CBF22;C=640;L=56;R=5;s17;b17;w;
2020.08.01 16:53:07 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 640 RSSI -71.5 -> Somfy RTS
2020.08.01 16:53:07 4: MapleSduino1: SomfyRTS, bitdata: 10100000010001110100011101000101100111001011111100100010 (56)
2020.08.01 16:53:07 4: MapleSduino1: Dispatch, YsA04747459CBF22, Dropped due to short time or equal msg

2020.08.01 16:53:07 4: MapleSduino1: Read, msg: MC;LL=-1278;LH=1286;SL=-640;SH=638;D=A04747459CBF20;C=640;L=53;R=5;s17;b17;
2020.08.01 16:53:07 4: MapleSduino1: Parse_MC, Found manchester protocol id 43 clock 640 RSSI -71.5 -> Somfy RTS
2020.08.01 16:53:07 4: MapleSduino1: SomfyRTS, bitdata: 10100000010001110100011101000101100111001011111100100000 (53)
2020.08.01 16:53:07 1: MapleSduino1: SOMFY_Parse : Somfy RTS checksum error! :A04747459CBF20:
2020.08.01 16:53:07 3: MapleSduino1: Unknown code YsA04747459CBF20, help me!
Bit 54-56 ergänzt ergibt das korrekte Bitmuster: 10100000010001110100011101000101100111001011111100100010


Mit wie vielen Wiederholungen werden die Signale der Handsender gesendet?
Hast Du mal geschaut mit wie vielen Wiederholungen der Funksender vom Türgong sendet? Dies sind wahrscheinlich recht viele Wiederholungen.

Für die Handsender bin ich mir nicht ganz sicher, vermute aber ohne Wiederholung bei kurzen Drücken der Taste.
Den Türgong triggere ich über eine Fotodiode und einem Digispark, dadurch sind die Wiederholungen immer konstant, gesendet wird mit 2 Wiederholungen.

Gruß
Rolf

[stef1938]

Code Auswählen Erweitern

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?

Die "SIGNALduino_nanoCC1101_3322rc10DMC.hex" enthält für den normalen Betrieb nicht nötige Debugausgaben.
Bitte teste auch mal meine V 3.3.2.1-rc9 die sollte bei SOMFY eigentlich genauso gut funktionieren
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Ich habe die Erkennung vom Anfang des SOMFY Signals etwas anders programmiert als in der offiziellen Version von Sidey, dies hat evtl Vorteile bei nicht optimalen Empfangsbedingungen.

Gruß Ralf

Hallo Ralf,

diese FW funktioniert auch einwandfrei. Teste noch ein wenig. Was bei beiden FWs nicht so gut funktioniert, ist wenn ich mehrere Befehle zugleich abgebe. ZB über Homebridge/Homekit alle Raffstores im Wohnzimmer auf 50% setze. Die Raffstores starten teilweise stark zeitversetzt (bis zu 10 Sek). Es scheint aber so, als ob FHEM für die Berechnung der Position, bereits mit Erteilung des Befehls zu zählen beginnt und nicht erst mit dem Absetzen des Signals.

Gibts hierfür vielleicht eine Lösung?

Versuche in der Zwischenzeit das Signal zu optimieren.

LG, Stef

[Ralf9]

diese FW funktioniert auch einwandfrei. Teste noch ein wenig. Was bei beiden FWs nicht so gut funktioniert, ist wenn ich mehrere Befehle zugleich abgebe. ZB über Homebridge/Homekit alle Raffstores im Wohnzimmer auf 50% setze. Die Raffstores starten teilweise stark zeitversetzt (bis zu 10 Sek). Es scheint aber so, als ob FHEM für die Berechnung der Position, bereits mit Erteilung des Befehls zu zählen beginnt und nicht erst mit dem Absetzen des Signals.

Ist bei der Firmware von Sidey die Verzögerung beim Starten geringer?

Gibts hierfür vielleicht eine Lösung?

Kannst Du bitte mal ein log Auszug posten mit einem Signalduino verbose 4

Gruß Ralf

[Ralf9]

Hallo Rolf,

ich habe es mir mal angeschaut, mit den folgenden Annahmen:
- die meisten Fernbedienungen senden mit 56 Bit und die ersten 4 Bit sind immer "A"
- die "Telis 6 Chronis RTS" und "TELIS COMPOSIO" senden mit 80 Bit und die ersten 4 Bit sind immer "8"
- die "Telis 4 Mod/Var RTS Pure" senden mit 80 Bit und die ersten 4 Bit sind zwischen 8 und F
- es gibt auch noch einen Windsensor der hat 80 Bit und fängt mit "A" an
- es gibt laut der u.g. Bemerkung angeblich noch eine Fernbedienung wo die ersten 4 Bit zufällig sind, diese würde ich aber nicht berücksichtigen, da diese recht alt ist und niemand bekannt ist der diese hat

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.

damit ist dann der folgende Kompromiss möglich:
a:) Länge <= 60
- wenn die ersten 4 Bit "1010" (A) sind, dann ok
- bei einer Länge von 56 oder 57 wird geprüft ob die ersten 5 Bit "01010" sind, falls ja, dann wird das erste Bit entfernt, bei einer Länge von 56 wird am Ende eine 0 ergänzt
- bei einer Länge von 52 - 55 werden die fehlenden Bits am Anfang zu "A" ergänzt
z.B.

Code Auswählen Erweitern

MC;LL=-1292;LH=1267;SL=-640;SH=638;D=811D1D1672FC88;C=639;L=54;
100000010001110100011101000101100111001011111100100010 (54)
entfernen von Bits am Anfang, damit die Länge 52 wird
0000010001110100011101000101100111001011111100100010 (52)
1010 (A) am Anfang zufügen
10100000010001110100011101000101100111001011111100100010 (56)

b:) für eine Fernbedienung mit 80 Bits
- wenn die die ersten 4 Bit "1010" (A) oder "1000" 8 sind, dann ok
- bei einer Länge von 80 oder 81 wird geprüft ob die ersten 5 Bit "01010" oder "01000" sind, falls ja, dann wird das erste Bit entfernt, bei einer Länge von 80 wird am Ende eine 0 ergänzt
- bei einer Länge von 78 oder 79 Bit wird am Anfang "10" ergänzt (bei 79 Bit wird vorher ein Bit am Anfang entfernt)


c:) damit es auch für die "Telis RTS 1 (vanilla color with 3 grey buttons)" und die "Telis 4 Mod/Var RTS Pure" passt, gibt es neu eine zusätzliche Protocol ID 43.1 die in der whitelist aktiviert werden muss (es ist dafür ein 00_SIGNALduino.pm Modul von mir ab 2021 notwendig)
- bei einer Länge von 57 wird am Anfang ein Bit entfernt
- bei einer Länge von 81 und wenn das erste Bit 0 ist, wird am Anfang ein Bit entfernt
- bei einer Länge > 80 wird hinten auf 80 Bit gekürzt

Das Ergänzen von fehlenden Bits am Ende wird zu aufwändig.

Es sollten damit folgende Besonderheiten berücksichtigt sein:

- Bei der "Telis 4 Mod/Var RTS Pure" sendet die Fernbedienung die Nachrichten zweimal, zuerst mit einer Länge von 81 und dann mit einer Länge von 80.
Bei der ersten Nachricht ist am Ende ein Bit zuviel.
Die Nachrichten fangen immer mit einer Hex Ziffer zwischen 8 und F an.

- Bei der "Telis 6 Chronis RTS" und "TELIS COMPOSIO" ist bei einer Länge von 81 meistens am Anfang ein Bit zuviel

- Bei der Firmware von Sidey kommt es recht häufig vor, daß am Anfang ein Bit zuviel ist, auch wenn die Länge passt (56 oder 80 Bit)

Gruß Ralf

[nagelreo]

Hallo Ralf,

wäre der folgende Kompromiss möglich:
- Bei einer Länge von 57, wird wie gehabt das erste Bit entfernt.
- bei einer Länge von 52 - 55 wird geprüft ob die ersten 4 Bit "A" sind, falls nein, dann werden die fehlenden Bits am Anfang zu "A" ergänzt

Das Ergänzen der ersten 4 Bit auf "A" oder "8" gefällt mir sehr gut. Vermutlich müsste "A" oder "8" über ein Attribut definiert werden.   
Alle meine Fernbedienungen senden am Anfang ein "A". Zur Häufigkeit fehlender Bit am Anfang oder Ende habe ich leider keine Statistik erhoben.

Wie bereits erwähnt, ich würde gerne testen.

Vielen Dank und Gruß
Rolf

[capo]

Hallo,

für wahr, ist schon lange her....
Ich bin mir nicht sicher, ob das neue Attribut mit in die aktuelle Version  von 10_SOMFY.pm übernommen  wurde.
Es gibt zwei Möglichkeiten, das Modul zu ersetzen:
1. Ersetzte einfach im FHEM - Ordner die 10_SOMFY.pm durch die 99_myUtilsSOMFY.pm und verhindere über das global Attribut exclude_from_update  das bei einem Update das Modul überschrieben wird oder
2. die 99_myUtils...pm Module werden als letztes geladen, überschreiben also andere Module, falls die subs die gleichen Namen haben.

Ich hänge Dir mal die Version an, die bei mir derzeit läuft und auch mit den Handsendern funktioniert.


Elektrolurch

Hallo,
ich würde gerne nochmal auf das eigentliche Thema zurückkommen: Abgleich Status/Position von Handsender und SIGNALduino für SOMFY-Rolläden.
Ist es noch richtig, dass die Lösung mit den " associated-devices" nicht in der 10_SOMFY.pm Berücksichtigung gefunden hat, sondern ich mir aus dem Thread eine der Lösungsvarianten aussuchen darf?

VG, capo

[dirk_neujahr@freenet.de]

Hallo !
Die Lösungen scheinen in das offizielle Modul eingeflossen zu sein ! Mit einer Mischung aus Userattribut associated-devices und rawdevice AdressevomRollo scheint es zu funktionieren, ohne dass man von Hand irgendwelche Dateien austauschen muss. So ist zumindest bei mir der Stand, wobei mir haufenweise Fernbedienungen autocreated werden...hatte erst an die Nachbarschaft gedacht, aber so viele Fenster gibt es gar nicht bei denen

VG Dirk

[nagelreo]

Hallo,

Die Lösungen scheinen in das offizielle Modul eingeflossen zu sein ! Mit einer Mischung aus Userattribut associated-devices und rawdevice AdressevomRollo scheint es zu funktionieren, ohne dass man von Hand irgendwelche Dateien austauschen muss. So ist zumindest bei mir der Stand, wobei mir haufenweise Fernbedienungen autocreated werden...hatte erst an die Nachbarschaft gedacht, aber so viele Fenster gibt es gar nicht bei denen

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

[Kawaci]

Hallo, und sorry an @nagelreo das ich erst jetzt antworte!

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.

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

Gruß
Rolf

In meinem letzten post hatte ich noch alte readings drinnen von meinem signalesp! Es funktioniert leider noch immer nicht bzw bin ich noch nicht drauf gekommen warum es nicht funktioniert, ab und zu logt der signalesp die fb und mal nicht!

Hier der log des handsenders!

Code Auswählen Erweitern

2020-07-14_09:23:01 Markise_FB parsestate: off
2020-07-14_09:23:02 Markise_FB parsestate: stop
2020-07-14_09:23:04 Markise_FB parsestate: stop
2020-07-14_09:23:21 Markise_FB parsestate: stop
2020-07-14_09:28:50 Markise_FB parsestate: stop
2020-07-14_09:29:08 Markise_FB parsestate: on
2020-07-14_09:29:11 Markise_FB parsestate: stop
2020-07-14_09:41:28 Markise_FB parsestate: stop
2020-07-14_09:55:57 Markise_FB parsestate: stop
2020-07-14_13:59:09 Markise_FB parsestate: on
2020-07-16_11:11:43 Markise_FB parsestate: off
2020-07-21_19:53:26 Markise_FB parsestate: off
2020-07-24_13:14:05 Markise_FB parsestate: off
2020-07-27_22:10:11 Markise_FB parsestate: off
2020-07-28_12:15:08 Markise_FB parsestate: on
2020-07-29_14:34:27 Markise_FB parsestate: off
2020-07-31_11:26:44 Markise_FB parsestate: on
2020-08-02_12:57:00 Markise_FB parsestate: stop
2020-08-06_13:11:50 Markise_FB parsestate: on
2020-08-06_16:40:14 Markise_FB parsestate: off
2020-08-13_11:43:52 Markise_FB parsestate: stop

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!

Hier die bereinigte Signalesp list

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       Ys5027A7A7FA6899CA002C
   DevState   initialized
   DeviceName 192.168.178.33:23
   FD         112
   FUUID      5c4ffa50-f33f-f967-bdb1-f5f187dcbff9e4ec
   LASTDMSG   Ys5027A7A7FA6899CA002C
   LASTDMSGID 43
   MSGCNT     38375
   NAME       sduino
   NR         41
   NR_CMD_LAST_H 3
   PARTIAL   
   RAWMSG     MC;LL=-1293;LH=1241;SL=-653;SH=620;D=5027A7A7FA6899CA002C;C=634;L=80;R=0;
   RSSI       -74
   STATE      opened
   TIME       1597368613
   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.20
   versionmodul v3.4.4
   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|99|104)#.*
     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|98)#.*
     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+#.*
   OLDREADINGS:
   QUEUE:
   READINGS:
     2020-08-02 08:35:46   cc1101_config   Freq: 433.420 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
     2020-08-02 08:35:46   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2020-08-02 08:35:47   cc1101_patable  C3E = 00 84 00 00 00 00 00 00 => 5_dBm
     2020-07-27 08:12:50   config          MS=1;MU=1;MC=1;Mred=1
     2020-07-27 08:13:16   freeram         41144
     2020-08-14 03:33:18   ping            OK
     2020-08-02 08:35:45   state           opened
     2020-07-27 08:15:14   uptime          5 13:55:56
   XMIT_TIME:
     1597324055
     1597324059
     1597324061
   additionalSets:
   helper:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     43
   msIdList:
   muIdList:
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 43

[nagelreo]

Hallo Kawaci,

poste bitte ein paar MC's (fhem logfile, verbose 4) von erkannten und nicht erkannten Signalen.

Gruß
Rolf

[Kawaci]

sorry aber wie mach ich das?

Hallo Kawaci,

poste bitte ein paar MC's (fhem logfile, verbose 4) von erkannten und nicht erkannten Signalen.

Gruß
Rolf

[nagelreo]

Hallo Kawaci,

- im Sduino den Wert im Attribut verbose von 3 auf 4 erhöhen.
- eine Taste der Fb mehrfach im Abstand von ca. 2 sec drücken.
- den logfile fhem öffnen und die logs der entsprechenden Signale kopieren.

Gruß Rolf