Geiger Antriebstechnik - Rolladensteuerung

[drhirn]

Guten Abend,

ich habe in meiner Mietwohnung eine Funk-Rolladensteuerung von Geiger Antriebstechnik. Wie ich auf einem Datenblatt lese (http://www.geiger-antriebstechnik.de/fileadmin/user_upload/documents/GEIGER_F_PDB_Funkzubehoer_100W0621_DE.pdf), werden deren Systeme in einem Frequenzband "um 434 MHz" betrieben. Könnte ich die also mit einem CUL433 steuern?

Danke!
Stefan

[rudolfkoenig]

Vermutlich nicht.

Analogie: einen Japaner kann zwar jeder hoeren, aber erst dann verstehen wenn man die Sprache gelernt hat. Wenn jemand dem culfw die Geiger-Sprache beibringt, dann klappt das mit FHEM. Es sei denn, dass Geiger einen der bekannten Sprachen (d.h. Protokolle) verwendet, was aber mAn eher unwahrscheinlich ist.

[drhirn]

Aja, verstehe. Danke für die Info!
Ich habe mal bei Geiger angefragt, ob die genauere Infos dazu liefern könnten. Falls ich was erfahre, lasse ich es euch wissen.

[fasch]

Hallo,
obwohl das Thema schon sehr lange still liegt, möchte ich es trotzdem nochmal aufnehmen.
Denn auch ich bin an der Ansteuerung von Geiger Antriebstechnik interessiert.
Die Frage wäre, welche Wege es gibt den Code zu entschlüsseln, auch wenn der
Hersteller scheinbar keine weitere Unterstützung geliefert hat.

Vielleicht helfen ja ein paar Informationen, die ich selber gesammelt habe.
Der Sender arbeitet eindeutig im 433,92 Mhz Bereich mit festen Codes.
Dies ergibt sich aus Unterlagen von Geiger, sowie aus Angeboten bei Amazon
von Geiger kompatiblen Handsendern. Verwundert hat mich die Codierung des
Handsenders mit 11 Dip-Schaltern, die jeweils drei Stellungen haben, nämlich + 0 -
Das ergibt 3 hoch 11 = 177147 mögliche Codes.

Ich denke also, es müsste möglich sein die Codes mit einem nanoCUL 433
zu empfangen oder zu senden. Leider bin ich bei der Entschlüsselung da noch
nicht weiter. Ich hatte gehofft, dass mit dem nanoCUL eine Art Clone Funktion
aufbauen könnte, aber da bin ich noch nicht weiter. Ich habe einen Geiger
Handsender, auf dem ich beliebige Codes einstellen kann. Aber ich habe bisher
noch nichts empfangen.

Habe ich da eine Chance weiter zu kommen?

Ach ja:
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) nanoCUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB

Gruß, Jens

[drhirn]

Danke für's Wiederbeleben meine Frage
Bei mir ist das Thema leider eingeschlafen, nachdem ich keinerlei brauchbare Aussagen des Herstellers bekommen habe. Hab dann auch kurz mit einem NanoCUL herumgespielt, aber leider keine verwertbaren Ergebnisse erhalten.

[derfehler]

Hallo

ich habe mal den Coad entschlüsselt. leider komme ich nicht weiter wie ich diesen in ein Protokoll packen muss.
konntemit : pilight-send -p raw -c den code senden und für die Anderen Rolladen den Code berechnen, für den Befehl.
Hier meine Erkenntnisse zum Code:  ein + ist 1848 462 1848 462 ein o ist 1848 462 462 1848 ein - ist  462 1848 462 1848

1848 462 1848 462  = +
1848 462 1848 462  = +
1848 462 1848 462  = +
1848 462 462 1848  = o
462 1848 462 1848  = -
1848 462 1848 462  = +
462 1848 462 1848  = -
1848 462 462 1848   Werden Selbst vergeben = o Kommt auf die Taste vom Sender an
462 1848 462 15708   Runter

Telegramm Hoch 1848 462 462 15708

pilight-send -p raw -c "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 462 1848 462 1848 462 1848 462 15708"

[derfehler]

Hersteller des Geiger Funk ist http://www.tedsen.com/index.php?id=155

[Hakanzaza]

Hallo ich bin hier auch sehr neu!!
ich habe auch Geiger Funk Motoren.
dies sind mit tedsen santed webbox verbunden.
ich kann sie per app steuern und das ganze ist im Netz.
nun wies jemand wie ich das ganze in fehm einbinden kann und mit alexa steuern könnte??

http://www.tedsen.com/index.php?id=109

[sommer]

Hallo,
ich bin auch interessiert, ob es eine Möglichkeit gibt Geiger Funk Motoren mit Fhem zu steuern.
Hab versucht mit den Hinweisen etwas anzufangen, leider ohne Erfolg.
Hat es evtl. jemand bereits hinbekommen die Geiger Motoren zu steuern?

[fasch]

Hallo,
auch ich muss sagen, dass bei mir das Thema wieder eingschlafen ist, weil ich es nicht hinbekommen habe, überhaupt was zu empfangen.

Inzwischen weiss ich aber, dass ich einfach den falschen Weg gegangen bin.
Ich hatte einen nanoCUL gekauft, mit culfw betankt und dann mit "define nanoCUL CUL" gearbeitet. Damit empfängt man garnichts, egal welche culfw man benutzt.

Heute habe ich mal einfach einen anderen Weg probiert. Ich habe jetzt mal probeweise SIGNALduino für FHEM eingespielt und die Firmware nanoCC1101 auf meinen nanoCUL eingespielt. Laut Platine ist mein nanoCUL ein Nano V3.0 mit Mega 328P AU1532 und CC1101. Ich weiss zwar nicht, ob das überhaupt zusammen passt, aber jetzt empfange ich zumindest etwas. Wenn ich irgendwie weiter komme, dann damit.

Der gesendete Code ist: +-+ --- 00-

Aus dem log mit debug und verbose:

2018.01.02 18:31:05 5: sduino/RAW READ: ^BMU;P/0=313;P1=1212;P2=-309;P4=-2024;P5=-16091;P6=2014;D=01204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040;CP=0;R=236;^C

2018.01.02 18:31:05 4: sduino/msg READ: ^BMU;P0=313;P1=1212;P2=-309;P4=-2024;P5=-16091;P6=2014;D=01204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040;CP=0;R=236;^C
2018.01.02 18:31:05 1: DEBUG>sduino: incomming message: (MU;P0=313;P1=1212;P2=-309;P4=-2024;P5=-16091;P6=2014;D=01204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040;CP=0;R=236;)
2018.01.02 18:31:05 1: DEBUG>sduino: extracted  pattern 0 313

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  pattern 1 1212

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  pattern 2 -309

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  pattern 4 -2024

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  pattern 5 -16091

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  pattern 6 2014

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  data 01204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040562620404626204040404040462046204040

2018.01.02 18:31:05 1: DEBUG>sduino: extracted  clockidx 0
2018.01.02 18:31:05 1: DEBUG>sduino: extracted RSSI 236

2018.01.02 18:31:05 1: DEBUG>sduino: processing unsynced message

2018.01.02 18:31:05 1: DEBUG>Testing against Protocol id 13.1 -> FLAMINGO FA21 b
2018.01.02 18:31:05 1: DEBUG>Expect 76 bits in message
........


Wenn überhaupt kommt man wohl in dieser Richtung weiter. Ich hoffe, ich finde Zeit für weitere Tests.

Mittendrin im log fand ich auch:
2018.01.02 18:56:25 4: SIGNALduino_unknown Protocol: 46
2018.01.02 18:56:25 4: SIGNALduino_unknown converted to bits: 00110011111101011000

Wenn ich dort einsetze: 00 == +, 11 == -, 01 == 0
dann bin ich schon fast am Ergebnis.

Gruß, Jens

[sommer]

Hallo Jens,

vielen Dank für Dein schnelles Update, wäre natürlich super wenn Du da weiterkommen würdest.

[fasch]

Hallo,
ich wollte mal einen Zwischenstand zu meinen bisherigen Tests geben, da ich glaube, dass ich auf dem richtigen Weg bin. Vielleicht horchen ja auch ein paar Leute mit, die mehr Erfahrung haben als ich und können bei den offenen Problemen helfen.

Wie ich bereits berichtete habe ich einen nanoCUL433 (Mega 328P) mit CC1101 fertig bei ebay gekauft. Meine vorherigen Versuche haben alle nichts gebracht, aber jetzt kann ich mit SIGNALduino Meldungen empfangen und tatsächlich auch erfolgreich als Raw Message wieder raussenden. Nur bei der Decodierung der Message fehlt noch ein Bit.

Hier meine Installation.
Ich habe die Installationsanleitung in https://wiki.fhem.de/wiki/SIGNALduino#Einbinden_in_FHEM exakt befolgt. Und dann dieses Objekt erzeugt:

Code Auswählen Erweitern


defmod sduino SIGNALduino /dev/serial/by-id/usb-FTDI_USB__-__Serial_Cable_12345678-if00-port0
attr sduino cc1101_frequency 433.920
attr sduino debug 1
attr sduino flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr sduino hardware nanoCC1101
attr sduino rawmsgEvent 1
attr sduino whitelist_IDs 46


Das flashCommand Attribut wird automatisch erzeugt. Mit

Code Auswählen Erweitern


set sduino flash
set sduino reset

hat man dann hoffentlich einen laufenden nanoCUL. Das kann man auch anhand der Readings prüfen.

Code Auswählen Erweitern


ccconf      freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
ccpatable   C3E = 00 60 00 00 00 00 00 00  => 0_dBm
cmds        V R t X F S P C r W x e
config      MS=1;;MU=1;;MC=1
ping        OK
state      opened
version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50


Zusätzlich habe ich einen kleinen Eventhandler geschrieben, der erstmal nur Debug Ausgaben macht.

Code Auswählen Erweitern


defmod sduino_event notify sduino:DMSG.*|sduino:RAWMSG.* { Log 1, "DEBUGsduino " . $EVENT }
attr sduino_event verbose 1


Mit diesem Handler finde ich nach einem Druck auf die Fernbedienung unter anderem folgende Nachricht im Log.

Code Auswählen Erweitern


2018.01.03 17:29:46 1: DEBUGsduino RAWMSG MU;P0=-32001;P1=2027;P2=-301;P3=313;P4=-2021;P5=-16083;D=012123434121234343434343412341234343512123434121234343434343412341234343512123434121234343434343412341234343512123434121234343434343412341234343;CP=3;R=0;


Von dieser Message nehme ich die Felder P0-P5 und D und schicke sie per RAW wieder mit dem Prefix SR;R=3; wieder raus. Vorher muss ich natürlich das Rollo in die Gegenrichtung bewegen damit was passiert und dann:

Code Auswählen Erweitern


set sduino raw SR;R=3;P0=-32001;P1=2027;P2=-301;P3=313;P4=-2021;P5=-16083;D=012123434121234343434343412341234343512123434121234343434343412341234343512123434121234343434343412341234343512123434121234343434343412341234343;


Und schon bewegt sich das Rollo.

Mein Problem ist das Dekodieren der Message. Ich hatte ja schon festgestellt, dass es eine Darstellung für den von Geiger genutzten Code gibt:

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

Bei einer 9 stelligen Kennung ergibt das 18 Bit übertragene Daten. Das Protokoll 46 vom SIGNALduino, EKX1BE, findet bei mir aber nur 17 Bit. Das letzte Bit fehlt immer, aber die restlichen passen. Darum habe ich den DMESG Eventhandler angestellt. Im log steht jetzt unter anderem:

Code Auswählen Erweitern


