2-/3-fach kinetic switch an ESP8266 (Arduino)

[Pit0911 L. (peter_l603)]

Arduino Sketch für die Verwendung von 2-/3-fach Kinetic Switch an 
ESP8266 (Wemos D1) mit RFM69HW.

Dieses Projekt ist ein Auszug aus meiner Homeautomation über MQTT und 
enthält eine Basisfunktionalität zum Empfangen von 433Mhz-FSK-Codes der 
Mehrfach- Schalter (https://www.kinetic-switch.de/).
In diesem Sketch sind alle MQTT-Aktionen entfernt um die einfache 
Verwendung und Anpassungen zu erleichtern.

Ich habe den Schaltplan und mein PCB-Board als Bilder angefügt.
Aktuell sind bei mir 2 Kinetic-Schalter für meine Hauseinfahrt und meine 
Garage seit einigen Wochen  im Einsatz und es gab bisher keine Probleme.

Im Arduino-Sketch sind einige Kommentare für die wesentlichen 
Konfigurationen und Funktionen.

Beschreibung:

Verbindung RFM69HW an WEMOS D1:
// CS/NSS pin:    D8
// DIO0 pin:      D1
// RESET pin:     D3
// SCK            D5
// MOSI           D7
// MISO           D6
// 3,3V           3,3V (5V killt den RFM69HD!!!)
// GND            GND

Ich habe die wichtigen Settings in folgender Structure abgelegt (wird in 
der MQTT-Version per WEB-Server aktualisiert und als File auf dem ESP 
abgelegt...):

struct setvals {
  int ontime =300;                        // holdtime for each relais 
(millisecs), its possible for a defined pulstime on the external gate 
control (you can change to longer)
  String sync ="21A4";                    // the syncword in a RF-stream 
for kinetic switches...
  String c1[2] = {"C46A01", "EF3B04"};    // three hex values for a 
indentifier kinetic-button ('C46A' is kinetic switch ID (from the swicht 
backside label), next hex value is the button-id )
  String c2[2] = {"C46A02", "EF3B02"};    // three hex values for a 
indentifier kinetic-button ('C46A' is kinetic switch ID (from the swicht 
backside label), next hex value is the button-id )
                                          // '01 -  left button
                                          // '02' - right button
                                          // '04' - middle button

} settings;


RF-Code und Dekodierung:
Die Einstellungen für den RFM69HW sind fest auf die entsprechenden Werte 
eingestellt (diese Parameter werden von den meisten kinetic-switches 
verwendet).

Das Syncword für den RF-Stream wird über die Settings auf '21 A4' 
festgelegt.
die darauf folgenden Bytes sind :
23 EF 3B 02 64 21 4C 48 36 C4 E7 D5 7B A5 39 2D

Das erste Byte (23) ist nicht relevant und wird ignoriert.
Die beiden folgenden Bytes 'EF 3B' sind die Device-ID (steht auf der 
Rückseite des kinetic switches (siehe Bild kinswitch_3.jpg).
Das vierte Byte '02' ist die Button-ID ('01 - left, '02' - right, 
'04' - middle)
Die nächsten 2 Bytes '64 21' sind der CRC-16-Code über die Switch- und 
Button ID..., wird im Sketch geprüft.
Der Rest enthält den Zustand (press or release button) und weitere nicht 
verwendete Daten.
Ich werte den Schalterzustand nicht aus, der erste gültige Code setzt 
den zugeordneten Output für die definierte ontime (300 ms).
Der Wert ist für die meisten Torsteuerungen ausreichend, kann aber 
leicht angepasst werden.
Die kinetic-switches senden den Code mehrfach...auch das ist hier nicht 
relevant.

Aktuell ist der Sketch für 2 Känäle (Relaise) definiert.
Ich verwende 2 Schalter (je einen 2-fach und 3-fach) für das Tor und 
einen der 3-fach Schalter für die Garage.
Die beiden Setting-Arrays C1, und C2 enthalten die jeweiligen Button-ids 
mit der vorangestellten switch-id ({"C46A02", "EF3B02"}). Damit schalten 
beide rechte Buttons das Tor bei mir.
Wer möchte kann hier auch einen 3. Kanal oder mehrere kinetic switches 
hinzufügen.

Die beigefügte Schaltung ist wegen dem LM1117/3,3 für einen maximale 
Eingangsspannung von 12V DC ausgelegt! Bei höheren Eingangsspannungen 
muss dieser durch andere Typen ersetzt werden oder mit einen geeigneten 
DC/DC-Wandler begrenzt werden.

Meine Versuche den CC1101 als Empfänger einzusetzen sind trotz gleicher 
HF-Parameter gescheitert, obwohl ich die Daten mit einem SDR-RTL 
eindeutig decodieren konnte.
Offensichtlich sind die Teile aus China nicht brauchbar...
Mit dem RFM69HW (433 MHz) funktioniert der Empfang einwandfrei.
Die nötige Antenne ist ein Stück Kupferdraht von 16,5 cm länge, einfach 
über einen Stift gewickelt...

Achtung!
Eingriffe in eure Torsteuerungen solltet ihr nur mit den nötigen 
Kenntnissen vornehmen!
Ich übernehme keine Haftung für verursachte Schäden!

[J. S. (jojos)]

kann man so machen, nur sind die Tore dann sehr einfach zu öffnen. Kein 
Rolling Code, keine Sicherheit gegen Replay Angriffe. Und das geht sehr 
einfach mit so Werkzeugen wie Flipper Zero.

[Pit0911 L. (peter_l603)]

J. S. schrieb:
> kann man so machen, nur sind die Tore dann sehr einfach zu öffnen. Kein
> Rolling Code, keine Sicherheit gegen Replay Angriffe. Und das geht sehr
> einfach mit so Werkzeugen wie Flipper Zero.

Danke für die Antwort!
Es ist einfach billiger das Tor so öffnen zu lassen, als es durch 
mechanische Gewalt zu zerstören.
Ich wohne auch nicht im Hochsicherheitsgefängnis...
Aber du hast Recht.

Also für alle:
Dieses Projekt betrachtet keine Sicherheitsbedenken.
Wer darauf Wert legt, sollte sich entsprechende Funktionen 
implementieren.

[Daniel (dcerf)]

@Pit0911 L. (peter_l603)
Ein ganz liebes und großes Dankeschön für Dein post.
2 verschiedene CC1101 empfangen bei mir auch nichts Auswertbares.
Mit RFM69 hat es sofort funktioniert.

Dann versuche ich auch evtl. zu helfen.

Pit0911 L. schrieb:
> Das Syncword für den RF-Stream wird über die Settings auf '21 A4'
> festgelegt.
> die darauf folgenden Bytes sind :
> 23 EF 3B 02 64 21 4C 48 36 C4 E7 D5 7B A5 39 2D
>
> Das erste Byte (23) ist nicht relevant und wird ignoriert.
> Die beiden folgenden Bytes 'EF 3B' sind die Device-ID (steht auf der
> Rückseite des kinetic switches (siehe Bild kinswitch_3.jpg).
> Das vierte Byte '02' ist die Button-ID ('01 - left, '02' - right,
> '04' - middle)
> Die nächsten 2 Bytes '64 21' sind der CRC-16-Code über die Switch- und
> Button ID..., wird im Sketch geprüft.
> Der Rest enthält den Zustand (press or release button) und weitere nicht
> verwendete Daten.
> Ich werte den Schalterzustand nicht aus, der erste gültige Code setzt
> den zugeordneten Output für die definierte ontime (300 ms).

Das erste Byte (23) gehört zur Sync-ID (syncWord).
Die beiden folgenden Bytes 'EF 3B' sind die Device-ID.
Das vierte Byte '02' ist buttonState.

Kinetic-Schalter
senden beim schalten nur den buttonState mit führender "0" z.B.: "02", 
"04", "08", "0.."
Beim schalten in eine Position dann z.B. "02" und beim umschalten in die 
andere Position dann z.B. "08"

Kinetic-Taster
senden beim drücken den buttonState (wie die Schalter) z.B.: "02"
beim loslassen des Tasters dann einen buttonState von "C0"

Payload ist die SwitchID (2 byte) + buttonSate (1 byte) und crc16 (2 
byte)
Im Code dann RF_PACKET_SIZE 5 // 5 byte statt 16

Dein Code wertet den Schaltzustand aus.
Der "Rest" hat damit nichts zu tun.

Jede Übertragung erfolgt mit 3 frames.
Weitere (für die original Empfänger unnötige) Frames... so lange noch 
Energie des Kinetic-Switch vorhanden ist.

Sync-ID (syncWord) hat 4 byte.
54 21 A4 23

Preamble 32 bit (4byte)
55 55 55 55

In dem Code:
radio1.setPreambleLength(32); // RF-Stream length (bytes)

32 bit Länge, nicht bytes.
Das setzen ist nicht nötig, weil schon vorher festgelegt bei:
int rstate = radio1.begin(433.3, 96, 50, 100.0, 13, 32);

konfig würde ich 100Kbps statt 96 vorziehen.

Code:
Ist es nicht etwas unglücklich im struct String zu verwenden um es 
später jedes mal in uint8_t zu konvertieren?
Hängt das mit der nicht vorhandenen MQTT Implementierung zusammen?

An Deinem kompletten Code mit MQTT hätte ich sehr großes Interesse ;-)

Dankeschön.