Geiger Antriebstechnik - Rolladensteuerung

Begonnen von drhirn, 14 Juli 2015, 20:10:23

Vorheriges Thema - Nächstes Thema

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

#5
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

#6
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

#8
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:

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

set sduino flash
set sduino reset

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

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.


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.


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:

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:


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:

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:
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:
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):
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ß

fasch

Hallo,
erstmal zu den allgemeinen Fragen. Nein, es gibt keinen speziellen Stop Befehl, es gibt nur Auf und Ab, zum Stoppen muss man die Gegenrichtung drücken. Es gibt noch die Möglichkeit eine Zwischenposition einzulernen, das bedeutet aber, dass das normale Auf und Ab dann jeweils auf die Zwischenlage geht. Um zur Endlage zu kommen muss man dann mindestens 1,5 Sekunden drücken. Ich glaube das gefällt mir nicht.

Ich glaube, ich habe mich etwas unglücklich ausgedrückt. Auch ich will mich erstmal mit Dummys auf die Sendeseite konzentrieren und ich habe genau die gleiche Analyse gemacht wie Du. Und ich bin mit meinem Dummy und einem CommandAlias fertig. Deine Analyse passt dazu und bei mir funktioniert das jetzt perfekt.

Ich habe jetzt einen Dummy, bei dem ich ein Rollo/Fenster auswählen kann und dann Auf oder Ab anwählen kann. Als Eingabe benötige ich nur den DIP Code, denn ich in einen Raw Befehle umwandele. Das Dummy hat 2 weitere Settings: sendRepeats == (default 4) Anzahl Wiederholungen beim Senden und duinoName ist der Name des SIGNALduino, der is bei mir und als default: sduino.

Über eine Liste wird das Rollo gewählt und dann Auf oder Ab, enstpricht "set Rollos windowName Schlafen; set Rollos up". Zum direkten Aufruf per set geht auch "set Rollos (up|down) Schlafen".

Wäre schön, wenn Du Dir das anpassen könntest und dann mal testen würdest. Das Ergebnis würde ich gerne wissen. Ich denke Du kannst das ohne weitere Hilfe.

Weitere Hinweise:
Vor dem Rollo wird noch der vermutete Zustand des Rollos gezeigt, den will ich dann später mit empfangenen Signalen updaten, darum ist das etwas aufwendiger vorbereitet. Außerdem gibt es etwas Code, der den vermuteten Zustand einzelner Fenster anpasst, wenn eine Gruppe aktiviert wird.

Wie ich einen SIGNALduino namens sduino eingerichtet habe, habe ich ja bereits beschrieben. Und hier der Rest aus der Raw-Ansicht:


defmod Rollos dummy
attr Rollos cmdIcon up:fts_shutter_up down:fts_shutter_down
attr Rollos devStateIcon .*isdown:fts_shutter_down@#EE7621 .*isup:fts_shutter_up@#EE7621 .*down:fts_shutter_down@green .*up:fts_shutter_up@green .*:fts_shutter_updown@#EE7621
attr Rollos group 20 Rolladen
attr Rollos readingList windowName sendRepeats duinoName
attr Rollos room Rolladen
attr Rollos setList up:noArg down:noArg windowName:Kueche,Terrasse,Sued1,Sued2,West1,West2,Arbeit,Schlafen,Bad,Kind,AlleOben,AlleWohnen,PraxisWest,PraxisNord,PraxisFlur,PraxisWC,AllePraxis,AlleUnten sendRepeats:slider,1,1,9 duinoName:textField
attr Rollos verbose 4
attr Rollos webCmd windowName:up:down

defmod RollosAlias cmdalias set Rollos (up|down|windowName|sendRepeats|duinoName).* AS {\
### Format is:    set Rollos up|down|windowName [ < windowname > ]\
### do not catch: set Rollos < windowname > < any value > ## recursion\
### readingsVal windowname is used or set, on windowname, if no windowname is given\
\
my $verb = 1;;\
Log 1, '#' .  $EVENT . '#';;\
my ($dev, $cmd, $win) = split(/\s+/, $EVENT);;\
$win = ReadingsVal($dev, 'windowName', 'none') unless ($win);;\
Log 4, join(' ', ('set', $dev, $cmd, $win));;\
if ($cmd =~ /^(up|down)$/) {\
my %codes = (\
'upPraxisWest' => '+-+ --0 000', 'downPraxisWest' => '+-+ --0 00-',\
'upPraxisNord' => '+-+ --0 0-0', 'downPraxisNord' => '+-+ --0 0--',\
'upPraxisFlur' => '+-+ --0 00+', 'downPraxisFlur' => '+-+ --0 0+0',\
'upPraxisWC' => '+-+ --0 -00', 'downPraxisWC' => '+-+ --0 -0-',\
'upAllePraxis' => '+-+ --0 --0', 'downAllePraxis' => '+-+ --0 ---',\
'upAlleUnten' => '+-+ --0 -0+', 'downAlleUnten' => '+-+ --0 -+0',\
'upKueche' => '+-+ --+ 000', 'downKueche' => '+-+ --+ 00-',\
'upTerrasse' => '+-+ --+ 0-0', 'downTerrasse' => '+-+ --+ 0--',\
'upSued1' => '+-+ --+ 00+', 'downSued1' => '+-+ --+ 0+0',\
'upSued2' => '+-+ --+ -00', 'downSued2' => '+-+ --+ -0-',\
'upWest1' => '+-+ --+ --0', 'downWest1' => '+-+ --+ ---',\
'upWest2' => '+-+ --+ -0+', 'downWest2' => '+-+ --+ -+0',\
'upArbeit' => '+-+ --- 000', 'downArbeit' => '+-+ --- 00-',\
'upSchlafen' => '+-+ --- 0-0', 'downSchlafen' => '+-+ --- 0--',\
'upBad' => '+-+ --- 00+', 'downBad' => '+-+ --- 0+0',\
'upKind' => '+-+ --- -00', 'downKind' => '+-+ --- -0-',\
'upAlleOben' => '+-+ --- --0', 'downAlleOben' => '+-+ --- ---',\
'upAlleWohnen' => '+-+ --- -0+', 'downAlleWohnen' => '+-+ --- -+0',\
);;\
### Groups, change status of windownames\
my %groups = (\
'AlleOben' => ['Arbeit','Schlafen','Bad','Kind'],\
'AllePraxis' => ['PraxisWest','PraxisNord','PraxisFlur','PraxisWC'],\
'AlleWohnen' => ['Terrasse','Sued1','Sued2','West1','West2'],\
'AlleUnten' => ['Kueche','AlleWohnen','AllePraxis']\
);;\
my $g;;\
my @rooms = ();;\
foreach $g (@{$groups{$win}}) {\
push(@rooms, defined($groups{$g})? @{$groups{$g}} : $g);;\
}\
foreach $g (@rooms) {\
Log 4, join(' ', 'setreading', $dev, $g, $cmd);; \
fhem(join(' ', 'setreading', $dev, $g, $cmd), $verb);;\
};;\
fhem(join(' ', 'setreading', $dev, $win, $cmd), $verb);;\
fhem(join(' ', 'set', $dev, $win, $cmd), $verb);;\
my $inx = $cmd . $win;;\
if (defined($codes{$inx})) {\
my $rawmesg = $codes{$inx};;\
$rawmesg =~ s/ //g;;\
$rawmesg =~ s/0/01/g;;\
$rawmesg =~ s/\+/00/g;;\
$rawmesg =~ s/-/11/g;;\
$rawmesg =~ s/1/34/g;;\
$rawmesg =~ s/0/12/g;;\
### Definition for last bit 0 or 1\
my $p5 = ($rawmesg =~ /2$/) ? '-2045' : '-16092';;\
### last value is 5 always\
$rawmesg =~ s/.$/5/;;\
$rawmesg = 'set ' . ReadingsVal($dev, 'duinoName', 'sduino') . ' raw SR;;R=' . ReadingsVal($dev, 'sendRepeats', '4')\
. ';;P0=-32001;;P1=2039;;P2=-298;;P3=321;;P4=-2010;;P5=' . $p5 . ';;D=0' . $rawmesg . ';;';;\
Log 4, "convert: " . $codes{$inx} . " " . $rawmesg;;\
### escape all semicolon\
$rawmesg =~ s/;;/;;;;/g;;\
fhem($rawmesg, $verb);;\
}\
} elsif ($cmd eq 'windowName') {\
my $lastval = 'is' . ReadingsVal($dev, $win, 'none');;\
fhem(join(' ', 'setreading', $dev, $cmd, $win), $verb);;\
fhem(join(' ', 'setstate', $dev, $win, $lastval), $verb);;\
fhem(join(' ', 'set', $dev, $win, $lastval), $verb);;\
} elsif (($cmd eq 'sendRepeats' && $win =~ /^[1-9]$/) || ($cmd eq 'duinoName' && $win ne '')) {\
fhem(join(' ', 'setreading', $dev, $cmd, $win), $verb);;\
$win = ReadingsVal($dev, 'windowName', 'none');;\
my $lastval = 'is' . ReadingsVal($dev, $win, 'none');;\
fhem(join(' ', 'set', $dev, $win, $lastval), $verb);;\
} else {\
Log 4, join(' ', 'set', $dev, $cmd, $win, ': unknown cmd');;\
}\
}
attr RollosAlias verbose 4

setstate RollosAlias defined



fasch

Heir noch zwei Screenshots. Der vermutete Rollo-Status ist dunkelgelb nach dem Auswählen des Rollos und grün, nach einer Aktivierung.

fasch

Nochmal Hallo,
für einen Test habe ich wohl zuviel spezifisches reingeschrieben. Daher jetzt nochmal einfacher.
Alles was wir brauchen ist ein sendMsg für Geiger DIP Codes. Also habe ich daraus jetzt einen cmdalias für
set sduino sendDIP --++00-0+#4
Leerzeichenm können zusätzlich eingefügt werden und werden ignoriert. #<resends> ist optional und per default 4. Es geht also auch:
set sduino sendDIP --+ +00 -0+
Hier die Raw Definition eines cmdalias für ein SIGNALduino namens sduino:

defmod GeigerAlias cmdalias set sduino sendDIP .* AS {\
my ($dev, $cmd, $params) = split(/\s+/, $EVENT, 3);;\
Log 0, 'sendDIP#' .  $dev . ':' . ':' . $cmd . ':' . $params . ':';;\
$params =~ s/\s//g;;\
my ($parm, $repeats) = split('#', $params);;\
$repeats = 4 unless ($repeats);;\
$parm =~ s/0/1234/g;;\
$parm =~ s/\+/1212/g;;\
$parm =~ s/-/3434/g;;\
my $p5 = ($parm =~ /2$/) ? '-2045' : '-16092';;\
$parm =~ s/.$/5/;;\
$parm = 'set ' . $dev . ' raw SR;;R=' . $repeats\
. ';;P0=-32001;;P1=2039;;P2=-298;;P3=321;;P4=-2010;;P5=' . $p5 . ';;D=0' . $parm . ';;';;\
Log 0, "converted: " . $parm;;\
### escape all semicolon\
$parm =~ s/;;/;;;;/g;;\
fhem($parm);;\
}

setstate GeigerAlias defined


Wenn das ein paar Leute testen können und das überall funktioniert, können wir das ggf. an die SIGNALduino Leute geben.

sommer

Hallo,

erstmal super Idee.
Bei mir hat das GeigerAlias aber nicht ganz funktioniert, ich musste ein paar Kleinigkeiten ändern:


1 defmod GeigerAlias cmdalias set sduino sendDIP .* AS {\
2 my ($dev, $cmd, $params) = split(/\s+/, $EVENT, 3);;\
3 Log 0, 'sendDIP#' .  $dev . ':' . ':' . $cmd . ':' . $params . ':';;\
4 $params =~ s/\s//g;;\
5 my ($parm, $repeats) = split('#', $params);;\
6 $repeats = 4 unless ($repeats);;\
7 $parm =~ s/0/1234/g;;\
8 $parm =~ s/\+/1212/g;;\
9 $parm =~ s/-/3434/g;;\
10 $parm = substr($parm, 0, 30) . substr($parm, 32, 36);;\
11 my $p5 = ($parm =~ /2$/) ? '-2045' : '-16092';;\
12 $parm =$parm . '35';;\
13 $parm = 'set ' . $dev . ' raw SR;;;;R=' . $repeats\
14 . ';;;;P0=-32001;;;;P1=2039;;;;P2=-298;;;;P3=321;;;;P4=-2010;;;;P5=' . $p5 . ';;;;D=0' . $parm . ';;;;';;\
15 Log 0, "converted: " . $parm;;\
16 ### escape all semicolon\
17 $parm =~ s/;;;;/;;;;;;;;/g;;\
18 fhem($parm);;\
19 }


Wie ich in meinem letzten Post beschrieben habe, hat das 8 DIP (bei mir) nur 2 Signale (statt 4), daher habe ich die Zeile 10 hinzugefügt (gibt bestimmt noch andere Arten 2 Zeichen zu entfernen :-) ).
Zeile 12 - Die Abschlusssignale kommen einfach mit dazu (mit den fixen P Werten ist es immer 35).
Mit diesen zwei Änderungen hat es bei mir funktioniert (mit rauf und runter fahren).

Ich gehe mal davon aus, das es hiermit bei Dir nicht funktioniert (wobei ich bei Deinem raw signal auch diesen Eigenheit im 8 DIP finde - oder interpretiere ich da etwas falsches?).

Eventuell könnte man die beiden Arten kombinieren?

Gruß

fasch

Hallo,
die Geiger Motoren brauchen immer einen Neunstelligen DIP Code. Ich habe mir bewusst nicht die Mühe gemacht die Länge im Code zu prüfen. Vielleicht gibt es neben Geiger ja noch andere passende Hersteller mit anderer Länge. Entweder es klappt oder eben nicht. Obwohl es immer ein neunstelliger Code ist, ist es eigentlich immer so, dass Du nur eine DIP Reihe für Deinen Sender hast. Die haben je nach Anzahl der Kanäle keine Lust auf 2, 4 oder mehr DIP Reihen. Wenn es ein 2 Kanal Sender (Auf und Ab) ist, dann sind es eben 8 Dips und den neunten legt der Sender selber fest, einen für Auf und einen für Ab. Ich habe einen 12 Kanal Sender, den GF2005, dort habe ich eben tatsächlich nur eine DIP Reihe, bei der nur die ersten 6 Dips ausgewertet werden und die restlichen 3 kommen je nach Kanal Position dazu. Nur die programmierbaren Sender kannst Du wirklich frei belegen, ansonsten hast Du nur die Wahl des Anfangpunkts.

Anstatt der 35 hättest Du einfach einen neunten DIP hinzufügen können eine Null wäre 1234, ein Minus wäre eine 3434, ein Plus wäre 1212  und die letzte Ziffer wird dann auch von meinem Code immer in eine 5 umgewandelt. Und P5 wird danach gesetzt, ob es ursprünglich eine 2 oder 4 hinten war.

Also schicke doch einfach 9 DIPs und probiere alle 3 Möglichkeiten dafür aus. Einer davon ist dann vermutlich Auf und ein weiterer ist Ab.

Gruß zurück.

sommer

Hallo Jens,
Deine Ausführungen sind natürlich komplett richtig und passen auch bei mir.
Ich hab mich tatsächlich von meinem Ein-Kanal Sender (GF0001) etwas irritieren lassen, was den 8. und 9. DIP angeht.
Mir ist bei meinen Codes nicht aufgefallen das die 0 == 3412 ist (was bei Deinen Px Werten = 1234 ist) - ähm ich hoffe das war verständlich. Nun ja, ich denke ich habe mein Fehler gefunden.

Meine Änderungen an den GeigerAlias sind natürlich unnötig (und passen ja auch nur auf meinen einen Handsender).

Hab den GeigerAlias im Original von Dir wieder eingespielt und konnte es an einigen Rollläden erfolgreich Testen. Nochmals vielen Dank.

Ich würde auch noch den RollosAlias von Dir auch bei mir Einspielen (mit meinen Rollläden natürlich) und auch Testen. Ich würde Dir auch Feedback dazu geben (das könnte allerdings ein paar Tage dauern).

Gruß 

drhirn

Nachdem ich leider nur ungefähr eine Ahnung habe, von was ihr redet: Wäre es eventuell möglich, nach Abschluss eurer Recherchen eine Dummy-Erklärung zu schreiben?
Danke!

fasch

Na gut,
ich versuche mal eine Zusammenfassung, evtl. kann man da ja ein Wiki daraus machen.

Summary:

Es geht um funk-gesteuerte Rolladen der Firma Geiger Serie GF. Sender gibt es von Geiger oder Tedsen. Anlernbare 434Mhz Billigsender können auch genutzt werden. Es gibt programmierbare Sender und Sender mit DIP-Schaltern, die jeweils 3 Positionen kennen, nämlich +, 0 und -.

Für die Motoren mit ihren Funk-Empfängern gilt: Die Funkempfänger kennen genau zwei Befehle, nämlich AUF und AB. Der Stopp erfolgt, wenn der Sender das Signal der Gegenrichtung sendet oder wenn die Endlage erreicht wurde. Man kann auch zusätzlich eine Zwischenposition definieren. Dann erfolgt der Stopp an der Zwischenposition. Zum Überspringen der Zwischenposition muss man beim Sender die Richtungstaste länger als 1,5 Sekunden drücken, dann geht das Rollo direkt zur Endlage. Oder man muss nach Erreichen der Zwischenlage ein zweites Mal drücken. Geiger nutzt einen statischen (non-rolling) Code im Bereich 433.92 Mhz. Es gibt keine Rückmeldungen vom Motor über die aktuelle Stellung. Für Rolladen ist jeder einzelne Befehl ein genau 9 stelliger Code, also z.B.  "-+- +0+ 000" für AUF und "-+- +0+ 00-" für AB. Die Codes werden über den Sender eingelernt. Markisen nutzen meines Wissens nur einen 7 stelligen Code. Jeder Empfänger kann bis zu 3 Sender (also 6 Codes) einlernen, damit können auch Gruppen eingelernt werden.

Es gibt Sender für unterschiedliche Anzahlen von Rollos, also z.B. 1, 2, 4, 6, 18, 50. Das entspricht jeweils der doppelten Anzahl Codes (AUF und AB). Etwas verwirrend: Ein mit DIP Schaltern zu programmierender Sender hat nur eine Reihe mit bis zu 9 DIP-Schaltern. Hiermit wird sozusagen nur der erste Code oder Präfix eingestellt, den Rest vergibt der Sender selber. Der Sender für 1 Rollo (2 Codes) hat z.B. nur 8 DIP-Schalter das neunte Zeichen wird vom Sender bestimmt. Also z.B. 0 für AUF und - für AB. Der Sender für 6 Rollos (12 Codes) hat zwar 9 DIP Schalter, aber es sind nur die ersten 6 DIP Schalter relevant, der Rest ist je nach Sender-Taste festgelegt. Bei den programmierbaren Sendern GF0043 und GF0050 können die 9-stelligen Codes frei definiert werden.

In FHEM benutzt man am Besten einen 433nanoCUL mit CC1101 und das Modul SIGNALduino. Mit culfw ist es uns nicht gelungen die Geiger Sender zu empfangen oder etwas zu senden. Die Installation von SIGNALduino und das Flashen eines nanoCUL mit CC1101 ist ausgiebig beschrieben in: https://wiki.fhem.de/wiki/SIGNALduino. Das Problem mit SIGNALduino ist, dass es weder die Notation von Geiger kennt, noch das genaue Protokoll. Wir haben uns da jetzt etwas reingekniet und einen cmdalias geschrieben, der die Geiger-Notation annimmt und an den SIGNALduino als raw message weiter gibt.

Dazu definiert man zuerst den SIGNALduino, hier mit dem Namen "sduino"

define sduino SIGNALduino /dev/serial/by-id/usb-FTDI_USB__-__Serial_Cable_12345678-if00-port0
attr sduino cc1101_frequency 433.920
attr sduino hardware nanoCC1101


Danach definieren wir einen cmdalias auf das object sduino mit folgender Raw definition:

defmod GeigerAlias cmdalias set sduino sendDIP .* AS {\
my ($dev, $cmd, $params) = split(/\s+/, $EVENT, 3);;\
Log 1, join(':','sendDIP#', $dev, $cmd, $params, ':');;\
$params =~ s/\s//g;;\
my ($parm, $repeats) = split('#', $params);;\
$repeats = 4 unless ($repeats);;\
$parm =~ s/0/1234/g;;\
$parm =~ s/\+/1212/g;;\
$parm =~ s/-/3434/g;;\
my $p5 = ($parm =~ /2$/) ? '-2045' : '-16092';;\
$parm =~ s/.$/5/;;\
$parm = 'set ' . $dev . ' raw SR;;R=' . $repeats\
. ';;P0=-32001;;P1=2039;;P2=-298;;P3=321;;P4=-2010;;P5=' . $p5 . ';;D=0' . $parm . ';;';;\
$parm =~ s/;;/;;;;/g;;\
fhem($parm);;\
}

setstate GeigerAlias defined



Damit haben wir jetzt die Möglichkeit Geiger Codes abzusetzen. Und zwar mit dem Befehl:

set sduino sendDIP -+-+0+000

Für Rollos muss die Länge des Codes immer 9 sein. Es gibt dann pro Rollo einen Auf und einen Ab Code.

Per default wird der Code nicht einmal, sondern viermal hintereinander gesendet. Das macht ein normaler Handsender auch so. Optional kann die Anzahl der Wiederholungen auch hinten mit "#" angegeben werden, also:

set sduino sendDIP -+-+0+000#9

So könnte man z.B. auch einen langen Tastendruck simulieren. Leerzeichen im sendDIP werden ignoriert, es geht also auch übersichtlicher:

set sduino sendDIP -+- +0+ 000


Damit kann man jetzt einen Dummy bauen, der die Codes für Auf und Ab versendet, indem er "set sduino sendDIP" aufruft.

Diesen Sendecode haben wir bisher mit 2 Leuten geprüft, es wäre schön, wenn weitere Leute die Gültigkeit bestätigen könnten.

Soweit das Senden der Geiger-Codes. Ein offener Punkt ist noch das Empfangen von Geiger Codes. Wenn wir einen Geiger Sender betätigen und dabei den SIGNALduino in Debug mode setzen können wir folgendes sehen:


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
....

Wir haben festgestellt. Der neunstellige Geigercode mit +0- wird vom sduino als 18Bit Code aus 0 und 1 decodiert. Wir wissen, es gilt:
00 == +, 11 == -, 01 == 0
Das letzte Bit des Signals ist allerdings etwas anders und darum erkennt die Decodierung nur 17 Bit. D.h. gesendet wurde:
0 0 1 1 0 0 1 1 1 1 1 1 0 1 0 1 1 ?
In diesem Fall kann "?" nur eine "1" sein, da es für "10" keine Decodierung gibt.  Das wäre dann der Geigercode: +-+---00-

So kann man gesendete Codes, ausgenommen des letzten Zeichens, empfangen und muss dann das letzte Zeichen erraten, jedenfalls bei + oder 0. Wir hättten aber auch noch gerne eine automatische Lesefunktion. Das ist jetzt der Punkt, wo wir mit den SIGNALduino Leuten reden sollten.

drhirn

Wow, das war ausführlich! Vielen, vielen Dank!

Jetzt  müsste ich nur noch rausfinden, wo ich einen fixfertigen 433nanoCUL mit CC1101 herbekomme. Meine Bastelversuche haben zwar funktioniert, aber anscheinend so gestrahlt, dass sie meine Internetleitung lahm gelegt haben ;)
Im Wiki-Artikel zu Signalduino steht In-Circuit als Anbieter. Aber ich weiß nicht genau, welches Produkt ich da brauche. Könnte mir da jemand einen Tipp geben bitte?

Danke nochmal!
Stefan

fasch

Hallo,
also ich habe meinen einfach fertig bei eBay gekauft. Mein Anbieter hieß damals  flexstarr*. Wenn ich aktuell einfach nach "nanoCUL CC1101 433" bei eBay suche finde ich jede Menge fertig zwischen 27 und 40 Euro, alles ziemlich ähnlich, bis auf die Antenne. Wichtig ist halt 433 Mhz, CC1101 und da sollte noch was von Nano V3.0 und Mega 328P stehen, dann passt es eigentlich. Einer liefert sogar mit SIGNALduino geflasht, das müsste dann auf jeden Fall passen, aber das ist auch selber schnell gemacht. Meiner hat die einfache Antenne mit dem gedrehten Draht und liegt trotzdem keinen Meter von meiner FritzBox entfernt.

drhirn

Perfekter Tipp!
Danke! Ich werde dann berichten.

sommer

Hallo,

ich habe meinen nanoCul auch selbst zusammengesteckt. Läuft bei mir Problemlos.
Ich habe folgende zwei Teile verwendet:
https://www.amazon.de/ATmega328P-Arduino-Compatible-Verbesserte-USB-Kabel/dp/B00Q6WTWGO/ref=pd_sim_147_3?_encoding=UTF8&psc=1&refRID=BZMTYF61Z8VD8JXZ956A
https://www.amazon.de/Stable-Funk-Module-Technische-externer-Antenne/dp/B00GBW6WJY/ref=pd_sim_147_12?_encoding=UTF8&psc=1&refRID=JCAQPED4828GB6PJNHV2
(Das Funkmodul dauert leider etwas länger bei der lieferung, evtl. gibt es alternative Lieferanten)

Damit kann man zumindest die Teile schnell verbinden ohne zu löten. Für eine kompaktere Version kann man natürlich den Arduino und den Funkmodul auch ohne
Pins nehmen und mit kurzen kablen verlöten.

Die Schaltpläne gibt es auf diversen Blogs (ich kann den von Matthias Kleine empfehlen).

Viel spaß.

drhirn

Sodala, SIGNALduino läuft.
Ich kapier nur leider die Sache mit den zu sendenden Codes nicht so ganz.

Mein Sender ist ein GF0001 mit 9 DIPs (+0+ -++ -+-)
Nach dessen Betätigung bekomme ich im FHEM-Log u46#130D8 für runter und u46#130D0 für rauf.
Jetzt hätte ich mir das so zusammen gewurschtelt, dass
u46#130D8 = +0 +- ++ -0 -+
und
u46#130D0 = +0 +- ++ -0 ++
10 Stellen jeweils.

Mir war danach nicht ganz klar, was für einen Code ich jetzt genau an den Rolladen schicken muss. Deshalb habe ich ausprobiert und bin zu folgendem Ergebnis gekommen:

Runter: +0+ -++ -0-
Rauf:     +0+ -++ -00

Stoppen muss ich jeweils mit dem Code der Gegenrichtung.

Der Code ist also nicht identisch mit eurem.

fasch

Hallo,
ich denke das passt alles zum bisher gesagten.

Zu dem was u46 liest:
Wie gesagt, u46 ist nicht die Lösung, sondern nur ähnlich. Man kann da nur mit bis zu 17Bit, also 8 DIP Codes, stimmenden Ergebnissen rechnen.
Dein ermitteltes Ergebnis mit +0+ -++ -0- und +0+ -++ -00 stimmt aber wieder mit den ersten 17Bit, also den ersten acht Codierungen überein.
Ich finde auch hier gilt: von den neun Codierungen wurden die ersten acht richtig erkannt.

Zu Deinen DIP Schaltern:
Ich habe mal das Handbuch für GF0001 bis GF0003 bei Geiger durchgelesen.
http://www.geiger.de/fileadmin/user_upload/documents/GEIGER_F_BAL_GF0-01-03_100W0602-000_DE.pdf

Dort steht tatsächlich wortwörtlich und dazu gibt es sogar ein Bild:

Codierung:
Bitte verwenden Sie für die Einstellung Ihrer individuellen Codierung die Dip-Schalter 1 - 7 des 9-poligen 
Codierschalters. Die Dip-Schalter 8 + 9 stellen Sie bitte wie abgebildet in die mittlere Position.
Über die Dip-Schalter 8 + 9 erzeugt Ihr Handsender automatisch die verschiedenen Codierungen für die bis zu 
6 Tasten des Gerätes. Diese so genannte ,, Kanal-Auswahl" kann nicht beeinflusst werden.


Also: Die Stellung von DIP 8 und 9 ist für die Codierung uninteressant, vermutlich benutzt der GF0001 am Ende immer 00 und 0-. Und die ersten 7 DIPs passen doch. Welche Auswirkung DIP 8 und 9 haben, die in Mittelstellung stehen sollen, ist leider nicht erklärt. Vielleicht ist das die Anzahl Wiederholungen oder auch was ganz anderes.

Wenn der GF0001 hinten 00 und 0- benutzt, passt das auch zu meinem Sender für 3 Rollos.
Der nutzt für die Reihe 1 hinten auch Auf: 00 und Ab: 0-.
Und für Reihe 2 hinten Auf: -0 und Ab: --
Und für Reihe 3 hinten Auf: 0+ und Ab: +0

Bei Dir gilt dann: Die ersten 7 DIPs gelten und hinten kommt 00 und 0- dran. Das passt dann wieder exakt.
sommer hatte nur 8 DIPs. Evtl. werden da ja auch nur 7 ausgewertet.

Vielleicht muss ich mal bei Geiger in Bietigheim vorbei fahren, sind ja nur knapp 600 km.

drhirn

Ich werde, wenn ich dann zuhause bin, ausprobieren, was passiert, wenn ich DIP 8+9 in die Mittelstellung stelle.

Eh, 600km, quasi um's Eck ;). Bezweifle allerdings, dass dir Geiger bei deinem Besuch irgendetwas erzählen wird ;)

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.  8)


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

Eine Übertragung einer Nachricht sieht in etwa so aus
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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

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:

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

#34
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:

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):


attr sduino development 78y
attr sduino  whitelist_IDs 78



Dann solltet ihr schon mal in etwa folgende Events erhalten:

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

drhirn

Hallo Sidey,

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


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


attr sduino  whitelist_IDs 78


Ist erforderlich.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

drhirn

Hatte mir auch selber auffallen können ;)

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

drhirn


Ralf9

Wenn Ihr die aktuelle Entwicklungs Version habt, dann sollte der log ungefähr so aussehen:
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:
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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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.


HomeAuto_User

Hallo,
ich habe mal soeben euren Faden überflogen.
Bisher verwendet Ihr die Daten ohne ein Modul.

Besteht Interesse an der Einbindung in ein Modul? Wenn ja, bräuchte ich bitte Eure Mithilfe in Form von RAWMSG Daten und der Definition was Ihr gedrückt habt.
MfG
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

drhirn

Ich weiß nicht, ob ein extra Modul Sinn macht. Aber ich liefere gerne weitere Informationen. Musst nur noch etwas genauer sagen, was du gerne hättest.

Sender ist ein GF0001
Meine DIP-Stellung: + 0 + - + + - 0 0

Ich bekomme irgendwie keine vernünftige RAWMSG raus. Deswegen gleich ein verbose5 des SIGNALduino.

Rauf:

2019.03.06 20:55:04 4: Signalduino/msg READ: MU;P0=822;P1=-3372;P2=-257;P3=2077;P4=326;P5=-2014;P6=-15770;D=01023245453232323245453245324632323245323245453232323245453245324632323245323245453232323245453245324;CP=4;R=24;
2019.03.06 20:55:04 5: Signalduino: substr: 632323245323245453232323245453245324632323245323245453232323245453245324
2019.03.06 20:55:04 4: Signalduino: Fingerprint for MU Protocol id 78 -> geiger matches, trying to demodulate
2019.03.06 20:55:04 5: part is 3232324532324545323232324545324532 starts at position 0 and ends at 35
2019.03.06 20:55:04 5: Signalduino: Starting demodulation (StartStr: 6 first found at 29 regex: (?:6)((?:32|45){14,}) Pos 29) length_min_max (14..18) length=17
2019.03.06 20:55:04 5: Signalduino: dispatching hex: u78#3B3CA
2019.03.06 20:55:04 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3CA length 18 dispatch(1/4) RSSI = -62
2019.03.06 20:55:04 5: Signalduino Dispatch: u78#3B3CA, test gleich
2019.03.06 20:55:04 1: DEBUGsduino DMSG u78#3B3CA
2019.03.06 20:55:04 5: Signalduino Dispatch: u78#3B3CA, -62 dB, dispatch
2019.03.06 20:55:04 5: Signalduino: dispatch u78#3B3CA
2019.03.06 20:55:04 4: SIGNALduino_unknown incomming msg: u78#3B3CA
2019.03.06 20:55:04 4: SIGNALduino_unknown rawData: 3B3CA
2019.03.06 20:55:04 4: SIGNALduino_unknown Protocol: 78
2019.03.06 20:55:04 4: SIGNALduino_unknown converted to bits: 00111011001111001010
2019.03.06 20:55:04 4: geiger message converted to tristate code: 01F10110FF
2019.03.06 20:55:04 5: SIGNALduino_unknown: Signalduino Protocol u7878 found in AttrVal development!
2019.03.06 20:55:04 5: part is 3232324532324545323232324545324532 starts at position 36 and ends at 71
2019.03.06 20:55:04 5: Signalduino: 2. try demodulation at Pos 36
2019.03.06 20:55:04 5: Signalduino: dispatching hex: u78#3B3CA
2019.03.06 20:55:04 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3CA length 18 dispatch(2/4) RSSI = -62
2019.03.06 20:55:04 5: Signalduino Dispatch: u78#3B3CA, test gleich
2019.03.06 20:55:04 4: Signalduino Dispatch: u78#3B3CA, Dropped due to short time or equal msg
2019.03.06 20:55:04 4: Signalduino/msg READ: MS;P1=464;P2=-4054;P3=-1977;P4=-8939;D=14131313121312131312131313131213131212121313131313131312131213121212131213;CP=1;SP=4;R=255;O;
2019.03.06 20:55:23 4: Signalduino/msg READ: MC;LL=-218;LH=236;SL=-118;SH=121;D=82AFF9C95B1;C=115;L=44;R=231;
2019.03.06 20:55:24 4: Signalduino/msg READ: MC;LL=-237;LH=255;SL=-111;SH=131;D=55FF392B63E;C=122;L=43;R=232;
2019.03.06 20:55:24 4: Signalduino/msg READ: MC;LL=-237;LH=259;SL=-109;SH=126;D=E0ABFE7256C7C;C=121;L=50;R=232;
2019.03.06 20:55:24 4: Signalduino/keepalive ok, retry = 0
2019.03.06 20:55:24 4: Signalduino/msg READ: MU;P1=244;P2=127;P3=-252;P4=-111;D=0102320202020102424242310131324242424242424241;CP=2;R=232;
2019.03.06 20:55:24 5: Signalduino: start pattern for MU Protocol id 78 -> geiger not found, aborting
2019.03.06 20:55:24 4: Signalduino/msg READ: MU;P0=-235;P1=250;P2=128;P3=-120;D=0101010232323232323232313202323132013201010231023132320232323231;CP=2;R=232;
2019.03.06 20:55:24 5: Signalduino: start pattern for MU Protocol id 78 -> geiger not found, aborting
2019.03.06 20:55:25 4: Signalduino/msg READ: MC;LL=-250;LH=237;SL=-117;SH=131;D=0ABFE95B0;C=122;L=34;R=229;
2019.03.06 20:55:31 4: Signalduino/msg READ: MS;P1=485;P2=-9521;P3=-1959;P4=-4515;D=1213131414141414141314141313131313131414131413141414141413;CP=1;SP=2;R=250;O;
2019.03.06 20:55:32 4: Signalduino/msg READ: MS;P0=-4521;P1=485;P2=-1958;P3=-9523;D=1312121010101010101210101212121212121010121012101010101012;CP=1;SP=3;R=250;
2019.03.06 20:55:36 4: Signalduino/msg READ: MS;P3=462;P4=-1982;P5=-4057;P6=-8928;D=36343434353435343435343434343534343535353434343434343435343534353535343534;CP=3;SP=6;R=1;O;
2019.03.06 20:55:57 3: jetzt
2019.03.06 20:55:58 4: Signalduino/msg READ: MU;P0=-32001;P1=2072;P2=-260;P3=326;P4=-2015;P5=-15769;D=01212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351;CP=3;R=37;O;
2019.03.06 20:55:58 5: Signalduino: substr: 51212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351212123412123434121212123434123412351
2019.03.06 20:55:58 4: Signalduino: Fingerprint for MU Protocol id 78 -> geiger matches, trying to demodulate
2019.03.06 20:55:58 5: part is 1212123412123434121212123434123412 starts at position 0 and ends at 35
2019.03.06 20:55:58 5: Signalduino: Starting demodulation (StartStr: 5 first found at 36 regex: (?:5)((?:12|34){14,}) Pos 36) length_min_max (14..18) length=17
2019.03.06 20:55:58 5: Signalduino: dispatching hex: u78#3B3CA
2019.03.06 20:55:58 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3CA length 18 dispatch(1/4) RSSI = -55.5
2019.03.06 20:55:58 5: Signalduino Dispatch: u78#3B3CA, test gleich
2019.03.06 20:55:58 1: DEBUGsduino DMSG u78#3B3CA
2019.03.06 20:55:58 5: Signalduino Dispatch: u78#3B3CA, -55.5 dB, dispatch
2019.03.06 20:55:58 5: Signalduino: dispatch u78#3B3CA
2019.03.06 20:55:58 4: SIGNALduino_unknown incomming msg: u78#3B3CA
2019.03.06 20:55:58 4: SIGNALduino_unknown rawData: 3B3CA
2019.03.06 20:55:58 4: SIGNALduino_unknown Protocol: 78
2019.03.06 20:55:58 4: SIGNALduino_unknown converted to bits: 00111011001111001010
2019.03.06 20:55:58 4: geiger message converted to tristate code: 01F10110FF
2019.03.06 20:55:58 5: SIGNALduino_unknown: Signalduino Protocol u7878 found in AttrVal development!
2019.03.06 20:55:58 5: part is 1212123412123434121212123434123412 starts at position 36 and ends at 71
2019.03.06 20:55:58 5: Signalduino: 2. try demodulation at Pos 36
2019.03.06 20:55:58 5: Signalduino: dispatching hex: u78#3B3CA
2019.03.06 20:55:58 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3CA length 18 dispatch(2/4) RSSI = -55.5
2019.03.06 20:55:58 5: Signalduino Dispatch: u78#3B3CA, test gleich
2019.03.06 20:55:58 4: Signalduino Dispatch: u78#3B3CA, Dropped due to short time or equal msg
2019.03.06 20:55:58 5: part is 1212123412123434121212123434123412 starts at position 72 and ends at 107
2019.03.06 20:55:58 5: Signalduino: 3. try demodulation at Pos 72
2019.03.06 20:55:58 5: Signalduino: dispatching hex: u78#3B3CA
2019.03.06 20:55:58 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3CA length 18 dispatch(3/4) RSSI = -55.5
2019.03.06 20:55:58 5: Signalduino Dispatch: u78#3B3CA, test gleich
2019.03.06 20:55:58 4: Signalduino Dispatch: u78#3B3CA, Dropped due to short time or equal msg
2019.03.06 20:55:58 5: part is 1212123412123434121212123434123412 starts at position 108 and ends at 143
2019.03.06 20:55:58 5: Signalduino: 4. try demodulation at Pos 108
2019.03.06 20:55:58 5: Signalduino: dispatching hex: u78#3B3CA
2019.03.06 20:55:58 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3CA length 18 dispatch(4/4) RSSI = -55.5
2019.03.06 20:55:58 5: Signalduino Dispatch: u78#3B3CA, test gleich
2019.03.06 20:55:58 4: Signalduino Dispatch: u78#3B3CA, Dropped due to short time or equal msg
2019.03.06 20:55:59 4: Signalduino/msg READ: MU;P0=-275;P1=2060;P2=320;P3=-2016;P4=-15776;P5=1204;D=01010231010232310101010232310231024101010235;CP=2;R=236;
2019.03.06 20:55:59 5: Signalduino: substr: 4101010235
2019.03.06 20:55:59 4: Signalduino: Fingerprint for MU Protocol id 78 -> geiger matches, trying to demodulate
2019.03.06 20:55:59 5: Signalduino: 0. try, regex ((?:4)((?:10|23){14,})) did not match


Runter:

2019.03.06 20:58:44 4: Signalduino/msg READ: MU;P0=-15694;P1=2009;P2=-261;P3=324;P4=-2016;D=01212123412123434121212123434123434301212123412123434121212123434123434301212123412123434121212123434123434301212123412123434121212123434123434301212123412123434121212123434123434301;CP=3;R=30;
2019.03.06 20:58:44 5: Signalduino: substr: 01212123412123434121212123434123434301212123412123434121212123434123434301212123412123434121212123434123434301212123412123434121212123434123434301212123412123434121212123434123434301
2019.03.06 20:58:44 4: Signalduino: Fingerprint for MU Protocol id 78 -> geiger matches, trying to demodulate
2019.03.06 20:58:44 5: part is 1212123412123434121212123434123434 starts at position 0 and ends at 35
2019.03.06 20:58:44 5: Signalduino: Starting demodulation (StartStr: 0 first found at 0 regex: (?:0)((?:12|34){14,}) Pos 0) length_min_max (14..18) length=17
2019.03.06 20:58:44 5: Signalduino: dispatching hex: u78#3B3C8
2019.03.06 20:58:44 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3C8 length 18 dispatch(1/4) RSSI = -59
2019.03.06 20:58:44 5: Signalduino Dispatch: u78#3B3C8, test gleich
2019.03.06 20:58:44 1: DEBUGsduino DMSG u78#3B3C8
2019.03.06 20:58:44 5: Signalduino Dispatch: u78#3B3C8, -59 dB, dispatch
2019.03.06 20:58:44 5: Signalduino: dispatch u78#3B3C8
2019.03.06 20:58:44 4: SIGNALduino_unknown incomming msg: u78#3B3C8
2019.03.06 20:58:44 4: SIGNALduino_unknown rawData: 3B3C8
2019.03.06 20:58:44 4: SIGNALduino_unknown Protocol: 78
2019.03.06 20:58:44 4: SIGNALduino_unknown converted to bits: 00111011001111001000
2019.03.06 20:58:44 4: geiger message converted to tristate code: 01F10110F0
2019.03.06 20:58:44 5: SIGNALduino_unknown: Signalduino Protocol u7878 found in AttrVal development!
2019.03.06 20:58:44 5: part is 1212123412123434121212123434123434 starts at position 36 and ends at 71
2019.03.06 20:58:44 5: Signalduino: 2. try demodulation at Pos 36
2019.03.06 20:58:44 5: Signalduino: dispatching hex: u78#3B3C8
2019.03.06 20:58:44 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3C8 length 18 dispatch(2/4) RSSI = -59
2019.03.06 20:58:44 5: Signalduino Dispatch: u78#3B3C8, test gleich
2019.03.06 20:58:44 4: Signalduino Dispatch: u78#3B3C8, Dropped due to short time or equal msg
2019.03.06 20:58:44 5: part is 1212123412123434121212123434123434 starts at position 72 and ends at 107
2019.03.06 20:58:44 5: Signalduino: 3. try demodulation at Pos 72
2019.03.06 20:58:44 5: Signalduino: dispatching hex: u78#3B3C8
2019.03.06 20:58:44 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3C8 length 18 dispatch(3/4) RSSI = -59
2019.03.06 20:58:44 5: Signalduino Dispatch: u78#3B3C8, test gleich
2019.03.06 20:58:44 4: Signalduino Dispatch: u78#3B3C8, Dropped due to short time or equal msg
2019.03.06 20:58:44 5: part is 1212123412123434121212123434123434 starts at position 108 and ends at 143
2019.03.06 20:58:44 5: Signalduino: 4. try demodulation at Pos 108
2019.03.06 20:58:44 5: Signalduino: dispatching hex: u78#3B3C8
2019.03.06 20:58:44 4: Signalduino: decoded matched MU Protocol id 78 dmsg u78#3B3C8 length 18 dispatch(4/4) RSSI = -59
2019.03.06 20:58:44 5: Signalduino Dispatch: u78#3B3C8, test gleich
2019.03.06 20:58:44 4: Signalduino Dispatch: u78#3B3C8, Dropped due to short time or equal msg
2019.03.06 20:58:47 4: Signalduino/msg READ: MU;P0=-2420;P1=680;P2=-1272;P3=-785;P4=218;P7=-9052;D=01212121212121212121212121212121342431342431342431212134212431213421243134212121212431342121243134212121212431213421212124313421243134212121243134212121212121212431213424312134212431213424313424312134247121212121212121212121212121212134243134243134243121;CP=1;R=225;O;
2019.03.06 20:58:47 5: Signalduino: start pattern for MU Protocol id 78 -> geiger not found, aborting


