search

RFD-FHEM / RFFHEM

Counterpart of SIGNALDuino, it's the code for FHEM to work with the data received from the uC
GNU General Public License v3.0
44 stars 33 forks source link

Protokoll für Mandolyn Funksteckdosen Set #716

Closed codeartisan-de closed 4 years ago

codeartisan-de commented 4 years ago

Specifications for new sensor / switch / or other device ...

IMG_20191214_005607 IMG_20191214_005537 IMG_20191214_005546

Uraltes Funksteckdosenset, das ich hier liegen hatte und bisher mit einem angepassten rc-switch Arduino Uno einsetze.

rc-switch: https://github.com/sui77/rc-switch Anpassung für Mandolyn: https://github.com/codeartisan-de/rc-switch/commit/379859cff87a3ce7bf99fa00107036056c93a54f

Specifications

File Rev Last Change

fhem.pl 20651 2019-12-03 08:39:54Z rudolfkoenig 98_autocreate.pm 19372 2019-05-11 15:13:59Z rudolfkoenig 14_CUL_TCM97001.pm 19762 2019-07-02 19:21:52Z bjoernh 91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig 01_FHEMWEB.pm 20540 2019-11-19 08:25:23Z rudolfkoenig 92_FileLog.pm 20537 2019-11-18 21:28:30Z rudolfkoenig 98_help.pm 19915 2019-07-29 20:01:16Z betateilchen 91_notify.pm 19374 2019-05-11 17:48:03Z rudolfkoenig 14_SD_Keeloq.pm 32 2019-08-31 12:00:00Z v3.4-dev_02.12. 00_SIGNALduino.pm 19857 2019-07-19 18:00:16Z Sidey 90_SIGNALduino_un.pm 19858 2019-07-19 18:16:55Z Sidey 10_SOMFY.pm 15807 2018-01-06 23:32:41Z viegener 99_SUNRISE_EL.pm 18732 2019-02-25 13:15:34Z rudolfkoenig 98_SVG.pm 20537 2019-11-18 21:28:30Z rudolfkoenig 98_update.pm 20600 2019-11-26 18:07:13Z rudolfkoenig 99_Utils.pm 18920 2019-03-16 09:58:52Z rudolfkoenig 98_version.pm 15140 2017-09-26 09:20:09Z markusbloch

AttrTemplate.pm 20425 2019-10-30 08:33:31Z rudolfkoenig Blocking.pm 17553 2018-10-17 15:56:35Z rudolfkoenig DevIo.pm 20174 2019-09-16 18:04:03Z rudolfkoenig GPUtils.pm 19666 2019-06-20 11:17:29Z CoolTux HttpUtils.pm 20375 2019-10-17 22:52:43Z rudolfkoenig RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert No Id found for SD_ProtocolData.pm No Id found for SD_Protocols.pm SetExtensions.pm 19208 2019-04-17 19:27:09Z rudolfkoenig TcpServerUtils.pm 19138 2019-04-07 10:17:21Z rudolfkoenig

f18.js 20069 2019-08-27 08:36:02Z rudolfkoenig fhemweb.js 20554 2019-11-20 20:53:04Z rudolfkoenig svg.js 19667 2019-06-20 13:39:55Z rudolfkoenig

Logs

Logs für 3 mal kurze Zeit einige der Tasten gedrückt. Taste siehe Dateiname - also 1 bzw. 2 Ein bzw. Aus.

MANDOLYN.1.EIN.txt MANDOLYN.1.AUS.txt MANDOLYN.2.EIN.txt MANDOLYN.2.AUS.txt

in rc-switch: Protokoll 7 20bit

1.Ein Code: 00000000000000010001 1.Aus: Bekomme ich nicht gelesen. Defekt? 2.Ein Code: 00000000000010010011 2.Aus Code: 00000000000010000010

codeartisan-de commented 4 years ago

Hallo.

Ich habe erst mal versucht im Ticket das nötigste auf die Schnelle anzugeben. Wenn mehr Logs/Bilder/Infos nötig sind schaue ich gerne was ich hin bekommen. Mit rc-switch hab ich das Set vor 3 Jahren irgendwie zum laufen bekommen. Mit FHEM / Perl hab ich aber keine Ahnung und wüsste nicht wo ich anfangen sollte.

HomeAutoUser commented 4 years ago

Guten Morgen @codeartisan-de, danke für das Ticket.

Du kannst gern mal bitte update all https://raw.githubusercontent.com/HomeAutoUser/RFFHEM/dev-r34_Mandolyn/controls_signalduino.txt versuchen und danach ein shutdown restart vornehmen.

Dann bitte noch im Empfänger das Protokoll 97 aktivieren und schon solltest du beim Empfang ein Device u54 erhalten. ist das so?

Edit: kannst du die Remote aufschrauben ohne Schaden zu machen? Wenn ja, wären 2 Bilder vom Inneren noch interessant.

codeartisan-de commented 4 years ago

Cool, das ging ja fix. Update ging. Dann bekomme ich auch

2019.12.14 12:55:56 4: sduino: Read, msg READredu: MU;P0=10280;P1=-642;P2=1256;P3=-1280;P4=610;P5=-15180;D=012121212121212121212121212121234121212345;CP=2;R=40;
2019.12.14 12:55:56 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 12:55:56 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 12:55:56 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 12:55:56 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 12:55:56 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 12:55:56 4: sduino: Parse_MU, Decoded matched MU Protocol id 54 dmsg u54#FFFEE length 20 dispatch(1/4) RSSI = -54
2019.12.14 12:55:57 4: SIGNALduino_unknown incomming msg: u54#FFFEE
2019.12.14 12:55:57 4: SIGNALduino_unknown rawData: FFFEE
2019.12.14 12:55:57 4: SIGNALduino_unknown Protocol: 54
2019.12.14 12:55:57 4: SIGNALduino_unknown converted to bits: 11111111111111101110
2019.12.14 12:55:57 4: SIGNALduino_unknown sduino Protocol:54 | To help decode or debug, please add u54! (attr sduino development u54)
2019.12.14 12:55:57 4: Unknown, please report
2019.12.14 12:55:57 3: sduino: Unknown code u54#FFFEE, help me!

Dann bitte noch im Empfänger das Protokoll 97 aktivieren

Was is gemeint mit aktivieren und wirklich 97?

Ich habe gemacht attr sduino development u54 und damit eine Device bekommen SIGNALduino_unknown_54

2019.12.14 13:04:03 4: sduino: Read, msg READredu: MU;P0=606;P1=-645;P2=28488;P3=-340;P4=5048;P6=1249;P7=-1284;D=12341616161616161616161616161616167016161670;CP=6;R=37;
2019.12.14 13:04:03 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 13:04:03 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 13:04:03 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 13:04:03 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 13:04:03 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 13:04:03 4: sduino: Parse_MU, Decoded matched MU Protocol id 54 dmsg u54#FFFEE length 20 dispatch(1/4) RSSI = -55.5
2019.12.14 13:04:03 4: SIGNALduino_unknown incomming msg: u54#FFFEE
2019.12.14 13:04:03 4: SIGNALduino_unknown rawData: FFFEE
2019.12.14 13:04:03 4: SIGNALduino_unknown Protocol: 54
2019.12.14 13:04:03 4: SIGNALduino_unknown converted to bits: 11111111111111101110
2019.12.14 13:04:03 1: sduino: SIGNALduino_unknown UNDEFINED sensor SIGNALduino_unknown_54 detected
2019.12.14 13:04:03 2: autocreate: define SIGNALduino_unknown_54 SIGNALduino_un SIGNALduino_unknown_54
2019.12.14 13:04:03 2: autocreate: define FileLog_SIGNALduino_unknown_54 FileLog ./log/SIGNALduino_unknown_54-%Y.log SIGNALduino_unknown_54
2019.12.14 13:04:03 4: sduino: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate

Richtig soweit?

codeartisan-de commented 4 years ago

kannst du die Remote aufschrauben ohne Schaden zu machen? Wenn ja, wären 2 Bilder vom Inneren noch interessant.

Das hatte ich befürchtet. War nur zu faul ;-)

IMG_20191214_131920 IMG_20191214_131938

elektron-bbs commented 4 years ago

Leider nur ein Klecks auf dem Chip :-( Aber, ich denke, das Protokoll ist eh schon eingebaut :-) Wir haben bereits Protokoll 34 für diese Fernbedienung:

comment => 'remote control DMV-7000, TR-502MSV',

Dort müsste nur "start" auskommentiert werden, dann sollte diese FB funktionieren. Allerdings gab es da irgendein Problem: https://github.com/RFD-FHEM/RFFHEM/issues/195#issuecomment-442923650

Auch Protokoll 31 sieht dem verdammt ähnlich. Wenn ich dort "start" auskommentiere, wird es auch dekodiert.

HomeAutoUser commented 4 years ago

Dort müsste nur "start" auskommentiert werden, dann sollte diese FB funktionieren. Allerdings gab es da irgendein Problem: #195 (comment)

Das ist ja der Knackpunkt und einfach herausnehmen wäre nur auf Verdacht denke ich.

Auch Protokoll 31 sieht dem verdammt ähnlich. Wenn ich dort "start" auskommentiere, wird es auch dekodiert.

Maximal bei Protokoll 31 könnte ich "einknicken" weil es dort definiv nichts mehr vom User gibt.

elektron-bbs commented 4 years ago

