SIGNALduino

SIGNALduino
Zweck / Funktion
	Empfang und Verarbeitung von digitalen Signalen
Allgemein
Typ	Gerätemodul
Details
Dokumentation	EN / DE; Thema
Support (Forum)	Sonstige Systeme
Modulname	00_SIGNALduino.pm
Ersteller	Sidey (Forum /Wiki)
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Einleitung

Übersicht

Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem CUL) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.

Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben. Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben. Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.

Vorteil gegenüber einem CUL/FHEMduino

Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: MU-Nachrichten werden z.T. als MC erkannt).

Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichende Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.

Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.

Hardware

Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden.

Der SIGNALduino basiert auf einem Arduino Nano, die Schaltung entspricht der des FHEMduino oder dem Selbstbau_CUL:

Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum FHEMduino
Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum Selbstbau_CUL.
Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, link zum Hersteller.

Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten.

Es stehen auch für den UNO und PRO Mini Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf github. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der Arduino IDE oder einem Makefile SIGNALduino Compilieren kann.

Es gibt auch eine Variante des SIGNALduino, die auf einem ESP8266 nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.

An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:

CC1101 Bezeichnung	ESP Pin
CLK	GPIO14
MOSI	GPIO13
MISO	GPIO12
CSN	GPIO15
GDO0	GPIO4
GDO2	GPIO5

Wird ein einfacher Empfänger / Sender Kombination verwendet, dann über die PINs:

Bezeichnung	ESP Pin
Transmitter	GPIO4
Receiver	GPIO5

Einfache Module

Beispielschaltplan SIGNAL(FHEM)duino

Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:

FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€).
RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.

Die Verkabelung erfolgt analog zum FHEMduino und das bedeutet (Arduino -> Modul):

PIN D2 an DATA des RX-Moduls
PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)

Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.

Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).

Software: Modul

USB-ID ermitteln

Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl

 ls -l /dev/serial/by-id

ausführen. Beispielhaft sieht das Ergebnis etwa so aus: lrwxrwxrwx 1 root root 13 Jan 31 00:02 usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port -> ../../ttyUSB0 Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.

FHEM-Modul laden

Die SIGNALduino Module werden über das FHEM update verteilt, sobald die Änderungen einen "stabilen" und alltags tauglichen Zustand haben.

Die in der Entwicklung befindliche Version kann mit folgenden Befehlen geladen werden:

FHEM aktualisieren: update
SIGNALduino Modul und Firmware aktualisieren: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet. Außerdem wird auch die Firmware geladen; im Log-File sieht man, wo diese hinkopiert wurden: z.B. nach FHEM/firmware/SIGNALduino_nano328.hex
Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):

define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600

Solltet Ihr einen SIGNALESP via IP einbinden wollen ist die Syntax

define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23

Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt.

Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden: update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.

Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.

Flashen des Arduino mit der SIGNALduino Firmware

Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:

sudo apt-get install avrdude

In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut hardware lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transreceiver verwenden, so wählt bitte folgende Hardware attr sduino hardware nanoCC1101 sonst üblicherweise attr sduino hardware nano328

Anschließend kann der flash Befehl abgesetzt werden: set sduino flash Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.

Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:

set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex

(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)

Flashen einer Firmware über HTTP

Die Firmware wird in absehbarer Zeit nicht mehr über den Update Mechanismus verteilt werden. Damit die passende Firmware auf den SIGNALduiono geladen werden kann, wird diese dann über HTTP geladen.

Vorabversion einer Firmware

Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt. Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.

Aktuell (Anfang 2018) ist noch die Version 3.3.1 in Entwicklung. Diese steht aktuell in einer Release Candidate Version zur Verfügung.

Für die Folgenden Microcontroller kann man die Firmware downloaden. (Die Download Links funktionieren erst ab einer FHEM-Modul Version vom 11.03.2018!)

SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101

set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_nanocc1101.hex

SIGNALDuino_nano.hex für einen Nano ohne cc1101

set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_nano.hex

SIGNALDuino_promini.hex für einen promini 3,3v / 8 Mhz ohne cc1101

set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_promini.hex

SIGNALDuino_miniculcc1101.hex für einen promini 3,3v / 8 Mhz mit cc1101 (minicul)

set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_miniculcc1101.hex

SIGNALDuino_radinocc1101.hex für einen radino mit cc1101

set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_radinocc1101.hex

SIGNALESP_331rc2.bin (mit cc1101) für einen ESP8266 set ipduino flash https://drive.google.com/uc?export=download&id=1V8ZfLnRnskc64XZkfL-qwmI7AsSd6KRG !Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool z.B. "ESP8266Flasher.exe" oder Esptool und einer seriellen Konsole.

Nach dem Booten des ESPs, spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN verbinden.

Flashen eines radino Boards mit ATmega32U4

Diese Funktion steht nur in der Entwicklungsversion dev-r33 zur Verfügung: Das Radino Board muss derzeit noch mit Angabe des Dateinamens geflasht werden: set sduino flash FHEM/firmware/SIGNALDuino_radinoCC1101.hex

Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.

Geräteerkennung

Unterstützte Geräte

Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden automatisch erkannt und in der Konfiguration eingetragen, wenn der SIGNALduino läuft. Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist.

Produkt	(E)mpfangen (S)enden	Hinweise	Verwendetes Modul	Protokoll ID
TCM Wetterstation (97001 und 21xxx Serie)	E		CUL_TCM97001	0
ABS Wetterstation (ABS 700)	E		CUL_TCM97001	0
Prologue Wetterstation	E		CUL_TCM97001	0
Rubicson Wetterstation	E		CUL_TCM97001	0
NC_WS Wetterstation	E		CUL_TCM97001	0
GT-WT-02 Wetterstation	E		CUL_TCM97001	0
AURIOL Wetterstation	E		CUL_TCM97001	0
Mebus Wetterstation	E		CUL_TCM97001	0
Intertechno Funkschalter	E S		IT	3,4,5,17
~~Conrad RSL Funkschalter~~	E S	Funktioniert aktuell nicht	SIGNALduino_RSL
Oregon Scientific Wettersensoren	E	Protokoll V2 & V3 implementiert	OREGON	10
Bresser Temp/Hydro Sensor	E		Hideki	12
Hama TS33C	E		Hideki	12
TFA Temp/Hydro Sensor	E		Hideki	12
Lacrosse TX2/TX3 Sensoren	E		CUL_TX	8
TFA 30320902	E		SD_WS07	7
Eurochron eas800z	E		SD_WS07	7
Technoline WS6750/TX70DTH	E		SD_WS07	7
FreeTec Außenmodul NC-7344	E		SD_WS07	7
CTW600	E		SD_WS09	9
WH1080	E		SD_WS09	9
Visivon remote pt4450	E		none	24
Einhell HS 434/6	E		none	21
Flamingo FA20RF / FA21RF Rauchmelder	E		none	13
mumbi m-FS300	E		none	26,27
TFA 30.3200	E		none	33
Livolo	E		none	20
Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571	E [S?]	IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo?	IT	3
Smartwares SH5-TSO-A	E S		IT	?
X10 Security Devices	E			39
Somfy RTS	E S		SOMFY	43

Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für Funksteckdose das Attribut

attr <Funksteckdose> ITclock 300

gesetzt werden, der Standardwert ist 250.

Mein Gerät wird in FHEM nicht erkannt

1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:

2. Eröffnet ein Thema unter github nach folgendem Muster:

Thema : Protokoll für <Das verwendete Gerät>

Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x

3. Auszug aus dem Logfile, welches zum Gerät gehört.

Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.

Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.

Es wird ein Protokoll erkannt, Autocreate legt aber kein device an

Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten. Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.

Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden. Im FHEM Log tauchen Meldungen ähnlich dieser auf

2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081

Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:

Entweder, wenn wir den Inhalt der Nachricht nur zu teilen wissen, da er sich ändert: define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on) attr mydoif do always

Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on) attr mydoif do always

Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.

Das Logfile

Im Logfile ab Verbose 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).

Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:

MS - Nachricht mit Sync Puls: Hierzu ein Beispiel

MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;

P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.

MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.

MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;

MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.

MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;

Es erscheinen viele Meldungen dieser Art:

Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate

Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen. Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:

dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt
dass die Anzahl der Sync-Pulse eine präzise Zahl ist
dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen

Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".

Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).

Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei jeglichen Transceiver-Systemen immer gleich erkannt werden muss - an dieser Stelle ist also ganz klar, dass diese Daten an allgemeine FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von jeglichen Transceiver-Systemen diese Daten immer auf die gleiche Weise (generisch/zentral) für die jeweilige Hersteller-Funk-Komponente erledigen.

Die Abfolge ist also ganz klar: Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> generische/zentrale Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. 14_SD_WS.pm).

Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)

Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen

"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann.

sduino: Unknown code u1FFFFF0, help me!

Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:

SIGNALduino_unknown incomming msg: u85#FF8081

Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.

Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen. Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. Die Protokollnummer kann Tabelle #Unterst.C3.BCtzte_Ger.C3.A4te entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form W50#FF553335FFBC dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (attr sduino whitelist_IDs 50).

Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!

Die Angabe erfolgt durch Komma getrennt: z.B.:

1,2,5,10

Senden mit dem SIGNALduino

Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:

set sduino sendMsg P3#00111010#R4

Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x. Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits. sduino: extracted data 00111010 (bin) sduino: Found Protocol id 3

Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig: set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;

R=3 bedeutet, das Signal wird 3x gesendet. Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden. Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.

Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.

Fehlerbehandlung

Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:

get raw e

als Antwort kommt dann "ccFactoryReset done". Ob ein solcher Reset nötig ist, erkennt man an der Antwort auf den Befehl "get config", auf den dann die Meldung "config: MS=1;MU=1;MC=1" folgen sollte.

In der Firmware sind die folgenden Befehle eingebaut

get raw C<reg>

<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: C35 -> C35 = 0D

get raw e

EEPROM / factory reset. resets all eeprom values without reboot

get raw r<AA>

Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)

get raw r<AA>n

Read 16 byte from eeprom (z.B. r00n)

get raw W<AA>

Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

Die Sendeleistung lässt sich mit

get sduino ccreg 3E

prüfen, wobei die Rückmeldung wie folgt zu lesen ist:

 "-10_dBm"  => '34',
 "-5_dBm"   => '68',
 "0_dBm"    => '60',
 "5_dBm"    => '84',
 "7_dBm"    => 'C8',
 "10_dBm"   => 'C0'

Dabei wird die Sendeleistung dauerhaft mit dem Befehl

set sduino cc1101_patable <value>

hochgeschaltet (<value> durch den Wert ersetzen).

Weitere Firmware-Befehle sind im Thread-Beitrag Beitrag zu finden.

Foren Links