-
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
Alphavision Slender Line Plus motor canvas #906
Comments
Ich denke, die Codes passen. Einige Fragen bleiben noch: Bilder von der Fernbedienung wären brauchbar, möglichst auch von den "Innereien", wenn sie zerstörungsfrei zu öffnen ist. Schaltkreisbezeichnungen helfen oft bei der Bestimmung des verwendeten Protokolls. |
Auf der Rückseite der Fernbedienung steht AC114-01B, RF-Transmitter, Frequency: 433.92MHz. Es gibt ein Loch, vermutlich mit einem Taster darunter. Ein Batteriewechsel hat keinen Code-Wechsel zur Folge - anbei ein frischer Log (hoch, stop, runter, stop): Eine Web-Suche nach AC114 brachte dieses Projekt hervor (samt Bild von innen und dem Taster). Nochmal hier von außen und innen: Here they say they got it working with rc-switch. |
Das müsstest du bitte noch genauer untersuchen. Ich habe noch Zweifel, ob die Ident der Fernbedienung "fest eingebrannt" ist, oder sie sich ändert. |
Ich habe beim Leinwand-Verkäufer eine Anleitung zum Anlernen von Fernbedienungen angefordert. Bis dahin würde ich nur ungern die Kopplung zwischen Sender und Empfänger auflösen. |
OK, verstehe ich. Die Fernbedienung scheint bei zweimaliger Bedienung der Tasten UP/DOWN jeweils bei der zweiten Betätigung einen anderen Code zu senden. Die zweite Betätigung löst doch ein STOP aus - sehe ich das richtig?
Ich drösele das aber anders auf:
Bitte zeichne mal noch folgende Vorgänge auf: |
Ich habe versucht, auf die wichtigen Meldungen (READredu -> Funknachricht, Decoded -> eine Interpretationsmöglichkeit) zu filtern:
Ich halte alle Nachrichten, die nicht u56 mit Länge 64|68 sind, für Fehlinterpretationen. Dann ergibt gibt sich auch nur eine Interpretation je Funknachricht, womit sich weiter reduzieren lässt auf
Die unbekannte Nachricht, die mit ca. 1 Sekunde Verspätung gesendet wird, kommt manchmal nicht - oder wird nicht gehört. Die 64-Zeichen-Nachrichten sind vermutlich auch nur falsch verstanden. Die vollständige Log-Datei: |
Ich gehe davon aus, das die Nachrichten 65 Bit lang sein müssen, weil im letzten Byte (vor der 8) eine Checksumme ist. Die restlichen 3 Bit werden aufgefüllt, damit Nibble übergeben werden können. |
Die zweite Nachricht kommt ja sowohl bei hoch als auch bei runter. Für das letzte Logfile drückte ich 3x runter, 3x hoch. |
Ja, scheint so, als ob bei jedem Tastendruck zuerst mehrmals der eigentliche Befehl gesendet wird nd anschließend mehrmals ein "AFTER_UPDOWN". Kommen bei STOP auch zwei verschiedene Nachrichten? |
Bei Stopp kommt immer nur u56#A3479696010023978. Gibt es keine Möglichkeit das frisch geloggte Signal zu senden bevor du das Protokoll ordentlich aufgenommen hast? |
Das Senden müsste eigentlich beispielsweise mit "set sduino sendMsg P29#0xF7E#R4" funktionieren: Aus der Doku: |
Wieso P29? Und 0xF7E? Bewirkt jedenfalls nichts. Ich hatte ja schon sendMsg wie oben in der issue description (siehe letzter Satz) genutzt, aber das funktioniert auch nicht. |
Das war nur ein Beispiel, was ich vorhin auf die Schnelle aus der Doku kopiert habe.
Kann aber sein, das es auch nicht funktioniert, weil 3 Bit zu viel gesendet werden. Dann müsste Hex in Binär gewandelt werden, die 3 letzten Nullen entfernen, so das 65 Bit übrig bleiben. Der Sendebefehl ist dann (Achtung auch wieder nur ein Beispiel!): Aus der Doku: Wenn auch das nicht funktioniert erwartet der Empfänger vielleicht tatsächlich die zweite Nachricht hinterher. |
Alphavision Slender Line Plus motor canvas, remote control AC114-01B see #906
Oh man, weder das FHEM-Modul noch der ESP-Code bemängeln Dezimalzahlen mit Buchstaben... hier wäre eine Ausgabe wie "wrong decimal, did you mean 0x....?" wünschenswert. Und die Debugausgabe des Moduls sollte auch "Decoded matched MU protocol id 56 dmsg u56#0x...." ausgeben. Am besten hätten wir von Anfang an über das Wiederholen der Signale mit SignalDuino reden sollen. Langer Rede kurzer Sinn: Ich muss mindestens R3 verwenden, darunter passiert nichts. Aber ab R3 klappt es bisher jedes Mal:
Vielen Dank bis hierhin. Wenn ich noch helfen kann, sag bescheid. |
Das ist doch schon mal ein Fortschritt!!! Ich habe zwischenzeitlich einen neuen Branch für die ersten Tests erstellt. Ein Update darauf kannst du mit folgendem Befehl durchführen:
Es sollte dir nach einem Neustart dann nach drei empfangenen Nachrichten der Fernbedienung ein neues Device "AC114_01B_479696" angelegt werden. Den Befehl "after_updown" muss ich dann sicher noch irgendwie unterdrücken. |
Es dauerte etwas, weil der Restart nun nach Digest::CRC verlangte, das portable Perl-CPAN aber nicht mit Umlauten im Pfad klarkommt. Nach manueller Installation des CRC-Moduls gings aber weiter. |
Ist der Befehl "after_updown" zu irgend etwas zu gebrauchen, oder kann er tatsächlich weg? |
Bei meiner Leinwand macht "after_updown" nichts - weder während sie fährt, noch wenn sie steht. Der Hersteller hat mir geantwortet, wie man eine neue Fernbedienung anlernt (sowohl beim Sender als auch Empfänger Stopp gedrückt halten), aber das ändert nichts an den Codes. Der Reset-Knopf im Empfänger ist für mich leider unzugänglich, da an die Decke geklebt und der Kleber sicherlich nicht stärker ist als die Gehäuse-Haltenasen (ich hätte beim Versuch, das Ding zu öffnen, also das ganze Gehäuse in der Hand). |
Ich habe den Befehl "after_updown" jetzt aus der Setlist entfernt und beim Empfang wird er nicht ausgewertet. Ich habe keine Vorstellung, wozu der eigentlich gedacht ist. Einen Code für "program" habe ich in https://github.com/akirjavainen/A-OK gefunden. Hoffe mal, das der stimmt. Bitte mach nochmal ein Update, wie gestern und probiere dann ausgiebig. |
Ich würde das Protokoll jetzt gerne in den Master-Branch überführen. |
Läuft perfekt. |
Alphavision Slender Line Plus motor canvas, remote control AC114-01B see #906 * change version from 3.5.0 to 3.5.1
Das Protokoll ist jetzt im Master-Branch. Ich schließe dieses Issue. |
@elektron-bbs Ich würde unheimlich gern OpenMQTTGateway in Verbindung mit HomeAssistant einsetzen. OMG setzt auf rtl_433_ESP, jedoch ohne flex decoder. Gibt es dort ein Protokoll, welches ähnlich zu dem AC114-01B oder BeSmart von SignalDuino ist? Ich würde dann (gern mit deiner Unterstützung) beide Protokolle hinzufügen, damit OMG dieses empfangen und senden kann. |
Ob es dort etwas ähnliches gibt, kann ich nicht beantworten. Im Prinzip müsste ja jede Fernbedienung als Beispiel herhalten können (ich finde dort auf Anhieb aber nur drei Stück). FS20 (https://github.com/NorthernMan54/rtl_433_ESP/blob/master/src/rtl_433/devices/fs20.c) erscheint mir z.B. am einfachsten anpassbar. |
Mit der Hilfe von @zuckschwerdt habe ich generic_motion als Grundlage genommen. Mit dem RTL2832U funktioniert es auch. Mit dem ESP und OpenMQTTGateway (also rtl_433_ESP) noch nicht zuverlässig. SignalDuino ist aber der Beweis, dass es nicht am ESP liegt. |
Specifications for new sensor / switch / or other device ...
Specifications
The highest RSSI with most narrow bandwidth can be achieved at 433.88 MHz.
The remote has five buttons where "left" and "right" do not make the SignalDuino blink. Pressing the other buttons creates the following messages (every time with each button press, tried it multiple times):
Verbose 5 logs:
presslogs.zip
Up/Down have similar messages thus I guess the following messages are important:
u56#A3479696010043B78
for upu56#A3479696010023978
for stopu56#A347969601000B7F8
for downBut trying to send those message like thise has no effect:
set sduino sendMsg u56#A3479696010023978
The text was updated successfully, but these errors were encountered: