SOMFY Rolladen und Handsender Status bzw. Position abgleichen mit SIGNALduino

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

Vorheriges Thema - Nächstes Thema

Ralf9

Am Anfang der Nachricht ist die folgende Pulsfolge: 2516, -2622, 4828
z.B. 123 wobei P1=2516;P2=-2622;P3=4828

Damit beim Dekodieren der Anfang erkannt werden kann, muss diese Pulsfolge am Anfang sein. Wahrscheinlich sind die Pulse -2622, 4828 am Anfang auch ausreichend.
Bei nicht so guten Empfangsbedingungen kann es vorkommen, daß am Anfang einige Pulse fehlen.

Kannst Du mal mehrere Tastendrücke als MU-Nachrichten posten?
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,

kein Problem, siehe Anhang. Ich hoffe, das Bild ist ok und hilft weiter.
Was interessiert dich am rolling code noch?

Gruß
Rolf

nagelreo

Hallo Ralf9,

vielen Dank.
Die Erkennung vom Start habe ich verstanden und nehme an, dass im ersten Beispiel P4-P7 die Daten Bits sind. Diese werden dann in long low/high und short low/high umgesetzt. Nicht nachvollziehen kann ich den letzten Schritt der Dekodierung, "mapping", "sSlL-Notation".

Ich habe je 10 MU Signale "zu" und "my" generiert.

2020.03.04 23:25:57 4: CUL1: Read, msg READredu: MU;P0=-1308;P1=1266;P2=-650;P3=625;P4=2870;P5=-2590;P7=4816;D=454570101232323032323210321230323232101010101232303232123230323212301032123010323210323;CP=3;R=37;
2020.03.04 23:25:58 4: CUL1: Read, msg READredu: MU;P0=2520;P1=-2628;P2=4828;P3=-1295;P4=1279;P5=-657;P6=617;D=010123434565634365654365436565656543456563434565636565456563656545634365456343656543656;CP=6;R=36;
2020.03.04 23:26:00 4: CUL1: Read, msg READredu: MU;P0=2526;P1=-2642;P2=4832;P3=-1287;P4=1282;P5=-647;P6=628;D=01012343456563656565654365654365656543656543434565636565456563656545634365456343656543656;CP=6;R=38;
2020.03.04 23:26:01 4: CUL1: KeepAlive, ok, retry = 0
2020.03.04 23:26:01 4: CUL1: Read, msg READredu: MU;P0=2548;P1=-2596;P2=4836;P3=-1291;P4=1284;P5=-659;P6=616;D=01012343456345636565436565656565656543654563434565636565456563656545634365456343656543656;CP=6;R=37;
2020.03.04 23:26:02 4: CUL1: Read, msg READredu: MU;P0=2546;P1=-2592;P2=4852;P3=-1281;P4=1285;P5=-655;P6=623;D=1012343456343656565456565656365656565456343434565636565456563656545634365456343656543656;CP=6;R=38;
2020.03.04 23:26:04 4: CUL1: Read, msg READredu: MU;P0=20152;P1=-2624;P2=2488;P3=4824;P4=-1294;P5=1286;P6=-652;P7=614;D=0121345456747654767656767674767676767656767674545676747676567674767656745476567454767654767;CP=7;R=38;
2020.03.04 23:26:05 4: CUL1: Read, msg READredu: MU;P0=-651;P1=630;P2=-4780;P3=2424;P4=-2644;P5=4820;P6=-1287;P7=1277;D=2345676701610101010107010167610101010761076767010161010701016101070167610701676101076101;CP=1;R=36;
2020.03.04 23:26:07 4: CUL1: Read, msg READredu: MU;P0=2598;P1=-2586;P2=4844;P3=-1294;P4=1285;P5=-655;P6=613;D=01012343434565636565456563656565656565434563434565636565456563656545634365456343656543656;CP=6;R=38;
2020.03.04 23:26:08 4: CUL1: Read, msg READredu: MU;P0=2586;P1=-2626;P2=4816;P3=-1289;P4=1284;P5=-654;P6=623;D=010123434345636565654563456365656565654343434565636565456563656545634365456343656543656;CP=6;R=37;
2020.03.04 23:26:10 4: CUL1: Read, msg READredu: MU;P0=4836;P1=-1295;P2=1274;P3=615;P4=-657;D=01212121213434243121343434343434243431212434313434243431343424312134243121343421343;CP=3;R=37;
2020.03.04 23:27:01 4: CUL1: KeepAlive, ok, retry = 0
2020.03.04 23:27:55 4: CUL1: Read, msg READredu: MU;P0=-2700;P1=4788;P2=-1296;P3=1286;P4=628;P5=-655;P6=-22284;P7=2084;D=701232323245453245354245453232323545454545423542354235423542454545354245454532454536;CP=4;R=23;
2020.03.04 23:27:56 4: CUL1: Read, msg READredu: MU;P0=27348;P1=-2580;P2=2532;P3=4812;P4=-1307;P5=1266;P6=637;P7=-653;D=01213454546757645467576454545454675767676764576457645764576467676757646767675467675;CP=6;R=25;
2020.03.04 23:27:57 4: CUL1: Read, msg READredu: MU;P0=1281;P1=624;P2=-654;P3=-5080;P4=2104;P5=-2676;P6=4804;P7=-1291;D=34567070712071207121212021707021707021217070712021212121712071207021217121212121212121;CP=1;R=25;
2020.03.04 23:27:59 4: CUL1: Read, msg READredu: MU;P0=2676;P1=-2624;P2=4836;P3=-1290;P4=1286;P5=618;P6=-654;D=01012343435656434356565643564346534656565653434356465656565356435643465653565656565656565;CP=5;R=25;
2020.03.04 23:28:00 4: CUL1: Read, msg READredu: MU;P0=1286;P1=629;P2=-637;P3=-132;P4=2636;P5=-2638;P6=4816;P7=-1289;D=34545670707121212120712121212070702171212021217070712021212121712071207021217121212121212121;CP=1;R=28;
2020.03.04 23:28:01 4: CUL1: KeepAlive, ok, retry = 0
2020.03.04 23:28:01 4: CUL1: Read, msg READredu: MU;P0=-2666;P1=2452;P2=4824;P3=-1285;P4=1283;P5=-648;P6=623;P7=-23032;D=010234345656565634365656565656543456365456565634343654565656563654365434565636565656565656567;CP=6;R=26;
2020.03.04 23:28:02 4: CUL1: Read, msg READredu: MU;P0=-650;P1=617;P2=-4780;P3=2432;P4=-2648;P5=4788;P6=-1293;P7=1285;D=1234567670101016107610107010167670101016701016767610701010101610761076701016101010101010101;CP=1;R=26;
2020.03.04 23:28:03 4: CUL1: Read, msg READredu: MU;P0=-160;P1=2520;P2=-2632;P3=4812;P4=-1293;P5=1283;P6=-642;P7=632;D=01212345456767454547676567476545676767676767674545476567676767476547654567674767676767676767;CP=7;R=28;
2020.03.04 23:28:04 4: CUL1: Read, msg READredu: MU;P0=-428;P1=2530;P2=-2626;P3=4816;P4=-1300;P5=1292;P6=-647;P7=626;D=012123454567674767654767654545456767476567674545476567676767476547654567674767676767676767;CP=7;R=28;
2020.03.04 23:28:05 4: CUL1: Read, msg READredu: MU;P0=2580;P1=-2616;P2=4828;P3=-1292;P4=1274;P5=-660;P6=618;D=01012343456345634365654365654345656345656563434365456565656365436543456563656565656565656;CP=6;R=27;


Gruß
Rolf

HomeAuto_User

"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

Ralf9

ZitatDie Erkennung vom Start habe ich verstanden und nehme an, dass im ersten Beispiel P4-P7 die Daten Bits sind. Diese werden dann in long low/high und short low/high umgesetzt.
MU;P0=-1308;P1=1266;P2=-650;P3=625;P4=2870;P5=-2590;P7=4816;D=4545701012323230323232103
Die Daten sind:
P0=-1308 long low
P1=1266 long high
P2=-650 short low
P3=625 short high

ZitatIch habe je 10 MU Signale "zu" und "my" generiert.
Du hast sehr gute Empfangsbedingungen, wie Du selber erkennen kannst, ist bei allen MU Nachrichten der Sync (2516, -2622, 4828) am Anfang.

Ich kann bei diesen MU Nachrichten keine erkennen wo was nicht passt.
Ich habe ein paar Stichproben nach MC Nachrichten umgewandelt, sieht alles gut aus.
MC;LL=-1294;LH=1286;SL=-652;SH=614;D=A6E1F851C72CBB;C=640;L=56;R=128;
MC;LL=-1289;LH=1284;SL=-654;SH=623;D=A9E4FD51C72CBB;C=641;L=56;R=128;
MC;LL=-1291;LH=1281;SL=-654;SH=624;D=ADBCA5158368FF;C=641;L=56;R=128;
MC;LL=-1293;LH=1283;SL=-642;SH=632;D=A2B9A0158368FF;C=641;L=56;R=128;
MC;LL=-1292;LH=1274;SL=-660;SH=618;D=A4BBA2158368FF;C=640;L=56;R=128;

Nachtrag:
Bitte schau mal wie oft es vorkommt, daß MU-Nachrichten ohne Sync am Anfang empfangen 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

nagelreo

Hallo zusammen,

HomeAuto_User, vielen Dank für die beiden Links, die haben mir für das Verständnis sehr geholfen. Dennoch habe ich den letzten Schritt der Dekodierung (Umwandlung der Puls-Werte in die Bits) noch nicht ganz verstanden, arbeite aber noch daran.

Ralf, mein Zitat zu den Startwerten P4-P7 bezog sich auf die Daten vom 3.3. 22:15, das passt aber auch zu den von dir erwähnten Daten.
Zu den MU-Nachrichten ohne Sync am Anfang habe ich heute Vormittag (ca. 11 Uhr) 129 Signale generiert. Ca. 3 Stunden davor und danach wurde keine fremden MU-Signale empfangen, daher nehme ich an dass die Signale ausschließlich von meinem RTS stammen.
Im ersten Schritt habe ich die my-Taste (Adresse 97EB96) 5 mal kurz und danach 5 mal länger gedrückt, im zweiten Schritt die FB 3 mal jeweils 5 Sekunden.
Die Anzahl der Signale liegt im Median bei 101 (40 - 207!!!), die Anzahl der Puls-Zeiten P0 bis P7 zwischen 4 (!) und 7. Der "Vorspann" ist ebenfalls in den Extremen sehr unterschiedlich.
Die Bewertung der Sync Werte habe ich mit den Sync-Zeiten 2500, -2500, 4800 durchgeführt, danach sind 110 ok, 17 nicht ok und 2 unklar.
Die Daten sind in der Excel-Datei angehängt.

Gruß
Rolf


Ralf9

Ich habe mir die Nachrichten in der Exceltabelle angesehen, demnach fehlt bei ca 10-15% der Sync am Anfang.

Der Anfang wird auch noch richtig erkannt, wenn die roten Pulse fehlen. In vielen Fällen passt es noch, wenn die roten und der blaue Puls fehlt.
MU;P0=2526;P1=-2642;P2=4832;P3=-1287;P4=1282;P5=-647;P6=628;D=010123434565636565656543656543

Wenn bei Dir bei mehr als ca 10 - 15% der empfangenenen MC-Nachrichten der Anfang nicht passt, kannst Du es auch mit meiner V 3.3.2.1-rc9 versuchen
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Wenn Dir die 10 - 15% zu viel sind, kannst Du mal versuchen ob Du die Empfangsbedingungen verbessern kannst.

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,

vielen Dank.
Im Prinzip könnte ich mit den nicht zuordenbaren Signalen leben. Da dabei aber der rolling code nicht korrigiert wird, werden die nachfolgenden Signale auch nicht mehr zugeordnet (?).

Ich habe den Einfluss folgender Empfangsbedingungen geprüft:
rAmpl, Frequenz, bWidth, Sens und der Entfernung Sender zum Signalduino. Im Vorversuch habe ich die Frequenz vom Somfy-Sender mit einem DAB-DVB-Stick ermittelt, dieser liegt bei 433.47 MHz und am Signalduino indirekt bestätigt (kein Empfang mit 433.420 MHz / 58 KHz, aber mit 433.47 MHz / 58 KHz).
In der Tendenz sehe ich einen Einfluss der Frequenz, der Verstärkung und vermutlich der Entfernung, die Puls-Signale entsprechen nur in wenigen Fällen den Erwartungen, Details siehe Exceltabelle.
Wie bereits erwähnt habe ich keine nennenswerte Probleme beim Steuern der Rollläden. Unklar ist mir, ob der Empfänger von meinem Signalduino defekt ist.


Gruß
Rolf

Ralf9

Wichtig ist eine gute Antenne oder eine nicht so grosse Entfernung und dass es in der Nähe des Signalduino keine Störquellen gibt.
Evtl bringt es auch was den Standort des Signalduino zu verändern.
Was für ein Empfänger hast Du am Signalduino?
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,

ich benutze einen CUL Selbstbau von Schlauhaus mit einem Arduino Nano 3 und einem cc1101.
Die original Antenne ist 6.5 cm, die habe ich heute aufgrund deiner Info durch eine 13 cm Antenne ausgetauscht. Die Signale sind deutlich besser, dennoch gibt es relativ viel fehlerhafte Signale.

Die MU und MC Daten verstehe ich nicht.
Bei den MU Signalen schaut es so aus, als wäre das Problem am Anfang, bei der Erfassung der Sync Daten. Die MC Daten sind wie bereits erwähnt korrekt, wenn am Ende ein Bit (0) ergänzt wird, Detail Exceltabelle


Decodierung enc                   dec
fhem      A8EBF6D94FA433  A8431D2F96EB97  10101000111010111111011011011001010011111010010000110011000 (56) Bit am Anfang entfernt
manuell  A8EBF6D94FA433  A8431D2F96EB97  10101000111010111111011011011001010011111010010000110011000 (56) Bit am Anfang entfernt

fhem      54F2FC642F5A91  54A60E984B75CB  01010100111100101111110001100100001011110101101010010001 (56)
manuell  A9E5F8C85EB522  A94C1D3096EB97 10101001111001011111100011001000010111101011010100100010 (56) Bit am Anfang entfernt,  "0" am Ende angehängt

fhem      55727CE42F5A91  55270E98CB75CB  01010101011100100111110011100100001011110101101010010001 (56)
manuell  AAE4F9C85EB522 AA4E1D3196EB97 10101010111001001111100111001000010111101011010100100010 (56) Bit am Anfang entfernt,  "0" am Ende angehängt

fhem      55F3FD642F5A91  55A60E994B75CB  01010101111100111111110101100100001011110101101010010001 (56)
manuell  ABE7FAC85EB522  AB4C1D3296EB97 10101011111001111111101011001000010111101011010100100010 (56) Bit am Anfang entfernt,  "0" am Ende angehängt

fhem      ACE6FBC85EB522  AC4A1D3396EB97 10101100111001101111101111001000010111101011010100100010000 (56) Bit am Anfang entfernt
manuell  ACE6FBC85EB522  AC4A1D3396EB97 10101100111001101111101111001000010111101011010100100010000 (56) Bit am Anfang entfernt


Gibt es dafür eine Erklärung?

Vielen Dank und Gruß
Rolf

Ralf9

ZitatCUL Selbstbau von Schlauhaus
das verwendete cc1101 sollte passen.
Zitat
Bei den MU Signalen schaut es so aus, als wäre das Problem am Anfang, bei der Erfassung der Sync Daten
Bei allen Nachrichten wo der Syncpuls von ca 4800 am Anfang dabei ist, sollte der Anfang eigentlich richtig erkannt werden.

ZitatDie MC Daten sind wie bereits erwähnt korrekt, wenn am Ende ein Bit (0) ergänzt wird, Detail Exceltabelle
Woher weisst Du ob Du am Ende eine 0 oder eine 1 ergänzen musst?
Ob die Nachricht mit einer 0 oder 1 endet ist abhängig vom enckey (1.Byte der Nachricht) und der Adresse

Ist in der Nähe des sduino evtl eine Störquelle?
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,

die MU Signale kann ich leider noch nicht in den Hex Code umwandeln. Auf Basis der Statistik werden aber auch Signale ohne ca. 4800 beim Anfangs-Puls richtig erkannt.

