Wie steuere ich Elero Rolladen mit FHEM?

[HCS]

Anbei eine Version zum testen.

Da gibt es noch ein kleines Problem, habe sie wieder zurückgezogen.
Wenn ich es im Griff habe, hänge ich sie dann im nächsten Beitrag an.

[HCS]

Wenn ich es im Griff habe, hänge ich sie dann im nächsten Beitrag an.

So jetzt aber.
Probier das mal bitte, ob das bei Dir klappt.

[Technikfreak]

Hallo,

sieht so aus als funktioniert es. Kann das Problem seit dem Update nicht mehr erkennen. Vielen Dank!

[HCS]

Prima, ich warte mal noch ein wenig, ob Du doch noch Probleme entdeckst, wenn nicht, checke ich es dann ein.

[quadcorei8085]

Hi,

Mein deutsch ist nicht perfekt.
Ich habe ELERO protocol reverse engineered.
Momentan ohne dokumentation aber gibts verschiedene beispiele und PYTHON code wie man "encrypt" könnte.

https://github.com/QuadCorei8085/elero_protocol

Ihr könnte auch beischpiele für ESP32 finden.

[Ralf9]

ich bin zufällig über einen Post im Forum gestolpert (https://forum.fhem.de/index.php/topic,15144.75.html Post #79 ) welcher mich an ein altes Elero Problem erinnert hat. Ich würde nämlich gerne die Nachrichten der Windsensoren mitlesen können, um dann in Fhem die Aktion der Rolläden zu steuern (anstatt Sensor und Aktor direkt zu koppeln - ist auf dem Dach nämlich gar nicht so einfach). Der gerne verwendete Elero USB Transmitter Stick kann das nämlich genau nicht (wie auch andere spannende Dinge).

Wäre das nicht etwas für den Signalduino 868 MHz (zumindets für HW mit C1100)?

Die SPI Config Register stehen in https://github.com/QuadCorei8085/elero_protocol/blob/main/main.cpp#L532
Demnach ist die Frequenz 869,525MHz mit GFSK Codierung wenn ich das richtig dekodiert habe. Das ist zwar etwas "neben" dem 868,3MHz Standard aber wohl für die Abtsimmung immer noch nah genug.

Hier ist ein erster Versuch, bitte mal testen ob mit meiner Firmware (3.3.4 oder 4.x.x) was empfangen wird
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900

Code Auswählen Erweitern

get sduino raw CW0007,0209,0307,04D3,0591,063C,078C,0845,0B08,0D21,0E71,0F7A,107B,1183,1213,1352,14F8,1543,173F,1818,191D,1A1C,1BC7,1C00,1DB2,21B6,2211,23EA,242A,2500,261F,3D0D,3E04,4045,416C,4272,436F,4400
Dies ergibt die folgenden Werte:

Code Auswählen Erweitern

freq:869.525MHz bWidth:232KHz rAmpl:42dB sens:12dB (DataRate:76766.97Baud)

N=13 ccmode=4 sync=D391 Modulation:GFSK (SYNC_MODE:30/32 sync) DEVIATN:34.912kHz

Gruß Ralf

[Michi]

Hallo Ralf, hallo quadcorei8085,

Vielen Dank für Eure Unterstützung und schnelle Hilfe bzw. Umsetzung.

Ein weiterer Signalduino zum Testen ist bestellt. Ich werde berichten...

Viele Grüße

Michi

[Michi]

Bisher hatte ich leider kein Glück etwas zu empfangen

   
• Mein Arduino Nano weigert sich hartnäckig die neue Firmware zu flashen. Daher bin ich auf einen Busware CUL_3 868MHz ausgewichen
• Verwendete Firmware ist die SIGNALduino_culV3CC1101_onlyFsk_334dev211207.hex
• Kannst du mir bei dem raw Kommando noch mal auf die Sprünge helfen?
• 
        
  • Wenn erfolgreich – bekomme ich dann nur eine empfangene Nachricht angezeigt oder kontinuierlich?
  • Ich hatte mir die SPI Register noch einmal angeschaut. In dem Kommando sind sie etwas anders als in dem Beispiel von quadcorei8085. Ist das gewollt?
  • Die Zugriffe auf die Register 40xx am Ende des Raw Kommandos habe ich nicht verstanden. Ist das ein Burst Zugriff? Oder ist das etwas anderes?

Viele Grüße, Michi

[Ralf9]

Mein Arduino Nano weigert sich hartnäckig die neue Firmware zu flashen.

Hast Du es auch mit "attr sduino hardware nanoCC1101_optiboot" versucht, falls der nano einen optiboot Bootloader hat.

Die Nachrichten sollten kontinuierlich kommen.

Die Zugriffe auf die Register 40xx am Ende des Raw Kommandos habe ich nicht verstanden.

3D0D ist ccN = 13
3E04 ist ccmode = 4
40 - 47 ist die max 8 Zeichen Bankkurzbeschreibung ( hier ist 4045,416C,4272,436F,4400 Elro)

Ich hatte mir die SPI Register noch einmal angeschaut. In dem Kommando sind sie etwas anders als in dem Beispiel von quadcorei8085. Ist das gewollt?

Wo hast Du außer bei außer beim reg 00 (07 anstatt 06) abweichungen festgestellt?

Die Testregister "2959,2C81,2D35,2E09" sind nicht im Raw Kommando enthalten, Du kannst sie mal Testweise mit "set sduino cc1101_reg" setzen.
Die Testregister gehen bei einem Bankwechsel oder einem reset verloren, da sie nicht im EEPROM gespeichert werden.

Du kannst auch mal testen ob es was bringt, wenn Du die reg 00, 07 und 08 änderst.

00 GDO2 von alt 07 nach neu 01

Code Auswählen Erweitern

GDO2 1
Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is
reached. De-asserts when the RX FIFO is empty.
GDO2 7
Asserts when a packet has been received with CRC OK. De-asserts when the first byte is read from the RX FIFO.

07 PKTCTRL1 von alt 8C nach neu 84

Code Auswählen Erweitern

Bit 3:  Enable automatic flush of RX FIFO when CRC is not OK. This requires that
only one packet is in the RXIFIFO and that packet length is limited to the
RX FIFO size.

08 PKTCTRL0 von 45 nach 44

Code Auswählen Erweitern

Bit 0 + 1
00 Fixed packet length mode. Length configuredPKTLEN register
01  Variable packet length mode. Packet length configured by the first byte after sync word

Gruß Ralf

[Michi]

Die gute Neuigkeit gleich am Anfang. Ich kann Nachrichten empfangen! Vielen Dank für die Hilfe.

Ich habe einiges ausprobiert, aber am Ende macht der Wert im C1101 Register 0x3E den Unterschied. Verwendet habe ich:

Code Auswählen Erweitern

CW0007,0209,0307,04D3,0591,063C,078C,0845,0B08,0D21,0E71,0F7A,107B,1183,1213,1352,14F8,1543,173F,1818,191D,1A1C,1BC7,1C00,1DB2,21B6,2210,23EA,242A,2500,261F,2C81,2D35,2E09,3D0D,3EC2,4045,416C,4265,4372,446F,4500

Empfangen wird zum Beispiel:
2022-04-15 13:16:06 SIGNALduino sduino_868 RAWMSG MN;D=1BE74510050101F58D2AF58D2AF58D2A01110042CD317F734D01C705FFB1;N=13;R=220;
2022-04-15 13:16:06 SIGNALduino sduino_868 RAWMSG MN;D=1BE74510150101F58D2AD91023F58D2A01110042CD317F734D01C705F9AF;N=13;R=214;
2022-04-15 13:16:06 SIGNALduino sduino_868 RAWMSG MN;D=1BE74510150101F58D2A3F6823F58D2A01110042CD317F734D01C70522AE;N=13;R=243;

Im Code von quadcorei8085 steht am Ende der CC1101 Initialisierung ein "spi_write_reg(0x7E, 0xC2);". Da ich kein 0x7E Register im CC1101 Datenblatt finden konnte, habe ich 0x40 in der Annahme eines Burstzugriffes abgezogen und dann das Register 0x3E auf 0xC2 gesetzt. Damit werden dann Nachrichten empfangen. Juhu - Nur warum ?

3D0D ist ccN = 13
3E04 ist ccmode = 4
40 - 47 ist die max 8 Zeichen Bankkurzbeschreibung ( hier ist 4045,416C,4272,436F,4400 Elro)

Ist nicht das Register 0x3D SNOP und 0x3E der Zugriff auf die PATABLE? Den Bezug auf ccN und ccmode verstehe ich an dieser Stelle nicht. Wird das im Code irgendwo umgewandelt? Ich habe eigentlich kein besonderes Handling von 0x3D oder 0x3E im Code finden können. Es funktioniert auch wenn ich 0x3D nicht initialisiere. Also hier wäre ich für Hilfe dankbar. Damich ich auch verstehe, was ich hier tue 

Verstehe ich das richtig, dass die Bankkurzbeschreibung auf dem Nano verbleibt und also nicht per SPI in den CC1101 geschrieben wird? Die Funktion ist dann mehrere Protokolleinstellungen in jeweils einer Bank zu halten um dann einfach Umschalten zu können? Richtig ?

Auch bei der Berechnung von N und R aus der Nachricht grübele ich noch.


Im Code von quadcorei8085 wird das C1101 Register 0x00 (GDO2) mit 0x06 initialisiert statt 0x07 wie in deinem Ansatz. Es geht am Ende beides. Bei 0x06 bekomme ich auch Teilframes empfangen, bei 0x07 meistens nur "ganze" Frames. Das liegt wohl am vorhanden CRC Check bei 0x07, der bei den Teilframes fehlschlagen sollte. Dadurch werden zwar Frames verloren, die empfangenen Frames sind dann aber "sauber" und damit einfacher auszuwerten.

Das Protokoll an sich ist wohl doch noch etwas komplizierter als von quadcorei8085 beschrieben. Ich bekomme Frames nicht nur mit einer Länge von 0x1B sondern auch 0x1D, 0x1E und 0x24. Die Struktur sieht ähnlich aus, aber da muss noch etwas mehr Arbeit investiert werden. Welche Fernbedienung verwendet wird macht dabei schon den ersten Unterschied. Z.B. VarioTel2 vs. MultiTel2. Und natürlich senden die Aktoren auch eine Response...

Bei Neuigkeiten werde ich berichten.

Viele Grüße Michi

[Ralf9]

CW0007..2C81,2D35,2E09

Hast Du auch mal getestet ob es auch ohne das Setzen der TEST2, TEST1 und TEST0 Register funktioniert?

und dann das Register 0x3E auf 0xC2 gesetzt. Damit werden dann Nachrichten empfangen. Juhu - Nur warum ?

Bei meiner Firmware gibts einige konfigvariablen
0x3E ist ccmode, damit wird festgelegt wie die Firmware die Daten vom cc1101 empfängt:
0 - für ASK/OOK
1 - damit werden Daten vom cc1101 FIFO empfangen
2 - wie 1, aber es werden doppelte Nachrichten unterdrückt (wird bei Kopp FC verwendet)
3 und 4 wird bei La Crosse und ähnlichen Protokollen verwendet

Da bei La Crosse die einfache Empfangsroutine nicht funktioniert hat, waren bei 3 und 4 modifizierungen notwendig.
Die Routine für ccmode=4 habe ich vom CUL übernommen.

ccmode kann mit "set sduino raw ccmode=.." gesetzt werden.

Daß es mit 0x3E = 0xC2 funktioniert hat, war zufall, diesen ccmode gibt es eigentlich nicht, es dürfte ccmode=1 entsprechen.

Bitte teste mal ccmode=1 und ccmode=2, falls gleiche Nachrichten empfangen werden, müssten diese mit  ccmode=2 unterdrückt werden.

0x3D ist ccN,  N wird an der MN-Nachricht angehängt, damit kann die Parse Routine im 00_Signalduino.pm Modul die MN-Nachricht der entspechenden Protocol ID zuordnen.
N wird auch benötigt, daß beim Maple oder ESP32 mit mehreren cc1101 Modulen eine Nachricht über das passende cc1101 Modul gesendet wird.

R ist RSSI welche im 00_Signalduino.pm Modul umgerechnet wird

Code Auswählen Erweitern

$rssi = ($rssi>=128 ? (($rssi-256)/2-74) : ($rssi/2-74));

Verstehe ich das richtig, dass die Bankkurzbeschreibung auf dem Nano verbleibt und also nicht per SPI in den CC1101 geschrieben wird? Die Funktion ist dann mehrere Protokolleinstellungen in jeweils einer Bank zu halten um dann einfach Umschalten zu können? Richtig ?

Ja, mit "get sduino cmdBank s" können dann die Bankkurzbeschreibungen angezeigt werden.

Das Protokoll an sich ist wohl doch noch etwas komplizierter als von quadcorei8085 beschrieben. Ich bekomme Frames nicht nur mit einer Länge von 0x1B sondern auch 0x1D, 0x1E und 0x24. Die Struktur sieht ähnlich aus, aber da muss noch etwas mehr Arbeit investiert werden. Welche Fernbedienung verwendet wird macht dabei schon den ersten Unterschied. Z.B. VarioTel2 vs. MultiTel2. Und natürlich senden die Aktoren auch eine Response...

Ja mir ist das ganze auch noch nicht so richtig klar.

Ich hab mal mit dieser Nachricht

Code Auswählen Erweitern

MN;D=1BE74510050101F58D2AF58D2AF58D2A01110042CD317F734D01C705FFB1;N=13;R=220;
die Zuordung aufgeschrieben:

Code Auswählen Erweitern

                                          1 2 3 4 5 6 7 8  LQI RSSI
1BE74510050101F58D2AF58D2AF58D2A0111 0042 CD317F734D01C705 FF  B1
LLcciiIIHHyyggssssssbbbbbbffffffddDD ????

LL       = packet len
cc       = index/counter (used for rolling code)
ii       = packet info
II       = packet info 2
HH       = hop information (motors can relay remote messages)
yy       = sys address
gg       = source group
ss ss ss = source address   (remote control's address)
bb bb bb = backward address (remote control's address - when remote is sending directly)
ff ff ff = forward address  (remote control's address - when remote is sending directly)
dd       = destination count
DD       = destination

Die Bedeutung von 0042 ist mir nicht klar.

Ich habe damit "CD317F734D01C705" xor_encode.py ausgeführt und dies erhalten "0x00 0x00 0x16 0x03 0x00 0x00 0x00 0x40 "

Gruß Ralf

[quadcorei8085]

Hi,

Ich habe VarioTel2, aber wenn die MultiEtwas ist auch kompatibel mit der Rolladen dann Ich würde vermuten dass die Encrypt/Decrypt protocol ist die gleiche.

Variotel2 ist so dass jede taste Druck/Lass wird separat geschickt.

Bei mir wenn Ich ein taste drucke dann sehe 2x 3 packete (2x weil 1 ist taste druck 1 ist lassen - so button press/release is separate)

wenn du druckst (ohne lassen) -> 3x taste-druck botschaft wird mit payload = "0x00 0x00 0x00 0x01 0x00 ... 0x00" geschickt
und sofort wenn du der Taste lassts -> 3x "gleiche" (naturlich packet ID/counter ist anders) botschaft mit payload = "0x00 0x00 0x00 0x00 0x00 ... 0x00" geschickt

vom denen Ich weisst welche bit position ist meine Taste, jede taste be mir hatte verschiedene bit position (wie erwartet).
Ich habe verschiedene kanale nicht probiert Ich glaube dass ist einfach nur "destination address" aber habe nie geprüft.

[Michi]

Kurzes Statusupdate

Sowohl ccmode 1 als auch 2 scheinen zu funktionieren (ccmode 3 oder 4 nicht). Ein Unterdrücken von doppelten Frames bei ccmode 2 habe ich nicht festgestellt.

Ich glaube mittlerweile, dass der Unterschied bei den Sendern eher daran liegt, ob ein Empfänger angelernt ist oder nicht (und nicht unbedingt am Typ). Bei einem angelernten Empfänger sollte man ja ein konkretes Ziel haben wohin man senden möchte...

Ein Senden einer Nachricht beim Loslassen einer Taste habe ich nicht beobachtet.

Österliche Grüße - Michi

[quadcorei8085]

Wenn Ich ein taste drucke und dann lasse ich sehe die 2x 3 packete:

beim druck:
29 pck_len=0x1B 0x07 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x40 0xB1 0x17 0x96 0xC0 0xF1 0x4B 0x35 CRC=0 LQI=b RSSI=176
29 pck_len=0x1B 0x07 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x40 0xB1 0x17 0x96 0xC0 0xF1 0x4B 0x35 CRC=0 LQI=a RSSI=176
29 pck_len=0x1B 0x07 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x40 0xB1 0x17 0x96 0xC0 0xF1 0x4B 0x35 CRC=0 LQI=b RSSI=177

beim lassen:
29 pck_len=0x1B 0x08 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x7C 0xEF 0x32 0x28 0x84 0x43 0xFC 0xC9 CRC=0 LQI=5 RSSI=176
29 pck_len=0x1B 0x08 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x7C 0xEF 0x32 0x28 0x84 0x43 0xFC 0xC9 CRC=0 LQI=5 RSSI=174
29 pck_len=0x1B 0x08 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x7C 0xEF 0x32 0x28 0x84 0x43 0xFC 0xC9 CRC=0 LQI=5 RSSI=175

decode(0x40, 0xB1, 0x17, 0x96, 0xC0, 0xF1, 0x4B, 0x35) = (0x00 0x00 0x20 0x00 0x00 0x00 0x00 0xC0)
wo letztes byte 0xC0 ist ein parity (wie ich erinnere, war schon fast einem jahr).

decode(0x7C, 0xEF, 0x32, 0x28, 0x84, 0x43, 0xFC, 0xC9) = (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00)

so bit 5 im 3. byte ist die gedruckte Taste.

[Ralf9]

hier
https://github.com/appi1/elero_protocol/blob/main/main.cpp
wird das cc1101
Register 0x17 auf 0x3F gesetzt

Code Auswählen Erweitern

Bit 3:2  RXOFF_MODE  Stay in RX
Bit 1:0  TXOFF_MODE  RX

und das Register 0x18 auf 0x18 gesetzt

Code Auswählen Erweitern

Bit 5:4  FS_AUTOCAL   When going from IDLE to RX or TX (or FSTXON)

wenn ich das richtig überblicke, dann wird der cc1101 nur am Anfang calibriert, danach nicht mehr.
Laut Register 18 erfolgt ein calibrate nur bei einem Wechsel von idle zu RX oder zu TX.
Da laut Register 17 der cc1101 nach empfang einer Nachricht in RX bleibt, wird nie calibriert.

Bleibt die Frequenz über längere Zeit stabil, wenn kein calibrate erfolgt?


@Michi
bitte poste mal die MN-Nachrichten die Du beim Drücken der Tasten auf, ab und Stop empfängst.