SIGNALduino: Unterschied zwischen den Versionen
K (Fix completely wrong [text] order (of processing handling)) |
Sidey (Diskussion | Beiträge) K (Aktualisierung auf aktuellen Stand, Pflege von Hyperlinks) |
||
(90 dazwischenliegende Versionen von 14 Benutzern werden nicht angezeigt) | |||
Zeile 8: | Zeile 8: | ||
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]]) | |ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]]) | ||
}} | }} | ||
== Einleitung == | == Einleitung == | ||
=== Übersicht === | === Übersicht === | ||
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem | {{Randnotiz|RNTyp=Info|RNText=Wo finde ich was/welche Info? | ||
;Hardware | |||
#SIGNALDuino ((noch) "hier") | |||
#[[Selbstbau CUL]] | |||
#[[Maple-SignalDuino]] | |||
#[[ESP32-SignalDuino]] | |||
;Firmware | |||
#"Sidey" - [[SIGNALduino#Flashen_des_Arduino_mit_der_SIGNALduino_Firmware|mittels Modul]] | |||
#"Ralf9" - [https://github.com/Ralf9/SIGNALDuino Github] | |||
;FHEM Modul | |||
#"Sidey" - [[SIGNALduino]] ("hier") | |||
#"Ralf9" - {{Link2Forum|Topic=111653|Linktext=hier beschrieben}} | |||
}} | |||
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 erkennt Signale anhand von Mustern und gibt sie an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben. | 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 (z.B. Raspberry) gemacht. | |||
=== Vorteil gegenüber einem CUL/FHEMduino === | === 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 änderbarer/updatebarer Rechner-Seite). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung auf Stick-Firmware-Seite korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]). | |||
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichenden Frequenzen steuerbar sind. So empfangen die ''Somfy''-Rolladenmotoren beispielsweise auf 433.42 MHz 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 | 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. | ||
=== Entwicklungsversion === | |||
Der SIGNALduino wird derzeit aktiv weiterentwickelt. In FHEM existieren inzwischen zwei verschiedene Versionen: eine offizielle (Maintainer ist Sidey) und eine inoffizielle (Maintainer ist Ralf9). Die offizielle Version wird über den update-Prozess verteilt, wer die inoffizielle nutzen will, muss hier händisch eingreifen. Beide Versionen sind inzwischen so weit entwickelt, dass sie nicht mehr ohne Weiteres kompatibel sind. Man muss also eine Entscheidung treffen, welches das für einen geeignete Modul ist. Das betrifft inzwischen nicht nur das eigentliche SIGNALduino.pm-Modul, sondern auch die dazugehörige Firmware. | |||
==== Offizielles Modul (Sidey) ==== | |||
Die offizielle Version wird in mehreren Forenbeiträgen beschrieben: {{Link2Forum|Topic=58397|Linktext=erster Beitrag]}} (inzwischen geschlossen), {{Link2Forum|Topic=58396|LinkText=weiterer Thread}} sowie {{Link2Forum|Topic=60170|Linktext=noch ein Thread}}. | |||
An einem weiteren Thread ({{Link2Forum|Topic=58396|Linktext=Link}}) scheinen beide Autoren beteiligt zu sein. | |||
==== Inoffizielles Modul (Ralf9) ==== | |||
Das Modul von Ralf9 wird {{Link2Forum|Topic=111653|Linktext=hier}} beschrieben. Wer es installieren möchte, muss beim üblichen update-Prozess das Modul 00_SIGNALduino.pm vom [[update]] (Attribut ''[[Update#exclude from update|exclude from update]]'') ausschließen oder nach jedem Update erneut Ralf9s-Modul herunterladen. Die Installation des Moduls wird im ersten Post beschrieben, Hilfe gibt es auch in diesem Thread. | |||
== Hardware == | == Hardware == | ||
=== Controller === | |||
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe [[ESP8266#Bekannte_Probleme|diesen Hinweis]]). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe [https://www.tippscout.de/internet-was-sind-tcp-ip-udp-und-icmp_tipp_2268.html hier]) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet. | |||
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht dem [[Selbstbau CUL]] (eine frühere Version ist der nicht mehr weiterentwickelte [[FHEMduino]]): | |||
* 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]]. Dieser Aufbau wird derzeit empfohlen. | |||
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php 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 [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini 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 [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist momentan die Übersetzung mittels [https://platformio.org/ Plattform IO]. 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]] oder [https://de.wikipedia.org/wiki/ESP32 ESP32] nativ läuft. | |||
Auch an den "ESP8266" oder "ESP32" kann ein [[Selbstbau CUL|CC1101]] Modul via SPI angebunden werden: | |||
{| | | |||
!CC1101 Bezeichnung | |||
!ESP 8266 Pin | |||
!ESP 32 PIN | |||
|- | |||
|CLK||GPIO14 | |||
|D18 | |||
|- | |||
|MOSI||GPIO13 | |||
|D23 | |||
|- | |||
|MISO||GPIO12 | |||
|D19 | |||
|- | |||
|CSN||GPIO15 | |||
|D5 | |||
|- | |||
|GDO0||GPIO4 | |||
|D4 | |||
|- | |||
|GDO2||GPIO5 | |||
|D13 | |||
|} | |||
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die Pins: | |||
{| | | |||
! Bezeichnung | |||
! ESP 8266 Pin | |||
|- | |||
|Transmitter||GPIO4 | |||
|- | |||
|Receiver||GPIO5 | |||
|} | |||
=== Sendemodule === | |||
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}} | |||
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] | [[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] | ||
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen: | Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen: | ||
* FS1000A Dies ist das Sendemodul (TX) | * FS1000A Dies ist das Sendemodul (TX) - es 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. | * RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland. | ||
Zeile 53: | Zeile 115: | ||
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). | 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 | == Software == | ||
=== USB-ID ermitteln === | === 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 | 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 | ||
<pre> ls -l /dev/serial/by-id </pre> | <pre> ls -l /dev/serial/by-id </pre> | ||
ausführen. Beispielhaft sieht das Ergebnis etwa so aus: | 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'' | |||
''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. | 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 === | === FHEM-Modul laden === | ||
Die SIGNALduino Module werden über das FHEM [[update]] verteilt. | Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.5.4 seit 06.01.2023 verteilt. | ||
Die in | Mit Version 3.5.x ist die Unterstützung für Geräte mit '''FSK'''-Modulation integriert. | ||
Die aktuell in Entwicklung befindliche Version kann über folgende Vorgehensweise installiert werden: | |||
* FHEM aktualisieren: <code>update</code> | * FHEM aktualisieren: <code>update</code> | ||
* SIGNALduino Modul | * SIGNALduino Modul aktualisieren: <code>update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master<nowiki/>/controls_signalduino.txt</code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.<code><nowiki/></code> | ||
* Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen: <code>update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt</code>, um weitere Entwicklungs-Updates zu bekommen, und damit das nächste Standard-<code>update</code> nicht die alte Version wieder einspielt. | |||
Das Gerät kann wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden): | |||
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code> | :<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code> | ||
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. | * Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird): | ||
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code> | |||
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 - | |||
Verbindungsversuche via telnet müssen dieselbe Baudrate verwenden. | |||
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>. | Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>. | ||
Zeile 83: | Zeile 151: | ||
:<code>sudo apt-get install avrdude</code> | :<code>sudo apt-get install avrdude</code> | ||
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 | 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 Transceiver verwenden, so wählt bitte folgende Hardware | ||
<code>attr sduino hardware nanoCC1101</code> | :<code>attr sduino hardware nanoCC1101</code> | ||
sonst üblicherweise | sonst üblicherweise | ||
<code>attr sduino hardware nano328</code> | :<code>attr sduino hardware nano328</code> | ||
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. | |||
:<code>attr sduino updateChannelFW testing</code> | |||
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl | |||
:<code>get sduino availableFirmware</code> | |||
Anschließend kann der ''flash'' Befehl abgesetzt werden: | Anschließend kann der ''flash'' Befehl abgesetzt werden: | ||
<code>set sduino flash </code> | :<code>set sduino flash <und-dann-auswaehlen></code> | ||
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt. | Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt. | ||
Zeile 96: | Zeile 168: | ||
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde) | (je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde) | ||
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in {{Link2Forum|Topic=114413|LinkText=diesem Forenthema}}. | |||
==== Flashen einer Firmware über HTTP ==== | |||
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. | |||
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases 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. | |||
Die Version 3.4 ist die aktuell stabile Version. | |||
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen. | |||
Dazu muss das Attribut <code>hardware</code> auf einen gültigen Wert angepasst werden! | |||
Über den GET Befehl <code>availableFirmware</code> werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut <code>updateChannelFW</code> kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll. | |||
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen. | |||
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden. | |||
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B. | |||
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101 | |||
<code>set sduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex | |||
oder | |||
SIGNALESP_.hex (mit cc1101) für einen ESP8266 | |||
<code>set ipduino flash </code>https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex | |||
!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. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole. | |||
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File. | |||
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 nach Eingabe der Daten verbinden. | |||
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ . | |||
Dort kann auch eine Änderungshistorie eingesehen werden. | |||
==== Flashen eines radino Boards mit ATmega32U4 ==== | ==== Flashen eines radino Boards mit ATmega32U4 ==== | ||
Diese Funktion steht | Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung: | ||
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird. | Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird. | ||
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut <code>flashCommand</code> hinterlegt werden muss. | |||
==== Fehler beim Flashen ==== | |||
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen. | |||
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen: | |||
<code> | |||
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log | |||
</code> | |||
=== Geräteerkennung === | === Geräteerkennung === | ||
==== Unterstützte Geräte ==== | ==== 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 [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft. | Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft. | ||
{|class="wikitable" | Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte Geräte]] lassen sich die Geräte näher identifizieren. | ||
! style="text-align:left;"| Produkt | {| class="wikitable" | ||
! style="text-align:left;" | Produkt | |||
! (E)mpfangen<br />(S)enden | ! (E)mpfangen<br />(S)enden | ||
! Hinweise | ! Hinweise | ||
! Verwendetes Modul | ! Verwendetes Modul | ||
! Protokoll ID | ! Protokoll ID | ||
|- | |||
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3 | |||
|- | |- | ||
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0 | |TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0 | ||
Zeile 132: | Zeile 250: | ||
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17 | |Intertechno Funkschalter||E S|| ||IT || 3,4,5,17 | ||
|- | |- | ||
| | |Conrad RSL Funkschalter||E S|| || SIGNALduino_RSL || | ||
|- | |- | ||
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10 | |[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10 | ||
Zeile 153: | Zeile 271: | ||
|- | |- | ||
|CTW600||E || || SD_WS09 || 9 | |CTW600||E || || SD_WS09 || 9 | ||
|- | |||
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9 | |||
|- | |- | ||
|WH1080||E || || SD_WS09 || 9 | |WH1080||E || || SD_WS09 || 9 | ||
Zeile 160: | Zeile 280: | ||
|Einhell HS 434/6||E || || none || 21 | |Einhell HS 434/6||E || || none || 21 | ||
|- | |- | ||
|Flamingo FA20RF / FA21RF Rauchmelder||E || || | |Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2 | ||
|- | |- | ||
|mumbi m-FS300||E || || none || 26,27 | |mumbi m-FS300||E || || none || 26,27 | ||
Zeile 167: | Zeile 287: | ||
|- | |- | ||
|Livolo||E|| || none || 20 | |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 || ? | |Smartwares SH5-TSO-A||E S|| || IT || ? | ||
Zeile 174: | Zeile 296: | ||
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43 | |[[Somfy_via_SIGNALduino|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 | 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'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut | ||
:<code>attr <Funksteckdose> ITclock 300</code> | :<code>attr <Funksteckdose> ITclock 300</code> | ||
gesetzt werden, der Standardwert ist 250. | gesetzt werden, der Standardwert ist 250. | ||
==== Mein Gerät wird in FHEM nicht erkannt ==== | ==== 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: | 1. Prüfen, ob vom Sensor die Signaldaten (<code>verbose</code> >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit: | ||
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues/new?template=sensor---device-feature.md github]: | |||
<!-- <syntaxhighlight lang="md"> ... markdown lexer not yet available; use pre instead --> | |||
<pre> | |||
## Specifications for new sensor / switch / or other device ... | |||
- manufacturer: | |||
- model name: | |||
- pictures of the device / the board (very helpful) | |||
## Specifications | |||
- Microcontroller: | |||
- Version (Firmware): | |||
: | |||
<!-- ( can be found here devicename -> Internals -> version ) --> | |||
- Versionmodul (FHEM Module): | |||
</pre> | |||
3. Auszug aus dem Logfile, welches zum Gerät gehört. | 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. | :''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.'' | ||
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]]. | |||
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ==== | ==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ==== | ||
Im SIGNALduino sind > | Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Modul, welches diese Protokolle verarbeitet. | ||
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. | 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 auch kurz und knapp manuell (also ohne Modul und automatisch angelegtem Gerät). | ||
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden. | Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden. | ||
Im FHEM Log tauchen Meldungen ähnlich dieser auf | Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf | ||
<code> | <code> | ||
Zeile 203: | Zeile 340: | ||
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen: | Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen: | ||
Entweder, wenn wir den Inhalt der Nachricht nur zu | Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert: | ||
<code> | <code> | ||
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on) | define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on) | ||
Zeile 210: | Zeile 348: | ||
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring | Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring | ||
<code> | <code> | ||
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on) | define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on) | ||
Zeile 217: | Zeile 356: | ||
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch. | Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch. | ||
=== | Als Alternative zu DOIF hier ein regex-verwendendes [[notify]]-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen: | ||
Im Logfile ab [[ | |||
<code> | |||
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; } | |||
</code> | |||
Selbstverständlich muss in diesem Moment auch eine <code>sub my_sender_trigger_indicate()</code> definiert werden (z.B. in <code>FHEM/99_myUtils.pm</code>), die dort z.B. als Test eine Log-Ausgabe (<code>Log3()</code>) machen kann. | |||
=== Das Logfile === | |||
Im Logfile ab [[verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (<code>verbose</code> 3 unterdrückt diese Meldungen). | |||
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden. | |||
Die Protokolle können wie folgt unterschieden werden: | 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 - Nachricht mit Sync Puls: Hierzu ein Beispiel | ||
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und | :<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und Vorzeichen): Die Zahl gibt in Mikrosekunden die Zeitdauer an, das Vorzeichen bestimmt, ob es sich um eine gesendetes Signal gehandelt hat (positives Vorzeichen) oder ob das Signal gerade pausierte (negatives Vorzeichen). Insofern ist die Beschreibung "negatives Signal" irreführend - es gab in der Zeitspanne gerade kein Signal. Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde 395 Mikrosekunden (P1) ein Signal gesendet (weil P1='''+'''395), danach gab es 8916 Mikrosekunden kein Signal (Pause, wegen P5='''-'''8196). 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 - 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. | ||
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code> | :<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code> | ||
*MU - Message unsynced: Diese Art von Nachrichten | *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. | ||
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code> | :<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code> | ||
* MN : Nachrichten dieser Art wurden vom cc1101 vor bearbeitet. Die Nachrichten dieser Art enthalten unter D= den Empfangenen Datensatz hexadezimal codiert. Der Wert R= gibt die Empfangsstärke, auch hexadezimal an.<syntaxhighlight lang="bash"> | |||
MN;D=3002925F3A1E7B6C000200002584;R=43; | |||
</syntaxhighlight> | |||
Es erscheinen viele Meldungen dieser Art: | Es erscheinen viele Meldungen dieser Art: | ||
Zeile 240: | Zeile 391: | ||
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate | Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate | ||
</pre> | </pre> | ||
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 Internet-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 folgende Bits-Bereiche enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Daten-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 (identisch) 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. <code>14_SD_WS.pm</code>). | |||
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==== | ====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen==== | ||
Zeile 251: | Zeile 420: | ||
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. | 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. | Derartige Einträge können mit dem Attribut <code>WhitelistID</code> 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 <code>WhitelistID</code> 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. | 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 [[# | Die Protokollnummer kann der Tabelle [[#Unterstützte Geräte|Unterstützte Geräte]] 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 <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>). | ||
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!! | {{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!! | ||
}} | }} | ||
Zeile 260: | Zeile 429: | ||
=== Senden mit dem SIGNALduino === | === Senden mit dem SIGNALduino === | ||
Der SIGNALduino kann etwas "raw senden", indem ihm das | 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: | ||
<code> | <code> | ||
Zeile 273: | Zeile 442: | ||
</code> | </code> | ||
Alternativ kann das Signal auch in einer " | Alternativ kann das Signal auch in einer "Rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig: | ||
<code> | <code> | ||
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;; | set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;; | ||
Zeile 279: | Zeile 448: | ||
R=3 bedeutet, das Signal wird 3x gesendet. | R=3 bedeutet, das Signal wird 3x gesendet. | ||
Die Übertragung besteht aus den in D | Die Übertragung besteht aus den in D angegebenen Pulsen, welche in P0-P5 definiert werden. | ||
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren. | Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren. | ||
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden. | Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden. | ||
====Fehlersuche==== | |||
(Zielgerät reagiert nicht, etc.) | |||
* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein | |||
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}} | |||
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort {{Link2Forum|Topic=58397|Message=775434|LinkText=Signalduino Version 3.3.1}}, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut <code>ITClock</code> eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt Geräte-Instanz-spezifische Konfiguration) das <code>ITclock</code> eines IT-Client-Devices. | |||
== Fehlerbehandlung == | == Fehlerbehandlung == | ||
=== Modul-Initialisierung === | |||
==== Perl-Modul Digest::CRC fehlt ==== | |||
Das FHEM-Log kann (bei Version ab 3.5.x) folgendes enthalten: | |||
<code>Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /opt/fhem . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870. | |||
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code> | |||
In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul <code>Digest::CRC</code> (Ubuntu und Debian: Package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden. | |||
=== Konfiguration von Firmware/Hardware (Reset usw.) === | |||
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden: | Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden: | ||
:<code> | :<code>set raw e</code> | ||
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading <code>cc1101_config</code>, dort unsinnige Werte angezeigt werden oder dem Reading <code>config</code> welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht. | |||
In der Firmware sind die | In der Firmware sind diverse Befehle eingebaut, welche über einen <code>set raw</code> Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollte die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des <code>set raw</code> Befehls nur im Logfile ab verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird: | ||
:<code>C<reg></code> <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: <code>set raw C35</code> führt ab verbose 4 zu einer Logausgabe folgender Art: <code>Read, msg: C35 = 0D</code> | |||
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. | :<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot | ||
Example: C35 | :<code>W<AA><XX></code> 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 des CC1101) | ||
EEPROM / factory reset. resets all eeprom values without reboot | |||
Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die | |||
Die Sendeleistung lässt sich mit | Die Sendeleistung lässt sich mit | ||
:<code>get sduino | :<code>get sduino ccpatable</code> | ||
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: | prüfen, wobei die Rückmeldung wie folgt zu lesen ist: | ||
Zeile 322: | Zeile 503: | ||
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}} | * {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}} | ||
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}} | * {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}} | ||
* {{Link2Forum|Topic=82379|Message=1033374|LinkText=SIGNALDuino Schaltplan}} | |||
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }} | * {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }} | ||
* [http://www. | * [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung] | ||
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]] | * [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]] | ||
* [[Somfy via SIGNALduino]] | * [[Somfy via SIGNALduino]] | ||
[[Kategorie:Interfaces]] | [[Kategorie:Interfaces]] | ||
[[Kategorie:Arduino]] | [[Kategorie:Arduino]] | ||
[[Kategorie:433MHz]] | |||
[[Kategorie:868MHz]] |
Aktuelle Version vom 2. April 2023, 11:24 Uhr
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
![Info green.png](/w/images/thumb/0/02/Info_green.png/20px-Info_green.png)
- Hardware
- SIGNALDuino ((noch) "hier")
- Selbstbau CUL
- Maple-SignalDuino
- ESP32-SignalDuino
- Firmware
- "Sidey" - mittels Modul
- "Ralf9" - Github
- FHEM Modul
- "Sidey" - SIGNALduino ("hier")
- "Ralf9" - Thema
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 (z.B. Raspberry) 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 änderbarer/updatebarer Rechner-Seite). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung auf Stick-Firmware-Seite 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 abweichenden Frequenzen steuerbar sind. So empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 MHz 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.
Entwicklungsversion
Der SIGNALduino wird derzeit aktiv weiterentwickelt. In FHEM existieren inzwischen zwei verschiedene Versionen: eine offizielle (Maintainer ist Sidey) und eine inoffizielle (Maintainer ist Ralf9). Die offizielle Version wird über den update-Prozess verteilt, wer die inoffizielle nutzen will, muss hier händisch eingreifen. Beide Versionen sind inzwischen so weit entwickelt, dass sie nicht mehr ohne Weiteres kompatibel sind. Man muss also eine Entscheidung treffen, welches das für einen geeignete Modul ist. Das betrifft inzwischen nicht nur das eigentliche SIGNALduino.pm-Modul, sondern auch die dazugehörige Firmware.
Offizielles Modul (Sidey)
Die offizielle Version wird in mehreren Forenbeiträgen beschrieben: Thema (inzwischen geschlossen), weiterer Thread sowie Thema.
An einem weiteren Thread (Thema) scheinen beide Autoren beteiligt zu sein.
Inoffizielles Modul (Ralf9)
Das Modul von Ralf9 wird Thema beschrieben. Wer es installieren möchte, muss beim üblichen update-Prozess das Modul 00_SIGNALduino.pm vom update (Attribut exclude from update) ausschließen oder nach jedem Update erneut Ralf9s-Modul herunterladen. Die Installation des Moduls wird im ersten Post beschrieben, Hilfe gibt es auch in diesem Thread.
Hardware
Controller
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. Bei Einbindung via ESP muss man beachten, dass der ESP nach 5 Minuten Inaktivität seine TCP-Verbindung unterbricht (siehe diesen Hinweis). Zu diesem Zweck gibt es einen Signalduino-eigenen Ping-Befehl ('get signalduino ping'), der diese Aktivität wieder aufbaut. Ping-Befehle sind auch auf Betriebssystemebene bekannt - allerdings beachte man, dass der ping-Befehl auf Betriebssystemebene ICMP verwendet, zum "Aufwachen" des ESP aber auf TCP-Ebene aktiviert werden muss (zum Unterschied siehe hier) und man daher besser den Signalduino-eigenen Befehl und nicht das Betriebssystem verwendet.
Der SIGNALduino basiert auf einem Arduino Nano, die Schaltung entspricht dem Selbstbau CUL (eine frühere Version ist der nicht mehr weiterentwickelte FHEMduino):
- 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. Dieser Aufbau wird derzeit empfohlen.
- 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 momentan die Übersetzung mittels Plattform IO. 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 oder ESP32 nativ läuft.
Auch an den "ESP8266" oder "ESP32" kann ein CC1101 Modul via SPI angebunden werden:
CC1101 Bezeichnung | ESP 8266 Pin | ESP 32 PIN |
---|---|---|
CLK | GPIO14 | D18 |
MOSI | GPIO13 | D23 |
MISO | GPIO12 | D19 |
CSN | GPIO15 | D5 |
GDO0 | GPIO4 | D4 |
GDO2 | GPIO5 | D13 |
Wird eine einfache Empfänger / Sender Kombination verwendet, dann über die Pins:
Bezeichnung | ESP 8266 Pin |
---|---|
Transmitter | GPIO4 |
Receiver | GPIO5 |
Sendemodule
![X mark.svg](/w/images/thumb/a/a2/X_mark.svg/20px-X_mark.svg.png)
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:
- FS1000A Dies ist das Sendemodul (TX) - es 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
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 alltagstauglichen Zustand haben. Aktuell wird dort die Version 3.5.4 seit 06.01.2023 verteilt.
Mit Version 3.5.x ist die Unterstützung für Geräte mit FSK-Modulation integriert.
Die aktuell in Entwicklung befindliche Version kann über folgende Vorgehensweise installiert werden:
- FHEM aktualisieren:
update
- SIGNALduino Modul aktualisieren:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet. - Es empfiehlt sich, die Github-Quelle dauerhaft einzutragen:
update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
, um weitere Entwicklungs-Updates zu bekommen, und damit das nächste Standard-update
nicht die alte Version wieder einspielt.
Das Gerät kann 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 (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):
define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Die Baudrate beim SIGNALduino beträgt 57600 -
Verbindungsversuche via telnet müssen dieselbe Baudrate verwenden.
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 Transceiver verwenden, so wählt bitte folgende Hardware
attr sduino hardware nanoCC1101
sonst üblicherweise
attr sduino hardware nano328
Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing.
attr sduino updateChannelFW testing
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl
get sduino availableFirmware
Anschließend kann der flash Befehl abgesetzt werden:
set sduino flash <und-dann-auswaehlen>
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)
Wenn ein miniCUL geflasht werden soll, sind einige Besonderheiten zu beachten. Details dazu in diesem Forenthema.
Flashen einer Firmware über HTTP
Die Firmware wird nicht mehr über den FHEM Update Mechanismus verteilt. Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP aus den Github Releases 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.
Die Version 3.4 ist die aktuell stabile Version.
Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen.
Dazu muss das Attribut hardware
auf einen gültigen Wert angepasst werden!
Über den GET Befehl availableFirmware
werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut updateChannelFW
kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.
Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen. Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.
Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B. SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101
set sduino flash
https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_radinocc11013.3.1.hex
oder
SIGNALESP_.hex (mit cc1101) für einen ESP8266
set ipduino flash
https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_ESP8266cc11013.3.1.hex
!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. Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File.
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 nach Eingabe der Daten verbinden.
Die Hauptseite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ . Dort kann auch eine Änderungshistorie eingesehen werden.
Flashen eines radino Boards mit ATmega32U4
Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten Version zur Verfügung:
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut flashCommand
hinterlegt werden muss.
Fehler beim Flashen
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.
Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den folgenden Pfad an euren Servernamen anhängen:
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log
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. In der detaillierten Liste Geprüfte Geräte lassen sich die Geräte näher identifizieren.
Produkt | (E)mpfangen (S)enden |
Hinweise | Verwendetes Modul | Protokoll ID |
---|---|---|---|---|
Conrad Wetterstation KW9110 | E S | Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst | CUL_TCM97001 | 0.3 |
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 | 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 | |
CTW602 | E | neuere Version des CTW600 mit 868.35 MHz | SD_WS09 | 9 |
WH1080 | E | SD_WS09 | 9 | |
Visivon remote pt4450 | E | none | 24 | |
Einhell HS 434/6 | E | none | 21 | |
Flamingo FA20RF / FA21RF / FA22RF Rauchmelder | E | FLAMINGO | 13,13.1,13.2 | |
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 (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) 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:
## Specifications for new sensor / switch / or other device ... - manufacturer: - model name: - pictures of the device / the board (very helpful) ## Specifications - Microcontroller: - Version (Firmware): <!-- ( can be found here devicename -> Internals -> version ) --> - Versionmodul (FHEM Module):
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.
Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: Unbekannte_Funkprotokolle.
Es wird ein Protokoll erkannt, Autocreate legt aber kein device an
Im SIGNALduino sind >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches Modul, welches diese Protokolle verarbeitet. 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 auch kurz und knapp manuell (also 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 (und, insbesondere, im FHEMWEB Event Monitor) 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.
Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }
Selbstverständlich muss in diesem Moment auch eine sub my_sender_trigger_indicate()
definiert werden (z.B. in FHEM/99_myUtils.pm
), die dort z.B. als Test eine Log-Ausgabe (Log3()
) machen kann.
Das Logfile
Im Logfile ab verbose 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose
3 unterdrückt diese Meldungen).
UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt Unbekannte Funkprotokolle (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.
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 Vorzeichen): Die Zahl gibt in Mikrosekunden die Zeitdauer an, das Vorzeichen bestimmt, ob es sich um eine gesendetes Signal gehandelt hat (positives Vorzeichen) oder ob das Signal gerade pausierte (negatives Vorzeichen). Insofern ist die Beschreibung "negatives Signal" irreführend - es gab in der Zeitspanne gerade kein Signal. Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde 395 Mikrosekunden (P1) ein Signal gesendet (weil P1=+395), danach gab es 8916 Mikrosekunden kein Signal (Pause, wegen P5=-8196). 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;
- MN : Nachrichten dieser Art wurden vom cc1101 vor bearbeitet. Die Nachrichten dieser Art enthalten unter D= den Empfangenen Datensatz hexadezimal codiert. Der Wert R= gibt die Empfangsstärke, auch hexadezimal an.
MN;D=3002925F3A1E7B6C000200002584;R=43;
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 Internet-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 folgende Bits-Bereiche enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Daten-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 (identisch) 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 der Tabelle Unterstützte Geräte 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
).
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 angegebenen 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.
Fehlersuche
(Zielgerät reagiert nicht, etc.)
- Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein
- Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort Signalduino Version 3.3.1, wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut
ITClock
eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt Geräte-Instanz-spezifische Konfiguration) dasITclock
eines IT-Client-Devices.
Fehlerbehandlung
Modul-Initialisierung
Perl-Modul Digest::CRC fehlt
Das FHEM-Log kann (bei Version ab 3.5.x) folgendes enthalten:
Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /opt/fhem . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.
In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul Digest::CRC
(Ubuntu und Debian: Package libdigest-crc-perl
) installiert werden und fhem neu gestartet werden.
Konfiguration von Firmware/Hardware (Reset usw.)
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:
set raw e
Ob ein solcher Reset nötig ist, erkennt man an dem Inhalt vom Reading cc1101_config
, dort unsinnige Werte angezeigt werden oder dem Reading config
welches durch den Befehl "get config" aktualisiert wird, was im Standard auf "MS=1;MU=1;MC=1" entspricht.
In der Firmware sind diverse Befehle eingebaut, welche über einen set raw
Befehl im Modul direkt ausgeführt werden können. Sofern möglich, sollte die Abfrage von Werten aus dem Modul allerdings mit den dafür vorgesehenen Kommandos erfolgen, da die Rückmeldungen des set raw
Befehls nur im Logfile ab verbose 4 erscheinen. Die Befehle sind nützlich, wenn direkt auf den Microcontroller zugegriffen wird:
C<reg>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example:set raw C35
führt ab verbose 4 zu einer Logausgabe folgender Art:Read, msg: C35 = 0D
e
EEPROM / factory reset. resets all eeprom values without rebootW<AA><XX>
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 des CC1101)
Die Sendeleistung lässt sich mit
get sduino ccpatable
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.