Zur Dekodierung der MC Signale (Bits) habe ich mir ein Excel-Tool gebastelt (Anhang). Damit werden die Bits aus der MC Nachricht in den Hex-Code umgewandelt und mit dem enc dekodiert. Im Tool kann das Start-Bit variiert und natürlich auch ein Bit angehängt werden. "0" oder "1" entscheide ich über die ermittelte Adresse, die muss richtig sein. Dass die restlichen Bits korrekt sind, wird zusätzlich durch den ermittelten ctrl und rolling code belegt.

Gibt es eine Möglichkeit die MU und MC parallel auszugeben?

Die Störquelle bzw. den Einfluss vom Standort des Empfängers prüfen ich Anfang der Woche.

Gruß
Rolf

Ralf9

ZitatAuf Basis der Statistik werden aber auch Signale ohne ca. 4800 beim Anfangs-Puls richtig erkannt.
siehe:
ZitatDer Anfang wird auch noch richtig erkannt, wenn die roten Pulse fehlen. In vielen Fällen passt es noch, wenn die roten und der blaue Puls fehlt.
MU;P0=2526;P1=-2642;P2=4832;P3=-1287;P4=1282;P5=-647;P6=628;D=010123434565636565656543656543

ZitatZur Dekodierung der MC Signale (Bits) habe ich mir ein Excel-Tool gebastelt (Anhang). Damit werden die Bits aus der MC Nachricht in den Hex-Code umgewandelt und mit dem enc dekodiert. Im Tool kann das Start-Bit variiert und natürlich auch ein Bit angehängt werden. "0" oder "1" entscheide ich über die ermittelte Adresse, die muss richtig sein. Dass die restlichen Bits korrekt sind, wird zusätzlich durch den ermittelten ctrl und rolling code belegt.

Dies müsstest Du jetzt nur noch in die sub SOMFY_Parse vom SOMFY Modul integrieren.

ZitatGibt es eine Möglichkeit die MU und MC parallel auszugeben?
Ja beim selbst compilieren der firmware gibts dafür Debug Optionen. Du kannst aber davon ausgehen, daß die MC passt, wenn die ca. 4800 am Anfang dabei 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

nagelreo

Hallo Ralf,

vielen Dank für die Rückmeldung.

ZitatDies müsstest Du jetzt nur noch in die sub SOMFY_Parse vom SOMFY Modul integrieren.

Leider funktioniert das nicht, da mir kein Algorithmus dazu einfällt und ich mich nicht in die sub SOMFY_Parse integrieren kann und will ;D.
Die Versuche zu Störquellen und Standort haben auch keine neuen Erkenntnisse gebracht.

Zwischenzeitlich habe ich meinen DAB-DBV-T Stick mit der Software von Universial Radio Hacker eingerichtet und Nachrichten parallel zum Signalduino mit geschnitten und ausgewertet.
Die Nachrichten (Bits) sind 100 % identisch zu denen vom Signalduino/Fhem (Anhang Excel-Datei). Das gilt für fehlerhafte und korrekte Nachrichten. Bei den fehlerhaften Nachrichten fehlt nach wie vor nur das letzte Bit (56). Das Ergebnis "my-Taste fehlerhaft" und "down-Taste ok" ist zufällig und lies sich nicht reproduzieren.

Als Fazit schließe ich, dass meine Hardware (Signalduino und Rasp-3) ok ist.
Bezüglich dem Demodulieren bin ich mir nicht sicher, da ich die beiden Algorithmen nicht kenne. Wenn diese identisch sind, ist das Ergebnis vermutlich auch gleich.

Bleibt nur der Sender (?).
Wenn ja, warum wird das Signal vom Somfy-Rollo erkannt?
Ich werde noch weitere Handsender prüfen.
Hat jemand noch eine Idee?

Vielen Dank und Gruß
Rolf

nagelreo

Hallo Ralf,

zum Algorithmus habe ich doch eine Idee, die funktionieren könnte.
Bei den nicht erkannten Codes fehlt ein Bit, 56 anstatt 57. Soweit ich mich erinnere und was ich erwarte, stimmt in allen Fällen die cks nicht, das muss ich aber noch überprüfen. Dann hängt man das Bit 0 oder 1 an und prüft die cks. Wenn diese stimmt, müsste die Adresse korrekt sein.

Da ich mit Perl/Linux noch nicht so vertraut bin, dauert das etwas.

Gruß
Rolf