-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rojaflex 433.92 Shuttercontroll support #955
Comments
Please provide logdata as text |
Hello, Thank you for the quick reply! You will find the log attached. |
We need some information when you send one of the commands. Best approch: Press one button serval times and paste the log snippet for that time here. Repeat this with every button |
Mir scheint, das hier ein Sensor mit Protokoll 38 dazwischen funkt und von der Fernbedienung keinerlei Signale empfangen werden:
Bitte den Test mit der Fernbedienung nochmal mit deaktivierten Protokoll 38 wiederholen. Verbose 4 sollte ausreichen und bitte notieren wann welche Taste betätigt wurde, oder gleich in separate Logs für up/down/stop. Die Bezeichnung der Fernbedienung wäre wichtig zu wissen. |
Hello, you were totally right. It was nothing from the remote included :-( I bought a real SDR stick now and I am able to see the signal in Cubic SDR.
I seethe signal with rtf_433. Does the rtl_433 verbose output help too? Best regards |
I was able to gather some logs. from rtf_433. Does that help? bridge_down.txt |
Ich vermute, dass es sich um eine Art Frequenzmodulation handelt. Die Datenrate beträgt wahrscheinlich 10 kHz. Es fehlen uns noch wichtige Daten wie Syncword, Präambel und Frequenzhub. Google translator: |
Hi elektron-bbs, danke für die Hilfe. Ich habe mal ein paar "Records" von dem URH angehängt. damit bist du wahrscheinlich 3x schneller als ich. Und ein Bild vom Stop command. Vielleicht hilft das schon mal. |
Das sieht doch schon sehr gut aus. URH dekodiert da diese Nachrichten:
Kannst du den Spectrum Analyzer nochmal bitte mit größerer Bandbreite laufen lassen. Nur 1 kHz scheint mir zu schmal. Probiere mal mit 100 oder 200 kHz. Im Spektrum müssten dann 2 "Zacken" zu erkennen sein, so wie in den Abbildungen im Wiki (https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle#SIGNALduino_-_FSK). |
Ich habe die neuen Mitschnitte noch nicht komplett gecheckt, aber erste Versuche sahen schon gut aus. Ich habe hier noch einen Hinweis diesbezüglich aus den Weiten des Internets :-)
|
Hallo, das linke Horn hat: 433,90 Kann das hinkommen? Ich gucke jetzt mal ein paar Videos zu dem Thema. Viele Grüße |
Ja, das passt - 20 kHz. |
Hallo, kannst du mir deine Errungenschaften, also die Signaleigenschaften einmal zusammenfassen? ich würde mich schon mal an eine manuelle Decodierung mit dem 433 terminal program wagen wollen. Viele Grüsse |
Was ich bisher heraus gefunden habe: Frequenz: 433,92 MHz Meine Notizen zu den Nachrichten:
|
Ich glaube ich habe ein paar Muster im Protokoll erkannt. Original = 0xaaaaaaaad391d391083122fd298a018a8e30cd |
I am now able to see the messages live with: |
Laut Doku Kanäle 1 bis 15, dann gibt es da noch (Zitat):
Was ist 0xE Status?
Remote und Shutter?
Es sind jeweils 2 x 2 Nachrichten, wahrscheinlich pro Tastendruck. Habe ich aber nicht bei allen Aufzeichnungen gefunden (siehe Anhang Rojaflex.txt).
Da ist noch einiges zu klären. |
Ich weiß nicht, was rtl_433 dir da liefert. |
Mit dem Kommando "rtl_433 -R 0 -X "n=rojaflex,m=FSK_PCM,s=100,l=100,r=102400,preamble=0xaaaaaaaa" bekomme ich live die Hexwerte, die du dankenswerter Weise manuell berechnet hast. Also noch nicht wirklich mehr als wir jetzt haben. Nur besser zum Debuggen.
Auch wenn ich das noch mal validieren muss, bin ich zu 99% sicher das in dem Fall eine 0x0 gesendet wird.
Es wird auf jedes Kommando von der "Fernbedienung" eine Antwort von dem Rolladen gesendet. remote_shutter-küche_2x-down_433_92MHz-1MSps-1MHz
Dann habe ich durch Zufall noch vielleicht Kompatible Protokolle gefunden die ich gleich mal teste:
|
Ich bin mit der Analyse des Commandos schon ganz gut voran gekommen. Dazu morgen mal mehr. Allerdings habe ich mich schon an Checksummen hoch und runter gerechnet. ich denke das ist eine CRC16 am Ende. Hast du da eine Idee? |
Hier der akutelle Stand, wenn man alle festen Werte von vorne weglässt. Interessant ist, das die Fernbedienung 2 Unterschiedliche Kommandos bei Runter sendet, wovon ich nur das erste verstehe. Und die Bridge sendet nur das erste Kommando beim Runter ... |
Ich habe die Nachrichten, die ich aus den Mitschnitten von URH erfassen konnte, mal in einer Excel-Datei erfasst. Vielleicht kannst du diese ja mal ergänzen. |
Hallo elektron-bbs, Ich gucke mir deine Tabelle morgen mal an. Mit ein bisschen Glück habe ich die Struktur jetzt vollständig. Es scheint also nicht mit IDs von den Geräte gearbeitet zu werden. Annahme. Des Weiteren nehme ich an das diese Token von dem Rolladen geprüft und übernommen werden und immer in der Antwort gleich bleiben. Anbei mal ein Capture von meinem getunten sdr_433 und die *.c Datei mit viel Doku. Und vielleicht sind auch noch Annahmen nicht richtig. Noch ein kleiner Nachtrag an Erkenntnissen:
Basis Token für hoch bei Kanal 0: 0x1AA5
Basis Token für runter bei Kanal 0: 0x8A85
Basis Token für Stop bei Kanal 0: 0x0A85
Basis Token für GetStatus bei Kanal 0: 0x025D // Das tanzt aus der Reihe
Also wenn es eine HomeID als statischen Schlüssel gibt Byte 10-12 und er User diese eingibt, |
Dank dem folgendem Tool konnte ich die CRC rausfinden und validieren. CRC16/CMS: Berechnet sich von Byte Position 8 (Name "Länge") bis zur Position 16 inklusive. Also die letzten zwei Byte von der Fernbedienung sind validiert eine CRC16/CMS. |
Spitzen Leistung, mal sehen, wie wir das in FHEM umsetzen können. Unter Umständen kann das ja auch schon der CC1101 selbst. |
Ich denke doch, die Firma setzt ja den TI_CC110L ein, siehe Dokumentation oben. Ich glaube der baut auf dem CC1101 auf. Ich komme jetzt erstmal weiter und probiere es kurzfristig per Sonoff RF 433 bridge und MQTT anzusteuern. Wäre natürlich auch cool wenn Ihr die Firma unterstützt. Viele Grüße Ich gucke mal ob ich die Tage einen Message Generator in Bash schreibe. |
Hey electron, ich habe den Decoder in rtf433 fertig implementiert und würde den Hersteller jetzt in FHEM übertragen wollen. Wie kann ich denn am besten helfen? Kannst du mir die Register Settings für den FSK mode für den SIGNALDuino geben? Damit kenne ich mich ja leider noch nicht so aus. Wenn ich die Hex Werte bekomme kann ich wieder starten mit dem Plugin. Siehe: merbanan/rtl_433#1705 |
Ich mache mal einen Schuss aus der Hüfte, ohne jegliche Gewähr :-) Ein Update darauf erfolgt mit folgendem Befehl:
Nach einem Neustart von FHEM muss bei dem SIGNALduino (434MHz, CC110x) unter dem Menupunkt "Display protocollist" das Protokoll 109 aktiviert werden. Anschließend muss noch das Attribut "rfmode" auf den Wert "Rojaflex" gesetzt werden. Nachdem der CC1101 konfiguriert ist (das dauert einige Sekunden) aktualisieren sich die Readings auf folgende Werte:
Solltest du damit schon etwas empfangen, so siehst du das erstmal nur im Log:
Ich schätze aber eher, das du dich erstmal durch die Register des CC1101 kämpfen musst um die vielfältigen Konfigurationen einzustellen. Ich habe mir dazu eine Excel-Datei erstellt, die ich mal mit hochlade. Vielleicht hilft dir das etwas. |
Nein noch nicht. Mache ich die Tage und melde mich dann noch mal. |
Der Test von Kanal 0 (alle Rolladen gleichzeitig) war zu 50% erfolgreich.
|
Wenn ich es richtig sehe, liegt es am Housecode vergleich.
|
Mhmm, das kann ich nicht nachvollziehen... Wenn ich mit einem Gerät sende, werden auf dem anderen Gerät die Zustände aller Geräte mit gleicher Ident geändert. Es wird allerdings kein Event ausgelöst. Man muss erst die Seite aktualisieren. Im Log sieht man beide Einträge:
|
Ich habe mich jetzt für "housecode " entschieden - da waren weniger Änderungen erforderlich :-) |
Super, ich mache mal ein Update. |
Restest erfolgreich. Wie du gesagt hast, man muss die Webseite manuell neu laden. Ein wenig unschön ist, das die Fernbedienung immer ein Request hinterher schickt und man daher im State Pauschal immer Refresh stehen hat. Allerdings möchte man ja auch sehen was ankommt. Da das Request nur für die Rolläden gedacht ist, könnten wir natürlich das Kommando auch komplett verwerfen, dann würde man ein bisschen schöner sehen was passiert. Siehe: |
Ich hätte ja erwartet, das nach dem request eine Rückmeldung der Antriebe erfolgt?!? |
Das kann ich beantworten. Dazu gibt es eine kurze und eine lange Antwort. Die kurze ist: Nein tun sie nicht. Die lange:
Um es kurz zu machen. Ich glaube die haben das nicht wirklich als Protokoll pro Kanal abgebildet. So lange man nur einen benutzt (nicht die Null) funktioniert es halt per Zufall so wie man es erwarten würde. |
Das scheint dann noch etwas "Beta" zu sein... |
|
zu 2. Wenn du dann keine weiteren Einwände hast, würde ich den Branch in den Master überführen. |
Zu 2. Dadurch, dass die Motoren ja falsch antworten, sobald sie gleichzeitig genutzt werden, würde ich es so lassen. Oder mindestens einstellbar lassen. Ich habe im defaultsetup bidirectional auf 0, weil es sonst bei mir garnicht funktioniert. die motoren antworten ja, wenn gleichzeitig gesteuert, alle auf dem gleichen Kanal. Und dann bekommt man nie das letzte position update :-( das ist ja der ganze misst. daher brauche ich das setting. Merge wäre natürlich cool. |
Nicht, das wir uns falsch verstehen, ich ändere nur den Default-Wert, wenn das Attribut nicht angelegt ist.
dann
Dann werden von FHEM erstmal nur die Readings motor, state und tpos erzeugt. solange das Attribut "bidirectional" nicht vom User angelegt und auf 0 gesetzt wird. |
Danke für die Erklärung. Super. |
Wenn du gemerged hast, ist die Frage, wie ich meine Installation auf den Master umziehen kann. Gibt es da einen einfachen Befehl? |
Dazu reicht dann in Zukunft ein Befehl:
oder einmalig dieser. um in Zukunft beim normalen Update die Module aus Master gleich mit zu aktualisieren:
Ich bin aber noch nicht dazu gekommen. Ich gebe dann Bescheid, wenn es soweit ist. |
Ich habe jetzt erstmal nur ein Update auf diesen Branch durchgeführt. Bitte nochmal testen. |
Update ist eingespielt. Test ongoing |
funktioniert |
Und ich habe jetzt doch gewisse Automationen auf Kanal 0 (alle Rollläden) umgestellt. Früher habe ich autom. alle Rollläden nacheinander angesteuert. Jetzt nutze ich durch deine Implementation das device 0. dadurch wird weniger gefunkt und es läuft sogar stabiler. |
OK, dann werde ich bei Gelegenheit einen pull request in den Master einleiten. |
@elektron-bbs Vielen Dank für die ganze Mühe! Ich benutze Rojaflex via FHEM und zusätzlich via Hombridge mit dem FHEM connector plugin. Anbei noch einmal meine Configuration für alle die einähnliches Setup haben.
Anbei meine Device Configuration:
|
@Hofyyy |
sorry to hijack the conversation, were you able to do it with the Sonoff RF Bridge? |
No I was not able to get it work with Sonoff RF Bridge, because the firmware is not able to speak the specific language. Also the special HF firmware which you can flash is also not able to speak the special format. The only easy way is not with this plugin :-P |
I am again on this topic. where you able to run this via rhe sonoff bridge? |
Specifications for new sensor / switch / or other device ...
The chip in the remote is the: TI_CC110L
I am able to receive data with:
cc1101_config | Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
cc1101_config_ext | Modulation: ASK/OOK, Syncmod: No preamble/sync | 2021-04-18 13:11:18
Specifications
TI_CC110L.pdf
FHEM LOG with Verbose 5
log.rtfd.zip
The text was updated successfully, but these errors were encountered: