SIGNALduino: Unterschied zwischen den Versionen
Sidey (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Trelle (Diskussion | Beiträge) |
||
| Zeile 100: | Zeile 100: | ||
|- | |- | ||
|X10 Security Devices||E|| || || 39 | |X10 Security Devices||E|| || || 39 | ||
|- | |||
|SOMFY RTS||E S|| || SOMFY || 43 | |||
|} | |} | ||
Version vom 28. Dezember 2016, 17:27 Uhr
| SIGNALduino | |
|---|---|
| Zweck / Funktion | |
| Unterstützung für CUL-Klon auf Arduino-Basis | |
| 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! | |
Das Modul SIGNALduino unterstützt den gleichnamigen Low-Cost Empfänger für digitale Signale, ähnlich einem CUL. Der SIGNALduino (Hardware) basiert auf einem Arduino. Hauptsächlich wurde er für den Arduino Nano entwickelt. Es stehen jedoch 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.
Er wird derzeit über den USB Port angeschlossen. Die Schaltung entspricht der des FHEMduino. In Arbeit ist auch eine Variante zum Selbstbau_CUL.
- Das Modul wird stetig weiterentwickelt
- Das Modul gibt bei Bedarf sehr viele Meldungen ins Logfile, in den Normaleinstellungen verhält es sich aber relativ ruhig.
Was macht dieser SIGNALduino?
Digitale Signale anhand von Mustern erkennen und zum Auswerten an FHEM weitergeben, dort können die Daten dann dekodiert werden. Zwischenzeitlich gibt der Arduino alle erkannten Signale an FHEM weiter, dies hilft um vor allem Signale zu finden, die noch nicht bekannt sind.
Beispiel: Arduino mit 433 Mhz Empfänger an einen Fhem Server anschließen und IT Steckdosen empfangen / schalten
Das System ist jedoch nicht auf 433 Mhz beschränkt. Es funktioniert auch mit anderen Frequenzen oder Medien, z.B. auch mit Infrarot oder direkt angebunden via Draht.
Worin liegt der Vorteil zu einem CUL oder FHEMduino?
Der vorteil besteht darin, dass man sehr schnell das Funksignal demodulieren kann. Wer Lust hat weitere Protokolle zu dekodieren, braucht dazu nur ein passendes FHEM Modul entwickeln oder ein universelles Modul erweitern. Änderungen am Arduino Code sind "eigentlich" nicht notwendig, dadurch skaliert das System gut.
Andere Möglichkeit: Wer einen Wettersensor dekodieren möchte, muss ja erst mal feststellen, was der Sensor sendet. Dazu kann man den SIGNALduino auch an den Sendeausgang des Sensors anbinden und empfängt die digitalen Signale. Bitte achtet aber auf die passenden Spannungen, bevor ihr eine solche Schaltung vornehmt. Ein Arduino Nano verträgt 5V.
Unterstützte Geräte
Für die folgenden Geräte gibt es derzeit eine Unterstützung für den Betrieb mit Fhem. Die Geräte werden automatisch erkannt und in der Konfiguration eingetragen wenn der SIGNALduino mal läuft.
| 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 | |
| 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 | |
| Eurochon 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 | |
| Einhel HS 434/6 | E | none | 21 | |
| FA21RF | E | none | 13 | |
| mumbi m-FS300 | E | none | 26,27 | |
| TFA 30.3200 | E | none | 33 | |
| Livolo | E | none | 20 | |
| Smartwares SH5-TSO-A | E S | IT | ? | |
| X10 Security Devices | E | 39 | ||
| SOMFY RTS | E S | SOMFY | 43 |
Hardware
Wie muss der Arduino verkabelt werden? Die Verkabelung ist Identisch zum FHEMduino
Des weiteren benötigt man neben dem Arduino ein Sendemodul und auch ein Empfangsmodul. Für gut befunden sind z.B. ein RXB6 Modul um 433 Mhz Signale empfangen zu können.
Einbinden in FHEM
Die SIGNALduino Module werden über das FHEM update verteilt.
Die in der Entwicklung befindliche Version kann auch geladen werden. Dazu folgende Befehle in Fhem ausführen:
1. FHEM aktualisieren: update
2. SIGNALduino Modul und Firmware aktualisieren: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/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 seht ihr, 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 natürlich an die aktuellen Gegebenheiten angepasst werden):
define sduino SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt.
Flashen des Ardunio 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 ja bereits 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.
Beispiel:
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).
Daten aus dem Logfile erklärt
Im Logfile ab Verbose 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird:
Unknown Code, so oder ähnlich 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, welches diese Daten jetzt in ihre Bedeutung umwandeln kann.
sduino: Unknown code u1FFFFF0, help me!
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.
Diese Einträge können mit dem Attribut WhitelistID minimiert werden. Geräte, welche ihr empfangen wollt, könnt ihr in die WhitelistID aufnehmen. Die Geräte werden dadurch anhand einer Protokollnummer identifiziert. Diese kann der obigen Tabelle zum Teil entnommen werden. Hilfreich ist es auch, wenn ihr in den verwendeten Geräten im Internal <gerätename>_DMSG nachseht. Diese sind teilweise nach folgendem Schema aufgebaut: W50#FF553335FFBC W50 bedeutet dann Protokoll #50.
Ist der Aufbau nicht so, hilft noch ein Blick in den Quellcode
MS - Nachricht mit Sync Puls: Es wurde eine Signal empfangen. P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. 15 Bedeutet es wurde ein Signalpegel (1) 395 Mikrosekundenhigh und Anschließend (5) 8916 Mikrosekunden low gemessen. CP=1 ist die Referenz auf den Takt des Signales. Getaktet wird in diesem Fall mit ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.
MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;
MC - Nachricht vom Typ Manchester: Manchester Kodierte 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;
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
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:
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)
attr mydoif do always
Der Teil u85#FF8081 muss individuell angepasst werden.
Wie kann ich etwas Senden
Der SIGNALduino kann etwas senden, indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Genannt "raw senden".
Um in der FHEM Kommandozeile etwas zu senden muss der Befehl wie folgt eingegeben werden:
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.
set sduino sendMsg P3#00111010#R4
Moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.
Es erscheinen viele Logmeldungen für Geräte die ich nicht habe
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
Viele dieser Logmeldungen können durch Setzen des verbose Levels auf den Wert 3 unterdrückt werden.
Dennoch kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:
SIGNALduino_unknown incomming msg: u85#FF8081
Das Attribut whitelistIDs erlaubt es, anzugeben, welche Protokolle vom FHEM Modul berücksichtigt werden. 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 Angabe erfolgt durch Komma getrennt: z.B.:
1,2,5,10