RCswitch Protocol 1 - door/window sensor #1152
Comments
|
#389 ist ähnlich, nur etwas höherer Takt. |
|
protocol id 5 must be enabled via whitelist |
|
Ich helfe auch gerne mit weiteren Logs, wenn erforderlich. |
|
Aktiviere doch bitte das Protokoll 5. Anschließend ins Logfile schauen nachdem Du den Sensor ausgelöst hast. Im Logfile stehen dann weitere Anweisungen, die dazu führen, dass eine Definition eines unbekannten Gerätes erstellt wird. Auf der Basis können wir dann den Sensor mit seinen Daten implementieren. |
|
Ich habe jetzt erstmal die aktuelle Firmware geflasht: V 3.5.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 8 2022 18:09:56 Protokoll 5 ist aktiviert und wie im Log development auf m87,u5 gesetzt. Dies wurde nun mit Verbose 4 protokolliert: Magnetschalter zu: Manipulationskontakt schließen Manipulationskontakt öffnen Ich denke das vom Magnetschalter zu oft gesendet wird. Ich hoffe, das keine Fremdsignale enthalten sind. Hier ist manchmal recht viel Funkverkehr. |
|
Sieht gut aus, was mich aber wundert ist, dass er trotz gleichem "Befehl" unterschiedlich ausgewertet wird: Als ob eine Art counter hochgezählt würde. Ah ich hab mal übersetzt, es wurde wohl Das letzte byte gibt den Zustand an: reed_open = 0x0A; Das davor, soll eine eindeutige ID sein, das sollte sich dann bei mehreren Magnetschaltern unterscheiden. |
|
Merkwürdig. reed_open (nur 1x im Log): reed_close (jetzt auch nur noch 1x im Log): tamper_close (gelegentlich mehrere Nachrichten) tamper_open 2023.01.21 13:10:19 4: SIGNALduino_unknown converted to bits: 111111111111111100000111 2023.01.21 13:11:02 4: SIGNALduino_unknown converted to bits: 111111111111111100001000 Einen Counter gibt es wohl nicht. Aber es wird gelegentlich wohl auch der Status anderer Ports übertragen. Kann aber vielleicht auch noch ein Fehler in der Firmware sein? Vielleicht liegt das aber auch an elektrischen Störungen in der nähe meines Rechners...oder am Sensor selbst. |
|
Den Fall müsste man noch mal genauer durchleuchten. Vielleicht hat jemand vergessen ein debounce des Interrupts zu implementieren :) Um den Funk völlig auszuschließen, könnte man den Transmit Pin an dem Sensor mit dem Eingang des Signalduinos verbinden. Quasi Funk durch Kabel ersetzen. Ich glaube aber, es geht auch ohne, wenn man sich mit dem Entwickler der Sensor Firmware austauscht. Habt ihr noch Ideen? |
|
Er springt zwischen tamper_open und Close genauso wie bei reed_close. |
|
Ich habe mittlerweile schon so viele Messgeräte...aber leider keinen echten Logic-Analyzer. Auch eine Messung mit meinem DSO201 wird vermutlich keine neuen Erkenntnisse bringen? Worauf würdest Du genau hinaus wollen? Der Source Code der Firmware ist ja vorhanden: Ein debounce kann ich hier auch nicht wirklich erkennen. Generell könnte man aber festhalten, das die Signale empfangen werden. Das ist ja schon richtig gut :) |
|
Prinzipiell kannst Du den Signalduino auch mit einer anderen Firmware Flaschen. Aber das braucht es nicht. Einerseits muss der Sender einen eindeutigen Zustand senden. Davon unabhängige können wir den Sensor ja empfangen und integrieren. |
|
Leider finde ich dazu nirgends einen Stromlaufplan. Prellen dürfte es beim ersten Beispiel eigentlich nicht sein. Da sollte ja höchstens ein Eingang wackeln. Vielleicht hat er ja auch vergessen, für die restlichen Eingänge die Pullups zu aktivieren. Ich finde im Quellcode nur "enable_tamper_pullup();". Ansonsten passt Protokoll 5 eigentlich nicht so richtig. Diese Timings passen exakt zu Protokoll 3: Allerdings haben wir das nur als MS eingetragen, empfangen hier aber nur MU-Nachrichten. Wenn ich eine zweite Definition anlege mit "start" statt "sync", also für MU passt das. Allerdings muss ich clockabs auf 400 erhöhen, statt der 350 beim Sender. Vielleicht ist der Prozessor ja zu langsam, oder die delays werden nicht richtig berechnet. |
|
Die 5 ist ja quasi nie fertig geworden, wegen der schwankenden Timings. |
Der hier reicht für solche einfachen Sachen vollkommen: https://www.az-delivery.de/en/products/saleae-logic-analyzer |
|
Ist ja schon bestellt :) Achtung! Mir wurde die FW extra erstellt mit geänderten Timings. In wie fern diese geändert worden sind...keine Ahnung. Ich kann auch gerne nochmal die bisherige FW flashen und protokollieren. Mit den Pullups stimmt. Es ist nur am "Tamper" 3.3V. Am reed-Kontakt ist die Spannung bei ca. 0,2V (anderer Kontakt GND). Da wundert man sich, das es überhaupt funktioniert. Die Kontakte sind sehr empfindlich (auch bei der originalen FW). Selbst mein Messgerät löst schon einen Sendevorgang aus. |
Das ist wahrscheinlich der compilierte Code. Da kann man nicht sehen, was geändert wurde.
Naja, das muss man sich über unvorhersehbare Zustände nicht wundern. Wenn sie es nicht in der Firmware hinbekommen (ich kenne diesen Prozessor nicht), kannst du nur selbst Pullups anlöten. |
|
Es wäre besser, wenn Du die "bisherige" Firmware verwendest. Spezielle Timings helfen uns letztendlich nicht weiter. @elektron-bbs |
|
Ok. Ich habe jetzt wieder die "offizielle" neue Firmware geflasht. Hier die Logs: Tamper-Open reed-Close reed-Open Könnt ihr damit was anfangen? Übrigens: Die ganz offizielle Firmware wird schon sehr lange unterstützt. Als Bei dem Projekt von https://github.com/mightymos/ReedTripRadio/ geht es darum eine alternative Firmware für die Sensoren zu Programmieren. Geplant sind da noch ein paar Features mehr. Das ist da aber auch alles noch sehr neu und in Entwicklung. |
|
Warum wollen wir dann nicht beim IT-Protokoll bleiben? Mit dieser zusätzlichen Definition funktioniert es mit dem IT-Modul: Das Device habe ich dann so konfiguriert: Log vom Device: Bleibt nur noch ein Haken in der Firmware: Das Teil sendet bei "Tamper-Close" und "Tamper-Open" den gleichen Code: FFFF08 |
|
Wir brauchen kein weiteres Protokoll, der Sender muss nur die Anzahl an Wiederholungen erhöhen. Ob sich mit dem Intertechno aber die Daten brauchbar darstellen lassen bezweifle ich ein bisschen, aber womöglich geht es mit userreadings. |
|
Das lässt sich mit einem Attribut steuern: |
|
Na okay, hatte nicht erwartet, dass das mit der Batterie so klappt :) |
Habe das jetzt nochmal beobachtet. Manchmal kommt auch ein FFFF07. Springt dann meist kurze Zeit später wieder auf FFFF08. FFFF06 konnte ich jetzt auch bei einer leeren Batterie sehen. |
|
Es gibt jetzt eine neue Firmware. V0.3.0
Ein kurzer Test zeigt nun im device SIGNALduino_unknown_5 Also genauso wie im Source-Code der Firmware. Die zwei "kurzen" sind mit der neuen Firmware aufgezeichnet. Hier mal ein Log-Auszug mit der Originalen Firmware: Und hier mit der neuen: Wie kann ich sonst helfen? |
|
Du musst erst mal nichts mehr tun. Entweder binden wir meine Änderungen #1152 (comment) ein, oder hoffen auf den Vorschlag von @sidey79 mightymos/ReedTripRadio#4 (comment) |
|
Hmm, das müsste jetzt doch als MS passend zu Protokoll 3 erkannt werden, wird es aber nicht. |
|
Reichen 2 Nachrichten für die Erkennung von MS? |
|
Meiner Erinnerung nach ja. Dann habe ich mir überlegt, dass es mit aktivierten Debug Ausgaben vermutlich einfacher zu verstehen ist, warum es nicht klappt. |
|
Mein neues Spielzeug ist da :) Könnt ihr noch mehr Aufzeichnungen gebrauchen? Einfach bescheid geben. Auch ggf. in welchem Format ich das zur Verfügung stellen soll. |
|
Der Screenshot sieht aus wie von saleae Logic. Lade doch einfach mal eine Datei davon hoch. |
|
Richtig erkannt. :) |
@elektron-bbs Ich habe die Toleranz um 0,01 herabgesetzt und es mittels Test verifiziert, dass es damit korrekt als MS Signal erkannt wird. @bismosa https://github.com/RFD-FHEM/SIGNALDuino/actions/runs/4010274827 |
|
Ich habe jetzt erstmal einen Test mit der aktuellen Firmware v0.3.2 des Sensors gemacht. Dabei ist mir aufgefallen, dass der Sensor nun wieder wie das "Original" erkannt worden ist. Das gleiche IT Device (das mit der Originalen Firmware erstellt worden war) in FHEM reagiert nun auf alle Befehle. Die Firmware vom SIGNALDuino habe ich noch nicht angepasst. Die Timings selbst sind in der Firmware aber nicht angepasst worden. Hier mal die Aufzeichnungen in saleae Logic. Hier auch mal ein Auszug aus dem Log, wenn ich den Manipulationstaster loslasse (Firmware v0.3.1): Soll ich nochmal mit der Firmware v0.3.0 und der geänderten SIGNALDuino Firmware probieren? |
|
Ja bitte noch die Firmware des Signalduinos testen. Im Endeffekt liegt es aber an der Anzahl der 0 Bits. Da hatten wir eines zu wenig. |
|
Jetzt getestet mit der v0.3.2: Wie vorher. Das bisherige Device reagiert korrekt. Ich hoffe so war das gemeint? |
|
Das Ergebnis ist nicht, wie ich es erwartet habe. :-( |
|
Die Entscheidung, ob MS oder MU ausgegeben wird, scheint auch von anderen Faktoren abhängig zu sein. Nicht für umsonst haben wir diverse Protokolldefinitionen doppelt: 20/20.1, 54/54.1, 72/72.1, 74/74.1, 91/91.1, 118/118.1. Ich habe gerade auch wieder eine Fernbedienung in Arbeit, wo abhängig vom letzten Bit (0 oder 1), mal MS oder MU ausgegeben wird: https://github.com/RFD-FHEM/RFFHEM/tree/master_FB-FNK_Powerboat |
|
Ja, das würde ich mir gerne genauer ansehen. Ich werde es debuggen. Morgen oder so ') |
|
Ich teste gerade mal wieder eine neue Firmware (v0.3.3). Bei der Gelegenheit habe ich jetzt auch einen zweiten Testsensor mit der Firmware geflasht. Die Sensoren zeigen nun ähnliches Verhalten, wie in der Originalen Firmware. Sensor 2: Also eigentlich so, wie der Quellcode das auch sagt (in Binär übersetzt): Warum die Codes so unterschiedlich sind weiß ich nicht. Ich habe bisher von meinen 39 Sensoren (mit Original-FW) nur 5 Sensoren, die wie Sensor 1 sind. Alle anderen beginnen mit 1527x... Ich verstehe ja leider nur die Hälfte von allem...aber warum empfange ich jetzt überhaupt im richtigen Device, aber mit der alten Firmware nicht? Ist das nur durch Timing-Unterschiede? Wenn weitere FHEM-Logs oder Aufzeichnungen mit dem Logic-Analyzer gebraucht werden einfach bescheid geben :) |
|
Ein neues Protokoll brauchen wir glaube ich nicht. |
|
Thank you for helping to troubleshoot ReedTripRadio firmware. I am trying to offer support for "protocol 1" and stock timings so that many user receivers are compatible. I have both sonoff rev1 and rev2 hardware receivers. I also plan to move receivers so that testing is more comparable. Do you all know, is the retransmission a simple count at receiver? It may not matter either way if I just obey stock retransmission behavior but I am just trying to understand. |
Na klar. Gerne. Sensor 1: Tamper-Open Reed_Close Reed_Open Sensor 2: Tamper-Open Reed_Close (nicht erkannt) Reed_Close (erkannt) Reed_Open (nicht erkannt) Reed_Open (erkannt) |
Ich konnte nun endlich debuggen. Das problematische ist, die Erkennung der clock. |
|
Naja, ich habe das jetzt nur kurz getestet, zumindest scheint sich der Empfang nicht verschlechtert zu haben. |
Das clock Signal über die Pausen gesucht. Der kleinste Pausenwert, welcher zu >=14% im Signal vorkommt, wird als Takt angenommen. Bisher war dieses Verfahren erstaunlich gut geeignet, die Erkennungsrate ist dadurch aber nicht 100% korrekt, denn der Takt ist ja in Real unabhängig von Pause oder Puls. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Specifications for new sensor / switch / or other device ...
Specifications
Reported from here: mightymos/ReedTripRadio#4 (comment)
The text was updated successfully, but these errors were encountered: