Geiger Antriebstechnik - Rolladensteuerung

[drhirn]

Habe die DIPs jetzt in Mittelstellung. Kann den Rolladen mit der Fernbedienung noch steuern und der Code ist gleich geblieben: u46#130D0
Bestätigt also eure Theorie.

[Sidey]

Hi,

ich muss sagen. Respekt. Ihr habt euch da wirklich rein gekniet und viel heraus gefunden.
Das reicht ja schon für eine Tips und Tricks Anleitung im Wiki

Dass man mit dummys und co. so ziemlich alles machen kann, habe ich schon  geahnt, aber eine komplette Rolladensteuerung. Ich bin baff. 


Jetzt mal schnell zu den Signaldaten, die habe ich mir angesehen.

Eine Übertragung einer Nachricht sieht in etwa so aus

Code Auswählen Erweitern

P0=-32001;P1=2027;P2=-301;P3=313;P4=-2021;P5=-16083;D=121234341212343434343434123412343435;

Es wird drei oder vier mal Wiederholt.
Mit dem Protokoll ID 46 werden 17 Bit ausgewertet. Im Signal stecken allerdings 18 Bits.
Was hier passiert ist einfach ungünstig. Der Sender aktiviert das Sendemodul für das Letzte Bit in obigem Beispiel 313uS und deaktiviert es dann für etwa 2000uS. Das würde man als Signalfolge 34 nach obigem Beispiel empfangen.
Leider macht der Sender jetzt aber auch eine Pause von etwa 14ms in dem er nichts sendet.
Die 14ms + 2ms vom letzten Bit, kann der Empfänger aber nicht auseinander halten. So kommt es zu der Signalfolge 35.

Das muss ich mir noch mal ansehen, wie man das im SIGNALduino Modul am besten erkennt. Da wird mir aber schon etwas einfallen.

Kommen wir zu der Sache mit den dip Schaltern. Ich habe verstanden, es gibt unterschiedliche Fernbedienungen und die haben eine unterschiedliche Anzahl an Dipschaltern. Ist aber egal, das Signal hat immer 18 Bit. Im Zweifelsfall kann man halt einfach mehr oder weniger Bits durch die Dipschalter verändern.

Nun ist es so, dass in einem Bit genau zwei Zustände übermittelt werden können. 0 und 1.
Der Dipschalter hat aber drei Positionen. Also wird jeden dipschalter mit zwei Bits dargestellt. Dadurch lassen sich die drei mögliche Zustände darstellen. Das ist auch nichts neues, gibt es auch bei Funksteckdosen und wird dann als "tristate" Protokol bezeichnet.

Das SIGNALduino Modul demoduliert erst mal die Daten in Bits und die haben zwei Zustände. Also erst mal noch nicht ganz so wichtig.

Die Interpretation der Bits würde ich annehmen ist genau umgekeht, wie das aktuell der Fall ist. Allerdings ist das nur eine Annahme und letztendlich auch nicht wichtig.


Was euch jetzt im 1. Schritt fehlt ist wohl eine korrekte Demodulation der Funksignale. Und die dazu gehörende Sendemöglichkeit.
Das lässt sich mit einer Protokolldefinition im SIGNALduino Modul erreichen.

Passt das alles, wie ich es wiedergegeben habe?


Grüße Sidey

[fasch]

Hallo Sidey,
schön dass Du Dich hier meldest. Als Nächstes wäre ich sonst auf Dich zugekommen und hätte um Hilfe gebeten.

Das hast Du soweit richtig beschrieben.

Die Spezialitäten der DIP Codierung bei den Sendern spielt für den SIGNALduino keine Rolle. Im Endeffekt kommt beim Moter eine 9 stellige Tristate Codierung, also eine 18 stellige Bit-Codierung an. Die Abbildung ist beim Lesen und Schreiben immer gleich.

00 == +, 11 == -, 01 == 0

Laut Handbücher soll es für Markisen noch 7 stellige TriState Codes, also 14 Bits, geben, die auch von den Sendern erzeugt werden können. Ich habe aber keine Markise zum Testen. Darum würde ich das Protokoll flexibel gestalten wollen mit 14 bis 18 Bits oder ohne Beschränkung.

Wir könnten also gut mit einem 18 Bit Protokoll leben, aber schöner und lesbarer wäre natürlich eine TriState Umsetzung mit 7 bis 9 DIPs. Mein Ziel wäre also sowas wie:

Code Auswählen Erweitern


set sduino sendMsg P77#+-0--+00-#R4


Wobei R4 der Default wäre und die TriStates 7 bis 9 Zeichen haben können oder die Anzahl einfach nicht geprüft wird.

Die Message, die Du da heraus kopiert hast, war übrigens schon eine per "set raw" erzeugt Message.

Und Du hast wohl auch recht, dass das letzte Bit vermutlich beim Lesen nicht richtig erkannt wird, weil danach eine Pause kommt, die aber wohl auch nötig ist. Die Lösung wäre dann auch das Erkennen der Pause.

