Arduino Ethernet Transceiver 433MHz MQTT - Versionsgeschichte

Chris T. Ludwig: Rechtschreibkorrektur (automatisiert)

2026-07-31T15:52:14Z

Rechtschreibkorrektur (automatisiert)

← Nächstältere Version		Version vom 31. Juli 2026, 17:52 Uhr
Zeile 35:		Zeile 35:
	==Vorbereitungen==		==Vorbereitungen==

	'''TODO: Wikiseite für jede Komponente''' für ~~diejeniegen~~, die sich für das 'Dahinter' interessieren.		'''TODO: Wikiseite für jede Komponente''' für diejenigen, die sich für das 'Dahinter' interessieren.

	===Arduino Nano===		===Arduino Nano===
Zeile 144:		Zeile 144:
	In diesem Fall ist es ein Hardwareinterrupt an PIN 2 an dem der Receiver angeschlossen ist. Der ATmega328 des Nano hat auch nur 2 'voll' interruptfähige PINS, nämlich 2 (PD2/INT0) und 3 (PD3/INT1). Die allgemeinen Dinge will ich hier nicht wiederkaeuen. Weitere Informationen findet man z. B. [https://www.arduino.cc/reference/de/language/functions/external-interrupts/attachinterrupt/ hier].		In diesem Fall ist es ein Hardwareinterrupt an PIN 2 an dem der Receiver angeschlossen ist. Der ATmega328 des Nano hat auch nur 2 'voll' interruptfähige PINS, nämlich 2 (PD2/INT0) und 3 (PD3/INT1). Die allgemeinen Dinge will ich hier nicht wiederkaeuen. Weitere Informationen findet man z. B. [https://www.arduino.cc/reference/de/language/functions/external-interrupts/attachinterrupt/ hier].
	Eine Verwirrung, die vielleicht der Aufloesung bedarf, ist der erste Parameter der attachInterrupt 'pin'. Bei einigen Sketches findet man einfach nur den Interrupt pin eingetragen bei anderen irgendwie die Interrupt-Nummer und bei wieder anderen eine zusätzliche Funktion digitalPinToInterrupt(receiverPin).		Eine Verwirrung, die vielleicht der Aufloesung bedarf, ist der erste Parameter der attachInterrupt 'pin'. Bei einigen Sketches findet man einfach nur den Interrupt pin eingetragen bei anderen irgendwie die Interrupt-Nummer und bei wieder anderen eine zusätzliche Funktion digitalPinToInterrupt(receiverPin).
	Dazu eine kleine Erläuterung: In einem Mikrocontroller befindet sich ein Tabelle, in diesem Fall des ATmega328 am Anfang des Flashspeichers (32768 Bytes) ganz am Anfang, also ab Adresse 0x0000. Um dies nachzuschauen reicht ein Blick in Daten die im Flashspeicher des AVR landen (i.d.R. durch avrdude) zu werfen. Avrdude erhält normalerweise ein hex-File, welches vom Compiler erstellt wurde zum ~~Übrtragen~~ in den AVR. Das (Intel-)hex-File ist zwar lesbar aber ohne Kenntnis des Aufbaus nicht ohne weiteres interpretierbar. Ich arbeite deshalb lieber mit einem bin-File, welches nebenbei bemerkt auch von avrdude übertragen werden kann. Um ein (Intel-)hex-File in eine bin-File zu wandeln genügt folgender Befehl im 'richtigen' Verzeichnis, oder mit vollständigen Pfadangaben.		Dazu eine kleine Erläuterung: In einem Mikrocontroller befindet sich ein Tabelle, in diesem Fall des ATmega328 am Anfang des Flashspeichers (32768 Bytes) ganz am Anfang, also ab Adresse 0x0000. Um dies nachzuschauen reicht ein Blick in Daten die im Flashspeicher des AVR landen (i.d.R. durch avrdude) zu werfen. Avrdude erhält normalerweise ein hex-File, welches vom Compiler erstellt wurde zum Übertragen in den AVR. Das (Intel-)hex-File ist zwar lesbar aber ohne Kenntnis des Aufbaus nicht ohne weiteres interpretierbar. Ich arbeite deshalb lieber mit einem bin-File, welches nebenbei bemerkt auch von avrdude übertragen werden kann. Um ein (Intel-)hex-File in eine bin-File zu wandeln genügt folgender Befehl im 'richtigen' Verzeichnis, oder mit vollständigen Pfadangaben.
	/PlatformIO/Projects/Receiver_433/.pio/build/nanoatmega328new # objcopy -I ihex firmware.hex -O binary firmware.bin		/PlatformIO/Projects/Receiver_433/.pio/build/nanoatmega328new # objcopy -I ihex firmware.hex -O binary firmware.bin
	Im erzeugten Bin-File kann man jetzt recht einfach sehen, welches Byte an welche Stelle im Flashspeicher geschrieben wird.		Im erzeugten Bin-File kann man jetzt recht einfach sehen, welches Byte an welche Stelle im Flashspeicher geschrieben wird.
Zeile 333:		Zeile 333:
	</div></div>		</div></div>

	Im Handbuch des ATmega kann man nachlesen, an welche Stelle der Controller (Programmzähler) springt sobald ein Interrupt ausgelöst wird. In meinem ~~Besipiel~~ an die Adresse 0x0002 (INT0 Pin 2) sofern die Fusebits, BOOTRST und IVSEL) auf default stehen.		Im Handbuch des ATmega kann man nachlesen, an welche Stelle der Controller (Programmzähler) springt sobald ein Interrupt ausgelöst wird. In meinem Beispiel an die Adresse 0x0002 (INT0 Pin 2) sofern die Fusebits, BOOTRST und IVSEL) auf default stehen.

	[[Datei:ATmega VectorsTable.png\|600px]]		[[Datei:ATmega VectorsTable.png\|600px]]
Zeile 345:		Zeile 345:
	Adresse 0x0000 Byte AB Adresse 0x0001 EF ergibt im BigEndian(Motorola-Word):ABEF im LittleEndian (INTEL-Word): EFAB		Adresse 0x0000 Byte AB Adresse 0x0001 EF ergibt im BigEndian(Motorola-Word):ABEF im LittleEndian (INTEL-Word): EFAB

	In meinem Beispiel ist es also '940c 0062' und '940c 0343'. Die ~~Sprungasdressen~~ ergeben sich somit zu		In meinem Beispiel ist es also '940c 0062' und '940c 0343'. Die Sprungadressen ergeben sich somit zu
	940c 0062: 0 0000 0 0000 0000 0110 0010 jmp 0x00c4 (2*0x62)		940c 0062: 0 0000 0 0000 0000 0110 0010 jmp 0x00c4 (2*0x62)
	940c 0343: 0 0000 0 0000 0011 0100 0011 jmp 0x0686 (2*0x343)		940c 0343: 0 0000 0 0000 0011 0100 0011 jmp 0x0686 (2*0x343)
Zeile 1.029:		Zeile 1.029:
	* loop		* loop

	~~Überwachnung~~ der Verbindung mit connected		Überwachung der Verbindung mit connected

	Also setServer und setCallback nur der Vorbereitung dienen lohn sich der erste Blick auf connect.		Also setServer und setCallback nur der Vorbereitung dienen lohn sich der erste Blick auf connect.
Zeile 1.129:		Zeile 1.129:
	16:08:45.253863 IP 192.168.2.51.1096 > 192.168.2.1.1883: Flags [.], ack 35, win 512, length 0		16:08:45.253863 IP 192.168.2.51.1096 > 192.168.2.1.1883: Flags [.], ack 35, win 512, length 0

	Dieser doch recht umfangreiche Mitschnitt mit wireshark dient nur ~~Dokummenationszwecken~~. Die Ausführungen der WIKI-Seite [[MQTT]] sind etwas eingängiger.		Dieser doch recht umfangreiche Mitschnitt mit wireshark dient nur Dokumentationszwecken. Die Ausführungen der WIKI-Seite [[MQTT]] sind etwas eingängiger.

Chris T. Ludwig: /* MQTT mit EthernetENC Library */

2021-12-26T07:48:29Z

MQTT mit EthernetENC Library

← Nächstältere Version		Version vom 26. Dezember 2021, 09:48 Uhr
Zeile 815:		Zeile 815:
	mosquitto_sub -v -h 192.168.2.1 -p 1883 -t '/#' // ACHTUNG siehe unten		mosquitto_sub -v -h 192.168.2.1 -p 1883 -t '/#' // ACHTUNG siehe unten

	Und in einem weiteren ~~die~~ die SYSTEM-Nachrichten im Debug-Modus.		Und in einem weiteren die SYSTEM-Nachrichten im Debug-Modus.
	mosquitto_sub -v -h 192.168.2.1 -p 1883 -d -t '$SYS'		mosquitto_sub -v -h 192.168.2.1 -p 1883 -d -t '$SYS'

Chris T. Ludwig: /* MQTT mit EthernetENC Library */

2021-12-26T07:47:33Z

MQTT mit EthernetENC Library

← Nächstältere Version		Version vom 26. Dezember 2021, 09:47 Uhr
Zeile 803:		Zeile 803:

	==MQTT mit EthernetENC Library==		==MQTT mit EthernetENC Library==
	An der Stelle, an der das Senden und Empfangen von Kommandos über Funk erfolgreich war, stellt sich die Frage nach dem Protokoll zum Schalten per USB, LAN, WLAN, etc. Das ~~einfachste wäre~~ wohl ein MiniProtokoll zu implementieren. So was ~~ähnliches~~ wie "ESC Gruppencode Schaltercode ON\|OFF". Ich habe mich erst mal dagegen entschieden und einer Integration von MQTT den Vorzug gegeben. Erst wenn die Integration im AVR scheitern sollte, werde ich einen PubSubClient als Proxy auf einem PC probieren, etwas direkt in FHEM einbauen oder mal Tasmota probieren. Weitere Ideen bitte in das Kommentarfeld.		An der Stelle, an der das Senden und Empfangen von Kommandos über Funk erfolgreich war, stellt sich die Frage nach dem Protokoll zum Schalten per USB, LAN, WLAN, etc. Das Einfachste waere wohl ein MiniProtokoll zu implementieren. So was aehnliches wie "ESC Gruppencode Schaltercode ON\|OFF". Ich habe mich erst mal dagegen entschieden und einer Integration von MQTT den Vorzug gegeben. Erst wenn die Integration im AVR scheitern sollte, werde ich einen PubSubClient als Proxy auf einem PC probieren, etwas direkt in FHEM einbauen oder mal Tasmota probieren. Weitere Ideen bitte in das Kommentarfeld.

	Die erste Testkonfiguration bestand aus der Abfolge: Publischer -> Broker -> LAN -> ENC28J60 -> ArduinoMQTTSubcriber mit 433 MHz -> Schaltsteckdose -> Leuchte.		Die erste Testkonfiguration bestand aus der Abfolge: Publischer -> Broker -> LAN -> ENC28J60 -> ArduinoMQTTSubcriber mit 433 MHz -> Schaltsteckdose -> Leuchte.

Chris T. Ludwig: /* Wie und was empfängt man? */

2021-12-26T07:41:10Z

Wie und was empfängt man?

← Nächstältere Version		Version vom 26. Dezember 2021, 09:41 Uhr
Zeile 573:		Zeile 573:
	Bei der UHF Nutzung wird ein 4,7 MOhm Widerstand empfohlen. Dann liegt die Frequenz je nach Eingangsspannung zwischen etwa 6 und 8 kHz.		Bei der UHF Nutzung wird ein 4,7 MOhm Widerstand empfohlen. Dann liegt die Frequenz je nach Eingangsspannung zwischen etwa 6 und 8 kHz.
	Was bei der Durchsicht des Datenblattes weiter auffällt ist die Tatsache, dass der PT2262 nicht nur '0' und '1' unterscheidet, sondern einen dritten Zustand 'float' an seinen Eingangspins erkennt und sendet.		Was bei der Durchsicht des Datenblattes weiter auffällt ist die Tatsache, dass der PT2262 nicht nur '0' und '1' unterscheidet, sondern einen dritten Zustand 'float' an seinen Eingangspins erkennt und sendet.
	Zum Erkennen eines Bits muss man 32 ~~Oszilatorzyklen~~ (OSCZ) 'beobachten'. Für das SYNC sind es eigentlich 128 OSCZ, da aber das SYNC-Bit wie ein 0-Bit oder F-Bit anfängt aber nach weiteren 12 OSCZ kein Wechsel nach 1 erfolgt kann man an dieser Stelle schon von einem Sync-Bit ausgehen.		Zum Erkennen eines Bits muss man 32 Oszillatorzyklen (OSCZ) 'beobachten'. Für das SYNC sind es eigentlich 128 OSCZ, da aber das SYNC-Bit wie ein 0-Bit oder F-Bit anfängt aber nach weiteren 12 OSCZ kein Wechsel nach 1 erfolgt kann man an dieser Stelle schon von einem Sync-Bit ausgehen.

	* Eine 0 wird übertragen wenn der Adress-/Dateneingang auf VSS (Ground) liegt.		* Eine 0 wird übertragen wenn der Adress-/Dateneingang auf VSS (Ground) liegt.

Chris T. Ludwig: /* Wie und was empfängt man? */

2021-12-26T07:38:04Z

Wie und was empfängt man?

← Nächstältere Version		Version vom 26. Dezember 2021, 09:38 Uhr
Zeile 535:		Zeile 535:
	\|}		\|}

	Zum Vergleich auch mal noch eine (4 Kanal Fernbedienung mit einem PT2262. Hier gibt das ~~Datenblat~~ genau Auskunft über das Protokoll und ~~lässt~~ somit eine Kontrolle des Receivertestprogramms zu.		Zum Vergleich auch mal noch eine (4 Kanal Fernbedienung mit einem PT2262. Hier gibt das Datenblatt genau Auskunft über das Protokoll und laesst somit eine Kontrolle des Receivertestprogramms zu.

	{\| class="wikitable"		{\| class="wikitable"

Chris T. Ludwig: /* RC-Switch */

2021-12-26T07:36:54Z

RC-Switch

← Nächstältere Version		Version vom 26. Dezember 2021, 09:36 Uhr
Zeile 426:		Zeile 426:
	Als Library zum Testen benutzte ich diese [https://github.com/sui77/rc-switch/ https://github.com/sui77/rc-switch/].		Als Library zum Testen benutzte ich diese [https://github.com/sui77/rc-switch/ https://github.com/sui77/rc-switch/].

	Und als ~~erstes~~ das ReceiveDemo_Simple.		Und als Erstes das ReceiveDemo_Simple.

	===Wie und was empfängt man?===		===Wie und was empfängt man?===

Chris T. Ludwig: /* Testprogramm Sender */

2021-12-26T07:35:45Z

Testprogramm Sender

← Nächstältere Version		Version vom 26. Dezember 2021, 09:35 Uhr
Zeile 395:		Zeile 395:
	==Testprogramm Sender==		==Testprogramm Sender==

	Mit dem Sendertestprogramm habe ich mir weniger ~~Mühe~~ gegeben. Dort wird nur im ~~Sekundetakt~~. Ein Pulspaket (1000 Pulse) ausgegeben. Mit einem Oszilloskop ~~könnte~~ man hier gerade noch die maximale Bitrate (des C-Programms!) bestimmen.		Mit dem Sendertestprogramm habe ich mir weniger Muehe gegeben. Dort wird nur im Sekundentakt. Ein Pulspaket (1000 Pulse) ausgegeben. Mit einem Oszilloskop koennte man hier gerade noch die maximale Bitrate (des C-Programms!) bestimmen.

	<div class="toccolours mw-collapsible mw-collapsed" style="width:800px; overflow:auto;">		<div class="toccolours mw-collapsible mw-collapsed" style="width:800px; overflow:auto;">

Chris T. Ludwig: /* Testprogramm Empfänger */

2021-12-26T07:34:39Z

Testprogramm Empfänger

← Nächstältere Version		Version vom 26. Dezember 2021, 09:34 Uhr
Zeile 391:		Zeile 391:
	Interessant ist, dass der INT1 auch belegt ist, obwohl ich den im Programm gar nicht explizit benutzte. Um herauszufinden was da abgearbeitet wird, ist es mir zu mühsam jeden Mnemonic einzeln durchzugehen. Da hilft an dieser Stelle ein Simulator. Wen es interessiert sollte irgendwann später hier (TODO AVR Simulation) einen Blick reinwerfen.		Interessant ist, dass der INT1 auch belegt ist, obwohl ich den im Programm gar nicht explizit benutzte. Um herauszufinden was da abgearbeitet wird, ist es mir zu mühsam jeden Mnemonic einzeln durchzugehen. Da hilft an dieser Stelle ein Simulator. Wen es interessiert sollte irgendwann später hier (TODO AVR Simulation) einen Blick reinwerfen.

	Jetzt im Nachhinein betrachtet ist das Receiver-Test-Sketch ziemlich ungeschickt gewählt, da man außer einer nicht weiter deutbaren Zahlenreihenfolge keine weitere Ausgabe erhält. Dass das Programm funktioniert kann man testen indem man den Pin2 mal abklemmt und nur Nullen erhält;-)))		Jetzt im Nachhinein betrachtet ist das Receiver-Test-Sketch ziemlich ungeschickt gewählt, da man außer einer nicht weiter deutbaren Zahlenreihenfolge keine weitere Ausgabe erhält. Dass das Programm funktioniert kann man testen, indem man den Pin2 mal abklemmt und nur Nullen erhält;-)))

	==Testprogramm Sender==		==Testprogramm Sender==

