-
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
Jarolift-Geräte #380
Comments
GitMate.io thinks the contributors most likely able to help are @sidey79, and @elektron-bbs. |
Was ist hier der Bug an dem Thema? Ich habe das leider noch nicht erfasst. |
Das Label Bug wurde angeblich von Dir gesetzt und weil ich das „komisch“ fand nahm ich ihn weg aber aus Respekt setzte ich ihn wieder weil ich mir dachte das du dir was dabei dachtest. Ich vermute, das Label wurde automatisch gesetzt in deinem Namen. Vielleicht gibt es da div. Github Einstellungen. |
Das sollten wir mal beobachten. Gitmate könnte das gemacht haben. Das wollte ich nur mal testen. Wenn das was bringt, kann ich dafür ja auch ein eigenes Konto eröffnen. Dann sieht man wer es wirklich war :) |
Würde es was bringen wenn wir versuchen eine Definition zu erstellen und dann alles durchspielen wie gehabt ;) ? Mir scheint es vorerst nicht ersichtlich eine klare eindeutige Definition zu finden weil der Datenteil sehr unterschiedlich lang immer ist. |
Hallo,
Ob nun auch andere Sensoren dazwischen gefunkt haben weiß ich nicht. Bei bedarf kann ich auch mal eine Aufnahme mit SDR# machen. Da sieht man vielleicht besser was gesendet wird. Gruß |
Ich denke es ist ein Signal mit Synchronisieren Sequenz Dafür könnte man ein Protokoll definieren. |
Was haltet Ihr von der Definition ?
Erprobung:
Auffällig ist immer, das nach der P0=-16928;P1=1524 - Trennung, Daten folgen P2=-437;P3=384. |
Das könnte auch ein Versuch sein, den Empfänger bei seinem AGC zu helfen. Wenn da wirklich eine Information übertragen wird, haben wir vielleicht eine Herausforderung |
- added ID 87 Jarolift RFD-FHEM#380 - added doc ID 5 + revised and set developer status
* Update signalduino_protocols.hash - added ID 75 developId => y (start or sync failed) https://github.com/RFD-FHEM/SIGNALDuino/issues/69#issuecomment-440349328 - added doc ID 5 + revised and set developer status - added ID 87 Jarolift #380
n'Abend |
Hallo @gandi1791 Die Umsetzung wurde noch nicht angegangen weil es da einen "codierten" Bereich gibt aber man kann einen Teil der Auswertung auslesen auf jedenfall. Bist du fähig ein Modul zu schreiben? MfG |
ja, ist vorhanden:
Ich bin nur Hobby Programmierer, mehr leider nicht. |
Das ist ja schonmal ein Anfang. Als Tester dich gewonnen zu haben ist schonmal sehr viel wert! |
Was ich nicht ganz verstehe ist das hier:
Also development=1 habe ich gesetzt, aber ,u87 ? |
WEnn du nun das attribut development gesetzt hast, so wird bei jedem drücken ein Logfile erstellt. |
ja, ist so. Das Log beim Drücken habe ich oben schon reingepastet. |
Wie sehen denn die Daten im Logfile aus? Das müsste ja mit SIGNALduino_unknown_87 beginnen. |
Habe nochmal gedrückt (Kanal 4 - hoch):
|
mach mal bitet |
Die Angabe von u87 ist veraltet... Das Attribut development lässt sich nur noch mit 0 deaktivieren und mit 1 aktivieren. |
- added correct raw´s after bit reconstruction RFD-FHEM#380 (comment) (all raw´s with _iO not recognized correctly)
Hallo!
So lange die Taste an der Fernbedienung gedrückt wird, wird kontinuierlich der gleiche Code gesendet. Also quasi unendlich...
Ich versuche mal mein Glück. Ich habe jeweils einen augenblick länger gedrückt. Die Bilder sind immer zuerst eine Übersicht (ganzer Zeitraum) und dann im Detail eine msg. CH16 STOP:
CH15 STOP
CH14 STOP
Vielleicht hilft dies ja...ich kann auch gerne noch weitere Beispiele erstellen... Gruß |
@HomeAutoUser Wie sieht dein Vorschlag hinsichtlich verschobenes Telegramm aus? Wäre hier die Lösung den MS Decoder zu deaktivieren oder soll er umgebaut werden damit der richrige Teil erkannt wird? |
Ich gehe davon aus, da es das selbe Fehlverhalten wie bei dem Atlantic Protokoll ist.
Das ist eine gute Frage. Ich kann schlecht einschätzen wie und wo noch Optionen sind um den Decoder anzupassen oder umzubauen. Du steckst da hinsichtlich besser drin. Wir könnten ggf. nur einen neuen Faden eröffnen wo man das mal diskutieren könnte oder erörtern. @Ralf9 hat ja mit #493 (comment) eine Lösung geschaffen wenn man den Decoder so belässt. Entweder man lässt es so und wird die Variante einbauen um solche "Zerstückelungen" wieder zu "reparieren" oder der Decoder muss umgebaut werden, was aber vermutlich schwieriger erscheint und die Auswirkungen auf bestehende Definitionen nicht abschätzen können. |
Ja, MS Decoder umbauen ist etwas komplex. Frage am Rande. Wieso benötigt es drei verschiedene Bezeichnungen um die Preamblesequenz zu definieren? Wie sieht die denn aus? |
@sidey79 (Sync bestehend aus Time 0 | Time 1) | Pause1 | (Nutzdaten, Time 2 | Time 3) Pause 2 ---> neue Nachricht wieder mit Sync beginnend
|
Wir müssen also nur diese Sequenz vor dem Sync senden? Dazu braucht es kein A, B, C :) |
Letztendlich ja, wenn ich das nicht falsch im Kopf habe (ist ja schon spät :-D)
gebraucht wird aber
nun sollte ich es glaube aufgedröselt haben. |
Wenn man diese Nachricht nimmt: dann ist Das sendMsg kann dann z.B. so ausehen: |
Die Sequenz ist ja fest und nicht variabel. Der SendMSG Befehl sollte möglichst nur die zu sendende Bits enthalten. Die komplette Sequenz lässt sich ja In einer preSync Bezeichnung hinterlegen. |
Wenn du das mit einer Erweiterung preSync hinbekommst, dann müssen wir das so erweitern. Nur mit dieser Anpassung kann der User nach meiner Modulfertigstellung erfolgreich testen. |
der preSync müsste dann so aussehen, dies ergibt eine recht lange Definition Die definitionen a,b und c werden dann nicht mehr benötigt, |
Wenn wir schon dabei sind, ich hätte gerne als reserve für zukünftige besondere Protokolle zum Senden eine neue Definition, z.B. U universal |
Bleiben wir erst mal bei presSync.. Ja so würde sie dann aussehen. |
@sidey79 @Ralf9 was meinst du genau mit
? |
Die universelle reserve Definition z.B. U zum Senden, könnte z.B. als zweite Pause oder eine besondere Signalfolge am Ende verwendet werden, oder auch zum experimentieren und testen von sendMsg bei zukünftige neue Protokollen |
Zur vollständigkeit, das Protokoll kann erst richtig gesendet werden wenn diese RFD-FHEM/SIGNALDuino#109 Anpassung erfolgt. Es wurde heute getestet. |
Mit meiner V 3.3.2.1-rc8 Firmware sollte es jetzt schon funktionieren, Habt Ihr mir mal einen SendMsg Befehl? |
P87#101010111010011001011101010001110111111111111111011101011001001000000010P#R2 Wenn man den Befehl ohne Anpassung von RFD-FHEM/SIGNALDuino#109 senden würde, so ergibt sich ein Sendefehler welcher ca. 5sek. den Empfänger belegt. |
* Update SIGNALduino_TOOL_Dispatch_SD_Jaro.txt - added correct raw´s after bit reconstruction #380 (comment) (all raw´s with _iO not recognized correctly) * - update - input files update with new RAWMSG´s - modul 88_SIGNALduino_TOOL.pm | fix filtre option - modul 88_SIGNALduino_TOOL.pm | rename FilterFile_x to InputFile_x attribs - modul 88_SIGNALduino_TOOL.pm | added function length Datapart
Da das Modul mitlerweile über die DEV Version verteilt wird und keine Fehler diesbezüglich im letzten Monat auftraten, so schließe ich den Faden. Bei Fehlern oder Anregungen bitte erneut zu Wort melden oder diesen Faden "reopen". MfG |
Specifications for new sensor / switch / or other device ...
USER - Anfrage direkt per PN
Hier mal die Daten der TDRCT 04W (jede Taste mehrfach aller 10sekunden gedrückt):
The text was updated successfully, but these errors were encountered: