SIGNALduino - Versionsgeschichte

Sidey: Aktualisierung auf aktuellen Stand, Pflege von Hyperlinks

2023-04-02T09:24:31Z

Aktualisierung auf aktuellen Stand, Pflege von Hyperlinks

← Nächstältere Version		Version vom 2. April 2023, 11:24 Uhr
Zeile 40:		Zeile 40:

	==== Offizielles Modul (Sidey) ====		==== 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}}.		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.		An einem weiteren Thread ({{Link2Forum\|Topic=58396\|Linktext=Link}}) scheinen beide Autoren beteiligt zu sein.
Zeile 58:		Zeile 58:
	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.		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 ~~(für ordentlich breiten Support müsste man wohl eine CMake-Build-Config hinzufügen - ich sollte hier mal in~~ die ~~Pötte kommen~~.~~..) 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 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]] nativ läuft~~, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase~~.		Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] oder [https://de.wikipedia.org/wiki/ESP32 ESP32] nativ läuft.

	An den "~~SIGNALESP~~" kann ~~auch~~ ein CC1101 via SPI angebunden werden:		Auch an den "ESP8266" oder "ESP32" kann ein [[Selbstbau CUL\|CC1101]] Modul via SPI angebunden werden:

	{\| \|		{\| \|
	!CC1101 Bezeichnung		!CC1101 Bezeichnung
	!ESP Pin		!ESP 8266 Pin
			!ESP 32 PIN
	\|-		\|-
	\|CLK\|\|GPIO14		\|CLK\|\|GPIO14
			\|D18
	\|-		\|-
	\|MOSI\|\|GPIO13		\|MOSI\|\|GPIO13
			\|D23
	\|-		\|-
	\|MISO\|\|GPIO12		\|MISO\|\|GPIO12
			\|D19
	\|-		\|-
	\|CSN\|\|GPIO15		\|CSN\|\|GPIO15
			\|D5
	\|-		\|-
	\|GDO0\|\|GPIO4		\|GDO0\|\|GPIO4
			\|D4
	\|-		\|-
	\|GDO2\|\|GPIO5		\|GDO2\|\|GPIO5
			\|D13
	\|}		\|}

Zeile 85:		Zeile 92:
	{\| \|		{\| \|
	! Bezeichnung		! Bezeichnung
	! ESP Pin		! ESP 8266 Pin
	\|-		\|-
	\|Transmitter\|\|GPIO4		\|Transmitter\|\|GPIO4
Zeile 120:		Zeile 127:

	=== FHEM-Modul laden ===		=== 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.2 seit 18.01.~~2022~~ 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.

	Mit Version 3.5.x ist die Unterstützung für Geräte mit FSK-Modulation integriert.		Mit Version 3.5.x ist die Unterstützung für Geräte mit '''FSK'''-Modulation integriert.

	Die aktuell in Entwicklung befindliche Version ~~(3.5.3)~~ kann über folgende Vorgehensweise installiert werden:		Die aktuell in Entwicklung befindliche Version kann über folgende Vorgehensweise installiert werden:

	* FHEM aktualisieren: <code>update</code>		* FHEM aktualisieren: <code>update</code>
Zeile 243:		Zeile 250:
	\|Intertechno Funkschalter\|\|E S\|\| \|\|IT \|\| 3,4,5,17		\|Intertechno Funkschalter\|\|E S\|\| \|\|IT \|\| 3,4,5,17
	\|-		\|-
	\|~~<strike>~~Conrad RSL Funkschalter~~</strike>~~\|\|E S\|\| ~~Funktioniert aktuell nicht~~ \|\| SIGNALduino_RSL \|\|		\|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 372:		Zeile 379:
	*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 - 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:

Ph1959de: (Wiki-)Link korrigiert

2023-03-05T14:44:07Z

(Wiki-)Link korrigiert

← Nächstältere Version		Version vom 5. März 2023, 16:44 Uhr
Zeile 45:		Zeile 45:

	==== Inoffizielles Modul (Ralf9) ====		==== 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.		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 ==

Ph1959de: (erster) Versuch einer Übersicht über Hardware-/Firmware-/Modulversionen; Forenlinks auf Vorlage umgestellt

2023-03-05T14:39:20Z

(erster) Versuch einer Übersicht über Hardware-/Firmware-/Modulversionen; Forenlinks auf Vorlage umgestellt

← Nächstältere Version		Version vom 5. März 2023, 16:39 Uhr
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 ===
			{{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.		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.		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.		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.		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]).		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~~, ~~dabei bitte aber~~ auf ~~die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V~~.		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 ===		=== Entwicklungsversion ===
Zeile 29:		Zeile 40:

	==== Offizielles Modul (Sidey) ====		==== Offizielles Modul (Sidey) ====
	Die offizielle Version wird in mehreren Forenbeiträgen beschrieben: ~~[https://forum.fhem.de/index.php/topic,~~58397~~.0.html Erster Thread~~] (inzwischen geschlossen), {{Link2Forum\|Topic=58396\|LinkText=weiterer Thread}} sowie ~~[https://forum.fhem.de/index.php/topic,~~60170~~.0.html~~ noch ein Thread.]		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 (~~[https://forum.fhem.de/index.php/topic,~~58396~~.0.html~~ Link]) scheinen beide Autoren beteiligt zu sein.		An einem weiteren Thread ({{Link2Forum\|Topic=58396\|Linktext=Link}}) scheinen beide Autoren beteiligt zu sein.

	==== Inoffizielles Modul (Ralf9) ====		==== Inoffizielles Modul (Ralf9) ====
	Das Modul von Ralf9 wird ~~[https://forum.fhem.de/index.php/topic,~~111653~~.0.html~~ hier] beschrieben. Wer es installieren möchte, muss beim üblichen update-Prozess das Modul 00_SIGNALduino.pm vom 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.		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 ==

Andies: /* Das Logfile */ low high entspricht besser "Signal" und "Pause"

2022-11-28T19:41:10Z

Das Logfile: low high entspricht besser "Signal" und "Pause"

← Nächstältere Version		Version vom 28. November 2022, 21:41 Uhr
Zeile 354:		Zeile 354:

	*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 ~~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.		:<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.

AndreasMohr: Typos

2022-09-13T20:35:53Z

Typos

← Nächstältere Version		Version vom 13. September 2022, 22:35 Uhr
Zeile 113:		Zeile 113:
	Mit Version 3.5.x ist die Unterstützung für Geräte mit FSK-Modulation integriert.		Mit Version 3.5.x ist die Unterstützung für Geräte mit FSK-Modulation integriert.

	Die aktuell in Entwicklung ~~befindlichen~~ Version (3.5.3) kann über folgende Vorgehensweise installiert werden:		Die aktuell in Entwicklung befindliche Version (3.5.3) kann über folgende Vorgehensweise installiert werden:

	* FHEM aktualisieren: <code>update</code>		* FHEM aktualisieren: <code>update</code>
Zeile 446:		Zeile 446:
	==== Perl-Modul Digest::CRC fehlt ====		==== Perl-Modul Digest::CRC fehlt ====

	Das FHEM-Log kann (bei ab ~~Version~~ 3.5.x ) folgendes enthalten:		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.		<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.

Andies: /* Entwicklungsversion */ Unterscheidung offizielles Modul (Sidey) und inoffizielles Modul (Ralf9), da es deshalb viel Verwirrung im Forum gab.

2022-01-30T11:14:25Z

Entwicklungsversion: Unterscheidung offizielles Modul (Sidey) und inoffizielles Modul (Ralf9), da es deshalb viel Verwirrung im Forum gab.

← Nächstältere Version		Version vom 30. Januar 2022, 13:14 Uhr
Zeile 26:		Zeile 26:

	=== Entwicklungsversion ===		=== Entwicklungsversion ===
	Der SIGNALduino wird derzeit aktiv weiterentwickelt, ~~siehe dazu~~ https://~~github~~.~~com~~/~~RFD-FHEM~~. ~~Die offizielle Version wird~~ {{Link2Forum\|Topic=58396\|LinkText=~~hier~~}} ~~genauer~~ beschrieben. ~~Es existieren~~ im ~~Forum diverse angepasste Versionen~~, ~~auf die hier nicht näher eingegangen wird~~.		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: [https://forum.fhem.de/index.php/topic,58397.0.html Erster Thread] (inzwischen geschlossen), {{Link2Forum\|Topic=58396\|LinkText=weiterer Thread}} sowie [https://forum.fhem.de/index.php/topic,60170.0.html noch ein Thread.]

			An einem weiteren Thread ([https://forum.fhem.de/index.php/topic,58396.0.html Link]) scheinen beide Autoren beteiligt zu sein.

			==== Inoffizielles Modul (Ralf9) ====
			Das Modul von Ralf9 wird [https://forum.fhem.de/index.php/topic,111653.0.html hier] beschrieben. Wer es installieren möchte, muss beim üblichen update-Prozess das Modul 00_SIGNALduino.pm vom 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 ==

Beta-User: Perl-Modul Digest::CRC: Debian ergänzt

2022-01-19T05:28:56Z

Perl-Modul Digest::CRC: Debian ergänzt

← Nächstältere Version		Version vom 19. Januar 2022, 07:28 Uhr
Zeile 443:		Zeile 443:
	BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code>		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: Package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.		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.) ===		=== Konfiguration von Firmware/Hardware (Reset usw.) ===

Sidey: /* FHEM-Modul laden */ Hinweis zu SVN Version aktualisiert

2022-01-17T21:19:15Z

FHEM-Modul laden: Hinweis zu SVN Version aktualisiert

← Nächstältere Version		Version vom 17. Januar 2022, 23:19 Uhr
Zeile 101:		Zeile 101:

	=== FHEM-Modul laden ===		=== 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.4.2 seit 08.04.~~2020~~ 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.2 seit 18.01.2022 verteilt.

	~~Die in der Entwicklung befindliche~~ Version (3.5.x~~, bringt z.B.~~ Unterstützung für Geräte mit FSK-Modulation) kann ~~mit folgenden Befehlen geladen~~ werden:		Mit Version 3.5.x ist die Unterstützung für Geräte mit FSK-Modulation integriert.

			Die aktuell in Entwicklung befindlichen Version (3.5.3) kann über folgende Vorgehensweise installiert werden:

	* FHEM aktualisieren: <code>update</code>		* FHEM aktualisieren: <code>update</code>
	* 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.		* 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.		* 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.

Zeile 113:		Zeile 115:
	* Solltet Ihr einen SIGNALESP via IP einbinden wollen, ist die Syntax (ebenso wird auch vorgegangen wenn der SIGNALduino beispielsweise über ser2net freigeben wird):		* 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>		:<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 - via telnet ~~muss dann~~ dieselbe Baudrate ~~eingestellt werden~~.		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 434:		Zeile 438:
	==== Perl-Modul Digest::CRC fehlt ====		==== Perl-Modul Digest::CRC fehlt ====

	Das FHEM-Log kann (bei ~~neueren SIGNALduino-Modulen?~~) folgendes enthalten:		Das FHEM-Log kann (bei ab Version 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.		<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.

Ph1959de: Wiki-Links angepasst (z.B. Verlinkung üblicherweise nur bei erstem Vorkommen; Schreibweise korrigiert)

2021-08-26T08:21:04Z

Wiki-Links angepasst (z.B. Verlinkung üblicherweise nur bei erstem Vorkommen; Schreibweise korrigiert)

AndreasMohr: Cleanup

2021-08-25T23:54:00Z

Cleanup

← Nächstältere Version		Version vom 26. August 2021, 10:21 Uhr
Zeile 32:		Zeile 32:
	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 (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]]):		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]]		* 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.		* 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].		* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, Link zum [http://shop.in-circuit.de/index.php Hersteller].

Zeile 192:		Zeile 192:
	==== 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.
	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.		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.
	{\| class="wikitable"		{\| class="wikitable"
	! style="text-align:left;" \| Produkt		! style="text-align:left;" \| Produkt
Zeile 326:		Zeile 326:
	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:		Als Alternative zu DOIF hier ein regex-verwendendes [[notify]]-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:

	<code>		<code>
Zeile 335:		Zeile 335:

	=== Das Logfile ===		=== 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).		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.		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:		Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:
Zeile 390:		Zeile 390:
	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.		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 [[#~~Unterst.C3.BCtzte_Ger.C3.A4te~~\|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>).		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 446:		Zeile 446:
	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.		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 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:		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>		:<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>
	:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot		:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot
	:<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)		:<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)

← Nächstältere Version		Version vom 26. August 2021, 01:54 Uhr
Zeile 18:		Zeile 18:

	=== 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 updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung ~~der~~ Stick-Firmware korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).		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 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.		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.		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.
Zeile 266:		Zeile 266:
	\|[[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'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) 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.
Zeile 298:		Zeile 298:

	==== 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 >70 Protokolle implementiert. Jedoch gibt es nicht immer ein logisches ~~Module~~, ~~welche~~ diese Protokolle ~~verarbeiten~~.		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.
Zeile 326:		Zeile 326:
	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:		Als Alternative zu DOIF hier ein regex-verwendendes [[Notify]]-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:

	<code>		<code>
Zeile 332:		Zeile 332:
	</code>		</code>

	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.		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 ===		=== Das Logfile ===
Zeile 369:		Zeile 369:


	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 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...).		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.		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.
Zeile 426:		Zeile 426:
	* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein		* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein
	{{Randnotiz\|RNTyp=r\|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!}}		{{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 ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt ~~geräte~~-~~instanz~~-spezifische Konfiguration) das ITclock eines IT-Client-Devices.		* 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 ==
Zeile 439:		Zeile 439:
	BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 28, <$fh> line 1870.</code>		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 Digest::CRC (Ubuntu: ~~package~~ <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.		In diesem Fall ist der Transceiver nicht funktionsfähig - es muss erst Perl-Modul <code>Digest::CRC</code> (Ubuntu: Package <code>libdigest-crc-perl</code>) installiert werden und fhem neu gestartet werden.

	=== Konfiguration von Firmware/Hardware (Reset usw.) ===		=== Konfiguration von Firmware/Hardware (Reset usw.) ===
Zeile 448:		Zeile 448:
	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:		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>		:<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>
	:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot		:<code>e</code> EEPROM / factory reset. resets all eeprom values without reboot
	:<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)		:<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)