Mhmm, willst du dann 3 Definitionen für ein Protokoll drin lassen? Die Nachrichten aus https://github.com/RFD-FHEM/RFFHEM/issues/44 werden mit dieser Defintion auch dekodiert:

            name                    => 'QUIGG | LIBRA',
            comment             => 'remote control DMV-7000, TR-502MSV',
            id                      => '34',
            knownFreqs      => '433.92',
            one                     => [-1,2],
            zero                    => [-2,1],
            pause                   => [-15],   # 9900
            clockabs            => 600,
            reconstructBit  => '1',
            format              => 'twostate',
            preamble            => 'P34#',
            clientmodule    => 'SD_UT',
            length_min      => '19',
            length_max      => '20',

Das Problem ist wieder mal das der SIGNALduino immer wieder verschiedene Nachrichten aus den Protokollen macht. Mal ist es MS, mal MU, mal ist der Start vorn im Datenstring, mal hinten, mal trennt er die Nachrichten mit Wiederholungen, mal nicht.... :-(

HomeAutoUser commented 4 years ago

Mhmm, willst du dann 3 Definitionen für ein Protokoll drin lassen?

Die Frage ist, wollen wir in Kauf nehmen, ob mit Änderung der Definition es wo anders nicht mehr geht bei einem User. Es könnte ja sein, das diese Remote etwas abweichend sendet. Überall wo wir nur den "schwarzen Klecks" sehen, bewegen wir uns da auf einem Grad.

elektron-bbs commented 4 years ago

So richtig sicher bin ich mir jetzt auch nicht mehr. Ich glaube, wir mussten "start => [1]" einfügen, damit das Senden funktioniert, weil unsere Bit-Defintionen ja mit Low-Pegel beginnen: one => [-1,2]

Was mich wundert, sind die Unterschiede der Pausenzeiten hier: -8888, -11376, -9600 u.s.w. Auch das die Nachrichten so unregelmäßig zerstückelt kommen (Länge schwankt zwischen 40 bis 50 Zeichen) scheint mir eigenartig.

@codeartisan-de Setz mal bitte deinen SIGNALduino auf Standardeinstellungen (set sduino raw e) zurück und poste dann noch einmal Logs.

HomeAutoUser commented 4 years ago

@elektron-bbs

So richtig sicher bin ich mir jetzt auch nicht mehr. Ich glaube, wir mussten "start => [1]" einfügen, damit das Senden funktioniert, weil unsere Bit-Defintionen ja mit Low-Pegel beginnen: one => [-1,2]

Ich glaube das war so. Wir hatten lange hin und her probiert und überlegt.

@bismosa. besitzt du noch die QUIGG DMV-7000 ?

bismosa commented 4 years ago

Hallo! Jup...immer noch 4 Stück im Betrieb :)

Wie kann ich helfen?

Gruß Bismosa

HomeAutoUser commented 4 years ago

Das ging ja fix. Könntest du mal bitte die FW und das Modul auf die aktuelle Versionen updaten und danach uns nochmal Nachrichten von deinen QUIGG DMV-7000 zur Verfügung stellen.

@codeartisan-de hat ähnliche, welche vermutlich das selbe Protokoll besitzen aber dafür müssten wir das nochmal prüfen.

bismosa commented 4 years ago

Hallo! Sitze gerade am Rechner :) Aktuelle Version = https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt ?

HomeAutoUser commented 4 years ago

Jop diese. Welche FW nutzt du bei deinem Empfänger?

Sollte das alles aktuell sein, so haben wir eindeutigere "Vergleiche".

bismosa commented 4 years ago

FW: version: V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56 Habe nun diese V 3.4.0-dev SIGNALduino cc1101 (chip CC1101) - compiled at Dec 4 2019 22:02:15 Nachdem ich nun die FB wiedergefunden habe, musste ich feststellen, das diese nicht mehr geht. :( Schon damals waren Batterien ausgelaufen...das hat sich nun wohl so weit durchgefressen, das irgendwas anderes kaputt gegangen ist. Selbst mit einer externen Spannungsversorgung bin ich da nichts mehr geworden :( Sehr schade. Das einzige was ich nun dazu sagen kann ist: Empfangen tun die Steckdosen mit der aktuellen Version gut.

Sorry. Gruß Bismosa

codeartisan-de commented 4 years ago

Hallo @elektron-bbs & @HomeAutoUser

[...] Bit-Defintionen ja mit Low-Pegel beginnen [...]

Dabei fällt mir die Besonderheit ein die ich schon beim rc-switch beachten musste. Das Ding hat wohl ein invertiertes Singnal (invertedSignals = true in der Protokoll Def). Sprich startet Low. Wie ihr offensichtlich auch schon selber bemerkt habt ;-)

Ausserdem habe ich gerade gesehen das die eingecheckt Version im GitHub nicht die aktuellste ist mit der ich das Ding einsetze. Ich habe die pulseLength lokal auf 636 stehen (statt 650).

Setz mal bitte deinen SIGNALduino auf Standardeinstellungen (set sduino raw e) zurück und poste dann noch einmal Logs.

Und dabei fällt mir ein, das ich vergessen habe zu erwähnen, das ich 2 Werte angepasst habe bevor ich überhaubt eine Ausgabe für die FB bekommen habe.

ccconf | freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud) bWidth auf 464KHz von 325 sens auf 8dB von 4