2018.01.03 17:29:46 1: DEBUGsduino DMSG u46#33F58
....
2018.01.03 17:29:46 1: DEBUG>sduino: demodulated message raw (0 0 1 1 0 0 1 1 1 1 1 1 0 1 0 1 1), 17 bits
....
2018.01.03 17:29:46 1: DEBUG>sduino: padding 0 bit to bit_msg array
2018.01.03 17:29:46 1: DEBUG>sduino: padding 0 bit to bit_msg array
2018.01.03 17:29:46 1: DEBUG>sduino: padding 0 bit to bit_msg array
2018.01.03 17:29:46 1: DEBUG>sduino: dispatching now msg: u46#33F58


Die Hexzahl nach dem u46# ist nichts anderes als die umgewandelten Bits nach hex.
also:

Code Auswählen Erweitern


3 == 0011 == +-
3 == 0011 == +-
F == 1111 == --
5 == 0101 == 00
8 == 1000 (hier sind leider 3 Ziffern padding, wäre es 18 Bit, dann hätten wir 1100 also - mit padding)
ergibt: +-+ --- 00- wobei das letzte Bit fehlt.


Nun bin ich also auf der Suche nach dem 18 Bit. Wenn ich das hätte, könnte ich mit dem EventHandler sinnvoll verzweigen. Das könnte ich wohl hinbekommen.

Kennt jemand das SIGNALduino näher? Wo kann man da noch drehen um alles sauber zu bekommen? Ich denke mal es ist einer der Werte, die im Modul 00_SIGNALduino.pm definiert sind. Das EKX1BE Protokoll passt scheinbar nicht ganz genau.

Gruß, Jens

[sommer]

Hallo Jens,

ich musste mir noch ein nanoCul zusammenbauen (hatte zum Glück alles da ).
Ich habe alle Schritte von Dir übernommen und konnte ebenso alles nachvollziehen.
Seltsamerweise funktioniert der "set sduino raw ...." bei mir nicht immer (mit meinen aufgezeichneten P1-P5 und D), mal funktioniert es, mal nicht. Ich habe noch nicht ganz verstanden warum das so ist (unabhängig, ob rauf oder runter).

Mir ist allerdings noch folgendes ausgefallen, mein Sende code (DIP) ist folgende:
DIP=-++--+-+-
Ich habe keine Mittelstellung (0).
Mein nanoCul gibt folgenden Ausgabe für u46 im Log aus:
Rollanden hoch:
u46#C3CD0 -> 11 00 00 11 11 00 11 01 0000

Rollladen runter:
u46#C3CD8 -> 11 00 00 11 11 00 11 01 1000

Also irgendwie passen nur 7 DIP's, die letzten zwei DIP's werden nicht so dargestellt?

Gruß

[fasch]

Hallo,
als richtiges Ergebnis hätte ich jetzt
11 00 00 11 11 00 11 00 11
und für die Gegenrichtung evtl.
11 00 00 11 11 00 11 01 00
oder
11 00 00 11 11 00 11 11 00
erwartet. Auf jeden Fall 18 bit. Aber es passt auch zu meinem Phänomen mit dem fehlenden 18 Bit. Ich denke es hat was mit dem Timing zu tun. Das Protokoll 46 geht von 250 ms pro Flanke aus. Tatsächlich scheinen hier aber ca. 280 ms genutzt zu werden. Achte mal in den Raw Daten auf den CP= Wert. Wenn der z.B. 3 ist, dann gilt der Wert aus P3 als Timing. Bei mir ist das immer um 280. Ich verstehe allerdings zuwenig von dem ganzen Ablauf um genaueres sagen zu können. Ich werde mal versuchen mit den Entwicklern vom SIGNALduino Kontakt aufzunehmen und Hilfe zu suchen. Im Moment beschäftige ich mich allerdings mehr damit ein reines Sendemodul auf Basis der ausgelesen Raw-Daten zu schreiben. Das interessiert mich mehr als das Empfangen.

Beim Lesen weiterer Artikel habe ich bemerkt, das dort gerne "get sduino raw" anstatt "set" genommen wird. Der Effekt scheint der gleiche zu sein, da der Parameter erst mal in die Register geschrieben wird und der SR Präfix (Send Raw) zum Senden führt. Versuche es doch mal mit get statt set. Und überprüfe öfter den Eintrag in ccconf. Bei mir geht gerne mal die Bwidth von 325 auf 25 runter und dann läuft nichts mehr, bis ich das wieder korrigiere. Und dann brauche ich auch öfter mal ein Refresh der Web-Seite, weil Änderungen ansonsten mit einer ziemlichen Verzögerung angezeigt werden.

Dann ist mir aufgefallen, dass der von mir genannte Link auf eine veraltete Version verweist. Der aktuelle Link ist https://wiki.fhem.de/wiki/SIGNALduino Ich empfehle ein Update wie dort angegeben. In der Befehlszeile im FHEM eingeben:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
Die Firmware ist aber noch die Gleiche.

Benutzt Du einen Original Geiger/Tedsen Sender? Ich nutze den Geiger GF0043 und GF2005. Die haben beide die Mittelstellung. Dann habe ich noch ein paar billige Anlern-Sender.

Gruß,

[sommer]

Hallo,

danke für den Link, hat aber schon gepasst. Ich hatte die Schritte aus dem Wiki übernommen.

Ich benutze bisher nur einfache Handsender (GF0001) und einen zentralen Wandsender (Clocksender).
Daher kann ich mit den Sender auch nur die Signale für hoch und runter aufzeichnen. Zum Stoppen des Rollladen an einer beliebigen Stelle muss ich die Gegenrichtung kurz drücken. Würde mich schon interessieren, ob es auch einen eigenen Code für das Stoppen gibt.

Ansonsten würde ich erstmal auch nur die aufgenommenen Signale verwenden um eine einfachen Steuerung mit dummy module zu erstellen.
Die sende-Daten hab ich nun soweit gekürzt, das ich sogar ohne Aufzeichnung den Sendecode erstellen kann auf basis der DIP Stellung.

Meine Aufzeichnung sieht ja so aus:

Code Auswählen Erweitern

P0=-32001;P1=337;P2=-1981;P3=2068;P4=-255;P5=-15660;D=01212343434341212121234341212341212151212343434341212121234341212341212151212343434341212121234341212341212151212343434341212121234341212341212151212343434341212121234341212341212151212343434341212121234341

Wenn man das ganze etwas auseinander zieht kann man folgende Blöcke bei den Daten erstellen:
P0=-32001;P1=337;P2=-1981;P3=2068;P4=-255;P5=-15660;D=0 1212 3434 3434 1212 1212 3434 1212 34 1212 15 1212 3434 3434 1212 1212 3434 1212 34 1212 15 1212 .....

Vom Signal 0 bis Signal 15 sind die gleichen Blöcke wie zwischen den zwei 15'er Signale, diese wiederholen sich bis zum ende.
Des weiteren entsprechen die Signale (fast) meinen DIP Stellung, wenn man für "-" = 1212 und "+" = 3434 verwendet.
Das sind meine DIP Einstellungen für den einen Sender: -++--+-+-
Das heisst, ich brauche nur die Signale zwischen 0 und 15.

Ausnahme sind die letzten zwei DIP's. Der 8 DIP wird nur mit 2 Signalen dargestellt (statt ansonsten mit 4) und der 9 Block ist wieder komplett aber
im 9 Block wird auch die Richtung des Rollladen codiert.

In dem Fall ist der 9 Block 1212 (P1P2P1P2) - bedeutet Rollladen runter, wenn man den code auf 1234 (P1P2P3P4) so fährt der Rolladen nach oben.
Dieses Schema habe ich bei einem weiteren Rollladen angewendet und hat sofort funktioniert.

Mein sende Zeile sieht nun so aus (für hochfahren):

Code Auswählen Erweitern

set sduino raw SR;;R=20;;P0=-32001;;P1=337;;P2=-1981;;P3=2068;;P4=-255;;P5=-15660;;D=0121234343434121212123434121234123415;; 

Bei den Werten für P1-P5 verwende ich immer die gleichen (klar..).

Jens (fasch), Du hast gemeint einen eigenen Sendemodul zu erstellen, wie willst Du das machen bzw. was soll es enthalten?

Gruß