Chris T. Ludwig: /* Testprogramm Empfänger */

2021-12-26T07:34:05Z

Testprogramm Empfänger

← Nächstältere Version		Version vom 26. Dezember 2021, 09:34 Uhr
Zeile 391:		Zeile 391:
	Interessant ist, dass der INT1 auch belegt ist, obwohl ich den im Programm gar nicht explizit benutzte. Um herauszufinden was da abgearbeitet wird, ist es mir zu mühsam jeden Mnemonic einzeln durchzugehen. Da hilft an dieser Stelle ein Simulator. Wen es interessiert sollte irgendwann später hier (TODO AVR Simulation) einen Blick reinwerfen.		Interessant ist, dass der INT1 auch belegt ist, obwohl ich den im Programm gar nicht explizit benutzte. Um herauszufinden was da abgearbeitet wird, ist es mir zu mühsam jeden Mnemonic einzeln durchzugehen. Da hilft an dieser Stelle ein Simulator. Wen es interessiert sollte irgendwann später hier (TODO AVR Simulation) einen Blick reinwerfen.

	Jetzt im Nachhinein betrachtet ist das Receiver-Test-Sketch ziemlich ungeschickt gewählt, da man außer einer nicht weiter deutbaren Zahlenreihenfolge keine weitere Ausgabe erhält. ~~Das~~ das Programm funktioniert kann man testen indem man den Pin2 mal abklemmt und nur Nullen erhält;-)		Jetzt im Nachhinein betrachtet ist das Receiver-Test-Sketch ziemlich ungeschickt gewählt, da man außer einer nicht weiter deutbaren Zahlenreihenfolge keine weitere Ausgabe erhält. Dass das Programm funktioniert kann man testen indem man den Pin2 mal abklemmt und nur Nullen erhält;-)))

	==Testprogramm Sender==		==Testprogramm Sender==

Chris T. Ludwig: /* Testprogramm Empfänger */

2021-12-26T07:31:42Z

Testprogramm Empfänger

← Nächstältere Version		Version vom 26. Dezember 2021, 09:31 Uhr
Zeile 342:		Zeile 342:

	Wenn man die (default-)Eintraege aus dem Handbuch mit dem o.g. Beispiel vergleicht und jetzt noch im AVR Instruction Set Manual nachschlägt, dass der Opcode für JMP 1001 010k kkkk 110k kkkk kkkk kkkk kkkk (94\|95 XC\|XD XX XX) lautet, kann man erkennen, dass in meinem Beispiel die ersten beiden 'Jumps' (0c 94 62 00 0c 94 43 03) Reset und INT0 sind.		Wenn man die (default-)Eintraege aus dem Handbuch mit dem o.g. Beispiel vergleicht und jetzt noch im AVR Instruction Set Manual nachschlägt, dass der Opcode für JMP 1001 010k kkkk 110k kkkk kkkk kkkk kkkk (94\|95 XC\|XD XX XX) lautet, kann man erkennen, dass in meinem Beispiel die ersten beiden 'Jumps' (0c 94 62 00 0c 94 43 03) Reset und INT0 sind.
	Nebenbemerkung: Man beachte die umgekehrte Schreibweise der Bytes. Bei Wordzugriffen (16 Bit) ist die Reihenfolge der Bytes im Speicher oder wie hier in einem hexdump zu beachten. Es muss also festgelegt sein, ob das erste Byte in Richtung aufsteigender Adressen das höhere (Big Endian ~~Motorla~~-Fromat) oder das niedrigere Byte (Little Endian Intel-Format) des Wortes ist. Beispiel:		Nebenbemerkung: Man beachte die umgekehrte Schreibweise der Bytes. Bei Wordzugriffen (16 Bit) ist die Reihenfolge der Bytes im Speicher oder wie hier in einem hexdump zu beachten. Es muss also festgelegt sein, ob das erste Byte in Richtung aufsteigender Adressen das höhere (Big Endian Motorola-Fromat) oder das niedrigere Byte (Little Endian Intel-Format) des Wortes ist. Beispiel:
	Adresse 0x0000 Byte AB Adresse 0x0001 EF ergibt im BigEndian(Motorola-Word):ABEF im LittleEndian (INTEL-Word): EFAB		Adresse 0x0000 Byte AB Adresse 0x0001 EF ergibt im BigEndian(Motorola-Word):ABEF im LittleEndian (INTEL-Word): EFAB