Ich setze es aber gleich mal zurück und stelle die Werte einzeln hoch, um zu sehen welcher relevant war. Poste dann hier nochmal aus dem Log.

codeartisan-de commented 4 years ago 
2019.12.14 19:44:30 4: sduino: Set, raw e
2019.12.14 19:44:31 4: sduino: Read, msg: ccFactoryReset done
2019.12.14 19:44:31 4: sduino: HandleWriteQueue, nothing to send, stopping timer

get sduino ccconf ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud, Modulation:ASK/OOK)

Mhh, sens scheint er nicht zurück zu setzen. Aber jetzt ich bekomme auch keine Ausgabe mehr vom sduino für die FB. War also doch bWidth anzupassen.

2019.12.14 19:49:08 3: sduino: Set, Setting AGCCTRL0 (1D) to 90 / 4 dB
2019.12.14 19:50:36 4: sduino: Read, msg: C10 = 57
2019.12.14 19:50:36 3: sduino: parseResponse, bWidth: Setting MDMCFG4 (10) to 37 = 464 KHz

ccconf: freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:ASK/OOK)

Jetzt kommt wieder was. Taste 1.Ein:

2019.12.14 19:53:07 4: sduino: Read, msg READredu: MU;P0=328;P1=-656;P2=1262;P3=-1284;P4=590;P5=-3132;P6=132;P7=-4740;D=12121212121212121212121212121234121212345670;CP=2;R=18;
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Decoded matched MU Protocol id 54 dmsg u54#FFFEE length 20 dispatch(1/4) RSSI = -65
2019.12.14 19:53:07 4: SIGNALduino_unknown incomming msg: u54#FFFEE
2019.12.14 19:53:07 4: SIGNALduino_unknown rawData: FFFEE
2019.12.14 19:53:07 4: SIGNALduino_unknown Protocol: 54
2019.12.14 19:53:07 4: SIGNALduino_unknown converted to bits: 11111111111111101110
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 71 -> PEARL matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Read, msg READredu: MU;P0=-668;P1=-1300;P2=606;P3=-2184;P5=1234;P6=1636;P7=-272;D=05050675050505050505050505050512050505123;CP=5;R=21;
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 71 -> PEARL matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Read, msg READredu: MU;P0=876;P1=-647;P2=1247;P4=-1290;P5=600;P6=-29440;D=01212121212121212121212121212121245121212456;CP=2;R=21;
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 71 -> PEARL matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Read, msg READredu: MU;P0=-1032;P1=-184;P2=812;P3=-640;P4=1249;P5=-1340;P6=610;P7=-25968;D=2343434343434343434343434343434563434345672025212;CP=4;R=26;
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 19 -> minify matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 20 -> xavax matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Decoded matched MU Protocol id 54 dmsg u54#FFFEE length 20 dispatch(1/4) RSSI = -61
2019.12.14 19:53:07 4: sduino: Dispatch, u54#FFFEE, Dropped due to short time or equal msg
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 71 -> PEARL matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2019.12.14 19:53:07 4: sduino: Parse_MU, Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Read, msg READredu: MU;P0=610;P1=-336;P2=1250;P3=-646;P4=-1290;D=0123232323232323232323232323232324032323240;CP=2;R=34;
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 19 -> minify matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 54 -> Mandolyn matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Decoded matched MU Protocol id 54 dmsg u54#FFFEE length 20 dispatch(1/4) RSSI = -57
2019.12.14 19:53:08 4: sduino: Dispatch, u54#FFFEE, Dropped due to short time or equal msg
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 71 -> PEARL matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2019.12.14 19:53:08 4: sduino: Parse_MU, Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
sidey79 commented 4 years ago

Der Sender sendet wohl nicht auf 433.92 MHz. Entweder weiter oben oder weiter unten. Mit der breiteren Bandbreite erhöhst Du das spektrum. Die Bandwirth sollte auch mit dem Default wert klappen, wenn Du die Frequenz ein kleines bisschen anpasst. In welche richtung geht nur über probieren.

HomeAutoUser commented 4 years ago

@elektron-bbs ich habe nochmal überlegt und würde folgendes vorschlagen. Da von @codeartisan-de die TR-502MSV anders dekodiert wird, aber wir nicht wissen oder herausbekommen werden woran es liegt, so schlage ich vor, es als 34.1 einzufügen.

So würden wir die alte Def unangetastet lassen und wir stellen die Def´s direkt untereinander dar und so stellen wir auch die kompatiblität her zur bisherigen "34" Usern welche damals zufrieden waren.

HomeAutoUser commented 4 years ago

@codeartisan-de bitte erstelle mal noch mehr RAWMSG bitte. Feuerfrei ;-) es können ruhig auch 20 Stück sein um die Erkenntnis zu festigen.

elektron-bbs commented 4 years ago

Das wäre vieleicht eine Variante. Ich hatte überlegt, das wir start in der Definition weglassen und dann den Sendebefehl selbst zsammen basteln und dann ein "IOWrite($hash, 'raw', $msg);" zum Senden verwenden. Das Problem ist ja nur, das 21 Pulse gesendet werden müssen, wir aber nur 20 Bit verwenden. In den Logikanalysen in https://github.com/RFD-FHEM/RFFHEM/issues/44#issuecomment-156842845 ist das gut zu sehen.

Ich habe übrigens, wie auch @codeartisan-de als clockabs 635 errechnet. 600 scheint mir zu knapp, in den Logikdaten ist es immer so um die 660 herum.

Wir haben damals einen Fehler gemacht. Wir hätten die Daten invertieren sollen. Auf der Seite https://github.com/d-a-n/433-codes/blob/master/database.md#quigg habe ich eine gute Beschreibung der Bits gefunden und mal eine ältere Excel-Tabelle von uns damit aktualisiert: QUIGG_DMV-7000.xlsx

Falls du mit dem Modul beginnst, verwende bitte gleich meine Änderungen aus diesem Branch: https://github.com/RFD-FHEM/RFFHEM/tree/dev-r34_SD_UT-RC_10

codeartisan-de commented 4 years ago

@HomeAutoUser

bitte erstelle mal noch mehr RAWMSG

Richtige RAW msg "Read, RAW rmsg: ", also mit verbose = 5? Oder reichen euch die normalen wie bisher "Read, msg READredu:"? Und reicht es von ein bis zwei Tasten oder lieber möglicht viele verschiedene Tasten verwenden?

Ich schau mal wie ich dazu komme. Kann sein das es heute Abend wird. Hab immer nur kurz Zeit am Rechner.

HomeAutoUser commented 4 years ago

@elektron-bbs, als ersten Schritt sehe ich noch nicht, das wir am Modul was machen müssen. (Senden mal ausgenommen).

Ich habe eine zusätze Def 34.1 mal genommen und diese auch sofort an SD_UT weitergeleitet und schon erhalte ich die Taste :-) Das würde erstmal, schon @codeartisan-de zum testen der Tasten reichen. Wenn er das OK gibt, so könnten wir wegen dem Senden nochmal überlegen. Was meinst du?

Falls du mit dem Modul beginnst, verwende bitte gleich meine Änderungen aus diesem Branch: https://github.com/RFD-FHEM/RFFHEM/tree/dev-r34_SD_UT-RC_10

Ich würde vor Erweiterung oder Umschreiben des Modules, den Patch von Dir erstmal übernehmen separat, das dieser nicht untergeht.

@codeartisan-de, verbose 4 sollte uns reichen. Danke :-)

Edit: @elektron-bbs, mir ging gerade durch den Kopf und auch der Test zeigte, wenn ich die Daten in der Def 34.1 annehme und an SD_UT weiterleite, so kommen sie mit der richtigten Taste an und auch das senden zu einem anderen Empfänger ging ohne Mod des Modules.

elektron-bbs commented 4 years ago

Das Senden von Dimm-Befehlen hatten wir sicher noch gar nicht vorgesehen.

Wenn mit P34 gesendet wird, sollte das Senden von on/off eigentlich funktionieren.

Einen Haken hat die Variante sicher noch: Die Pakete, die mit P34 dekodiert werden, laufen sicher auch nochmal mit P34.1 durch. Das ist zwar unschön, dürfte aber auch nicht weiter stören.

codeartisan-de commented 4 years ago

So, hab den Mittagsschlaf mal sinnvoll genutz und ein Paar Codes zu Tasten 1 & 2 gesammelt.

Ich hab das attr comment "missbraucht" um die Taste mit ins Log zu schreiben. Ihr findet im Log immer eine Zeile der Form sduino: Attr, Calling sub with args: set comment = Mandolyn Taste 1 EIN und dann folgen die Einträge für diese Taste. Kann aber leider nicht ausschließen, das ab und zu ein anderes Gerät dazwischen gefunkt hat. Tagsüber ist irgendwie ganz schön was los auf dem Band hier. Samstagnacht war das Log wesentlich ruhiger.

Mandolyn.log

@HomeAutoUser, reichen die 4 Tasten erstmal oder soll ich für die anderen auch noch was sammeln?

Übrigens sehe ich gerade, das P34 auch recht häufig anschlägt! 2019.12.15 13:14:51 4: sduino: Parse_MU, Decoded matched MU Protocol id 34 dmsg P34#FFF7D length 20 dispatch(1/4) RSSI = -54 Das war mir vorher garnicht aufgefallen?! Ich hab jetzt auch ein Gerät SD_UT unknown_please_select_model im FHEM. Das war gestern noch nicht da. Soll ich damit mal weiter probieren? Und was kann/muss ich da machen? Mit Protokoll 31 hat er auch 2 mal was erkannt.

HomeAutoUser commented 4 years ago

Einen Haken hat die Variante sicher noch: Die Pakete, die mit P34 dekodiert werden, laufen sicher auch nochmal mit P34.1 durch. Das ist zwar unschön, dürfte aber auch nicht weiter stören.

Ich habe es soeben mal getestet:

2019.12.15 13:38:34 4: sduino_dummy: msg get raw: MU;P0=-9832;P1=577;P2=-670;P3=1219;P4=-1331;D=012341412323232341412341414123234123234141;CP=1;R=16;
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 5 -> Unitec matches, trying to demodulate
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 31 -> Pollin ISOTRONIC matches, trying to demodulate
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Decoded matched MU Protocol id 31 dmsg u31#9E46C length 20 dispatch(1/10) RSSI = -66
2019.12.15 13:38:34 4: SIGNALduino_unknown incomming msg: u31#9E46C
2019.12.15 13:38:34 4: SIGNALduino_unknown rawData: 9E46C
2019.12.15 13:38:34 4: SIGNALduino_unknown Protocol: 31
2019.12.15 13:38:34 4: SIGNALduino_unknown converted to bits: 10011110010001101100
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA matches, trying to demodulate
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Decoded matched MU Protocol id 34 dmsg P34#9E46C length 20 dispatch(1/10) RSSI = -66
2019.12.15 13:38:34 4: sduino_dummy: SD_UT protocol 34, bitData 10011110010001101100, hlen 5
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 34.1 -> Mandolyn matches, trying to demodulate
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Decoded matched MU Protocol id 34.1 dmsg P34#9E46C length 20 dispatch(1/10) RSSI = -66
2019.12.15 13:38:34 4: sduino_dummy: Dispatch, P34#9E46C, Dropped due to short time or equal msg
2019.12.15 13:38:34 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 50 -> Opus_XT300 matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 63 -> Warema matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 71 -> PEARL matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2019.12.15 13:38:35 4: sduino_dummy: Parse_MU, Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate

Ja es ist so aber sollte ja bei gleichen Ergebnis auch keine Rolle spielen. Es handelt sich ja um das "Gleiche".

Somit wäre der Weg frei, um von @codeartisan-de das zu integrieren und ab sofort sollte er dann im SD_UT das model TR_502MSV wählen und kann walten.

Was mit dabei gerade auffiel wo du auch schonmal geschaut hattest. Protokoll 31 ist ähnlich und ist bei uns als u definiert. Dem würde ich als development => y verpassen wollen, da es bei manchen Nachrichten ebenso von Def 34 ansprechen könnte. Von dem Protokoll haben wir auch nie eine Rückmeldung erhalten. Somit minimieren wir erneut Anfragen.

HomeAutoUser commented 4 years ago

Übrigens sehe ich gerade, das P34 auch recht häufig anschlägt!

@codeartisan-de perfekt würde ich mal sagen und das deckt sich mit dem was ich soeben schrieb. Device 34 SD_UT_unknown ist dein Gerät der Remote. Dort bitte mal das Model TR_502MSV auswählen und erneut die selbe Taste drücken. Ab sofort solltest du dort die Zustände erhalten ung ggf. auch senden können.

Mit Protokoll 31 hat er auch 2 mal was erkannt.

Ja, das ist ähnlich und wir werden es vermutlich auf Entwicklerstatus setzen, somit sollte dich das nicht interssieren.

EDIT: Wenn das funktioniert, dann mache bitte noch einmal update force https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt und teste erneut. Somit hättest du die letzte Entwicklerversion und wir müssten für deine Remote keine Definition anlegen weil diese auf ID 34 eintrifft.

elektron-bbs commented 4 years ago

Vieleicht hat sich das mit den 2 Definitionen jetzt schon von selbst erledigt. Wenn ich mir das Log Mandolyn.log von eben ansehe, findet eine Suche nach "dmsg u54" 45 Treffer und nach "dmsg P34" 50.

Protokoll 31 kann weg, das wird dann ab sofort mit P34 erledigt.

elektron-bbs commented 4 years ago

@HomeAutoUser Du müsstest dann eigentlich nur die Dimm-Befehle ergänzen:

1 EIN 00010001 1 AUS 00000000 1 HELL 00001010 1 DUNKEL 00011011 2 EIN 10010011 2 AUS 10000010 2 HELL 10001000 2 DUNKEL 10011001 3 EIN 11010010 3 AUS 11000011 3 HELL 11001001 3 DUNKEL 11011000 4 EIN 01010000 4 AUS 01000001 4 HELL 01001011 4 DUNKEL 01011010 ALLE EIN 11110000 ALLE AUS 11100001

Quelle: https://github.com/d-a-n/433-codes/blob/master/database.md#quigg

ACHTUNG - die Bits müssen invertiert werden!

codeartisan-de commented 4 years ago

@HomeAutoUser

Dort bitte mal das Model TR_502MSV auswählen [...]

Okay, hab ich gefunden (attr model). Am besten immer für Noobs beschreiben. Ich bin noch ganz neu bei FHEM und schaue es mir an um meine SOMFY via SIGNALduino anzubinden. Jetzt versuche ich halt gleich mal, ob ich die Funkdosen nicht auch damit hin bekommen kann.

Jedenfalls empfängt er jetzt alle Tasten. Aber die Erkennungsrate scheint mir - zumindest bei einigen Tasten - ein ganzes Stück schlechter als bei meiner rc-switch Lösung. Die hat gleichzeitig schneller und häufiger Werte geworfen. SIGNALduino und rc-switch hängen am selben Raspi, sind also etwa gleich weit weg. Könnte natürlich auch an FHEM vs. OpenHab (das steuert den rc-switch) liegen. Aber schauen wir mal weiter.

Das mit dem Update und Senden versuche ich später. Mittagsschlaf ist schon wieder zuende ;-)

HomeAutoUser commented 4 years ago

@elektron-bbs 

    "TR_502MSV" =>  {   "11101110"  => "Ch1_on",
                                        "11111111"  => "Ch1_off",
                                        "01101100"  => "Ch2_on",
                                        "01111101"  => "Ch2_off",
                                        "10101111"  => "Ch3_on",
                                        "10111110"  => "Ch3_off",
                                        "00101101"  => "Ch4_on",
                                        "00111100"  => "Ch4_off",
                                        "00001111"  => "Master_on",
                                        "00011110"  => "Master_off",
                                        "00010100"  => "dim_up",                # after Master on/off
                                        "00000101"  => "dim_down",          # after Master on/off
                                        "11110101"  => "Ch1_dim_up",        # after CH1 on/off
                                        "11100100"  => "Ch1_dim_down",  # after CH1 on/off
                                        "01110111"  => "Ch2_dim_up",        # after CH2 on/off
                                        "01100110"  => "Ch2_dim_down",  # after CH2 on/off
                                        "10110100"  => "Ch3_dim_up",        # after CH3 on/off
                                        "10100101"  => "Ch3_dim_down",  # after CH3 on/off
                                        "00110110"  => "Ch4_dim_up",        # after CH4 on/off
                                        "00100111"  => "Ch4_dim_down",  # after CH4 on/off
                                        hex_lengh       => "5",
                                        Protocol        => "P34",
                                        Typ                 => "remote"
                                    },

dort ist doch schon Dim dabei. Das mit der invertierung habe ich nun noch nicht angesehen oder genau verfolgt.

codeartisan-de commented 4 years ago

@HomeAutoUser Update gemacht. Empfang geht auch noch (Nachdem ich das Gerät neu anlegen musste weil save vergessen). Und ich konnte auch eine Dose anlernen und dann schalten.

Wie ist denn das jetzt wenn ich die Dosen mit einem anderen "Hauscode" nutzen will als die FB hat? Im OpenHAB hab ich das so. Die FB wird nur Empfangen. Und die Dosen werden nur aus den OpenHAB gesteuert und reagieren nicht direkt auf die FB. Dadurch kann ich beides getrennt voneinander nutzen.

Bekomme ich das im FHEM über ein Gerät auch hin? Was sicher geht ist direkt über den sduino die Codes zu senden.

elektron-bbs commented 4 years ago

@HomeAutoUser Jo, stimmt, ich hatte wohl bei QUIGG_DMV nachgesehen. Woher soll ich auch wissen, das GT-7000=TR_502MSV=QUIGG_DMV=ISOTRONIC=MANDOLYN :-)

HomeAutoUser commented 4 years ago

Bekomme ich das im FHEM über ein Gerät auch hin? Was sicher geht ist direkt über den sduino die Codes zu senden.

Das sollte machbar sein indem du ein Device anlegst mit einem anderen Code am Ende. Deine jetzige REmote ist bsp. mit einem DEF TR_502MSV FF angelegt. Wenn du ein neues anlegst mit Bsp: TR_502MSV FE somit reagieren deine Steckdosen nicht mehr ;-) es sei denn, du lernst diese an. Das würde ich aber wenn gern in einem separaten Faden erläutern oder vertiefen.

Wichtig wäre erstmal, das für den Faden hier, deine Remote erkannt wird als Device und ob du auch senden kannst. Zielsetzung sollte somit sein, du kannst via FHEM die selben Steckdosen schalten wie mit der remote.

Wir wollen ungern einen Faden zur "Geräteintegrierung" missbrauchen um "Allgemeines zu FHEM" zu vermischen. Bitte nicht als Kritik ansehen, wir wollen somit nur vermeiden, das solche Fäden mehrere Themen umfassen und irgendwann bleiben sie mit "fremden" Themen abseits der Issues Beschreibung offen.

PS: Achso, sollten deine Steckdosen via dem angelegten Device schlechter schalten, so gibt es noch ein Attribut repeats. dieses kannst du nach oben regeln, somit könnte es besser werden. Steht in der Commref des Device.

elektron-bbs commented 4 years ago

Das Senden wird wahrscheinlich im Moment sowieso nicht richtig funktionieren. Wenn, dann bei ihm nur zufällig, da die ersten drei Nibble "FFF" sind.

In DEF haben wir nur die ersten zwei Nibble, es müssten aber 3 sein. Dito das Reading deviceCode 8 Bit, es müssen aber 12 sein.

In der sub SD_UT_Set werden stattdessen fest 4 Bit eingefügt:

my $adr = sprintf( "%08b", hex($definition[1])); # argument 1 - adress to binary with 8 digits $msg = $models{$model}{Protocol} . "#" . $adr . "1111";

Richtig wäre dann dort (wie bei QUIGG_DMV):

my $adr = sprintf( "%012b", hex($definition[1])); # argument 1 - adress to binary with 12 digits $msg = $models{$model}{Protocol} . "#" . $adr;

codeartisan-de commented 4 years ago

Schönen guten Abend @HomeAutoUser & @elektron-bbs. Hab heute wieder etwas Zeit zum basteln.

[...] DEF TR_502MSV FF [...]

Ah, dafür steht das FF! Prinzip denke ich verstanden. Werde ich mal mit rumspielen.

[...] via FHEM die selben Steckdosen schalten wie mit der remote [...]

Naja, wie gesagt, die Dosen reagieren eh nicht auf die FB. Hab die extra auf unabhängige Codes angelernt. Ich versuche aber mal mit der Erkenntnis von oben FHEM auf die Codes der Dosen einzustellen.

Wir wollen ungern einen Faden zur "Geräteintegrierung" [...]

Absolut OK. Wenn da noch Fragen aufkommen schau ich mal wo die besser hin passen.

Das Senden wird wahrscheinlich im Moment sowieso nicht richtig funktionieren. Wenn, dann bei ihm nur zufällig, da die ersten drei Nibble "FFF" sind.

Mhh, dann hatte ich Glück. Zumindest bei der Dose die ich bis jetzt getestet hatte. Nach anlernen aus FHEM ging das schalten mit FHEM und FB. Hab zur Sicherheit auch nochmal mit der FB angelernt. Auch da ging das schalten mit FHEM und FB. Und ein anderer Channel ging auch.

Wie gesagt, ich schau jetzt mal ob ich FHEM auf die Codes der Dosen Konfiguriert bekomme. Umlernen würde jetzt zu sehr stören. Sind ja im produktiven Einsatz am OpenHAB.

codeartisan-de commented 4 years ago

Wie gesagt, ich schau jetzt mal ob ich FHEM auf die Codes der Dosen Konfiguriert bekomme.

Funktioniert! Mit einem Device auf Gerätecode BF schalten jetzt auch die beiden verbauten Dosen sofort. Also für mich sieht das gut aus.

Sende übrigens die Codes tatsächlich invertiert im rc-switch. Wo ich hier mit dem sduino BF, also 1011 1111 brauche, sende ich im rc-switch 0100 0000. Ich denke aber das brauchte rc-switch nur um den Signalstart richtig zu erkennen.

Was ich jetzt noch nicht verstehe ist warum ich am Anfang nichts mit P34 empfangen habe? Kann das an der neueren sduino Firmeware Version liegen? Oder an dem anfangs höheren sens Wert? Hab extra nochmal in die ersten Logs von mir oben geschaut. Da schlägt kein Protokoll an.

Aber egal, geht ja jetzt. Besten Dank soweit schonmal für eure Unterstützung. Jetzt wäre noch eine Lösung für die xavax ( #717) cool ;-)

elektron-bbs commented 4 years ago

Die Codes werden eigentlich nur invertiert dargestellt. Bei einer Fernbedienung ist es bei der Entwicklung nicht immer eindeutig feststellbar, welche Pulsfolge für 1 oder 0 steht. Für die Funktion ist das aber unwichtig.

Das anfangs noch nichts von Protokoll 34 ausgewertet wurde, erkläre ich mir damit, das dein CC1101 noch nicht richtig konfiguriert war. Die ersten RAW-MSG sahen auch noch etwas eigenartig aus.

Aus diesem Grund würde ich dich auch bitten, von der anderen Fernbedienung (xavax) nochmal ein Log mit einigen Nachrichten anzufertigen.

elektron-bbs commented 4 years ago

Das Protokoll wurde vor 14 Tagen in den Entwicklerzweig übernommen. Ich schließe dieses Issue.