Unterscheidet sich halt immer, je nachdem, wie lange ich den Knopf drücke.

HomeAuto_User

Zitat von: drhirn am 06 März 2019, 21:00:50
Ich weiß nicht, ob ein extra Modul Sinn macht. Aber ich liefere gerne weitere Informationen. Musst nur noch etwas genauer sagen, was du gerne hättest.

...

Hallo,

ich würde kein Extra Modul machen.
Es existiert ein Modul welches derzeit als Universal genutz wird. Dort könnte ich es integrieren und via Model zuordnung kann dann ein Device von Euch angelegt werden.

Die RAWMSG sind schonmal gut. Ich schaue mal drüber.
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

HomeAuto_User

Ich habe Schonmal begonnen mir es anzusehen. Mehr RAWMSGs bräuchte ich, wenn machbar auch von anderen Remotes (dann bitte diese auch mit Herstellername).

Zusätzlich müssen wir alle Zustände in RAWMSGs wieder finden.

Gibt es eine Ident pro Remote welche man ändern kann? Diese müsste man verstellen und erneut RAWMSGs von den Zuständen sammeln.

Ziel des ganzen, aus den Bits die ,,Rubriken der Zustände" zu verifizieren.


Gesendet von iPhone mit Tapatalk Pro
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

elektron-bbs

Ich denke, wir können hier Protokoll 46 und 78 zusammen führen. Da sind mir zu viele Ähnlichkeiten: jeweils 9 DIP-Switch, Anzahl Bits und Timings stimmen auch überein.
Es wäre schön, wenn mal jemand Fotos von den "Innereien" der Fernbedienung posten könnte. Insbesondere interessiert mich, welcher Schaltkreis da verbaut ist.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

drhirn


elektron-bbs

#51
Danke, das hilft schon etwas weiter. Der Chip ist wahrscheinlich irgendein Mikroprozessor. Die Bezeichnung deutet tatsächlich darauf hin, das es das gleiche Protokoll wie 46 sein wird. Die Bezeichnung lässt auch darauf schließen, das die Firmware für 6 Tasten vorbereitet ist. Die Plätze für die restlichen 4 Tasten sind bei dir halt nur nicht bestückt.
Die Integration in das vorhandene SIGNALduino-Modul sollte kein Problem darstellen. Wir benötigen von der Fernbedienung mit 6 Tasten bitte noch RAWMSG aller Tasten.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

drhirn


elektron-bbs

Laut unseren Aufzeichnungen ist es für eine Fernbedienung eines Garagentorantriebes.

## Berner Garagentorantrieb GA401
# remote TEDSEN SKX1MD 433.92 MHz - 1 button | settings via 9 switch on battery compartment
# compatible with doors: BERNER SKX1MD, ELKA SKX1MD, TEDSEN SKX1LC, TEDSEN SKX1
# https://github.com/RFD-FHEM/RFFHEM/issues/91
# door open
# MU;P0=-15829;P1=-3580;P2=1962;P3=-330;P4=245;P5=-2051;D=1234523232345234523232323234523234540023452323234523452323232323452323454023452323234523452323232323452323454023452323234523452323232323452323454023452323234523452323232323452323454023452323234523452323;CP=2;
# door close
# MU;P0=-1943;P1=1966;P2=-327;P3=247;P5=-15810;D=01230121212301230121212121230121230351230121212301230121212121230121230351230121212301230121212121230121230351230121212301230121212121230121230351230121212301230121212121230121230351230;CP=1;
# letzes Bit unvollständig!
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

elektron-bbs

Eine Frage hätte ich noch: Sind nun 6 oder 7 DIP-Schalter von den 9 Stück für die Einstellung der Adresse zuständig? Oder gibt es unterschiedliche Varianten?
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

drhirn

Hmm, scheint außer mir niemand antworten zu wollen.
Wie finde ich das mit dem DIP-Schaltern raus? Ich bin da nicht so bewandert wie man merkt ;).

elektron-bbs

Bei Protokoll 78 und verbose 4 sollten Einträge folgender Art im Log erscheinen:


2019.03.06 20:55:04 4: SIGNALduino_unknown incomming msg: u78#3B3CA
2019.03.06 20:55:04 4: SIGNALduino_unknown rawData: 3B3CA
2019.03.06 20:55:04 4: SIGNALduino_unknown Protocol: 78
2019.03.06 20:55:04 4: SIGNALduino_unknown converted to bits: 00111011001111001010


Die letzte Zeile mit den Bits ist die entscheidende:
Von links nach rechts gelesen entsprechen immer zwei Bit einem DIP-Schalter. Die ersten beiden Nullen bitte ignorieren, diese sind fest vorangestellt.
Dann folgt hier z.B. 11 = Schalter 1 auf + gestellt, dann 10 = Schalter 2 in Mittelstellung (0), dann wieder 11 = Schalter 3 auch auf +, dann 00 = Schalter 4 auf - gestellt usw.
Eine Tabelle sähe dann z.B. so aus:

DIP:    1  2  3  4  5  6  7  8  9
Bit: 00 11 10 11 00 11 11 00 10 10

Wenn ich das bisher hier richtig verfolgt habe, sollte sich Position 8 und 9 mit der gewählten Taste ändern und die Positionen 1 bis 6 (oder eben 7) mit der Einstellung der DIP-Schalter in der Fernbedienung.
Ich habe jetzt den Code fast fertig für die GF0001 mit nur einem Kanal. Interessiert wäre ich noch an Logs von den anderen Fernbedienungen, die ihr verwendet. Bitte mit genauer Bezeichnung der Fernbedienung und Beschreibung der betätigten Tasten.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

drhirn

Zitat von: elektron-bbs am 12 März 2019, 17:09:30
Wenn ich das bisher hier richtig verfolgt habe, sollte sich Position 8 und 9 mit der gewählten Taste ändern und die Positionen 1 bis 6 (oder eben 7) mit der Einstellung der DIP-Schalter in der Fernbedienung.

Fast.
9 ist in der Tat die Richtung. Und 1-7 geben die DIP-Stellung an.
In meinem Fall ist Position 8 irrelevant. Die ändert sich nie. Weder durch Ändern des DIP-Schalters, noch durch verschiedene Tastendrücke. Bleibt immer 10. Vermute aber, die wäre dann für einen zweiten Kanal.

elektron-bbs

Dann hast du offensichtlich eine Fernbedienung mit nur einem Kanal.
Ich hatte hier irgendwo folgendes aufgeschnappt:

Bitte verwenden Sie für die Einstellung Ihrer individuellen Codierung die Dip-Schalter 1 - 7 des 9-poligen
Codierschalters. Die Dip-Schalter 8 + 9 stellen Sie bitte wie abgebildet in die mittlere Position.
Über die Dip-Schalter 8 + 9 erzeugt Ihr Handsender automatisch die verschiedenen Codierungen für die bis zu
6 Tasten des Gerätes. Diese so genannte " Kanal-Auswahl" kann nicht beeinflusst werden.

Wenn der GF0001 hinten 00 und 0- benutzt, passt das auch zu meinem Sender für 3 Rollos.
Der nutzt für die Reihe 1 hinten auch Auf: 00 und Ab: 0-.
               Und für Reihe 2 hinten Auf: -0 und Ab: --
               Und für Reihe 3 hinten Auf: 0+ und Ab: +0

Bei Dir gilt dann: Die ersten 7 DIPs gelten und hinten kommt 00 und 0- dran. Das passt dann wieder exakt.
sommer hatte nur 8 DIPs. Evtl. werden da ja auch nur 7 ausgewertet.

Aber ich dächte, irgend jemand hatte auch geschrieben, das nur DIP 1 bis 6 für die Adresse relevant wären. Vieleicht irre ich mich da aber auch.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

elektron-bbs

Ab sofort werden die Fernbedienungen von der aktuellen Entwicklerversion unterstützt. Um das auszuprobieren müsst ihr mittels folgendem Befehl diese Version installieren:

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

Nach einem Neustart und mehrmaligen Betätigen einer Taste sollte im Raum "SD_UT" ein neues Gerät "unknown_please_select_model" angelegt werden. Bei diesem Gerät muss dann mittels Attribut "model" die passende Fernbedienung ausgewählt werden. In Frage kommen hier folgende Modelle, je nach Anzahl der Tasten:

Tedsen_SKX1xx
Tedsen_SKX2xx
Tedsen_SKX4xx
Tedsen_SKX6xx

Angelegt werden dann z.B. solche Fernbedienungen: Tedsen_SKX1xx_F1FF11F oder Tedsen_SKX6xx_1F10110.
Die Definition entspricht den Schalterstellungen, wobei folgende Zuordnung gilt:

ID = DIP
1 = +
F = 0
0 = -
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

drhirn

Sodala:

Internals:
   CFGFN     
   DEF        Tedsen_SKX2xx 1F10110
   FUUID      5ca3a993-f33f-dc90-8df5-6be563f789350fe1
   IODev      Signalduino
   LASTInputDev Signalduino
   MSGCNT     3
   NAME       Tedsen_SKX2xx_1F10110
   NR         13946
   STATE      Button_1
   Signalduino_DMSG P46#ECF20
   Signalduino_MSGCNT 3
   Signalduino_RAWMSG MU;P0=-2009;P1=2076;P2=-259;P3=329;P4=-15751;P5=1216;D=012121212303012303034121212301212303012121212303012303034121212301212303012121212303012303034121212305;CP=3;R=37;
   Signalduino_RSSI -55.5
   Signalduino_TIME 2019-04-02 20:28:33
   TYPE       SD_UT
   bitMSG     11101100111100100000
   lastMSG    ECF20
   READINGS:
     2019-04-02 20:28:33   LastAction      receive
     2019-04-02 20:28:33   state           Button_1
     2019-04-02 20:28:33   tristateCode    1F10110F0
Attributes:
   IODev      Signalduino
   model      Tedsen_SKX2xx
   room       SD_UT


Sehr cool, ich danke euch!

drhirn

Blöde Frage: Ich habe jetzt alle Dateien aus der Entwicklerversion vom FHEM-Update ausgenommen. Wie erfahre ich, wann ich wieder regulär updaten kann?

HomeAuto_User

@drhirn,
was hast du dir alles aus dem Entwicklerfaden gezogen?

Ich gehe davon aus, das du wieder regulär updaten kannst, wenn eine neue Master Version draußen ist oder wenn das angepasste Modul im SVN geupdatet wurde. Um was handelt es sich bei dir?

Mfg


Gesendet von iPhone mit Tapatalk Pro
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

drhirn

Alles von da: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Gut, dann müsste ich das SVN beobachten.

Funktioniert übrigens wunderbarst! Danke nochmal!

derfehler

Hallo,

ich habe mal eine frage für die Iteration, hat von euch schon eine DOIF im Zusammenspiel mit den Fernbedienungen gemacht.
Ich würde gerne das ROLLO Modul verwenden. Bekomme aber die DOIF nicht richtig hin das ich mit den Fernbedienung und dem Module die Rollladen schalten kann. oder gibt es ein anderen weg eine gute Rollladen Automatisation hin zu bekommen.

derfehler

Hallo,

ich habe mal eine frage für die Iteration, hat von euch schon eine DOIF im Zusammenspiel mit den Fernbedienungen gemacht.
Ich würde gerne das ROLLO Modul verwenden. Bekomme aber die DOIF nicht richtig hin das ich mit den Fernbedienung und dem Module die Rollladen schalten kann. oder gibt es ein anderen weg eine gute Rollladen Automatisation hin zu bekommen.

drhirn

Versteh die Frage nicht ganz. Du kannst die Rollläden grundsätzlich aus FHEM heraus schon steuern?

derfehler

Ich würde gerne die Fernbedienungen weiter benutzen, aber auch das ganze per ROLLO Modul Schalten. leider weiß das ROLLO Modul nicht wenn ich den Rollladen per Fernbedienung gesteuert habe. diese Zusammenspiel bekomme ich nicht hin.

drhirn

Ich kenn das Modul leider nicht. Aber da gibt's ja den SET-Befehl "extern". Einfach ein notify, dass Signalduino bzw. deine Fernsteuerung überwacht und dann den Befehl an das ROLLO-Modul schickt.