Ok, Chris danke für die Antwort. Dann hoffe ich mal, dass sich ein Entwickler findet der uns bei einem RollingCode2 unerstützt.
@X-Ray hat die geänderten Timings ja schon raus gefunden.
-
433 MHz Funksteckdosen LIDL Silvercrest RCR DP3 3711-A (brennenstuhl) mit Homeduino
-
Hab mich bereits mal an einer rolling2.js versucht:
module.exports = function(helper) { var binaryToPulse, protocolInfo, pulsesToBinaryMapping; pulsesToBinaryMapping = { '01': '1', '12': '0', '34': '' }; binaryToPulse = { '1': '01', '0': '12' }; return protocolInfo = { name: 'rolling2', type: 'switch', values: { codeOn: { type: "string" }, codeOff: { type: "string" } }, brands: ["rollingCode2"], pulseLengths: [400, 600, 1000, 3000, 7250], pulseCount: 50, decodePulses: function(pulses) { var binary, result; binary = helper.map(pulses, pulsesToBinaryMapping); return result = { code: binary }; }, encodeMessage: function(message) { var code; if (message.state === true) { code = helper.map(message.codeOn[0], binaryToPulse); } else { code = helper.map(message.codeOff[0], binaryToPulse); } return "" + code + "34"; } }; };
bisher leider ohne Erfolg. Noch Ideen bzw. Dinge die angepasst werden müssten?
-
@X-Ray
Verry good that you try to solve the problem. Maybe you can give some more infos what you think have to be changed to the rollingcode1 so that @developer can look at the code and give you a hint.
I haven’t the experience to help you. -
The new pulseLength has to be integrated (I tried but it doesn’t work) and did i only have to add the rolling2.js (see above) and add ‘rolling2’ in the protocols array in the controller.js?
-
@x-ray
For a first test I would copy the original rollingcode1.js and take your rolligcode2 under the name rollingcode1.js. So you can see if your changes works -
@V1per
Tried your hint, when i now use the remote to read out the received things but now there is only the line “received” and “data” but no “code”… -
@x-ray
Strange… I think maybe your timings are not correct so pimatic can’t recornize the code from the remote.
Is the protocoll allways reconized as rolling1? -
@X-Ray
Give it any news? Maybe we should use one of the two other threats in the normal forum (not the german sektion) I hope a @developer has a hint. -
Not yet. Changed my 433mhz receiver to a superheterodyne. Will try next weekend to read out the signal of the remote.
-
Hallo,
ich hab mir mal einen Account hier erstellt da ich zufällig auf den Beitrag gestoßen bin und meine Erfahrung mit den Funksteckdosen teilen wollte.Meine Situation:
Ich bin momentan dabei mit einen Raspberry Zero W und Homebridge alles mögliche bei mir im Haus mit HomeKit steuerbar zu machen. Heute waren die Lidl Steckdosen dran und ich hatte noch einigem Reverse Engineering und Coden die Lösung. Fertige Sachen gibt es leider nicht.
Da ich mit Homeduino keine Erfahrung habe und ihr vermutlich kein Interesse an Homebridge lasse ich den Teil weg und beschränke mich auf die Schnittmenge. Ich weiß dass das keine direkte Lösung für euer Problem ist, aber vielleicht hilft es euch weiter.Wie schon bekannt muss man erst den Code auslesen um die Steckdosen anzusteuern. Ich verwende dafür die ganz normalen 433MHz Sender und Empfänger von Amazon für 8€.
Es sind vier verschieden Codes die die Fernbedienung nacheinander aussendet, wobei bei jedem Tastendruck der gleiche Code zwei mal gesendet wird. Einmal mit Protokoll 4 und einmal mit Protokoll 5. Warum dass so gemacht wurde verstehe ich nicht und das ist auch garnicht nötig, es reicht wenn man einen Code mit Protokoll 4 weiß.
Dazu nutze ich den RFSniffer im verbose Modus.Hier die Ausgabe am Pi nach einmaligem Betätigen des Einschalters von Steckdose “A” gesnifft mit
./RFSniffer -v
:Received 12046940 ============================================= ============================================= GENERAL ======= Received 12046940 Bitlength 24 Protocol 4 Delay(pulse length in us) 384 (delay provided from rc-switch) STATISTICS ========== Duration of data bits in pulse train : 36837 Data bit duration = 1535 and standard deviation = 5.20 Coefficient of variation of data-bit duration = 0.34 % (should be less than 10%) Do not use the rest of the information if big coefficient of variation Long-to-short duration ratio for data bits (rounded) = 3 Sync bit (in multiples of the pulseLength) = 1 6 Proposed protocol for RCswitch { 384, { 1, 6 }, { 1, 3 }, { 3, 1 }, false } STATISTICS OF VARIATION BY LEVELS ================================= (Differences here are probably artifacts from signal creation or detection) (This might be completely ignored, but pay attention to them if big differences are present and emission does not work) number of bits set (in 12046940): 14 longup, longdown, shortup, shortdown 1058, 1244, 289, 477 this might be useful for tweaking emmitting algorithms ============================================= RAW SIGNAL (us) =============== first level down 2407 1070 466 287 1242 1061 472 1059 479 293 1241 1057 476 1062 480 1059 474 1055 478 1057 482 290 1240 1059 478 291 1242 290 1254 1051 474 291 1239 294 1242 1058 488 282 1243 1059 476 1065 476 1050 484 290 1245 284 1252 292 ============================================= Received 12046940 ============================================= ============================================= GENERAL ======= Received 12046940 Bitlength 24 Protocol 5 Delay(pulse length in us) 514 (delay provided from rc-switch) STATISTICS ========== Duration of data bits in pulse train : 36565 Data bit duration = 1524 and standard deviation = 90.64 Coefficient of variation of data-bit duration = 5.95 % (should be less than 10%) Do not use the rest of the information if big coefficient of variation Long-to-short duration ratio for data bits (rounded) = 2 Sync bit (in multiples of the pulseLength) = 6 8 Proposed protocol for RCswitch { 514, { 6, 8 }, { 1, 2 }, { 2, 1 }, false } STATISTICS OF VARIATION BY LEVELS ================================= (Differences here are probably artifacts from signal creation or detection) (This might be completely ignored, but pay attention to them if big differences are present and emission does not work) number of bits set (in 12046940): 14 longup, longdown, shortup, shortdown 903, 1130, 414, 605 this might be useful for tweaking emmitting algorithms ============================================= RAW SIGNAL (us) =============== first level up 2978 4156 587 518 398 1121 933 615 933 617 405 1128 934 611 929 608 933 614 929 613 928 609 421 1173 885 615 413 1131 410 1120 934 616 413 1117 430 1128 934 605 415 1130 919 613 935 608 931 613 416 1123 421 1133 =============================================
Für uns ist nur das erste Signal mit Protokoll 4 interessant. Diese muss man mit ./codesend decimalcode [protocol] [pulselength] aus 433Utils/RPi_utils wieder aussenden. Statt den angezeigten 384 habe ich 355 angeben müssen da irgendwas am Pi die Pulsweite größer macht als man angibt und das muss wieder kompensiert werden.
Für die obige Ausgabe vom Einschalten des Kanal A nutzen wir also folgenden Befehl:sudo ./codesend 12046940 4 355
.
Und siehe da unsere Steckdose schaltet sich ein.
Für das Ausschalten und die anderen Kanäle ist es dann trivial.Hier das ausgesendete Signal von Pi das er auch gleichzeitig wieder empfängt. Beim einmaligen Ausführen von
codesend
wird das gleiche Signal warum auch drei mal hintereinander gesendet.:Received 12144236 ============================================= ============================================= GENERAL ======= Received 12144236 Bitlength 24 Protocol 4 Delay(pulse length in us) 394 (delay provided from rc-switch) STATISTICS ========== Duration of data bits in pulse train : 37847 Data bit duration = 1577 and standard deviation = 2.24 Coefficient of variation of data-bit duration = 0.14 % (should be less than 10%) Do not use the rest of the information if big coefficient of variation Long-to-short duration ratio for data bits (rounded) = 3 Sync bit (in multiples of the pulseLength) = 1 6 Proposed protocol for RCswitch { 394, { 1, 6 }, { 1, 3 }, { 3, 1 }, false } STATISTICS OF VARIATION BY LEVELS ================================= (Differences here are probably artifacts from signal creation or detection) (This might be completely ignored, but pay attention to them if big differences are present and emission does not work) number of bits set (in 12144236): 13 longup, longdown, shortup, shortdown 1094, 1193, 383, 482 this might be useful for tweaking emmitting algorithms ============================================= RAW SIGNAL (us) =============== first level down 2261 1097 480 385 1189 1098 477 1100 479 1095 484 382 1191 390 1186 1095 484 385 1192 1092 483 386 1190 385 1192 1098 480 1094 484 1093 485 383 1194 382 1200 1098 475 1094 488 379 1196 1091 487 1089 486 380 1198 379 1197 377 ============================================= Received 12144236 ============================================= ============================================= GENERAL ======= Received 12144236 Bitlength 24 Protocol 4 Delay(pulse length in us) 396 (delay provided from rc-switch) STATISTICS ========== Duration of data bits in pulse train : 37963 Data bit duration = 1582 and standard deviation = 77.41 Coefficient of variation of data-bit duration = 4.89 % (should be less than 10%) Do not use the rest of the information if big coefficient of variation Long-to-short duration ratio for data bits (rounded) = 3 Sync bit (in multiples of the pulseLength) = 1 6 Proposed protocol for RCswitch { 396, { 1, 6 }, { 1, 3 }, { 3, 1 }, false } STATISTICS OF VARIATION BY LEVELS ================================= (Differences here are probably artifacts from signal creation or detection) (This might be completely ignored, but pay attention to them if big differences are present and emission does not work) number of bits set (in 12144236): 13 longup, longdown, shortup, shortdown 1086, 1196, 354, 521 this might be useful for tweaking emmitting algorithms ============================================= RAW SIGNAL (us) =============== first level down 2269 1066 777 190 1157 1068 499 1129 490 1086 491 377 1202 376 1200 1085 491 377 1199 1089 487 374 1200 384 1200 1086 490 1086 493 1085 491 375 1205 371 1200 1084 492 1085 493 373 1199 1087 491 1085 594 328 1201 374 1201 372 ============================================= Received 12144236 ============================================= ============================================= GENERAL ======= Received 12144236 Bitlength 24 Protocol 4 Delay(pulse length in us) 394 (delay provided from rc-switch) STATISTICS ========== Duration of data bits in pulse train : 37837 Data bit duration = 1577 and standard deviation = 2.65 Coefficient of variation of data-bit duration = 0.17 % (should be less than 10%) Do not use the rest of the information if big coefficient of variation Long-to-short duration ratio for data bits (rounded) = 3 Sync bit (in multiples of the pulseLength) = 1 6 Proposed protocol for RCswitch { 394, { 1, 6 }, { 1, 3 }, { 3, 1 }, false } STATISTICS OF VARIATION BY LEVELS ================================= (Differences here are probably artifacts from signal creation or detection) (This might be completely ignored, but pay attention to them if big differences are present and emission does not work) number of bits set (in 12144236): 13 longup, longdown, shortup, shortdown 1082, 1205, 370, 494 this might be useful for tweaking emmitting algorithms ============================================= RAW SIGNAL (us) =============== first level down 2276 1088 491 374 1205 1083 494 1083 501 1077 495 369 1205 370 1205 1082 495 371 1205 1082 495 370 1206 371 1203 1082 496 1083 494 1087 495 369 1205 371 1206 1081 494 1083 495 369 1208 1079 494 1081 495 370 1205 371 1204 372 =============================================
Prinzipiell müsste man sich das ganze sniffen auch sparen können wenn man die Fernbedienung nicht mehr verwendet. Dann reicht es die entsprechenden Codes zu senden und die Steckdosen darauf zu programmieren.
Hier Beispielcodes mit denen es klappen sollte:
Kanal An Aus A 11940012 12494204 B 11704053 11742165 C 12494206 11940014 D 11742167 11559223 Viel Erfolg und ich hoffe ich konnte euch weiterhelfen
-
vielen dank @thomas2212 für deine ausführliche hilfe!
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebookmake it so !
-
@mwittig @developer
Ich versuche gerade den Code rolling1 so abzuändern, dass er funktioniert.
Falls ich das hin bekomme würde ich diesen z.B. rolling2 nennen und noch mal fragen wie ich die geänderten Dateien am besten nach Github bekomme.
Mein jetziges Problem ist aber, egal was ich in rolling1.js welche bei mir in folgenden Verzeichnis liegt:
~/pimatic-app/node_modules/pimatic-homeduino/node_modules/homeduino/node_modules/rfcontroljs/lib/protocols/rolling1.js
ändere es ändert nichts an dem jetzigen Verhalten, auch wenn ich dort völligen Quatsch rein schreibe…
Auch ein Pimatic neustart hilft nichts, was mache ich falsch?english:
I’m trying to change the code rolling1 to work.
If I can do that I would call it rolling2 and ask again how to get the changed files after Github.
But my current problem is, no matter what I have in rolling1. js in the following directory:
~/pimatic-app/node_modules/pimatic-homeduino/node_modules/homeduino/node_modules/rfcontroljs/lib/protocols/rolling1.js
it doesn’t change anything about the current behavior, even if I write complete nonsense there…
Even a Pimatic restart doesn’t help, what am I doing wrong? -
Sorry da hab ich momentan keine direkte Antwort drauf.
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebookmake it so !
-
Sendest / Empfängst du direkt vom / am Pi oder mit einem Arduino?
-
Mit Homeduino über einen Arduino.
-
Vielen Dank, Dein Beitrag hat mir sehr geholfen.
Habe mir kürzlich ein Steckdosenset von Brennenstuhl namens “RC CE1 4001” gekauft (sind wohl baugleich mit den Lidl-Dingern, wie ich irgendwo gelesen hab).
Nun hatte ich das Problem, dass beim drücken nur einer Taste nicht nur 2x der selbe Code wie bei Dir, sondern mehrere Verschiedene Codes - auf Protokoll 4,5 und manchmal auch 0 - beim RfSniffer ankamen. Beim Versuch, diese Codes zu senden tat sich nichts.
Bei meinen Recherchen war mir irgendwo auf Github auch einer der Codes aus Deiner Tabelle begegnet, der mir so allein aber auch erstmal nicht weiterhalf.
Als ich dann nach genau nach diesem Code in Kombination mit “rfsniffer” googlete, kam genau ein Suchergebnis: Dein Beitrag, welcher mir die entscheidende Information lieferte, die mir bisher fehlte: dass ich eine Pulslänge von 355 verwenden muss.
Und schwups - mit dieser Pulslänge und den o.g. Codes konnte ich prompt meine Steckdosen anlernen. Perfekt! Also vielen Dank!
Rein interessehalber wüsste ich aber schon gern mal, warum der RfSniffer beim drücken einer einzelnen Taste immer mehrere verschiedene Codes angezeigt hat. Weiss da jemand was? Hat er vielleicht einfach die empfangenen Daten irgendwie falsch interpretiert?
Gruß,
Chris -
@chriseff kannst du uns vielleicht mitteilen, wie du das Problem letztendlich gelöst hast? Also welches Protokoll du genutzt hast und welche Werte du gesetzt hast?
Liebe Grüße,
X-Ray -
@chriseff: Freut mich dass ich dir helfen konnte und es bei dir auch funktioniert
Bei meinen Recherchen war mit irgendwo auf Github auch einer der Codes aus Deiner Tabelle begegnet, der mir so allein aber auch erstmal nicht weiterhalf.
Kann es sein dass du in GitHub schon auf einem Beitrag von mir gestoßen bist? Wenn nicht, würde mich mal der Link zu den Codes auf Github interessieren.
Rein interessehalber wüsste ich aber schon gern mal, warum der RfSniffer beim drücken einer einzelnen Taste immer mehrere verschiedene Codes angezeigt hat. Weiss da jemand was? Hat er vielleicht einfach die empfangenen Daten irgendwie falsch interpretiert?
Wie schon erwähnt habe ich keine Erklärung dafür warum verschiedene Codes versendet werden, vielleicht ist das so eine Art “Verschlüsselung” um es uns unnötig schwer zu machen. Das beim einmaligen Betätigen der Taste mehrere Codes gesendet werden liegt glaube ich auch teilweise daran, dass die Codes solange ausgesendet werden wie die Taste gedrückt ist. Und dadurch dass das Senden kürzer dauert als der Tastendruck werden mehrere Codes versendet. Ich vermute als nicht dass der Fehler beim Sniffer liegt
-
@x-ray said:
@chriseff kannst du uns vielleicht mitteilen, wie du das Problem letztendlich gelöst hast? Also welches Protokoll du genutzt hast und welche Werte du gesetzt hast?
Na klar doch
Also ich habe Dose A in den Pairing-Modus versetzt und dann folgendes ausgeführt:
./codesend 11940012 4 355
wobei 11940012 der “An”-Code für A aus Thomas’ Tabelle ist. Und schon war die Dose auf diesen Code angelernt. (Der Aus-Code muss nicht extra angelernt werden, er wird wohl irgendwie aus dem An-Code berechnet.)
Und mit genau diesem Befehl kann ich die Dose jetzt auch einschalten. Zum Ausschalten wird einfach 11940012 durch 12494204 ersetzt.
@thomas2212 said:
Kann es sein dass du in GitHub schon auf einem Beitrag von mir gestoßen bist? Wenn nicht, würde mich mal der Link zu den Codes auf Github interessieren.
Haha, stimmt! Hatte den Code in Deiner sample-config.json gesehen…
-
Leider ist mein 433MHz Sender und Empfänger an einem Arduino angeschlossen und werden durch Homeduino bedient.
Da wirdcodesend 11940012 4 355
nicht funktionieren.
Und meine Versuche den Rollingcode1 umzuschreiben sind bis jetzt erfolglos…
Selbst mit dem RAW-Code konnte ich die Steckdose nicht zur zusammenarbeit überreden.