Da war ich bisher am Testen und habe gedacht, dass es wohl daran liegen könnte, dass u46 eine clockabs von 250 benutzt. Ich weiss nicht wirklich was es bedeutet, aber ich habe festgestellt, dass ein empfangenes Paket einen CP Verweis auf ein Feld hat, das eine Wert zwischen 280 und 320 enthält. Darum dachte ich, dass das Signal vielleicht anders getaktet ist und man es mit einer anderen clockabs besser erkennt. Vermutlich eine Sackgasse.

Die SendeModulation ist praktisch fertig und kann man direkt aus meinem cmdalias GeigerAlias übernehmen. Der wurde von mir und zwei weiteren Leuten getestet. Der übergebene TriState-Code wurde von den Motoren einwandfrei erkannt. Der cmdalias macht aus einem "set sduino sendDIP +-+000+-0#4" direkt ein "send sduino raw ...".

Beim Empfang müsste noch das letzte Bit vor der Pause erkannt werden und dann der Bit bzw. HexCode ggf. als TriState ausgegeben werden.

Gruß, Jens

[Sidey]

Hi,

Ja das mit dem tristate ist so eine Sache.

Ich habe das schon bei Funksteckdosen im Signalduino implementiert.
Wird dann halt 0, 1 oder F dargestellt.
Gut gefallen hat mir das aber bisher noch nie und war eher aus Gründen der Kompatibilität mit vorhandenen Implementierungen heraus.

Die Standard Vorgehensweise wäre:
Signalduino Modul demoduliert in Bits.
Ein Logisches Modul wandelt dann die Bits in einen Tristate Code um.

Um das mit dem Logischen Modul nicht zu komplex zu machen, könnte man erst mal das Signalduino_Unknown Modul  verwenden um die Umwandlung zu machen. Devices würde das Modul dann halt nicht anlegen aber Events generieren.

So ein Modul für Rolläden Steuerung ist ja nicht über Nacht entwickelt.

Variable Länge 14-18 ist machbar.
Wenn man es völlig unbeschränkt lässt, dann passen alle möglichen Signale. Das will auch keiner.

Was ich so grob überlegt habe:
Wenn man die Demodulierung für 0 / 1 vertauscht, dann kann man mit meinem einfachen Workaround (padding) immer ein Bit 0 anfügen, wenn es nicht 14 oder 18 Bits sind.
Dafür bräuchte ich keine neue Logik programmieren.
Das ist zwar nicht die super exakte Vorgehensweise ein Signal zu demodulieren, bislang bin ich damit aber immer gut zurecht gekommen.



Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[Sidey]

Hi,

so ich habe nun mit der Implementierung begonnen. Für die Demodulierung der Bits habe ich das Protokoll #78 angelegt.

Erst mal die Entwicklungs Version laden:

Code Auswählen Erweitern


update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt



Dann das Protokoll in einem Signalduino device über die Folgenden Attribute aktivieren (ggf. erweitert ihr die Attribute, wenn ihr dort schon Eintragungen vorgenommen habt):

Code Auswählen Erweitern


attr sduino development 78y
attr sduino  whitelist_IDs 78



Dann solltet ihr schon mal in etwa folgende Events erhalten:

Code Auswählen Erweitern

2018-01-21 21:56:30.959 SIGNALduino sduino DMSG U78#33028



Senden und das Umwandeln im un Modul ist noch offen.


Grüße Sidey

[drhirn]

Hallo Sidey,

ich hätte mal deine Schritte befolgt. Habe aber nach wie vor noch die alten Einträge im Eventmonitor:

Code Auswählen Erweitern


2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 4: Signalduino/msg READ: MU;P0=-2013;P1=2073;P2=-248;P3=331;P4=-15764;P5=576;D=012121230121230301212121230301230303412121230121230301212121230301230303412121230121230301212121230305;CP=3;R=37;
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 4: Signalduino: Fingerprint for MU Protocol id 46 -> EKX1BE matches, trying to demodulate
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 5: Signalduino: Starting demodulation at Position 1
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 5: Signalduino: dispatching bits: 0 0 0 1 0 0 1 1 0 0 0 0 1 1 0 1 1 0 0 0
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 4: Signalduino: decoded matched MU Protocol id 46 dmsg u46#130D8 length 20 RSSI = -55.5
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 5: Signalduino Dispatch: u46#130D8, test ungleich: disabled
2018-01-23 21:22:50 SIGNALduino Signalduino DMSG u46#130D8
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 5: Signalduino Dispatch: u46#130D8, -55.5 dB, dispatch
2018-01-23 21:22:50 SIGNALduino Signalduino UNKNOWNCODE u46#130D8
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 5: Signalduino: dispatching bits: 0 0 0 1 0 0 1 1 0 0 0 0 1 1 0 1 1 0 0 0
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 4: Signalduino: decoded matched MU Protocol id 46 dmsg u46#130D8 length 20 RSSI = -55.5
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 5: Signalduino Dispatch: u46#130D8, test gleich
2018-01-23 21:22:50 SIGNALduino Signalduino Signalduino 4: Signalduino Dispatch: u46#130D8, Dropped due to short time or equal msg


Hab ich etwas übersehen?

Danke!
Stefan

[Sidey]

Hatte einen Tippfehler

Code Auswählen Erweitern


attr sduino  whitelist_IDs 78


Ist erforderlich.

[drhirn]

Hatte mir auch selber auffallen können

Code Auswählen Erweitern

2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 4: Signalduino/msg READ: MU;P0=-15770;P1=2075;P2=-264;P3=326;P4=-2016;P5=948;D=012121234121234341212121234341234343012125;CP=3;R=208;
2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 4: Signalduino: Fingerprint for MU Protocol id 78 -> geiger matches, trying to demodulate
2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 5: Signalduino: Starting demodulation at Position 1
2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 5: Signalduino: dispatching bits: 1 1 1 0 1 1 0 0 1 1 1 1 0 0 1 0 0 0
2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3C8 length 18 RSSI = -98
2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 5: Signalduino Dispatch: u78#3B3C8, test ungleich: disabled
2018-01-23 22:55:30 SIGNALduino Signalduino DMSG u78#3B3C8
2018-01-23 22:55:30 SIGNALduino Signalduino Signalduino 5: Signalduino Dispatch: u78#3B3C8, -98 dB, dispatch
2018-01-23 22:55:30 SIGNALduino Signalduino UNKNOWNCODE u78#3B3C8


[Sidey]

Es müsste im Event Monitor auch ein Event auftauchen, wenn Du was vom Rolladen Sender empfängst.

Jetzt kommt der schwierigere Teil.

Wie wird denn die Bedeutung von hoch oder runter berechnet?
Ich habe das aktuell noch nicht verstanden.


Grüße Sidey

[drhirn]

Ja. Die Zeilen aus meinem vorigen Post kamen, als ich einen Knopf auf dem Rolladen-Sender gedrückt habe.
Die andere Frage kann sicher Jens beantworten.

[drhirn]

Schade, dass es hier so ruhig wurde. Alle am Schifahren?

[Sidey]

Ich fahre kein Ski....

Aber ich hatte auf mehr Details gehofft

Gesendet von meinem XT1650 mit Tapatalk

[drhirn]

Aber ich hatte auf mehr Details gehofft

Ja, ich auch

[Ralf9]

Wenn Ihr die aktuelle Entwicklungs Version habt, dann sollte der log ungefähr so aussehen:

Code Auswählen Erweitern

2018.02.17 21:13:09.688 4 : sduinoD/msg get raw: MU;P0=-15770;P1=2075;P2=-264;P3=326;P4=-2016;P5=948;D=012121234121234341212121234341234343012125;CP=3;R=208;
2018.02.17 21:13:09.688 4 : sduinoD: decoded matched MU Protocol id 78 dmsg u78#3B3C8 length 18 RSSI = -98
2018.02.17 21:13:09.688 5 : sduinoD: dispatch u78#3B3C8
2018.02.17 21:13:09.688 4 : SIGNALduino_unknown incomming msg: u78#3B3C8
2018.02.17 21:13:09.688 4 : SIGNALduino_unknown rawData: 3B3C8
2018.02.17 21:13:09.688 4 : SIGNALduino_unknown Protocol: 78
2018.02.17 21:13:09.688 4 : SIGNALduino_unknown converted to bits: 00111011001111001000
2018.02.17 21:13:09.688 4 : geiger message converted to tristate code: 01F10110F0

Und wenn in der 90_SIGNALduino_un.pm die folgende Zeile zugefügt wird
https://github.com/Ralf9/RFFHEM/blob/84d8a2a5122f4164ce87c7b51cfe5cf83d005659/FHEM/90_SIGNALduino_un.pm#L323
wird der folgende event erzeugt:

Code Auswählen Erweitern

2018-02-17 21:13:09.693 SIGNALduino sduinoD u78#3B3C8#00111011001111001000#01F10110F0

Darauf kann dann z.B. mit einem notify regiert werden.
Gesendet werden kann dann mit
set sduino sendMsg P78#00111011001111001000#R4

Ist dies für Euch so ausreichend oder möchtet Ihr dafür ein Modul programmieren?

Gruß Ralf

[derfehler]

Konnte jetzt auch testen  mit set sduino sendDIP - - -  + - +  - - -#20.
wenn ich normal sende dann wird immer die Beschattungspostion angefahren.
hatte das ganze auch schon über pilight mit rawCodeOff
462 1848 462 1848 462 1848 462 1848 462 1848 462 1848 1848 462 1848 462 462 1848 462 1848 1848 462 1848 462 462 1848 462 1848 1848 462 462 1848 1848 462 462 15778 estellt das funktioniert auch.