Mikrocontroller.net - Benutzerbeiträge [de]

JDY-24M BLE Bluetooth Mesh I/O

2022-01-29T20:55:26Z

Prediger: Erweitert

== Einleitung ==
Dieses Modul bietet mit mehreren der gleichen Bauform die Möglichkeit über BLE Bluetooth ein Mesh zu etablieren. Dies kann zum Beispiel für die Steuerung von Beleuchtung eingesetzt werden. Die Sicherheit bei dem System ist jedoch ähnlich derer von konventionellen Funkschaltern, da zur Identifikation nur ein 16 Bit Wert zur Verfügung steht. Also die Haustür würde ich nicht durch solch ein Modul direkt öffnen lassen. Es bietet aber die Möglichkeit via serieller Schnittstelle noch einen Microcontroller an zu schalten, der dann Sicherheitskritische Dinge steuern könnte.

== Eigenschaften ==
* Versorgungsspannung 1,9 - 3,6V
* Stromaufnahme je nach Betriebsart 3μA bis 4mA
* 5 Eingänge pulled up für Taster (15kΩ gegen Masse bei Ub = 3,3V reichen zum Auslösen)
* 5 Ausgänge (High 10mA, Low 14mA jeweils bei 0,3V Drop und Ub = 3,3V)
* Serielle Schnittstelle mit RS232 Logik.
* Als Hostmodul verwendbar
* 65280 Adressen in einem Netzwerk adressierbar

== Hardware ==

=== Modulbelegung ===
[[Datei:Belegung JDY-24M.png|mini|alternativtext=Belegung JDY-24M|Darstellung gemäß Datenblatt in der Anlage]]
Bei der mir vorliegenden Version 1.71 ist INPUT1[10] und INPUT2[8] vertauscht. Ich kann aber nicht sagen ob das bei anderen Versionen auch der Fall ist.
Die Anschlüsse sind bis auf STAT, ALED und PWRC selbsterklärend. Diese 3 Anschlüsse sind auch in der Betriebsart MESH kaum von Relevanz.
* STAT zeigt mit einem HIGH an, dass das Modul in irgendeiner Form connected ist.
* ALED ist nur im den anderen Betriebsarten relevant. Pulst HIGH wenn er auf Verbindung wartet, ist Dauer-HIGH wenn verbunden.
* PWRC weckt das Modul aus dem Schlafmodus und kann die Module in den Lernmodus versetzen.

=== Serielle Schnittstelle ===
Von der Logik her ist es eine RS232 Schnittstelle, die in Grundeinstellung auf 9600 Baud eingestellt ist. Mit 8 Bit Datenlänge, keine Parität und ein Stopbit. Es gibt somit viele USB zu Seriell Module und Chips die zum Verbinden des JDY-24M mit einem PC oder Server geeignet sind. Es ist lediglich sicherzustellen, dass die Signalpegel innerhalb der Versorgungsspannung des JDY-24M liegen.

=== Bluetooth Schnittstelle ===
Das Modul kann auch sehr weitreichend über BLE Bluetooth konfiguriert und gesteuert werden. Leider ist mir aber keine Software für Smartphons bekannt mit der das komfortabel und vollumfänglich möglich ist. Da dies aber möglich ist muss man unbedingt den Passwortschutz für diese Schnittstelle aktivieren. Mit der APP "nRF Connect for Mobile" lässt sich z.B. ein Smartphons mit den Modulen verbinden und die ein oder andere Funktion auch auslösen.

== Firmware ==
Das Modul lag mir in der Version 1.71 vor. In der Dokumentation nicht beschriebene Verhalten stammen aus dieser Version.

=== AT Befehle ===
Der AT Befehlssatz ist sehr logisch aufgebaut und es gibt nur wenige Ausnahmen die gegen eine einheitliche Linie gehen.
Alle Befehle beginnen mit der Zeichenfolge AT+
* Ausnahme der AT Befehl selbst der zum Testen der Schnittstelle verwendet werden kann.
Dem + folgt immer der eigentliche Befehl. In den weiteren Beschreibungen wird auch nur noch der Befehl genannt.
Dem Befehl können ohne Trennzeichen angehängt, ein oder mehrere Parameter folgen, die Parameter werden durch Kommas getrennt.
* Ausnahme der Befehl MESH, hier werden Binärdaten als Parameter übertragen.
Je nach Befehl und Anzahl der Parameter erkennt dass Modul ob es sich um eine Parameterabfrage oder ein Setzen von dessen Parametern handelt. 
Jeder AT Befehl muss mit \r\n (x0D,x0A) beendet werden. 
Einige Befehle geben keine Antwort zurück. 
Einige Antworten mit einem OK\r\n bei manchen kann das \n fehlen. Das +OK\r\n wie im Datenblatt angegeben kam mir in der Version 1.71 nicht unter. 
Bei einer Abfrage von Parametern folgt als Antwort das + mit dem Befehl, darauf ein = und dann die Parameterliste wie beim setzen.
Beispiele kommen im folgendem Abschnitt. 
Weitere Besonderheiten weden bei den Befehlen beschrieben.

=== Allgemeine AT Befehle ===
Die Abfolge entspricht etwa der, in der man die Einstellungen vornehmen sollte.
==== BAUD ====
Liest und setzt die Übertragungsgeschwindigkeit der seriellen Schnittstelle.
* AT+BAUD\r\n sendet +BAUD=4\r\n (Die 4 ist der Index für 9600 BAUD).
* AT+BAUD5\r\n sendet OK\r\n stellt die Schnittstelle auf 19200 BAUD ein (Der Wert mit dem ich arbeite).
==== RESET ====
Wird bei einigen Einstellungen wie z.B. bei BAUD benötigt, damit sie wirksam werden.
* AT+RESET\r\n sendet OK\r\n nach einem Moment folgt noch eine RESTART Meldung +JDY-24-START\r\n.
==== NAME ====
Mit NAME kann der Modulname verwaltete werden.
* AT+NAME\r\n sendet z.B. +NAME=JDY-24M\r\n
* AT+NAMEJDY-24M Flur\r\n sendet +NAME=JDY-24M Flur\r\nOK\r\n setzt den Name auf JDY-24M Flur. Hier die Besonderheit, dass der zu setzende Wert sofort ausgegeben wird.

=== Allgemeine AT Befehle verkürzte Dokumentation ===
Es entfällt in der Beschreibung nun das immer voran gestellte AT+ und das folgende \r\n bei den Antworten entfällt das voran gestellte +. Diese Zeichen sind zu ergänze bzw. werden vom Modul trotzdem gesendet.
==== VERSION ====
Mit VERSION liest man die Softwareversion des Moduls.
* VERSION liest z.B. VERSION=JDY-24M-V1.71
==== LADDR ====
Gibt es nur lesend und ermittelt die 12 Digit lange MAC-Adresse des Moduls.
* LADDR liest z.B. LADDR=11892007AC3E
==== ROLE ====
Mit ROLE wird die Betriebsart des Moduls gewählt.
* ROLE liest z.B. ROLE=5 (steht für die MESH Betriebsart).
* ROLE8 setzt die Näherungsdetektions Betriebsart.
==== PIN ====
Mit PIN wird eine 4 Digit Dec Wert als Pin gesetzt oder gelesen. Bei Version 1.71 ist sie 6 Digit lang. 
Die PIN wird bei einer Bluetooth Smartphoneverbindung verwendet, aber auch in der Master-Slave Betriebsart
* PIN liest z.B. PIN=123456
* PIN654321 setzt die PIN auf 654321
==== TYPE ====
Mit TYPE wird die PIN aktiviert bei 0 ist sie nicht aktiv
* TYPE liest z.B. TYPE=1 (PIN ist Aktive und wird nicht auf dem Smartphone gespeichert).
* TYPE2 setzt den Wert 2 es wird nach der PIN-Eingabe ein Automatischer reconnect ermöglicht.
==== CUIO ====
Mit CUIO kann man den logischen Zustand der Ausgänge des lokalen Moduls lesen und setzen.
* CUIO liest CUIO=0,1,0,0,1, (bedeutet OUTPUT 1-LOW 2-HIGH 3-LOW 4-LOW 5-HIGH).
* CUIO3,0 setzt den OUTPUT3 auf LOW
* CUIO2,1 setzt den OUTPUT2 auf HIGH
==== DEFAULT ====
Mit DEFAULT wird das Modul mit einem folgenden RESET wieder in die Werkseinstellungen zurück gesetzt.
* DEFAULT liest OK

== Betriebsarten ==
Das Modul kann ab der Softwareversion 1.6 in 8 verschiedenen Betriebsarten verwendet werden.

=== MESH network ===
Diese Betriebsart ist bei den Modulen vor eingestellt. Sie kann mit ROLE abgefragt oder gesetzt werden. Der Wert dafür ist 5.
Für den MESH betrieb müssen NETID und MADDR wie gewünscht eingestellt werden. Bitte nicht vergessen spätestens im Wirkbetrieb auch PIN zu setzen und mit TYPE zu aktivieren, damit nicht mit einem beliebigen Smartphone in das Netz eingedrungen werden kann. 
Es folgen weiter AT Befehle die für den MESH Betrieb benötigt werden. Nach dem Setzen der Werte sollte ein RESET gesendet werden. Ich kann im Moment noch nicht genau sagen welche Befehle den RESET brauchen und welche nicht.
==== NETID ====
Die NETID muss bei alle Module einer MESH den gleichen Wert haben, sie wird als 4 Digit Hex erwartet.
* NETID liest z.B. NETID=A3CF
* NETIDB74D setzt sie auf B74D
==== MADDR ====
Die 4 Digit lange Moduladresse darf innerhalb eines MESH nur einmal vorkommen. Sie kann damit gelesen und gesetzt werden.
* MADDR liest z.B. MADDR=AC3E
* MADDR3EF2 setzt sie auf 3EF2
==== MCLSS ====
Mit MCLSS legt man fest ob das Modul als Router im Netz agieren soll. Alle Module an denen ein Ausgang vom Server, oder einem anderen Modul gesteuert werden soll müssen in diesem Modus sein. Der Stromverbrauch liegt dann bei ca. 4mA.
* MCLSS liest z.B. MCLSS=0 (Das Modul ist im Router Betrieb).
* MCLSS1 setzt den Terminal Betrieb. Das Modul ist im Energiesparmodus. Die Eingänge können Daten auf den BLEBus senden und die lokalen Ausgänge setzen. Der BLEBus kann aber das Modul von sich aus nicht ansprechen.
==== KEY ====
Mit KEY stellt man ein, welcher Eingang des Moduls zu welchen Ausgang zugeordnet wird. Der gewählte Ausgang bezieht sich sowohl auf den lokalen Ausgang (abhängig von SUBTYPE) als auch auf einen eventuellen Ausgang eines anderen Moduls des MESH. Des weiteren gibt man eine Zielmoduladresse an. Je nach Einstellung des LEARN Modi wird diese anders berücksichtigt. Davon ebenfalls abhängig ist die Möglichkeit zu bestimmen, dass eine Aktion am Eingang auch auf der Seriellen Schnittstelle des adressierten Moduls ausgegeben wird.
*KEY1 liest z.B. KEY=1,BA1E,2,1 (Eine Signal am Eingang 1 sendet mit der Zielmoduladresse BA1E für den Ausgang 2 einen Zustand, der ggf. auch auf dem Seriellen Port ausgegeben wird.
*KEY2,BA32,4,0 setzt für den Eingang 2 eine Zuordnung zum Ausgang 4, und ggf. das Zielmodul BA32 ohne serielle Ausgabe.
==== SUBTYPE ====
Mit SUBTYPE koppelt man die lokalen Eingänge mit den lokalen Ausgängen entsprechend der Zuordnung die mit KEY gesetzt wurde.
*SUBTYPE liest z.B. SUBTYPE=0 (Signale an den Eingängen beeinflussen nicht die lokalen Ausgänge).
*SUBTYPE1 koppelt unter der Vorgabe aus KEY die Eingänge mit den Ausgängen.
==== LEARN ====
Mit LEARN stellt man im Prinzipe von Sender gesteuerten Ausgängen auf Empfänger gesteuerte Ausgänge um. Beim Sender wirkt sich das lediglich so aus, dass die Kommandosequenze, die in das MESH gesendet wird, sich ändert. Im ausgeschalteten Modus ist sie AAB2E7 und im eingeschalteten Modus AAB2D7. Dazu später mehr.
*LEARN leist z.B. 0 (Beim Emfänger: Er schaut ob ein Kommando AAB2E7 auf den Bus ist, prüft dann ob dies seine Adresse hat und stellt den Ausgang entsprechend ein. Sender gesteuert)
*LEARN1 setzt dem Empfänger gesteuerten Modus. Die Zielmoduladresse wird hier ignoriert, es wird nur geschaut, ob das Kommando AAB2D7 vom entsprechenden Modul kommt, wenn ja, wird der zugeordnete Ausgang entsprechend gesetzt. Diese Zuordnungen erfolgen mit LEAVAL.
==== LEAVAL ====
Mit LEAVAL setzt man die Zuordnung der Kommandos AAB2D7 im Empfängermodul. Die mit LEAVAL angelegte Tabelle ist nur wirksam, wenn LEARN auf 1 gesetzt ist. LEAVAL kann entgegen dem Datenblatt nicht gelesen werden!
*LEAVAL2,4,BA07 bewirkt im Empfänger, dass ein Ereignis mit dem Kommando AAB2D7 am Eingang 4 vom Sendermodul BA07, an den Ausgang 2 des Empfängermodul einstellt. Ausgänge können leider nicht mehrfach zugeordnet werden.
=== MESH Datenaustausch ===
In der MESH Betriebsart geben die Module Daten auf den MESH Bus. Dies kann geschehen durch den Wechsel eines Eingangs von High nach Low, durch senden eines MESH Befehls und durch die Antwortreaktion auf einen MESH Befehl. Zu erst betrachten wir uns das Format einer Modul Antwort.
==== Antwort von einem Modul im MESH ====
Die Antworten eines Moduls sind reine Binärdaten, sie kommen je nach Einstellung der Module auf den Seriellen Schnittstellen an.
Da die Binärdaten immer Byteorientiert sind, werden sie hier Hexadezimal beschrieben. 
Grundsätzlich immer vorhanden ist: 
[erster Befehlscode, 2 Bytes][Anzahl der noch folgenden Bytes, 1 Byte ][MADDR des Senders, 2 Bytes]
==== Antwort auf Abfrage ====
Antworten auf Abfrage besitzen kein Zieladressfeld. Die Folgenden Antworten mit dem folgenden ersten Befehlscode können auftreten
*F0 00 - Sendet den Status der Ausgänge
** F000 07 0008 01 00 01 00 00 - Am Modul MADDR 0008 ist der Ausgang 1 und 3 High
*F0 01 - Sendet den Status der Eingänge
** F001 07 0005 01 01 01 01 01 - Am Modul MADDR 0005 sind alle Eingänge offen (01 wegen internem Pull up)
*F0 02 - Sendet die MADDR (Ein wenig Sinnfrei ?!?)
** F002 04 0008 00 08 - Am Modul MADDR 0008 ist die MADDR 0008, welch Überraschung ;-)
*F0 03 - Sendet die NETID
** F003 04 0005 AB BA - Am Modul MADDR 0005 ist die NETID ABBA, auch nur wenig überraschend
*F0 04 - Sendet die PIN
** F004 06 0008 7B 04 05 06 - Am Modul MADDR 0008 ist die PIN codiert 7B040506. Die Codierung ist mir noch nicht klar
*F0 05 - Sendet den TYPE zur PIN
** F005 03 0008 00 - Am Modul MADDR 0008 ist der TYPE gleich null siehe AT Befehl TYPE
*F0 06 - Soll den Tasten Status senden (Bedeutung noch unklar)
** F006 07 0005 00 00 00 00 00 - Satus am Modul MADDR 0005 (bedarf noch Tests wann nicht 5 x 00)
*F0 07 - Sendet die MCLSS Einstellung
** F007 03 0008 00 - Am Modul MADDR 0008 ist MCLSS mit null gesetzt siehe AT Befehl MCLSS
*F0 08 - Sendet den eingestellten FRIEND (Mir noch unklar siehe Datenblatt)
** F008 08 0005 00 00 00 00 00 00 - Am Modul MADDR 0005 ist kein FRIEND gesetzt
*F0 09 - Sendet den FRTYPE
** F009 03 0005 00 - Am Modul MADDR 0005 ist der FRTYPE null siehe Datenblatt FRTYPE
==== Sonstige Antworten ====
Bei allen anderen Antworten wird die Antwort immer noch um die MADDR des Zielmoduls erweitert hier ist auch ein FFFF als Broadcast möglich. Bei den Antworten auf Grund einer Eingangsauslösung ist zu beachten, dass hier nicht die Nummer des Eingangs übergeben wird, sondern die Nummer die dem Eingang als zugehöriger Ausgang in KEY zugewiesen wurde. Dies hat auch in LEARN 1 seine Wirkung. Es ist also sehr gut zu überlegen, ob man hier von der vor eingestellten 1:1 Zuordnung abweichen möchte.
* F1 DD - Daten aus einer Übertragung von einer Seriellen Schnittstelle
** F1DD 08 0001 0008 41 42 43 44 - Modul MADDR 0001 sendet Daten 41424344 an Modul MADDR 0008, die Daten können an jeder Seriellen Schnittstelle sichtbar sein.
* F2 E7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 0 gesetzt ist.
** F2E7 09 0005 FFFF AAB2E7 02 01 - F2E7 und AAB2E7 kennzeichnen den Antworttyp. Gesendet wird vom Modul MADDR 0005 für alle Module (FFFF). Unabhängig von LEARN würden alle Module ihren Ausgang 02 auf 01 setzen. Abhängig von der Einstellung in KEY erscheint die Sequenz auch auf der Seriellen Schnittstelle der Module. Ebenso bestimmt auch KEY die Zielmoduladresse und den Ausgang.
* F2 D7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 1 gesetzt ist.
** F2D7 09 0005 FFFF AAB2D7 02 01 - F2D7 und AAB2D7 kennzeichnen den Antworttyp. Gesendet wird an alle Module des MESH, die Ziel MADDR ist hier ohne Bedeutung, ihr Wert wird aber weiter von KEY abgeleitet, eben so die "Ausgangzuordnung" die aber hier trotzdem als Eingang interpretiert wird. Hier kann es schnell Caos geben, wenn man von der 1:1 Zuordnung abweicht. Die Sequenz kommt immer an allen anderen Seriellen Schnittstellen an. Mit LEAVAL wird hier eingestellt ob ein Ausgang auf diese Antwort reagiert.
==== Befehle mit MESH senden ====
Mit dem AT Befehl MESH lassen sich Kommandos in das Mesh senden. Die Kommandos sind identisch mit den Kommandos die auch über Bluetooth in das Mesh über die Service UUID FFE3 gesendet werden können. Dazu muss die Bytefolge lediglich zwischen AT+MESH und \r\n auf der Seriellen Schnittstelle eingeschlossen werden. Da ja Binärdaten übertragen werden müssen wandelt man einfach AT+MESH in 41 54 2B 4D 45 53 48 um und \r\n in 0D 0A. So kann alles Hexadezimal übergeben werden. 
===== Beispiel: Das Hauptkommando 31 =====
Beispiel: 41542B4D455348 31 0008 F0B100 0D0A würde vom Modul MADDR 0008 den Status der Ausgänge anfordern. 
Hier sind wir auch schon bei einem Problem angekommen. Der Teil 31 0008 beschreib mit 31 eins der möglichen Hauptkommando und 0008 die MADDR des anzufragenden Moduls. Bei meinem Netzwerk wird die vorgegebene MADDR mehr oder weniger ignoriert und es fühlen sich alle Module angesprochen. Das ist bei reinen Abfragen noch händelbar, da die Antworten, siehe oben, alle ihre MADDR mit senden und sie so auch wieder zugeordnet werden können. Bei den Kommandos die aber Ausgänge schalten sollen ist das aber sehr doof. 
Bleiben wir bei dem Kommando, das Unterkommando ist hier F0B100 die zugehörige Antwort ist die zuvor beschriebene F000. Die Anfragen zu den gewünschten Antworten können schematisch gebildet werden. FnB10n fordert F00n an. Das heißt F7B107 fordert F007 an, also die Einstellung vom MCLSS. Noch mal in voller Länge: 41542B4D455348 31 0008 F7B107 0D0A. Damit ist schon alles zum Hauptkommando 31 gesagt.
===== Weiter Hauptkommandos =====
Bei denen von mir schon nachvollzogenen Hauptkommandos folgt immer die MADDR des Zielmoduls, die aber wie schon erwähnt nicht korrekt verarbeitet wird. 
Es gibt neben dem schon beschriebenen Hauptkommando 31 noch die folgenden Hauptkommandos:
* 00 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält OK\r\n als Antwort.
* 01 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 10 - Führt I/O Anweisungen aus, das sendende Modul erhält OK\r\n als Antwort.
* 11 - Führt I/O Anweisungen aus, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 41 - Soll AT Befehle auf entfernten Modulen setzen können (ist noch zu untersuchen).
* A1 - Soll transparent Daten an alle FRIENDS senden können (ist noch zu untersuchen).
* A2 - Soll transparent Daten an einen privaten FRIEND senden können (ist noch zu untersuchen).
===== Serielle Daten senden (00 und 01) =====
Beispiel: 41542B4D455348 00 0008 41424344 0D0A sendet für Modul MADDR 0008 'ABCD' auf die Serielle Schnittstelle
===== I/O Anweisungen (10 und 11) =====
Die I/O Anweisung wird nach dem gleichen Schema gebildet. Nach der Ziel MADDR folgt ein Unterkommando.
* AA B1 E7 [Ausgang] [Pegel] - das Kommando setzt den Ausgang (01, 02 ,...) auf den Pegel High (01) oder Low (00)
* AA B2 E7 [Ausgang] [Pegel] - sehe kein Unterschied zu AA B1 E7
* AB B1 E7 FF [Bits] - das Kommando setzt die Ausgänge Bit zugeordnet. Bit 0 -> Ausgang 1, Bit 4 -> Ausgang 5
* AB B2 E7 FF [Bits] - sehe kein Unterschied zu AB B1 E7 FF
* A1 B1 E7 [Ausgang] [beliebig] - das Kommando toggelt den Ausgang (01, 02 ,...)
* A1 B2 E7 [Ausgang] [beliebig] - sehe kein Unterschied zu A1 B1 E7
* A2 B1 E7 FF [beliebig] - (ist noch zu untersuchen)
* A2 B2 E7 FF [beliebig] - (ist noch zu untersuchen)
Beispiel: 41542B4D455348 10 0005 AAB1E7 02 01 sollte nur am Modul MADDR 0005 den Ausgang 2 auf high schalten.
==== Blockbild der Eingänge ====
[[Datei:Blockdarstellung Eingang JDY-24M .png.png|mini|alternativtext=Blockdarstellung eines Tastereingangs|Blockdarstellung eines Tastereingangs]]
==== Blockbild der Ausgänge ====
[[Datei:Blockdarstellung Ausgang JDY-24M.png|mini|alternativtext=Blockdarstellung eines Ausgangs|Blockdarstellung eines Ausgangs]]
== Workaround ==
Leider ist es mir bis jetzt nicht gelungen, das Problem bei der fehlerhaften Interpretation der Ziel MADDR beim Senden von MESH Kommandos zu lösen. Deshalb habe ich mich für einen Workaround entschieden. 
Am lokalen Modul lassen sich die Ausgänge mit dem Befehl CUIO eindeutig setzen und lesen. Ebenso arbeitet der LEARN 1 Mode auf den mir vorliegenden Modulen korrekt.
=== Verbinden von OUTPUT5 mit INPUT5 an Servermodul ===
Um ein Tastendruck vom Servermodul simulieren zu können, wird ein Ausgang mit einem Eingang des Moduls verbunden. Hier wird der OUTPUT5 mit INPUT5 verbunden. Das Modul erhält die folgende Konfiguration.
* SUBTYPE1
* LEARN1
Die Eingänge reagieren immer nur auf die fallende Flanke.
=== Startzustand des Eingangsflipflops ermitteln ===
* CUIO5,1 - Setzt den Ausgang 5 auf High wenn er es sowieso nicht schon ist, der Eingang reagiert darauf nicht
* CUIO5,0 - Setzt jetzt den Ausgang auf Low, was aber sofort den Übertrag vom Eingang wieder auf den Ausgang auslöst
* CUIO - Liest jetzt an seiner letzten Position den Pegel am Ausgang 5, der zugleich den letzten Zustand des Eingangsflipflops darstellt. Sprich ist der Wert High so wird der Eingang das nächste mal Low senden und umgekehrt.
=== Adressierung der Ausgänge der Module ===
Um nun alle Ausgänge in meiner MESH mit nur einem Eingang ansprechen zu können muss ich nun einiges an Moduladressen opfern. Ich gehe da nun wie folgt vor. Ich verwende nur Moduladressen von 0002 bis 0FFF für die Module selbst. Die erste Position der Adresse benötige ich für die Pinzuordnung. Auch bei den Zielmodulen setze ich
* SUBTYPE1
* LEARN1
für den Ausgang 2 am Modul mit der MADDR0008 setze ich dann
* LEAVAL 2,5,2008
Das bedeutet, der Ausgang 2 wird geschaltet, wenn das Modul mit der MADDR2008 und mit LEARN1 konfiguriert ist, am Eingang 5 ein Ereignis erfahren hat.
=== Den fernen Ausgang gezielt ansteuern ===
Der Startzustand vom Eingangsflipflop, haben wir uns gemerkt. Ist der gemerkte Zustand gleich dem, den ich setzen möchte, so muss zuerst das Eingangsflipflop sein Zustand ändern.
* CUIO5,1 - nur nötig wenn der letzte Zustand Low war.
* CUIO5,0 - Zustand ist nun geändert.
Ist der jetzige Zustand nicht High so muss nochmal ein
* CUIO5,1
gesendet werden, das Gute ist, es müssen nie beide CUIO5,1 gesendet werden. 
Jetzt ändern wir die Moduladresse unseres Servermoduls, das geht tatsächlich on the fly.
* MADDR2008 - bedeutet bei dem Verfahren Ausgang 2 am Modul 0008
Dann
* CUIO5,0
und die Moduladresse wieder zurück.
* MADDR0001
Den Zustand des Eingangsflipflops nun wieder merken. 
Damit sollte dann der gewünschte Ausgang geschaltet worden sein.
== Beispiel ==

=== Server seitig ===
Für die Serverseite wird ein JDY-24M wie, oben erwähnt, fest mit einem USB zu Seriell Modul verbunden. Ich habe hier ein [https://www.pinterest.de/pin/680676931159204002/ PL2303 Modul] verwendet. Ich habe mich aber nicht getraut den 3,3V Ausgang als Versorgung für den JDY-24M zu verwenden, so habe ich noch ein AMS1117-3.3V mit den nötigen Kondensatoren an den 5V Ausgang der PL2303 Moduls drangehängt und damit das JDY-24M versorgt. Um den beschriebenen Workaround anwenden zu können habe ich noch eine Brücke vom INPUT5 zum OUTPUT5 eingelötet. Das PL2303 ist nicht zu empfehlen wenn der Server auf Windows arbeitet. Hier kann es zu Problemen mit dem Treiber kommen, Linux hingegen hat damit keine Probleme. Das Modul muss dann wie folgt eingestellt werden:
*BAUD5
*RESET - Danach das Terminal von 9600 auf 19200 Baud umstellen.
*NAMEServer
*PIN000000 - irgendwas sinnvolleres als 000000 muss nicht mit den anderen JDY-24M übereinstimmen.
*TYPE2
*NETIDABBA - oder anstatt ABBA jeder andere 4-Digit Hex, gilt aber dann für alle Module.
*MADDR0001
*ROLE5 - ist normal vor eingestellt
*SUBTYPE1
*LEARN1
*RESET - zur Sicherheit
Damit ist das Servermodul betriebsfertig.
=== Client seitig ===
Der aktuelle Schaltplan für das Clientmodul ist hier zu finden: 
[https://oshwlab.com/prediger.titriel/JDY-24M-Client oshwlab --> JDY-24M-Client]
Das JDY-24M hat einen Haed in dem man ein 4Pol Stiftsockel auflöten kann, darüber lässt sich das Modul dann temporär mit einem USB zu Seriell Modul verbinden. Bitte bei der Wahl ein 3,3V Modul benutzen. Die Platine hat damit kein Problem wenn sie über den JDY-24M mit Strom versorgt wird. Das Modul, dann über ein Terminal wie folgt einstellen.
*BAUD5
*RESET - Danach das Terminal von 9600 auf 19200 Baud umstellen.
*NAMEFlurWohn
*PIN000000 - irgendwas sinnvolleres als 000000 muss nicht mit den anderen JDY-24M übereinstimmen.
*TYPE2
*NETIDABBA - Wichtig, gleiche 4-Digit Hex wie beim Server.
*MADDR0002
*ROLE5 - ist normal vor eingestellt
*SUBTYPE1
*LEARN1
*LEAVAL 1,5,1002
*LEAVAL 2,5,2002
*LEAVAL 3,5,3002
*LEAVAL 4,5,4002
*RESET - zur Sicherheit
Damit ist das Modul final konfiguriert und kann vom USB zu Seriell Modul abgetrennt werden, und an dem gewünschten Ort eingebaut werden. Die Beispielbeschaltung ist auf der zweiten Seite des Schaltplans zu sehen. Die muss ggf. erst in den Editor geladen werden um sie sehen zu können.
=== Beschreibung der Funktion ===
== Quellen ==

* [https://manuals.plus/wp-content/sideloads/super-bluetooth-jdy-24m-bluetooth-module-manual-optimized.pdf Datenblatt JDY-24M]

JDY-24M BLE Bluetooth Mesh I/O

2022-01-23T16:25:17Z

Prediger: Erweitert

== Einleitung ==
Dieses Modul bietet mit mehreren der gleichen Bauform die Möglichkeit über BLE Bluetooth ein Mesh zu etablieren. Dies kann zum Beispiel für die Steuerung von Beleuchtung eingesetzt werden. Die Sicherheit bei dem System ist jedoch ähnlich derer von konventionellen Funkschaltern, da zur Identifikation nur ein 16 Bit Wert zur Verfügung steht. Also die Haustür würde ich nicht durch solch ein Modul direkt öffnen lassen. Es bietet aber die Möglichkeit via serieller Schnittstelle noch einen Microcontroller an zu schalten, der dann Sicherheitskritische Dinge steuern könnte.

== Eigenschaften ==
* Versorgungsspannung 1,9 - 3,6V
* Stromaufnahme je nach Betriebsart 3μA bis 4mA
* 5 Eingänge pulled up für Taster (15kΩ gegen Masse bei Ub = 3,3V reichen zum Auslösen)
* 5 Ausgänge (High 10mA, Low 14mA jeweils bei 0,3V Drop und Ub = 3,3V)
* Serielle Schnittstelle mit RS232 Logik.
* Als Hostmodul verwendbar
* 65280 Adressen in einem Netzwerk adressierbar

== Hardware ==

=== Modulbelegung ===
[[Datei:Belegung JDY-24M.png|mini|alternativtext=Belegung JDY-24M|Darstellung gemäß Datenblatt in der Anlage]]
Bei der mir vorliegenden Version 1.71 ist INPUT1[10] und INPUT2[8] vertauscht. Ich kann aber nicht sagen ob das bei anderen Versionen auch der Fall ist.
Die Anschlüsse sind bis auf STAT, ALED und PWRC selbsterklärend. Diese 3 Anschlüsse sind auch in der Betriebsart MESH kaum von Relevanz.
* STAT zeigt mit einem HIGH an, dass das Modul in irgendeiner Form connected ist.
* ALED ist nur im den anderen Betriebsarten relevant. Pulst HIGH wenn er auf Verbindung wartet, ist Dauer-HIGH wenn verbunden.
* PWRC weckt das Modul aus dem Schlafmodus und kann die Module in den Lernmodus versetzen.

=== Serielle Schnittstelle ===
Von der Logik her ist es eine RS232 Schnittstelle, die in Grundeinstellung auf 9600 Baud eingestellt ist. Mit 8 Bit Datenlänge, keine Parität und ein Stopbit. Es gibt somit viele USB zu Seriell Module und Chips die zum Verbinden des JDY-24M mit einem PC oder Server geeignet sind. Es ist lediglich sicherzustellen, dass die Signalpegel innerhalb der Versorgungsspannung des JDY-24M liegen.

=== Bluetooth Schnittstelle ===
Das Modul kann auch sehr weitreichend über BLE Bluetooth konfiguriert und gesteuert werden. Leider ist mir aber keine Software für Smartphons bekannt mit der das komfortabel und vollumfänglich möglich ist. Da dies aber möglich ist muss man unbedingt den Passwortschutz für diese Schnittstelle aktivieren. Mit der APP "nRF Connect for Mobile" lässt sich z.B. ein Smartphons mit den Modulen verbinden und die ein oder andere Funktion auch auslösen.

== Firmware ==
Das Modul lag mir in der Version 1.71 vor. In der Dokumentation nicht beschriebene Verhalten stammen aus dieser Version.

=== AT Befehle ===
Der AT Befehlssatz ist sehr logisch aufgebaut und es gibt nur wenige Ausnahmen die gegen eine einheitliche Linie gehen.
Alle Befehle beginnen mit der Zeichenfolge AT+
* Ausnahme der AT Befehl selbst der zum Testen der Schnittstelle verwendet werden kann.
Dem + folgt immer der eigentliche Befehl. In den weiteren Beschreibungen wird auch nur noch der Befehl genannt.
Dem Befehl können ohne Trennzeichen angehängt, ein oder mehrere Parameter folgen, die Parameter werden durch Kommas getrennt.
* Ausnahme der Befehl MESH, hier werden Binärdaten als Parameter übertragen.
Je nach Befehl und Anzahl der Parameter erkennt dass Modul ob es sich um eine Parameterabfrage oder ein Setzen von dessen Parametern handelt. 
Jeder AT Befehl muss mit \r\n (x0D,x0A) beendet werden. 
Einige Befehle geben keine Antwort zurück. 
Einige Antworten mit einem OK\r\n bei manchen kann das \n fehlen. Das +OK\r\n wie im Datenblatt angegeben kam mir in der Version 1.71 nicht unter. 
Bei einer Abfrage von Parametern folgt als Antwort das + mit dem Befehl, darauf ein = und dann die Parameterliste wie beim setzen.
Beispiele kommen im folgendem Abschnitt. 
Weitere Besonderheiten weden bei den Befehlen beschrieben.

=== Allgemeine AT Befehle ===
Die Abfolge entspricht etwa der, in der man die Einstellungen vornehmen sollte.
==== BAUD ====
Liest und setzt die Übertragungsgeschwindigkeit der seriellen Schnittstelle.
* AT+BAUD\r\n sendet +BAUD=4\r\n (Die 4 ist der Index für 9600 BAUD).
* AT+BAUD5\r\n sendet OK\r\n stellt die Schnittstelle auf 19200 BAUD ein (Der Wert mit dem ich arbeite).
==== RESET ====
Wird bei einigen Einstellungen wie z.B. bei BAUD benötigt, damit sie wirksam werden.
* AT+RESET\r\n sendet OK\r\n nach einem Moment folgt noch eine RESTART Meldung +JDY-24-START\r\n.
==== NAME ====
Mit NAME kann der Modulname verwaltete werden.
* AT+NAME\r\n sendet z.B. +NAME=JDY-24M\r\n
* AT+NAMEJDY-24M Flur\r\n sendet +NAME=JDY-24M Flur\r\nOK\r\n setzt den Name auf JDY-24M Flur. Hier die Besonderheit, dass der zu setzende Wert sofort ausgegeben wird.

=== Allgemeine AT Befehle verkürzte Dokumentation ===
Es entfällt in der Beschreibung nun das immer voran gestellte AT+ und das folgende \r\n bei den Antworten entfällt das voran gestellte +. Diese Zeichen sind zu ergänze bzw. werden vom Modul trotzdem gesendet.
==== VERSION ====
Mit VERSION liest man die Softwareversion des Moduls.
* VERSION liest z.B. VERSION=JDY-24M-V1.71
==== LADDR ====
Gibt es nur lesend und ermittelt die 12 Digit lange MAC-Adresse des Moduls.
* LADDR liest z.B. LADDR=11892007AC3E
==== ROLE ====
Mit ROLE wird die Betriebsart des Moduls gewählt.
* ROLE liest z.B. ROLE=5 (steht für die MESH Betriebsart).
* ROLE8 setzt die Näherungsdetektions Betriebsart.
==== PIN ====
Mit PIN wird eine 4 Digit Dec Wert als Pin gesetzt oder gelesen. Bei Version 1.71 ist sie 6 Digit lang. 
Die PIN wird bei einer Bluetooth Smartphoneverbindung verwendet, aber auch in der Master-Slave Betriebsart
* PIN liest z.B. PIN=123456
* PIN654321 setzt die PIN auf 654321
==== TYPE ====
Mit TYPE wird die PIN aktiviert bei 0 ist sie nicht aktiv
* TYPE liest z.B. TYPE=1 (PIN ist Aktive und wird nicht auf dem Smartphone gespeichert).
* TYPE2 setzt den Wert 2 es wird nach der PIN-Eingabe ein Automatischer reconnect ermöglicht.
==== CUIO ====
Mit CUIO kann man den logischen Zustand der Ausgänge des lokalen Moduls lesen und setzen.
* CUIO liest CUIO=0,1,0,0,1, (bedeutet OUTPUT 1-LOW 2-HIGH 3-LOW 4-LOW 5-HIGH).
* CUIO3,0 setzt den OUTPUT3 auf LOW
* CUIO2,1 setzt den OUTPUT2 auf HIGH
==== DEFAULT ====
Mit DEFAULT wird das Modul mit einem folgenden RESET wieder in die Werkseinstellungen zurück gesetzt.
* DEFAULT liest OK

== Betriebsarten ==
Das Modul kann ab der Softwareversion 1.6 in 8 verschiedenen Betriebsarten verwendet werden.

=== MESH network ===
Diese Betriebsart ist bei den Modulen vor eingestellt. Sie kann mit ROLE abgefragt oder gesetzt werden. Der Wert dafür ist 5.
Für den MESH betrieb müssen NETID und MADDR wie gewünscht eingestellt werden. Bitte nicht vergessen spätestens im Wirkbetrieb auch PIN zu setzen und mit TYPE zu aktivieren, damit nicht mit einem beliebigen Smartphone in das Netz eingedrungen werden kann. 
Es folgen weiter AT Befehle die für den MESH Betrieb benötigt werden. Nach dem Setzen der Werte sollte ein RESET gesendet werden. Ich kann im Moment noch nicht genau sagen welche Befehle den RESET brauchen und welche nicht.
==== NETID ====
Die NETID muss bei alle Module einer MESH den gleichen Wert haben, sie wird als 4 Digit Hex erwartet.
* NETID liest z.B. NETID=A3CF
* NETIDB74D setzt sie auf B74D
==== MADDR ====
Die 4 Digit lange Moduladresse darf innerhalb eines MESH nur einmal vorkommen. Sie kann damit gelesen und gesetzt werden.
* MADDR liest z.B. MADDR=AC3E
* MADDR3EF2 setzt sie auf 3EF2
==== MCLSS ====
Mit MCLSS legt man fest ob das Modul als Router im Netz agieren soll. Alle Module an denen ein Ausgang vom Server, oder einem anderen Modul gesteuert werden soll müssen in diesem Modus sein. Der Stromverbrauch liegt dann bei ca. 4mA.
* MCLSS liest z.B. MCLSS=0 (Das Modul ist im Router Betrieb).
* MCLSS1 setzt den Terminal Betrieb. Das Modul ist im Energiesparmodus. Die Eingänge können Daten auf den BLEBus senden und die lokalen Ausgänge setzen. Der BLEBus kann aber das Modul von sich aus nicht ansprechen.
==== KEY ====
Mit KEY stellt man ein, welcher Eingang des Moduls zu welchen Ausgang zugeordnet wird. Der gewählte Ausgang bezieht sich sowohl auf den lokalen Ausgang (abhängig von SUBTYPE) als auch auf einen eventuellen Ausgang eines anderen Moduls des MESH. Des weiteren gibt man eine Zielmoduladresse an. Je nach Einstellung des LEARN Modi wird diese anders berücksichtigt. Davon ebenfalls abhängig ist die Möglichkeit zu bestimmen, dass eine Aktion am Eingang auch auf der Seriellen Schnittstelle des adressierten Moduls ausgegeben wird.
*KEY1 liest z.B. KEY=1,BA1E,2,1 (Eine Signal am Eingang 1 sendet mit der Zielmoduladresse BA1E für den Ausgang 2 einen Zustand, der ggf. auch auf dem Seriellen Port ausgegeben wird.
*KEY2,BA32,4,0 setzt für den Eingang 2 eine Zuordnung zum Ausgang 4, und ggf. das Zielmodul BA32 ohne serielle Ausgabe.
==== SUBTYPE ====
Mit SUBTYPE koppelt man die lokalen Eingänge mit den lokalen Ausgängen entsprechend der Zuordnung die mit KEY gesetzt wurde.
*SUBTYPE liest z.B. SUBTYPE=0 (Signale an den Eingängen beeinflussen nicht die lokalen Ausgänge).
*SUBTYPE1 koppelt unter der Vorgabe aus KEY die Eingänge mit den Ausgängen.
==== LEARN ====
Mit LEARN stellt man im Prinzipe von Sender gesteuerten Ausgängen auf Empfänger gesteuerte Ausgänge um. Beim Sender wirkt sich das lediglich so aus, dass die Kommandosequenze, die in das MESH gesendet wird, sich ändert. Im ausgeschalteten Modus ist sie AAB2E7 und im eingeschalteten Modus AAB2D7. Dazu später mehr.
*LEARN leist z.B. 0 (Beim Emfänger: Er schaut ob ein Kommando AAB2E7 auf den Bus ist, prüft dann ob dies seine Adresse hat und stellt den Ausgang entsprechend ein. Sender gesteuert)
*LEARN1 setzt dem Empfänger gesteuerten Modus. Die Zielmoduladresse wird hier ignoriert, es wird nur geschaut, ob das Kommando AAB2D7 vom entsprechenden Modul kommt, wenn ja, wird der zugeordnete Ausgang entsprechend gesetzt. Diese Zuordnungen erfolgen mit LEAVAL.
==== LEAVAL ====
Mit LEAVAL setzt man die Zuordnung der Kommandos AAB2D7 im Empfängermodul. Die mit LEAVAL angelegte Tabelle ist nur wirksam, wenn LEARN auf 1 gesetzt ist. LEAVAL kann entgegen dem Datenblatt nicht gelesen werden!
*LEAVAL2,4,BA07 bewirkt im Empfänger, dass ein Ereignis mit dem Kommando AAB2D7 am Eingang 4 vom Sendermodul BA07, an den Ausgang 2 des Empfängermodul einstellt. Ausgänge können leider nicht mehrfach zugeordnet werden.
=== MESH Datenaustausch ===
In der MESH Betriebsart geben die Module Daten auf den MESH Bus. Dies kann geschehen durch den Wechsel eines Eingangs von High nach Low, durch senden eines MESH Befehls und durch die Antwortreaktion auf einen MESH Befehl. Zu erst betrachten wir uns das Format einer Modul Antwort.
==== Antwort von einem Modul im MESH ====
Die Antworten eines Moduls sind reine Binärdaten, sie kommen je nach Einstellung der Module auf den Seriellen Schnittstellen an.
Da die Binärdaten immer Byteorientiert sind, werden sie hier Hexadezimal beschrieben. 
Grundsätzlich immer vorhanden ist: 
[erster Befehlscode, 2 Bytes][Anzahl der noch folgenden Bytes, 1 Byte ][MADDR des Senders, 2 Bytes]
==== Antwort auf Abfrage ====
Antworten auf Abfrage besitzen kein Zieladressfeld. Die Folgenden Antworten mit dem folgenden ersten Befehlscode können auftreten
*F0 00 - Sendet den Status der Ausgänge
** F000 07 0008 01 00 01 00 00 - Am Modul MADDR 0008 ist der Ausgang 1 und 3 High
*F0 01 - Sendet den Status der Eingänge
** F001 07 0005 01 01 01 01 01 - Am Modul MADDR 0005 sind alle Eingänge offen (01 wegen internem Pull up)
*F0 02 - Sendet die MADDR (Ein wenig Sinnfrei ?!?)
** F002 04 0008 00 08 - Am Modul MADDR 0008 ist die MADDR 0008, welch Überraschung ;-)
*F0 03 - Sendet die NETID
** F003 04 0005 AB BA - Am Modul MADDR 0005 ist die NETID ABBA, auch nur wenig überraschend
*F0 04 - Sendet die PIN
** F004 06 0008 7B 04 05 06 - Am Modul MADDR 0008 ist die PIN codiert 7B040506. Die Codierung ist mir noch nicht klar
*F0 05 - Sendet den TYPE zur PIN
** F005 03 0008 00 - Am Modul MADDR 0008 ist der TYPE gleich null siehe AT Befehl TYPE
*F0 06 - Soll den Tasten Status senden (Bedeutung noch unklar)
** F006 07 0005 00 00 00 00 00 - Satus am Modul MADDR 0005 (bedarf noch Tests wann nicht 5 x 00)
*F0 07 - Sendet die MCLSS Einstellung
** F007 03 0008 00 - Am Modul MADDR 0008 ist MCLSS mit null gesetzt siehe AT Befehl MCLSS
*F0 08 - Sendet den eingestellten FRIEND (Mir noch unklar siehe Datenblatt)
** F008 08 0005 00 00 00 00 00 00 - Am Modul MADDR 0005 ist kein FRIEND gesetzt
*F0 09 - Sendet den FRTYPE
** F009 03 0005 00 - Am Modul MADDR 0005 ist der FRTYPE null siehe Datenblatt FRTYPE
==== Sonstige Antworten ====
Bei allen anderen Antworten wird die Antwort immer noch um die MADDR des Zielmoduls erweitert hier ist auch ein FFFF als Broadcast möglich. Bei den Antworten auf Grund einer Eingangsauslösung ist zu beachten, dass hier nicht die Nummer des Eingangs übergeben wird, sondern die Nummer die dem Eingang als zugehöriger Ausgang in KEY zugewiesen wurde. Dies hat auch in LEARN 1 seine Wirkung. Es ist also sehr gut zu überlegen, ob man hier von der vor eingestellten 1:1 Zuordnung abweichen möchte.
* F1 DD - Daten aus einer Übertragung von einer Seriellen Schnittstelle
** F1DD 08 0001 0008 41 42 43 44 - Modul MADDR 0001 sendet Daten 41424344 an Modul MADDR 0008, die Daten können an jeder Seriellen Schnittstelle sichtbar sein.
* F2 E7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 0 gesetzt ist.
** F2E7 09 0005 FFFF AAB2E7 02 01 - F2E7 und AAB2E7 kennzeichnen den Antworttyp. Gesendet wird vom Modul MADDR 0005 für alle Module (FFFF). Unabhängig von LEARN würden alle Module ihren Ausgang 02 auf 01 setzen. Abhängig von der Einstellung in KEY erscheint die Sequenz auch auf der Seriellen Schnittstelle der Module. Ebenso bestimmt auch KEY die Zielmoduladresse und den Ausgang.
* F2 D7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 1 gesetzt ist.
** F2D7 09 0005 FFFF AAB2D7 02 01 - F2D7 und AAB2D7 kennzeichnen den Antworttyp. Gesendet wird an alle Module des MESH, die Ziel MADDR ist hier ohne Bedeutung, ihr Wert wird aber weiter von KEY abgeleitet, eben so die "Ausgangzuordnung" die aber hier trotzdem als Eingang interpretiert wird. Hier kann es schnell Caos geben, wenn man von der 1:1 Zuordnung abweicht. Die Sequenz kommt immer an allen anderen Seriellen Schnittstellen an. Mit LEAVAL wird hier eingestellt ob ein Ausgang auf diese Antwort reagiert.
==== Befehle mit MESH senden ====
Mit dem AT Befehl MESH lassen sich Kommandos in das Mesh senden. Die Kommandos sind identisch mit den Kommandos die auch über Bluetooth in das Mesh über die Service UUID FFE3 gesendet werden können. Dazu muss die Bytefolge lediglich zwischen AT+MESH und \r\n auf der Seriellen Schnittstelle eingeschlossen werden. Da ja Binärdaten übertragen werden müssen wandelt man einfach AT+MESH in 41 54 2B 4D 45 53 48 um und \r\n in 0D 0A. So kann alles Hexadezimal übergeben werden. 
===== Beispiel: Das Hauptkommando 31 =====
Beispiel: 41542B4D455348 31 0008 F0B100 0D0A würde vom Modul MADDR 0008 den Status der Ausgänge anfordern. 
Hier sind wir auch schon bei einem Problem angekommen. Der Teil 31 0008 beschreib mit 31 eins der möglichen Hauptkommando und 0008 die MADDR des anzufragenden Moduls. Bei meinem Netzwerk wird die vorgegebene MADDR mehr oder weniger ignoriert und es fühlen sich alle Module angesprochen. Das ist bei reinen Abfragen noch händelbar, da die Antworten, siehe oben, alle ihre MADDR mit senden und sie so auch wieder zugeordnet werden können. Bei den Kommandos die aber Ausgänge schalten sollen ist das aber sehr doof. 
Bleiben wir bei dem Kommando, das Unterkommando ist hier F0B100 die zugehörige Antwort ist die zuvor beschriebene F000. Die Anfragen zu den gewünschten Antworten können schematisch gebildet werden. FnB10n fordert F00n an. Das heißt F7B107 fordert F007 an, also die Einstellung vom MCLSS. Noch mal in voller Länge: 41542B4D455348 31 0008 F7B107 0D0A. Damit ist schon alles zum Hauptkommando 31 gesagt.
===== Weiter Hauptkommandos =====
Bei denen von mir schon nachvollzogenen Hauptkommandos folgt immer die MADDR des Zielmoduls, die aber wie schon erwähnt nicht korrekt verarbeitet wird. 
Es gibt neben dem schon beschriebenen Hauptkommando 31 noch die folgenden Hauptkommandos:
* 00 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält OK\r\n als Antwort.
* 01 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 10 - Führt I/O Anweisungen aus, das sendende Modul erhält OK\r\n als Antwort.
* 11 - Führt I/O Anweisungen aus, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 41 - Soll AT Befehle auf entfernten Modulen setzen können (ist noch zu untersuchen).
* A1 - Soll transparent Daten an alle FRIENDS senden können (ist noch zu untersuchen).
* A2 - Soll transparent Daten an einen privaten FRIEND senden können (ist noch zu untersuchen).
===== Serielle Daten senden (00 und 01) =====
Beispiel: 41542B4D455348 00 0008 41424344 0D0A sendet für Modul MADDR 0008 'ABCD' auf die Serielle Schnittstelle
===== I/O Anweisungen (10 und 11) =====
Die I/O Anweisung wird nach dem gleichen Schema gebildet. Nach der Ziel MADDR folgt ein Unterkommando.
* AA B1 E7 [Ausgang] [Pegel] - das Kommando setzt den Ausgang (01, 02 ,...) auf den Pegel High (01) oder Low (00)
* AA B2 E7 [Ausgang] [Pegel] - sehe kein Unterschied zu AA B1 E7
* AB B1 E7 FF [Bits] - das Kommando setzt die Ausgänge Bit zugeordnet. Bit 0 -> Ausgang 1, Bit 4 -> Ausgang 5
* AB B2 E7 FF [Bits] - sehe kein Unterschied zu AB B1 E7 FF
* A1 B1 E7 [Ausgang] [beliebig] - das Kommando toggelt den Ausgang (01, 02 ,...)
* A1 B2 E7 [Ausgang] [beliebig] - sehe kein Unterschied zu A1 B1 E7
* A2 B1 E7 FF [beliebig] - (ist noch zu untersuchen)
* A2 B2 E7 FF [beliebig] - (ist noch zu untersuchen)
Beispiel: 41542B4D455348 10 0005 AAB1E7 02 01 sollte nur am Modul MADDR 0005 den Ausgang 2 auf high schalten.
==== Blockbild der Eingänge ====
[[Datei:Blockdarstellung Eingang JDY-24M .png.png|mini|alternativtext=Blockdarstellung eines Tastereingangs|Blockdarstellung eines Tastereingangs]]
==== Blockbild der Ausgänge ====
[[Datei:Blockdarstellung Ausgang JDY-24M.png|mini|alternativtext=Blockdarstellung eines Ausgangs|Blockdarstellung eines Ausgangs]]
== Workaround ==
Leider ist es mir bis jetzt nicht gelungen, das Problem bei der fehlerhaften Interpretation der Ziel MADDR beim Senden von MESH Kommandos zu lösen. Deshalb habe ich mich für einen Workaround entschieden. 
Am lokalen Modul lassen sich die Ausgänge mit dem Befehl CUIO eindeutig setzen und lesen. Ebenso arbeitet der LEARN 1 Mode auf den mir vorliegenden Modulen korrekt.
=== Verbinden von OUTPUT5 mit INPUT5 an Servermodul ===
Um ein Tastendruck vom Servermodul simulieren zu können, wird ein Ausgang mit einem Eingang des Moduls verbunden. Hier wird der OUTPUT5 mit INPUT5 verbunden. Das Modul erhält die folgende Konfiguration.
* SUBTYPE1
* LEARN1
Die Eingänge reagieren immer nur auf die fallende Flanke.
=== Startzustand des Eingangsflipflops ermitteln ===
* CUIO5,1 - Setzt den Ausgang 5 auf High wenn er es sowieso nicht schon ist, der Eingang reagiert darauf nicht
* CUIO5,0 - Setzt jetzt den Ausgang auf Low, was aber sofort den Übertrag vom Eingang wieder auf den Ausgang auslöst
* CUIO - Liest jetzt an seiner letzten Position den Pegel am Ausgang 5, der zugleich den letzten Zustand des Eingangsflipflops darstellt. Sprich ist der Wert High so wird der Eingang das nächste mal Low senden und umgekehrt.
=== Adressierung der Ausgänge der Module ===
Um nun alle Ausgänge in meiner MESH mit nur einem Eingang ansprechen zu können muss ich nun einiges an Moduladressen opfern. Ich gehe da nun wie folgt vor. Ich verwende nur Moduladressen von 0002 bis 0FFF für die Module selbst. Die erste Position der Adresse benötige ich für die Pinzuordnung. Auch bei den Zielmodulen setze ich
* SUBTYPE1
* LEARN1
für den Ausgang 2 am Modul mit der MADDR0008 setze ich dann
* LEAVAL 2,5,2008
Das bedeutet, der Ausgang 2 wird geschaltet, wenn das Modul mit der MADDR2008 und mit LEARN1 konfiguriert ist, am Eingang 5 ein Ereignis erfahren hat.
=== Den fernen Ausgang gezielt ansteuern ===
Der Startzustand vom Eingangsflipflop, haben wir uns gemerkt. Ist der gemerkte Zustand gleich dem, den ich setzen möchte, so muss zuerst das Eingangsflipflop sein Zustand ändern.
* CUIO5,1 - nur nötig wenn der letzte Zustand Low war.
* CUIO5,0 - Zustand ist nun geändert.
Ist der jetzige Zustand nicht High so muss nochmal ein
* CUIO5,1
gesendet werden, das Gute ist, es müssen nie beide CUIO5,1 gesendet werden. 
Jetzt ändern wir die Moduladresse unseres Servermoduls, das geht tatsächlich on the fly.
* MADDR2008 - bedeutet bei dem Verfahren Ausgang 2 am Modul 0008
Dann
* CUIO5,0
und die Moduladresse wieder zurück.
* MADDR0001
Den Zustand des Eingangsflipflops nun wieder merken. 
Damit sollte dann der gewünschte Ausgang geschaltet worden sein.

== Quellen ==

* [https://manuals.plus/wp-content/sideloads/super-bluetooth-jdy-24m-bluetooth-module-manual-optimized.pdf Datenblatt JDY-24M]

Datei:Blockdarstellung Ausgang JDY-24M.png

2022-01-23T14:46:13Z

Prediger:

Blockdarstellung Ausgang JDY-24M

JDY-24M BLE Bluetooth Mesh I/O

2022-01-20T16:51:11Z

Prediger: /* Blockbild der Eingänge */

== Einleitung ==
Dieses Modul bietet mit mehreren der gleichen Bauform die Möglichkeit über BLE Bluetooth ein Mesh zu etablieren. Dies kann zum Beispiel für die Steuerung von Beleuchtung eingesetzt werden. Die Sicherheit bei dem System ist jedoch ähnlich derer von konventionellen Funkschaltern, da zur Identifikation nur ein 16 Bit Wert zur Verfügung steht. Also die Haustür würde ich nicht durch solch ein Modul direkt öffnen lassen. Es bietet aber die Möglichkeit via serieller Schnittstelle noch einen Microcontroller an zu schalten, der dann Sicherheitskritische Dinge steuern könnte.

== Eigenschaften ==
* Versorgungsspannung 1,9 - 3,6V
* Stromaufnahme je nach Betriebsart 3μA bis 4mA
* 5 Eingänge pulled up für Taster (15kΩ gegen Masse bei Ub = 3,3V reichen zum Auslösen)
* 5 Ausgänge (High 10mA, Low 14mA jeweils bei 0,3V Drop und Ub = 3,3V)
* Serielle Schnittstelle mit RS232 Logik.
* Als Hostmodul verwendbar
* 65280 Adressen in einem Netzwerk adressierbar

== Hardware ==

=== Modulbelegung ===
[[Datei:Belegung JDY-24M.png|mini|alternativtext=Belegung JDY-24M|Darstellung gemäß Datenblatt in der Anlage]]
Bei der mir vorliegenden Version 1.71 ist INPUT1[10] und INPUT2[8] vertauscht. Ich kann aber nicht sagen ob das bei anderen Versionen auch der Fall ist.
Die Anschlüsse sind bis auf STAT, ALED und PWRC selbsterklärend. Diese 3 Anschlüsse sind auch in der Betriebsart MESH kaum von Relevanz.
* STAT zeigt mit einem HIGH an, dass das Modul in irgendeiner Form connected ist.
* ALED ist nur im den anderen Betriebsarten relevant. Pulst HIGH wenn er auf Verbindung wartet, ist Dauer-HIGH wenn verbunden.
* PWRC weckt das Modul aus dem Schlafmodus und kann die Module in den Lernmodus versetzen.

=== Serielle Schnittstelle ===
Von der Logik her ist es eine RS232 Schnittstelle, die in Grundeinstellung auf 9600 Baud eingestellt ist. Mit 8 Bit Datenlänge, keine Parität und ein Stopbit. Es gibt somit viele USB zu Seriell Module und Chips die zum Verbinden des JDY-24M mit einem PC oder Server geeignet sind. Es ist lediglich sicherzustellen, dass die Signalpegel innerhalb der Versorgungsspannung des JDY-24M liegen.

=== Bluetooth Schnittstelle ===
Das Modul kann auch sehr weitreichend über BLE Bluetooth konfiguriert und gesteuert werden. Leider ist mir aber keine Software für Smartphons bekannt mit der das komfortabel und vollumfänglich möglich ist. Da dies aber möglich ist muss man unbedingt den Passwortschutz für diese Schnittstelle aktivieren. Mit der APP "nRF Connect for Mobile" lässt sich z.B. ein Smartphons mit den Modulen verbinden und die ein oder andere Funktion auch auslösen.

== Firmware ==
Das Modul lag mir in der Version 1.71 vor. In der Dokumentation nicht beschriebene Verhalten stammen aus dieser Version.

=== AT Befehle ===
Der AT Befehlssatz ist sehr logisch aufgebaut und es gibt nur wenige Ausnahmen die gegen eine einheitliche Linie gehen.
Alle Befehle beginnen mit der Zeichenfolge AT+
* Ausnahme der AT Befehl selbst der zum Testen der Schnittstelle verwendet werden kann.
Dem + folgt immer der eigentliche Befehl. In den weiteren Beschreibungen wird auch nur noch der Befehl genannt.
Dem Befehl können ohne Trennzeichen angehängt, ein oder mehrere Parameter folgen, die Parameter werden durch Kommas getrennt.
* Ausnahme der Befehl MESH, hier werden Binärdaten als Parameter übertragen.
Je nach Befehl und Anzahl der Parameter erkennt dass Modul ob es sich um eine Parameterabfrage oder ein Setzen von dessen Parametern handelt. 
Jeder AT Befehl muss mit \r\n (x0D,x0A) beendet werden. 
Einige Befehle geben keine Antwort zurück. 
Einige Antworten mit einem OK\r\n bei manchen kann das \n fehlen. Das +OK\r\n wie im Datenblatt angegeben kam mir in der Version 1.71 nicht unter. 
Bei einer Abfrage von Parametern folgt als Antwort das + mit dem Befehl, darauf ein = und dann die Parameterliste wie beim setzen.
Beispiele kommen im folgendem Abschnitt. 
Weitere Besonderheiten weden bei den Befehlen beschrieben.

=== Allgemeine AT Befehle ===
Die Abfolge entspricht etwa der, in der man die Einstellungen vornehmen sollte.
==== BAUD ====
Liest und setzt die Übertragungsgeschwindigkeit der seriellen Schnittstelle.
* AT+BAUD\r\n sendet +BAUD=4\r\n (Die 4 ist der Index für 9600 BAUD).
* AT+BAUD5\r\n sendet OK\r\n stellt die Schnittstelle auf 19200 BAUD ein (Der Wert mit dem ich arbeite).
==== RESET ====
Wird bei einigen Einstellungen wie z.B. bei BAUD benötigt, damit sie wirksam werden.
* AT+RESET\r\n sendet OK\r\n nach einem Moment folgt noch eine RESTART Meldung +JDY-24-START\r\n.
==== NAME ====
Mit NAME kann der Modulname verwaltete werden.
* AT+NAME\r\n sendet z.B. +NAME=JDY-24M\r\n
* AT+NAMEJDY-24M Flur\r\n sendet +NAME=JDY-24M Flur\r\nOK\r\n setzt den Name auf JDY-24M Flur. Hier die Besonderheit, dass der zu setzende Wert sofort ausgegeben wird.

=== Allgemeine AT Befehle verkürzte Dokumentation ===
Es entfällt in der Beschreibung nun das immer voran gestellte AT+ und das folgende \r\n bei den Antworten entfällt das voran gestellte +. Diese Zeichen sind zu ergänze bzw. werden vom Modul trotzdem gesendet.
==== VERSION ====
Mit VERSION liest man die Softwareversion des Moduls.
* VERSION liest z.B. VERSION=JDY-24M-V1.71
==== LADDR ====
Gibt es nur lesend und ermittelt die 12 Digit lange MAC-Adresse des Moduls.
* LADDR liest z.B. LADDR=11892007AC3E
==== ROLE ====
Mit ROLE wird die Betriebsart des Moduls gewählt.
* ROLE liest z.B. ROLE=5 (steht für die MESH Betriebsart).
* ROLE8 setzt die Näherungsdetektions Betriebsart.
==== PIN ====
Mit PIN wird eine 4 Digit Dec Wert als Pin gesetzt oder gelesen. Bei Version 1.71 ist sie 6 Digit lang. 
Die PIN wird bei einer Bluetooth Smartphoneverbindung verwendet, aber auch in der Master-Slave Betriebsart
* PIN liest z.B. PIN=123456
* PIN654321 setzt die PIN auf 654321
==== TYPE ====
Mit TYPE wird die PIN aktiviert bei 0 ist sie nicht aktiv
* TYPE liest z.B. TYPE=1 (PIN ist Aktive und wird nicht auf dem Smartphone gespeichert).
* TYPE2 setzt den Wert 2 es wird nach der PIN-Eingabe ein Automatischer reconnect ermöglicht.
==== CUIO ====
Mit CUIO kann man den logischen Zustand der Ausgänge des lokalen Moduls lesen und setzen.
* CUIO liest CUIO=0,1,0,0,1, (bedeutet OUTPUT 1-LOW 2-HIGH 3-LOW 4-LOW 5-HIGH).
* CUIO3,0 setzt den OUTPUT3 auf LOW
* CUIO2,1 setzt den OUTPUT2 auf HIGH
==== DEFAULT ====
Mit DEFAULT wird das Modul mit einem folgenden RESET wieder in die Werkseinstellungen zurück gesetzt.
* DEFAULT liest OK

== Betriebsarten ==
Das Modul kann ab der Softwareversion 1.6 in 8 verschiedenen Betriebsarten verwendet werden.

=== MESH network ===
Diese Betriebsart ist bei den Modulen vor eingestellt. Sie kann mit ROLE abgefragt oder gesetzt werden. Der Wert dafür ist 5.
Für den MESH betrieb müssen NETID und MADDR wie gewünscht eingestellt werden. Bitte nicht vergessen spätestens im Wirkbetrieb auch PIN zu setzen und mit TYPE zu aktivieren, damit nicht mit einem beliebigen Smartphone in das Netz eingedrungen werden kann. 
Es folgen weiter AT Befehle die für den MESH Betrieb benötigt werden. Nach dem Setzen der Werte sollte ein RESET gesendet werden. Ich kann im Moment noch nicht genau sagen welche Befehle den RESET brauchen und welche nicht.
==== NETID ====
Die NETID muss bei alle Module einer MESH den gleichen Wert haben, sie wird als 4 Digit Hex erwartet.
* NETID liest z.B. NETID=A3CF
* NETIDB74D setzt sie auf B74D
==== MADDR ====
Die 4 Digit lange Moduladresse darf innerhalb eines MESH nur einmal vorkommen. Sie kann damit gelesen und gesetzt werden.
* MADDR liest z.B. MADDR=AC3E
* MADDR3EF2 setzt sie auf 3EF2
==== MCLSS ====
Mit MCLSS legt man fest ob das Modul als Router im Netz agieren soll. Alle Module an denen ein Ausgang vom Server, oder einem anderen Modul gesteuert werden soll müssen in diesem Modus sein. Der Stromverbrauch liegt dann bei ca. 4mA.
* MCLSS liest z.B. MCLSS=0 (Das Modul ist im Router Betrieb).
* MCLSS1 setzt den Terminal Betrieb. Das Modul ist im Energiesparmodus. Die Eingänge können Daten auf den BLEBus senden und die lokalen Ausgänge setzen. Der BLEBus kann aber das Modul von sich aus nicht ansprechen.
==== KEY ====
Mit KEY stellt man ein, welcher Eingang des Moduls zu welchen Ausgang zugeordnet wird. Der gewählte Ausgang bezieht sich sowohl auf den lokalen Ausgang (abhängig von SUBTYPE) als auch auf einen eventuellen Ausgang eines anderen Moduls des MESH. Des weiteren gibt man eine Zielmoduladresse an. Je nach Einstellung des LEARN Modi wird diese anders berücksichtigt. Davon ebenfalls abhängig ist die Möglichkeit zu bestimmen, dass eine Aktion am Eingang auch auf der Seriellen Schnittstelle des adressierten Moduls ausgegeben wird.
*KEY1 liest z.B. KEY=1,BA1E,2,1 (Eine Signal am Eingang 1 sendet mit der Zielmoduladresse BA1E für den Ausgang 2 einen Zustand, der ggf. auch auf dem Seriellen Port ausgegeben wird.
*KEY2,BA32,4,0 setzt für den Eingang 2 eine Zuordnung zum Ausgang 4, und ggf. das Zielmodul BA32 ohne serielle Ausgabe.
==== SUBTYPE ====
Mit SUBTYPE koppelt man die lokalen Eingänge mit den lokalen Ausgängen entsprechend der Zuordnung die mit KEY gesetzt wurde.
*SUBTYPE liest z.B. SUBTYPE=0 (Signale an den Eingängen beeinflussen nicht die lokalen Ausgänge).
*SUBTYPE1 koppelt unter der Vorgabe aus KEY die Eingänge mit den Ausgängen.
==== LEARN ====
Mit LEARN stellt man im Prinzipe von Sender gesteuerten Ausgängen auf Empfänger gesteuerte Ausgänge um. Beim Sender wirkt sich das lediglich so aus, dass die Kommandosequenze, die in das MESH gesendet wird, sich ändert. Im ausgeschalteten Modus ist sie AAB2E7 und im eingeschalteten Modus AAB2D7. Dazu später mehr.
*LEARN leist z.B. 0 (Beim Emfänger: Er schaut ob ein Kommando AAB2E7 auf den Bus ist, prüft dann ob dies seine Adresse hat und stellt den Ausgang entsprechend ein. Sender gesteuert)
*LEARN1 setzt dem Empfänger gesteuerten Modus. Die Zielmoduladresse wird hier ignoriert, es wird nur geschaut, ob das Kommando AAB2D7 vom entsprechenden Modul kommt, wenn ja, wird der zugeordnete Ausgang entsprechend gesetzt. Diese Zuordnungen erfolgen mit LEAVAL.
==== LEAVAL ====
Mit LEAVAL setzt man die Zuordnung der Kommandos AAB2D7 im Empfängermodul. Die mit LEAVAL angelegte Tabelle ist nur wirksam, wenn LEARN auf 1 gesetzt ist. LEAVAL kann entgegen dem Datenblatt nicht gelesen werden!
*LEAVAL2,4,BA07 bewirkt im Empfänger, dass ein Ereignis mit dem Kommando AAB2D7 am Eingang 4 vom Sendermodul BA07, an den Ausgang 2 des Empfängermodul einstellt. Ausgänge können leider nicht mehrfach zugeordnet werden.
=== MESH Datenaustausch ===
In der MESH Betriebsart geben die Module Daten auf den MESH Bus. Dies kann geschehen durch den Wechsel eines Eingangs von High nach Low, durch senden eines MESH Befehls und durch die Antwortreaktion auf einen MESH Befehl. Zu erst betrachten wir uns das Format einer Modul Antwort.
==== Antwort von einem Modul im MESH ====
Die Antworten eines Moduls sind reine Binärdaten, sie kommen je nach Einstellung der Module auf den Seriellen Schnittstellen an.
Da die Binärdaten immer Byteorientiert sind, werden sie hier Hexadezimal beschrieben. 
Grundsätzlich immer vorhanden ist: 
[erster Befehlscode, 2 Bytes][Anzahl der noch folgenden Bytes, 1 Byte ][MADDR des Senders, 2 Bytes]
==== Antwort auf Abfrage ====
Antworten auf Abfrage besitzen kein Zieladressfeld. Die Folgenden Antworten mit dem folgenden ersten Befehlscode können auftreten
*F0 00 - Sendet den Status der Ausgänge
** F000 07 0008 01 00 01 00 00 - Am Modul MADDR 0008 ist der Ausgang 1 und 3 High
*F0 01 - Sendet den Status der Eingänge
** F001 07 0005 01 01 01 01 01 - Am Modul MADDR 0005 sind alle Eingänge offen (01 wegen internem Pull up)
*F0 02 - Sendet die MADDR (Ein wenig Sinnfrei ?!?)
** F002 04 0008 00 08 - Am Modul MADDR 0008 ist die MADDR 0008, welch Überraschung ;-)
*F0 03 - Sendet die NETID
** F003 04 0005 AB BA - Am Modul MADDR 0005 ist die NETID ABBA, auch nur wenig überraschend
*F0 04 - Sendet die PIN
** F004 06 0008 7B 04 05 06 - Am Modul MADDR 0008 ist die PIN codiert 7B040506. Die Codierung ist mir noch nicht klar
*F0 05 - Sendet den TYPE zur PIN
** F005 03 0008 00 - Am Modul MADDR 0008 ist der TYPE gleich null siehe AT Befehl TYPE
*F0 06 - Soll den Tasten Status senden (Bedeutung noch unklar)
** F006 07 0005 00 00 00 00 00 - Satus am Modul MADDR 0005 (bedarf noch Tests wann nicht 5 x 00)
*F0 07 - Sendet die MCLSS Einstellung
** F007 03 0008 00 - Am Modul MADDR 0008 ist MCLSS mit null gesetzt siehe AT Befehl MCLSS
*F0 08 - Sendet den eingestellten FRIEND (Mir noch unklar siehe Datenblatt)
** F008 08 0005 00 00 00 00 00 00 - Am Modul MADDR 0005 ist kein FRIEND gesetzt
*F0 09 - Sendet den FRTYPE
** F009 03 0005 00 - Am Modul MADDR 0005 ist der FRTYPE null siehe Datenblatt FRTYPE
==== Sonstige Antworten ====
Bei allen anderen Antworten wird die Antwort immer noch um die MADDR des Zielmoduls erweitert hier ist auch ein FFFF als Broadcast möglich. Bei den Antworten auf Grund einer Eingangsauslösung ist zu beachten, dass hier nicht die Nummer des Eingangs übergeben wird, sondern die Nummer die dem Eingang als zugehöriger Ausgang in KEY zugewiesen wurde. Dies hat auch in LEARN 1 seine Wirkung. Es ist also sehr gut zu überlegen, ob man hier von der vor eingestellten 1:1 Zuordnung abweichen möchte.
* F1 DD - Daten aus einer Übertragung von einer Seriellen Schnittstelle
** F1DD 08 0001 0008 41 42 43 44 - Modul MADDR 0001 sendet Daten 41424344 an Modul MADDR 0008, die Daten können an jeder Seriellen Schnittstelle sichtbar sein.
* F2 E7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 0 gesetzt ist.
** F2E7 09 0005 FFFF AAB2E7 02 01 - F2E7 und AAB2E7 kennzeichnen den Antworttyp. Gesendet wird vom Modul MADDR 0005 für alle Module (FFFF). Unabhängig von LEARN würden alle Module ihren Ausgang 02 auf 01 setzen. Abhängig von der Einstellung in KEY erscheint die Sequenz auch auf der Seriellen Schnittstelle der Module. Ebenso bestimmt auch KEY die Zielmoduladresse und den Ausgang.
* F2 D7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 1 gesetzt ist.
** F2D7 09 0005 FFFF AAB2D7 02 01 - F2D7 und AAB2D7 kennzeichnen den Antworttyp. Gesendet wird an alle Module des MESH, die Ziel MADDR ist hier ohne Bedeutung, ihr Wert wird aber weiter von KEY abgeleitet, eben so die "Ausgangzuordnung" die aber hier trotzdem als Eingang interpretiert wird. Hier kann es schnell Caos geben, wenn man von der 1:1 Zuordnung abweicht. Die Sequenz kommt immer an allen anderen Seriellen Schnittstellen an. Mit LEAVAL wird hier eingestellt ob ein Ausgang auf diese Antwort reagiert.
==== Befehle mit MESH senden ====
Mit dem AT Befehl MESH lassen sich Kommandos in das Mesh senden. Die Kommandos sind identisch mit den Kommandos die auch über Bluetooth in das Mesh über die Service UUID FFE3 gesendet werden können. Dazu muss die Bytefolge lediglich zwischen AT+MESH und \r\n auf der Seriellen Schnittstelle eingeschlossen werden. Da ja Binärdaten übertragen werden müssen wandelt man einfach AT+MESH in 41 54 2B 4D 45 53 48 um und \r\n in 0D 0A. So kann alles Hexadezimal übergeben werden. 
===== Beispiel: Das Hauptkommando 31 =====
Beispiel: 41542B4D455348 31 0008 F0B100 0D0A würde vom Modul MADDR 0008 den Status der Ausgänge anfordern. 
Hier sind wir auch schon bei einem Problem angekommen. Der Teil 31 0008 beschreib mit 31 eins der möglichen Hauptkommando und 0008 die MADDR des anzufragenden Moduls. Bei meinem Netzwerk wird die vorgegebene MADDR mehr oder weniger ignoriert und es fühlen sich alle Module angesprochen. Das ist bei reinen Abfragen noch händelbar, da die Antworten, siehe oben, alle ihre MADDR mit senden und sie so auch wieder zugeordnet werden können. Bei den Kommandos die aber Ausgänge schalten sollen ist das aber sehr doof. 
Bleiben wir bei dem Kommando, das Unterkommando ist hier F0B100 die zugehörige Antwort ist die zuvor beschriebene F000. Die Anfragen zu den gewünschten Antworten können schematisch gebildet werden. FnB10n fordert F00n an. Das heißt F7B107 fordert F007 an, also die Einstellung vom MCLSS. Noch mal in voller Länge: 41542B4D455348 31 0008 F7B107 0D0A. Damit ist schon alles zum Hauptkommando 31 gesagt.
===== Weiter Hauptkommandos =====
Bei denen von mir schon nachvollzogenen Hauptkommandos folgt immer die MADDR des Zielmoduls, die aber wie schon erwähnt nicht korrekt verarbeitet wird. 
Es gibt neben dem schon beschriebenen Hauptkommando 31 noch die folgenden Hauptkommandos:
* 00 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält OK\r\n als Antwort.
* 01 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 10 - Führt I/O Anweisungen aus, das sendende Modul erhält OK\r\n als Antwort.
* 11 - Führt I/O Anweisungen aus, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 41 - Soll AT Befehle auf entfernten Modulen setzen können (ist noch zu untersuchen).
* A1 - Soll transparent Daten an alle FRIENDS senden können (ist noch zu untersuchen).
* A2 - Soll transparent Daten an einen privaten FRIEND senden können (ist noch zu untersuchen).
===== Serielle Daten senden (00 und 01) =====
Beispiel: 41542B4D455348 00 0008 41424344 0D0A sendet für Modul MADDR 0008 'ABCD' auf die Serielle Schnittstelle
===== I/O Anweisungen (10 und 11) =====
Die I/O Anweisung wird nach dem gleichen Schema gebildet. Nach der Ziel MADDR folgt ein Unterkommando.
* AA B1 E7 [Ausgang] [Pegel] - das Kommando setzt den Ausgang (01, 02 ,...) auf den Pegel High (01) oder Low (00)
* AA B2 E7 [Ausgang] [Pegel] - sehe kein Unterschied zu AA B1 E7
* AB B1 E7 FF [Bits] - das Kommando setzt die Ausgänge Bit zugeordnet. Bit 0 -> Ausgang 1, Bit 4 -> Ausgang 5
* AB B2 E7 FF [Bits] - sehe kein Unterschied zu AB B1 E7 FF
* A1 B1 E7 [Ausgang] [beliebig] - das Kommando toggelt den Ausgang (01, 02 ,...)
* A1 B2 E7 [Ausgang] [beliebig] - sehe kein Unterschied zu A1 B1 E7
* A2 B1 E7 FF [beliebig] - (ist noch zu untersuchen)
* A2 B2 E7 FF [beliebig] - (ist noch zu untersuchen)
Beispiel: 41542B4D455348 10 0005 AAB1E7 02 01 sollte nur am Modul MADDR 0005 den Ausgang 2 auf high schalten.
==== Blockbild der Eingänge ====
[[Datei:Blockdarstellung Eingang JDY-24M .png.png|mini]]

== Quellen ==

* [https://manuals.plus/wp-content/sideloads/super-bluetooth-jdy-24m-bluetooth-module-manual-optimized.pdf Datenblatt JDY-24M]

Datei:Blockdarstellung Eingang JDY-24M .png.png

2022-01-20T16:49:02Z

Prediger:

Blockdarstellung Eingang JDY-24M

JDY-24M BLE Bluetooth Mesh I/O

2022-01-16T17:34:13Z

Prediger: Erweiterung

== Einleitung ==
Dieses Modul bietet mit mehreren der gleichen Bauform die Möglichkeit über BLE Bluetooth ein Mesh zu etablieren. Dies kann zum Beispiel für die Steuerung von Beleuchtung eingesetzt werden. Die Sicherheit bei dem System ist jedoch ähnlich derer von konventionellen Funkschaltern, da zur Identifikation nur ein 16 Bit Wert zur Verfügung steht. Also die Haustür würde ich nicht durch solch ein Modul direkt öffnen lassen. Es bietet aber die Möglichkeit via serieller Schnittstelle noch einen Microcontroller an zu schalten, der dann Sicherheitskritische Dinge steuern könnte.

== Eigenschaften ==
* Versorgungsspannung 1,9 - 3,6V
* Stromaufnahme je nach Betriebsart 3μA bis 4mA
* 5 Eingänge pulled up für Taster (15kΩ gegen Masse bei Ub = 3,3V reichen zum Auslösen)
* 5 Ausgänge (High 10mA, Low 14mA jeweils bei 0,3V Drop und Ub = 3,3V)
* Serielle Schnittstelle mit RS232 Logik.
* Als Hostmodul verwendbar
* 65280 Adressen in einem Netzwerk adressierbar

== Hardware ==

=== Modulbelegung ===
[[Datei:Belegung JDY-24M.png|mini|alternativtext=Belegung JDY-24M|Darstellung gemäß Datenblatt in der Anlage]]
Bei der mir vorliegenden Version 1.71 ist INPUT1[10] und INPUT2[8] vertauscht. Ich kann aber nicht sagen ob das bei anderen Versionen auch der Fall ist.
Die Anschlüsse sind bis auf STAT, ALED und PWRC selbsterklärend. Diese 3 Anschlüsse sind auch in der Betriebsart MESH kaum von Relevanz.
* STAT zeigt mit einem HIGH an, dass das Modul in irgendeiner Form connected ist.
* ALED ist nur im den anderen Betriebsarten relevant. Pulst HIGH wenn er auf Verbindung wartet, ist Dauer-HIGH wenn verbunden.
* PWRC weckt das Modul aus dem Schlafmodus und kann die Module in den Lernmodus versetzen.

=== Serielle Schnittstelle ===
Von der Logik her ist es eine RS232 Schnittstelle, die in Grundeinstellung auf 9600 Baud eingestellt ist. Mit 8 Bit Datenlänge, keine Parität und ein Stopbit. Es gibt somit viele USB zu Seriell Module und Chips die zum Verbinden des JDY-24M mit einem PC oder Server geeignet sind. Es ist lediglich sicherzustellen, dass die Signalpegel innerhalb der Versorgungsspannung des JDY-24M liegen.

=== Bluetooth Schnittstelle ===
Das Modul kann auch sehr weitreichend über BLE Bluetooth konfiguriert und gesteuert werden. Leider ist mir aber keine Software für Smartphons bekannt mit der das komfortabel und vollumfänglich möglich ist. Da dies aber möglich ist muss man unbedingt den Passwortschutz für diese Schnittstelle aktivieren. Mit der APP "nRF Connect for Mobile" lässt sich z.B. ein Smartphons mit den Modulen verbinden und die ein oder andere Funktion auch auslösen.

== Firmware ==
Das Modul lag mir in der Version 1.71 vor. In der Dokumentation nicht beschriebene Verhalten stammen aus dieser Version.

=== AT Befehle ===
Der AT Befehlssatz ist sehr logisch aufgebaut und es gibt nur wenige Ausnahmen die gegen eine einheitliche Linie gehen.
Alle Befehle beginnen mit der Zeichenfolge AT+
* Ausnahme der AT Befehl selbst der zum Testen der Schnittstelle verwendet werden kann.
Dem + folgt immer der eigentliche Befehl. In den weiteren Beschreibungen wird auch nur noch der Befehl genannt.
Dem Befehl können ohne Trennzeichen angehängt, ein oder mehrere Parameter folgen, die Parameter werden durch Kommas getrennt.
* Ausnahme der Befehl MESH, hier werden Binärdaten als Parameter übertragen.
Je nach Befehl und Anzahl der Parameter erkennt dass Modul ob es sich um eine Parameterabfrage oder ein Setzen von dessen Parametern handelt. 
Jeder AT Befehl muss mit \r\n (x0D,x0A) beendet werden. 
Einige Befehle geben keine Antwort zurück. 
Einige Antworten mit einem OK\r\n bei manchen kann das \n fehlen. Das +OK\r\n wie im Datenblatt angegeben kam mir in der Version 1.71 nicht unter. 
Bei einer Abfrage von Parametern folgt als Antwort das + mit dem Befehl, darauf ein = und dann die Parameterliste wie beim setzen.
Beispiele kommen im folgendem Abschnitt. 
Weitere Besonderheiten weden bei den Befehlen beschrieben.

=== Allgemeine AT Befehle ===
Die Abfolge entspricht etwa der, in der man die Einstellungen vornehmen sollte.
==== BAUD ====
Liest und setzt die Übertragungsgeschwindigkeit der seriellen Schnittstelle.
* AT+BAUD\r\n sendet +BAUD=4\r\n (Die 4 ist der Index für 9600 BAUD).
* AT+BAUD5\r\n sendet OK\r\n stellt die Schnittstelle auf 19200 BAUD ein (Der Wert mit dem ich arbeite).
==== RESET ====
Wird bei einigen Einstellungen wie z.B. bei BAUD benötigt, damit sie wirksam werden.
* AT+RESET\r\n sendet OK\r\n nach einem Moment folgt noch eine RESTART Meldung +JDY-24-START\r\n.
==== NAME ====
Mit NAME kann der Modulname verwaltete werden.
* AT+NAME\r\n sendet z.B. +NAME=JDY-24M\r\n
* AT+NAMEJDY-24M Flur\r\n sendet +NAME=JDY-24M Flur\r\nOK\r\n setzt den Name auf JDY-24M Flur. Hier die Besonderheit, dass der zu setzende Wert sofort ausgegeben wird.

=== Allgemeine AT Befehle verkürzte Dokumentation ===
Es entfällt in der Beschreibung nun das immer voran gestellte AT+ und das folgende \r\n bei den Antworten entfällt das voran gestellte +. Diese Zeichen sind zu ergänze bzw. werden vom Modul trotzdem gesendet.
==== VERSION ====
Mit VERSION liest man die Softwareversion des Moduls.
* VERSION liest z.B. VERSION=JDY-24M-V1.71
==== LADDR ====
Gibt es nur lesend und ermittelt die 12 Digit lange MAC-Adresse des Moduls.
* LADDR liest z.B. LADDR=11892007AC3E
==== ROLE ====
Mit ROLE wird die Betriebsart des Moduls gewählt.
* ROLE liest z.B. ROLE=5 (steht für die MESH Betriebsart).
* ROLE8 setzt die Näherungsdetektions Betriebsart.
==== PIN ====
Mit PIN wird eine 4 Digit Dec Wert als Pin gesetzt oder gelesen. Bei Version 1.71 ist sie 6 Digit lang. 
Die PIN wird bei einer Bluetooth Smartphoneverbindung verwendet, aber auch in der Master-Slave Betriebsart
* PIN liest z.B. PIN=123456
* PIN654321 setzt die PIN auf 654321
==== TYPE ====
Mit TYPE wird die PIN aktiviert bei 0 ist sie nicht aktiv
* TYPE liest z.B. TYPE=1 (PIN ist Aktive und wird nicht auf dem Smartphone gespeichert).
* TYPE2 setzt den Wert 2 es wird nach der PIN-Eingabe ein Automatischer reconnect ermöglicht.
==== CUIO ====
Mit CUIO kann man den logischen Zustand der Ausgänge des lokalen Moduls lesen und setzen.
* CUIO liest CUIO=0,1,0,0,1, (bedeutet OUTPUT 1-LOW 2-HIGH 3-LOW 4-LOW 5-HIGH).
* CUIO3,0 setzt den OUTPUT3 auf LOW
* CUIO2,1 setzt den OUTPUT2 auf HIGH
==== DEFAULT ====
Mit DEFAULT wird das Modul mit einem folgenden RESET wieder in die Werkseinstellungen zurück gesetzt.
* DEFAULT liest OK

== Betriebsarten ==
Das Modul kann ab der Softwareversion 1.6 in 8 verschiedenen Betriebsarten verwendet werden.

=== MESH network ===
Diese Betriebsart ist bei den Modulen vor eingestellt. Sie kann mit ROLE abgefragt oder gesetzt werden. Der Wert dafür ist 5.
Für den MESH betrieb müssen NETID und MADDR wie gewünscht eingestellt werden. Bitte nicht vergessen spätestens im Wirkbetrieb auch PIN zu setzen und mit TYPE zu aktivieren, damit nicht mit einem beliebigen Smartphone in das Netz eingedrungen werden kann. 
Es folgen weiter AT Befehle die für den MESH Betrieb benötigt werden. Nach dem Setzen der Werte sollte ein RESET gesendet werden. Ich kann im Moment noch nicht genau sagen welche Befehle den RESET brauchen und welche nicht.
==== NETID ====
Die NETID muss bei alle Module einer MESH den gleichen Wert haben, sie wird als 4 Digit Hex erwartet.
* NETID liest z.B. NETID=A3CF
* NETIDB74D setzt sie auf B74D
==== MADDR ====
Die 4 Digit lange Moduladresse darf innerhalb eines MESH nur einmal vorkommen. Sie kann damit gelesen und gesetzt werden.
* MADDR liest z.B. MADDR=AC3E
* MADDR3EF2 setzt sie auf 3EF2
==== MCLSS ====
Mit MCLSS legt man fest ob das Modul als Router im Netz agieren soll. Alle Module an denen ein Ausgang vom Server, oder einem anderen Modul gesteuert werden soll müssen in diesem Modus sein. Der Stromverbrauch liegt dann bei ca. 4mA.
* MCLSS liest z.B. MCLSS=0 (Das Modul ist im Router Betrieb).
* MCLSS1 setzt den Terminal Betrieb. Das Modul ist im Energiesparmodus. Die Eingänge können Daten auf den BLEBus senden und die lokalen Ausgänge setzen. Der BLEBus kann aber das Modul von sich aus nicht ansprechen.
==== KEY ====
Mit KEY stellt man ein, welcher Eingang des Moduls zu welchen Ausgang zugeordnet wird. Der gewählte Ausgang bezieht sich sowohl auf den lokalen Ausgang (abhängig von SUBTYPE) als auch auf einen eventuellen Ausgang eines anderen Moduls des MESH. Des weiteren gibt man eine Zielmoduladresse an. Je nach Einstellung des LEARN Modi wird diese anders berücksichtigt. Davon ebenfalls abhängig ist die Möglichkeit zu bestimmen, dass eine Aktion am Eingang auch auf der Seriellen Schnittstelle des adressierten Moduls ausgegeben wird.
*KEY1 liest z.B. KEY=1,BA1E,2,1 (Eine Signal am Eingang 1 sendet mit der Zielmoduladresse BA1E für den Ausgang 2 einen Zustand, der ggf. auch auf dem Seriellen Port ausgegeben wird.
*KEY2,BA32,4,0 setzt für den Eingang 2 eine Zuordnung zum Ausgang 4, und ggf. das Zielmodul BA32 ohne serielle Ausgabe.
==== SUBTYPE ====
Mit SUBTYPE koppelt man die lokalen Eingänge mit den lokalen Ausgängen entsprechend der Zuordnung die mit KEY gesetzt wurde.
*SUBTYPE liest z.B. SUBTYPE=0 (Signale an den Eingängen beeinflussen nicht die lokalen Ausgänge).
*SUBTYPE1 koppelt unter der Vorgabe aus KEY die Eingänge mit den Ausgängen.
==== LEARN ====
Mit LEARN stellt man im Prinzipe von Sender gesteuerten Ausgängen auf Empfänger gesteuerte Ausgänge um. Beim Sender wirkt sich das lediglich so aus, dass die Kommandosequenze, die in das MESH gesendet wird, sich ändert. Im ausgeschalteten Modus ist sie AAB2E7 und im eingeschalteten Modus AAB2D7. Dazu später mehr.
*LEARN leist z.B. 0 (Beim Emfänger: Er schaut ob ein Kommando AAB2E7 auf den Bus ist, prüft dann ob dies seine Adresse hat und stellt den Ausgang entsprechend ein. Sender gesteuert)
*LEARN1 setzt dem Empfänger gesteuerten Modus. Die Zielmoduladresse wird hier ignoriert, es wird nur geschaut, ob das Kommando AAB2D7 vom entsprechenden Modul kommt, wenn ja, wird der zugeordnete Ausgang entsprechend gesetzt. Diese Zuordnungen erfolgen mit LEAVAL.
==== LEAVAL ====
Mit LEAVAL setzt man die Zuordnung der Kommandos AAB2D7 im Empfängermodul. Die mit LEAVAL angelegte Tabelle ist nur wirksam, wenn LEARN auf 1 gesetzt ist. LEAVAL kann entgegen dem Datenblatt nicht gelesen werden!
*LEAVAL2,4,BA07 bewirkt im Empfänger, dass ein Ereignis mit dem Kommando AAB2D7 am Eingang 4 vom Sendermodul BA07, an den Ausgang 2 des Empfängermodul einstellt. Ausgänge können leider nicht mehrfach zugeordnet werden.
=== MESH Datenaustausch ===
In der MESH Betriebsart geben die Module Daten auf den MESH Bus. Dies kann geschehen durch den Wechsel eines Eingangs von High nach Low, durch senden eines MESH Befehls und durch die Antwortreaktion auf einen MESH Befehl. Zu erst betrachten wir uns das Format einer Modul Antwort.
==== Antwort von einem Modul im MESH ====
Die Antworten eines Moduls sind reine Binärdaten, sie kommen je nach Einstellung der Module auf den Seriellen Schnittstellen an.
Da die Binärdaten immer Byteorientiert sind, werden sie hier Hexadezimal beschrieben. 
Grundsätzlich immer vorhanden ist: 
[erster Befehlscode, 2 Bytes][Anzahl der noch folgenden Bytes, 1 Byte ][MADDR des Senders, 2 Bytes]
==== Antwort auf Abfrage ====
Antworten auf Abfrage besitzen kein Zieladressfeld. Die Folgenden Antworten mit dem folgenden ersten Befehlscode können auftreten
*F0 00 - Sendet den Status der Ausgänge
** F000 07 0008 01 00 01 00 00 - Am Modul MADDR 0008 ist der Ausgang 1 und 3 High
*F0 01 - Sendet den Status der Eingänge
** F001 07 0005 01 01 01 01 01 - Am Modul MADDR 0005 sind alle Eingänge offen (01 wegen internem Pull up)
*F0 02 - Sendet die MADDR (Ein wenig Sinnfrei ?!?)
** F002 04 0008 00 08 - Am Modul MADDR 0008 ist die MADDR 0008, welch Überraschung ;-)
*F0 03 - Sendet die NETID
** F003 04 0005 AB BA - Am Modul MADDR 0005 ist die NETID ABBA, auch nur wenig überraschend
*F0 04 - Sendet die PIN
** F004 06 0008 7B 04 05 06 - Am Modul MADDR 0008 ist die PIN codiert 7B040506. Die Codierung ist mir noch nicht klar
*F0 05 - Sendet den TYPE zur PIN
** F005 03 0008 00 - Am Modul MADDR 0008 ist der TYPE gleich null siehe AT Befehl TYPE
*F0 06 - Soll den Tasten Status senden (Bedeutung noch unklar)
** F006 07 0005 00 00 00 00 00 - Satus am Modul MADDR 0005 (bedarf noch Tests wann nicht 5 x 00)
*F0 07 - Sendet die MCLSS Einstellung
** F007 03 0008 00 - Am Modul MADDR 0008 ist MCLSS mit null gesetzt siehe AT Befehl MCLSS
*F0 08 - Sendet den eingestellten FRIEND (Mir noch unklar siehe Datenblatt)
** F008 08 0005 00 00 00 00 00 00 - Am Modul MADDR 0005 ist kein FRIEND gesetzt
*F0 09 - Sendet den FRTYPE
** F009 03 0005 00 - Am Modul MADDR 0005 ist der FRTYPE null siehe Datenblatt FRTYPE
==== Sonstige Antworten ====
Bei allen anderen Antworten wird die Antwort immer noch um die MADDR des Zielmoduls erweitert hier ist auch ein FFFF als Broadcast möglich. Bei den Antworten auf Grund einer Eingangsauslösung ist zu beachten, dass hier nicht die Nummer des Eingangs übergeben wird, sondern die Nummer die dem Eingang als zugehöriger Ausgang in KEY zugewiesen wurde. Dies hat auch in LEARN 1 seine Wirkung. Es ist also sehr gut zu überlegen, ob man hier von der vor eingestellten 1:1 Zuordnung abweichen möchte.
* F1 DD - Daten aus einer Übertragung von einer Seriellen Schnittstelle
** F1DD 08 0001 0008 41 42 43 44 - Modul MADDR 0001 sendet Daten 41424344 an Modul MADDR 0008, die Daten können an jeder Seriellen Schnittstelle sichtbar sein.
* F2 E7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 0 gesetzt ist.
** F2E7 09 0005 FFFF AAB2E7 02 01 - F2E7 und AAB2E7 kennzeichnen den Antworttyp. Gesendet wird vom Modul MADDR 0005 für alle Module (FFFF). Unabhängig von LEARN würden alle Module ihren Ausgang 02 auf 01 setzen. Abhängig von der Einstellung in KEY erscheint die Sequenz auch auf der Seriellen Schnittstelle der Module. Ebenso bestimmt auch KEY die Zielmoduladresse und den Ausgang.
* F2 D7 - Sendet den digitalen Status des ausgelösten Eingangs wenn LEARN 1 gesetzt ist.
** F2D7 09 0005 FFFF AAB2D7 02 01 - F2D7 und AAB2D7 kennzeichnen den Antworttyp. Gesendet wird an alle Module des MESH, die Ziel MADDR ist hier ohne Bedeutung, ihr Wert wird aber weiter von KEY abgeleitet, eben so die "Ausgangzuordnung" die aber hier trotzdem als Eingang interpretiert wird. Hier kann es schnell Caos geben, wenn man von der 1:1 Zuordnung abweicht. Die Sequenz kommt immer an allen anderen Seriellen Schnittstellen an. Mit LEAVAL wird hier eingestellt ob ein Ausgang auf diese Antwort reagiert.
==== Befehle mit MESH senden ====
Mit dem AT Befehl MESH lassen sich Kommandos in das Mesh senden. Die Kommandos sind identisch mit den Kommandos die auch über Bluetooth in das Mesh über die Service UUID FFE3 gesendet werden können. Dazu muss die Bytefolge lediglich zwischen AT+MESH und \r\n auf der Seriellen Schnittstelle eingeschlossen werden. Da ja Binärdaten übertragen werden müssen wandelt man einfach AT+MESH in 41 54 2B 4D 45 53 48 um und \r\n in 0D 0A. So kann alles Hexadezimal übergeben werden. 
===== Beispiel: Das Hauptkommando 31 =====
Beispiel: 41542B4D455348 31 0008 F0B100 0D0A würde vom Modul MADDR 0008 den Status der Ausgänge anfordern. 
Hier sind wir auch schon bei einem Problem angekommen. Der Teil 31 0008 beschreib mit 31 eins der möglichen Hauptkommando und 0008 die MADDR des anzufragenden Moduls. Bei meinem Netzwerk wird die vorgegebene MADDR mehr oder weniger ignoriert und es fühlen sich alle Module angesprochen. Das ist bei reinen Abfragen noch händelbar, da die Antworten, siehe oben, alle ihre MADDR mit senden und sie so auch wieder zugeordnet werden können. Bei den Kommandos die aber Ausgänge schalten sollen ist das aber sehr doof. 
Bleiben wir bei dem Kommando, das Unterkommando ist hier F0B100 die zugehörige Antwort ist die zuvor beschriebene F000. Die Anfragen zu den gewünschten Antworten können schematisch gebildet werden. FnB10n fordert F00n an. Das heißt F7B107 fordert F007 an, also die Einstellung vom MCLSS. Noch mal in voller Länge: 41542B4D455348 31 0008 F7B107 0D0A. Damit ist schon alles zum Hauptkommando 31 gesagt.
===== Weiter Hauptkommandos =====
Bei denen von mir schon nachvollzogenen Hauptkommandos folgt immer die MADDR des Zielmoduls, die aber wie schon erwähnt nicht korrekt verarbeitet wird. 
Es gibt neben dem schon beschriebenen Hauptkommando 31 noch die folgenden Hauptkommandos:
* 00 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält OK\r\n als Antwort.
* 01 - Sendet Daten an die Seriellen Schnittstellen im Netz, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 10 - Führt I/O Anweisungen aus, das sendende Modul erhält OK\r\n als Antwort.
* 11 - Führt I/O Anweisungen aus, das sendende Modul erhält +ACK=OK\r\n als Antwort.
* 41 - Soll AT Befehle auf entfernten Modulen setzen können (ist noch zu untersuchen).
* A1 - Soll transparent Daten an alle FRIENDS senden können (ist noch zu untersuchen).
* A2 - Soll transparent Daten an einen privaten FRIEND senden können (ist noch zu untersuchen).
===== Serielle Daten senden (00 und 01) =====
Beispiel: 41542B4D455348 00 0008 41424344 0D0A sendet für Modul MADDR 0008 'ABCD' auf die Serielle Schnittstelle
===== I/O Anweisungen (10 und 11) =====
Die I/O Anweisung wird nach dem gleichen Schema gebildet. Nach der Ziel MADDR folgt ein Unterkommando.
* AA B1 E7 [Ausgang] [Pegel] - das Kommando setzt den Ausgang (01, 02 ,...) auf den Pegel High (01) oder Low (00)
* AA B2 E7 [Ausgang] [Pegel] - sehe kein Unterschied zu AA B1 E7
* AB B1 E7 FF [Bits] - das Kommando setzt die Ausgänge Bit zugeordnet. Bit 0 -> Ausgang 1, Bit 4 -> Ausgang 5
* AB B2 E7 FF [Bits] - sehe kein Unterschied zu AB B1 E7 FF
* A1 B1 E7 [Ausgang] [beliebig] - das Kommando toggelt den Ausgang (01, 02 ,...)
* A1 B2 E7 [Ausgang] [beliebig] - sehe kein Unterschied zu A1 B1 E7
* A2 B1 E7 FF [beliebig] - (ist noch zu untersuchen)
* A2 B2 E7 FF [beliebig] - (ist noch zu untersuchen)
Beispiel: 41542B4D455348 10 0005 AAB1E7 02 01 sollte nur am Modul MADDR 0005 den Ausgang 2 auf high schalten.
==== Blockbild der Eingänge ====
!!! Das Bild muss überarbeitet werden. !!!
[[Datei:Blockdarstellung Eingang JDY-24M .png|mini|alternativtext=Blockdarstellung eines Tastereingangs|Blockdarstellung eines Tastereingangs]]

== Quellen ==

* [https://manuals.plus/wp-content/sideloads/super-bluetooth-jdy-24m-bluetooth-module-manual-optimized.pdf Datenblatt JDY-24M]

JDY-24M BLE Bluetooth Mesh I/O

2022-01-16T12:22:26Z

Prediger: Erweiterung

JDY-24M BLE Bluetooth Mesh I/O

2022-01-11T09:32:17Z

Prediger: Korrekturen

JDY-24M BLE Bluetooth Mesh I/O

2022-01-02T21:40:07Z

Prediger: Kleinere Korrekturen

JDY-24M BLE Bluetooth Mesh I/O

2022-01-02T15:48:20Z

Prediger:

Datei:Blockdarstellung Eingang JDY-24M .png

2022-01-02T14:30:37Z

Prediger:

JDY-24M Blockdarstellung Eingang

JDY-24M BLE Bluetooth Mesh I/O

2021-12-24T12:45:59Z

Prediger: Erweiterung

JDY-24M BLE Bluetooth Mesh I/O

2021-12-24T10:36:55Z

Prediger: Erweiterungen

JDY-24M BLE Bluetooth Mesh I/O

2021-12-23T22:06:07Z

Prediger: Erweiterung

JDY-24M BLE Bluetooth Mesh I/O

2021-12-23T16:44:07Z

Prediger: Weiterführung

Datei:Belegung JDY-24M.png

2021-12-23T16:12:40Z

Prediger:

Belegung JDY-24M

JDY-24M BLE Bluetooth Mesh I/O

2021-12-23T10:09:49Z

Prediger:

Dieses Modul bietet mit mehreren der gleichen Bauform die Möglichkeit über BLE Bluetooth ein Mesh zu etablieren. Dies kann zum Beispiel für die Steuerung von Beleuchtung eingesetzt werden. Die Sicherheit bei dem System ist jedoch ähnlich derer von konventionellen Funkschaltern, da zur Identifikation nur ein 16 Bit Wert zur Verfügung steht. Also die Haustür würde ich nicht durch solch ein Modul direkt öffnen lassen. Es bietet aber die Möglichkeit via serieller Schnittstelle noch einen Microcontroller an zu schalten, der dann Sicherheitskritische Dinge steuern könnte.

Eigenschaften:
* 5 Eingänge pulled up für Taster (15kOhm gegen Masse bei Ub = 3,3V reichen zum Auslösen)
* 5 Ausgänge (High 10mA, Low 14mA jeweils bei 0,3V Drop und Ub = 3,3V)
* Serielle Schnittstelle mit RS232 Logik.
* Als Hostmodul verwendbar
* Über 50000 Adressen in einem Netzwerk adressierbar

Weiteres folgt ....

JDY-24M BLE Bluetooth Mesh I/O

2021-12-23T10:07:22Z

Prediger: JDY-24M BLE Bluetooth Mesh I/O mit 5 I/O und serieller Schnittstelle

Dieses Modul bietet mit mehreren der gleichen Bauform die Möglichkeit über BLE Bluetooth ein Mesh zu etablieren. Die kann zum Beispiel für die Steuerung von Beleuchtung eingesetzt werden. Die Sicherheit bei dem System ist jedoch ähnlich derer von konventionellen Funkschaltern, da zur Identifikation nur ein 16 Bit wert zur Verfügung steht. Also die Haustür würde ich nicht durch solch ein Modul direkt öffnen lassen. Es bietet aber die Möglichkeit via RS232 noch einen Microcontroller an zu schalten, der dann Sicherheitskritische Dinge steuern könnte.

Eigenschaften:
* 5 Eingänge pulled up für Taster (15kOhm gegen Masse bei Ub = 3,3V reichen zum Auslösen)
* 5 Ausgänge (High 10mA, Low 14mA jeweils bei 0,3V Drop und Ub = 3,3V)
* Serielle Schnittstelle mit RS232 Logik.
* Als Hostmodul verwendbar
* Über 50000 Adressen in einem Netzwerk adressierbar

Weiteres folgt ....

Übersicht Funkmodule

2017-06-06T15:33:18Z

Prediger: Erweiterung

Hier eine kleine Übersicht über die vorhanden Funkmodule. in Arbeit !!!

== Übersicht ==

=== Module ===

{| class="wikitable"
|-
! !! [[RFM12|RFM12B]] !! [[RFM69|RFM69(H)(C)W]] !! [[NRF24L01_Tutorial|nRF24L01+]] !! [[ESP8266]] !! EMW3162
|-
| aktiv (Stand: Feb 2017)|| ja || ja || ja || ja || ja
|-
| Frequenz || 433, 868 Mhz || 315, 433, 868, 915 Mhz || 2,4 Ghz || colspan="2" style="text-align:center" | 2,4 Ghz (WLAN 802.11b/g/n)
|-
| Vcc || 2,2 - 3,8 V || 1,8 - 3,6 V || 1,9 - 3,6 V || 3,3 V || 3,3V
|-
| Max. Datenrate || 115,2 kbit/s || 300 kbit/s || 2 Mbit/s || 4,5-7 Mbit/s <ref>http://www.mikrocontroller.net/articles/ESP8266#Datendurchsatz.2FPerformanz</ref> <ref>http://www.mikrocontroller.net/topic/342240?page=single#3857630</ref> || bis 20 Mbit/s<ref>http://www.seeedstudio.com/depot/EMW3162-WiFi-Module-p-2122.html</ref>
|-
| Min. Datenrate || 1,2 kbit/s || 1,2 kbit/s || 0,25 Mbit/s || colspan="2" style="text-align:center" | ? Mbit/s
|-
| Stromaufnahme (TX/RX/Sleep) || 22 mA/11 mA/0,3 µA || 45 mA/16 mA/0,1 µA 130 mA/16 mA/0,1 µA (HCW) || 11,3 mA/13,3 mA/0,9 µA 115 mA/13,3 mA/0,9 µA (PA) || 215 mA/60 mA/0,9 µA || 24mA (20kbit/s), 320mA (max) / 52-59mA / 7mA (connected), 200 µA (sleep), 2µA (off)
|-
| Sendeleistung || +5 dBm || +13 dBm (~20 mW !) +20 dBm (HCW) || 0 dBm +20 dBm (mit PA) || +15 dBm (802.11g/n) +18,5 dBm (802.11b) || +14,5 dBm (802.11n) +15,5 dBm (802.11g) +18,5 dBm (802.11b)
|-
| Empfindlichkeit || -105 dBm || -120 dBm || -94 dBm || -98 dBm (802.11b) -93 dBm (802.11g) || -96 dBm (802.11b) -90 dBm (802.11g) -89 dBm (802.11n)
|-
| Reichweite || + || ++ || - || - || -
|-
| Paketmanagement || keines || Prüfsumme, Adresse, Verschlüsslung || Prüfsumme, Adresse, Retransmit || IPv4 (TCP und UDP) || IPv4 und IPv6 (TCP und UDP)
|-
| Verschlüsselung || - || ○ (AES, nur ECB <ref>https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode</ref> ) || - || colspan="2" style="text-align:center" | + (WLAN Verschlüsslung)
|-
| FIFO Size || 16 Bit || 66 Bytes || 3 separate 32 bytes TX and RX FIFOs || ? || ?
|-
| Support im Forum || ++ || ○ || ++ || + || ○
|-
| einfache Lib (Prüfsumme, Sender, Retransmit) || ? || ja, siehe Links || ja, siehe Links || Firmware buggy (01.2015) || WICED, UART Firmware
|-
|Preis (02.2017) || 2-4 € || 2-4 € || 0,7-2 € || 1-2 € || 8-10€
|-
|Verfügbarkeit (02.2017) || ++ || + || ++ || ++ || +
|-
|Bezugsquellen (02.2017) || [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=RFM12B Pollin], ebay, Ali || [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=RFM69 Pollin], Ali, ebay || ebay, Ali || ebay, Ali, [http://www.amazon.de/s/url=search-alias%3Daps&field-keywords=esp8266ex Amazon] || Ali, [http://www.seeedstudio.com/depot/EMW3162-WiFi-Module-p-2122.html Seedstudio]
|-
|Tauglichkeit SmartHome || + || ++ || ○ || ○ || ○
|-
|}

=== Frequenzen ===

siehe auch [[Allgemeinzuteilung]]

{| class="wikitable"
|-
! !! 433 Mhz !! 868 Mhz !! 2400 Mhz (2,4 Ghz)
|-
| Sendeleistung || 10 mW ERP || 10-500 mW ERP|| 10 mW ERP 100 mW EIRP
|-
| Duty Cycle || keinen || 0,1-10 % || keinen
|-
| Reichweite || ++ || + || -
|-
| Störung durch andere || + || ○ || ++
|-
|}

== Details zu den Modulen ==

=== RFM12B ===

Die RFM12(B) sind wohl die Urgesteine der drahtlosen Kommunikation: Tausendfach erprobt!

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]
* [[RF_SOAP]]
* [[Pollin_Funk-AVR-Evaluationsboard]]
* [http://www.mikrocontroller-elektronik.de/funkmodul-programmierung-rfm12b-rn-mikrofunk/ RN-MikroFunk AVR Miniatur Evaluationsboard und Tutorial]

=== RFM69 ===

Der RFM69 ist der Nachfolger des RFM12B. Er untersützt mehr Frequenzen und hat eine leicht höhere Sendeleistung. Die größten Neuerungen sind die integrierte AES-Verschlüsselung sowie das eingebaute Paketmanagement, das sich um Prüfsummen, Adressen kümmert.

Es gibt folgende Module:
* RFM69HCW, mit zusätzlicher PA, (+20 dBm TX)
* RFM69HW, mit zusätzlicher PA, (+20 dBm TX)
* RFM69CW, Pinkompatibel zum RFM12B
* RFM69W

Links:
* [https://github.com/LowPowerLab/RFM69 RFM69 Lib zur Ansteuerung mit Arduino]
* [http://www.airspayce.com/mikem/arduino/RadioHead/index.html RadioHead Lib zum Aufbau eines MESH-Netzwerkes]
* [http://www.mikrocontroller.net/topic/332579 Thread im Forum: Wer verwendet RFM69]

=== nRF24L01+ ===

Die wohl billigsten Funkmodule. Funken im 2,4 Ghz Band und haben alles in Hardware integriert für eine einfache Kommunikation. Gibt es schon länger am Markt, daher gibt es schon viele erprobte Bibliotheken für die Ansteuerung vom Arduino, RaspberryPi, ...

Achtung! Nicht mit nRF24L01 (ohne Plus) verwechseln. Diese Module werden nicht mehr hergestellt und sind veraltet!

* [http://tmrh20.github.io/RF24/ Bibliothek für die Ansteuerung über Arduino, RaspberryPi, Intel Galileo...]
* [http://tmrh20.github.io/RF24Network/ Bibliothek für eine ZigBee ähnliche Kommunikation (Mesh Nettwerk)]

=== SE8R01 ===

Wird bei AliExpress und E-Bay auch als simular nRF24L01+ angeboten. Er kostet die Hälfte vom nRF24L01+ und hat eine sehr kleine Bauform. Er ist NICHT kompatibel zum nRF24L01+ weder auf dem Funkkanal noch im Umgang mit den Konfigurationsregistern.
Die bislang brauchbarsten Informationen zu den Chip gab es unter [https://forum.arduino.cc/index.php?topic=366294.0 Finally Working code for se8r01(similar nrf24l01) 2mps, 1mps and 500kps]
Es scheint eine Datasheet V2.1 zu geben, ich habe es aber noch nirgends downloaden können.

[[Benutzer:Prediger|Prediger]] ([[Benutzer Diskussion:Prediger|Diskussion]])

=== nRF52 ===
Die [https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF52832#Overview nRF52 SoCs] können für Bluetooth und für Übertragungen auf Basis des proprietären 2.4 GHZ-Nordic-Protokolls (kompatibel zu nRF24) genutzt werden. Für Bluetooth 4.1-Übertragungen steht ein Software Stack ([https://www.nordicsemi.com/eng/nordic/download_resource/33863/4/14045603 Nordic Softdevice 130, specification 0.5]) zur Verfügung.
Das proprietäre 2.4 GHZ-Nordic-Protokoll unterstützt das Übertragen von Packages mit Addressierung, CRC sowie dem ACK und RESEND von Packages.
Die nRF52-SoCs besitzen einen Cortex M4F, 64kB RAM, 512kB integrierten Flash-Speicher, einen NFC-Tag sowie vielfältige weitere Peripherie. Der Cortex ist zur Nutzung für Anwenderprogramme vorgesehen. SDKs, auch für gcc, werden angeboten. Die Bausteine wurden auf die Verwendung mit 2-Lagen-PCBs hin optimiert und werden auch im QFN48 package verfügbar sein (Stand 09/2015).
Für das Empfangen beträgt der Strombedarf ca. 7mA ([http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.pdf.ps/nRF52832_OPS_v0.6.pdf Product Specification 0.6, "radio current consumption", page 224]). Dies ist relativ viel im Vergleich zu kabelgebundenen Übertragungen, entspricht jedoch lediglich 1/8 typischer WLAN-ICs (ESP8266).

=== ESP8266 ===

Das WLAN-Modul kann sowohl Client als auch AP sein. Damals hat der Release einen starken Hype ausgelöst und dementsprechend ist die Community rasant gewachsen, wodurch sich sogar ein eigenes Forum entwickelt hat ([http://www.esp8266.com www.esp8266.com]).

Das Modul kann man über AT-Kommandos steuern, es gibt ein LUA-Skript sowie MicroPython Interpreter und vieles mehr. Zudem kann den integrieten SoC auch direkt programmieren, sodass man für einfache Aufgaben (Temperatur auslesen etc.) keinen extra Mikrocontroller braucht. Für die Programmierung wird vom Hersteller eine fertig eingerichtete VM zur Verfügung gestellt, es gibt aber auch eine Port vom GCC und selbst in die Arduino Umgebung ist der ESP8266 mittlerweile eingepflegt.

* [https://docs.micropython.org/en/latest/esp8266/esp8266/tutorial/intro.html ESP8266 MicroPython]
* [http://www.nodemcu.com/index_en.html NodeMCU LUA Interpreter Website]
** [https://github.com/nodemcu/nodemcu-firmware NodeMCU Firmware]
* [https://github.com/esp8266/Arduino Arduino ESP8266]

=== EMW3162 ===

[http://hackaday.com/2015/03/24/emw3162-wifi-120mhz-needs-attention/ HackADay Eintrag]

[http://www.joinmx.com/uploadfiles/soft/EMW/DS0006E_EMW3162_V2.2.pdf Datasheet]

== Links ==
* [http://www.mikrocontroller.net/topic/354149 Thread zum Artikel (Fragen, Anregungen etc. hier posten)]
* [http://www.hoperf.com/upload/rf/RF12.pdf Datenblatt des ICs RF12] (PDF)
* [http://www.hoperf.com/upload/rf/RFM12.pdf Datenblatt des Moduls RFM12] (PDF)
* [http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf Datenblatt RFM69CW]
* [http://www.hoperf.com/upload/rf/RFM69W-V1.3.pdf Datenblatt RFM69W]
* [http://www.mikrocontroller.net/articles/NRF24L01_Tutorial kleines NRF24L01+ Tutorial in C]

== Fußnoten ==
<references/>

[[Kategorie:Bauteile]]
[[Kategorie:RFM12| ]]
[[Kategorie:Funk]]
[[Kategorie:Datenübertragung]]
[[Category:Hausbus]]

Übersicht Funkmodule

2017-06-06T14:40:34Z

Prediger: Korrektur

Hier eine kleine Übersicht über die vorhanden Funkmodule. in Arbeit !!!

== Übersicht ==

=== Module ===

{| class="wikitable"
|-
! !! [[RFM12|RFM12B]] !! [[RFM69|RFM69(H)(C)W]] !! [[NRF24L01_Tutorial|nRF24L01+]] !! [[ESP8266]] !! EMW3162
|-
| aktiv (Stand: Feb 2017)|| ja || ja || ja || ja || ja
|-
| Frequenz || 433, 868 Mhz || 315, 433, 868, 915 Mhz || 2,4 Ghz || colspan="2" style="text-align:center" | 2,4 Ghz (WLAN 802.11b/g/n)
|-
| Vcc || 2,2 - 3,8 V || 1,8 - 3,6 V || 1,9 - 3,6 V || 3,3 V || 3,3V
|-
| Max. Datenrate || 115,2 kbit/s || 300 kbit/s || 2 Mbit/s || 4,5-7 Mbit/s <ref>http://www.mikrocontroller.net/articles/ESP8266#Datendurchsatz.2FPerformanz</ref> <ref>http://www.mikrocontroller.net/topic/342240?page=single#3857630</ref> || bis 20 Mbit/s<ref>http://www.seeedstudio.com/depot/EMW3162-WiFi-Module-p-2122.html</ref>
|-
| Min. Datenrate || 1,2 kbit/s || 1,2 kbit/s || 0,25 Mbit/s || colspan="2" style="text-align:center" | ? Mbit/s
|-
| Stromaufnahme (TX/RX/Sleep) || 22 mA/11 mA/0,3 µA || 45 mA/16 mA/0,1 µA 130 mA/16 mA/0,1 µA (HCW) || 11,3 mA/13,3 mA/0,9 µA 115 mA/13,3 mA/0,9 µA (PA) || 215 mA/60 mA/0,9 µA || 24mA (20kbit/s), 320mA (max) / 52-59mA / 7mA (connected), 200 µA (sleep), 2µA (off)
|-
| Sendeleistung || +5 dBm || +13 dBm (~20 mW !) +20 dBm (HCW) || 0 dBm +20 dBm (mit PA) || +15 dBm (802.11g/n) +18,5 dBm (802.11b) || +14,5 dBm (802.11n) +15,5 dBm (802.11g) +18,5 dBm (802.11b)
|-
| Empfindlichkeit || -105 dBm || -120 dBm || -94 dBm || -98 dBm (802.11b) -93 dBm (802.11g) || -96 dBm (802.11b) -90 dBm (802.11g) -89 dBm (802.11n)
|-
| Reichweite || + || ++ || - || - || -
|-
| Paketmanagement || keines || Prüfsumme, Adresse, Verschlüsslung || Prüfsumme, Adresse, Retransmit || IPv4 (TCP und UDP) || IPv4 und IPv6 (TCP und UDP)
|-
| Verschlüsselung || - || ○ (AES, nur ECB <ref>https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode</ref> ) || - || colspan="2" style="text-align:center" | + (WLAN Verschlüsslung)
|-
| FIFO Size || 16 Bit || 66 Bytes || 3 separate 32 bytes TX and RX FIFOs || ? || ?
|-
| Support im Forum || ++ || ○ || ++ || + || ○
|-
| einfache Lib (Prüfsumme, Sender, Retransmit) || ? || ja, siehe Links || ja, siehe Links || Firmware buggy (01.2015) || WICED, UART Firmware
|-
|Preis (02.2017) || 2-4 € || 2-4 € || 0,7-2 € || 1-2 € || 8-10€
|-
|Verfügbarkeit (02.2017) || ++ || + || ++ || ++ || +
|-
|Bezugsquellen (02.2017) || [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=RFM12B Pollin], ebay, Ali || [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=RFM69 Pollin], Ali, ebay || ebay, Ali || ebay, Ali, [http://www.amazon.de/s/url=search-alias%3Daps&field-keywords=esp8266ex Amazon] || Ali, [http://www.seeedstudio.com/depot/EMW3162-WiFi-Module-p-2122.html Seedstudio]
|-
|Tauglichkeit SmartHome || + || ++ || ○ || ○ || ○
|-
|}

=== Frequenzen ===

siehe auch [[Allgemeinzuteilung]]

{| class="wikitable"
|-
! !! 433 Mhz !! 868 Mhz !! 2400 Mhz (2,4 Ghz)
|-
| Sendeleistung || 10 mW ERP || 10-500 mW ERP|| 10 mW ERP 100 mW EIRP
|-
| Duty Cycle || keinen || 0,1-10 % || keinen
|-
| Reichweite || ++ || + || -
|-
| Störung durch andere || + || ○ || ++
|-
|}

== Details zu den Modulen ==

=== RFM12B ===

Die RFM12(B) sind wohl die Urgesteine der drahtlosen Kommunikation: Tausendfach erprobt!

* [[AVR RFM12]]
* [[RFM12 Protokoll Stack]]
* [[RF_SOAP]]
* [[Pollin_Funk-AVR-Evaluationsboard]]
* [http://www.mikrocontroller-elektronik.de/funkmodul-programmierung-rfm12b-rn-mikrofunk/ RN-MikroFunk AVR Miniatur Evaluationsboard und Tutorial]

=== RFM69 ===

Der RFM69 ist der Nachfolger des RFM12B. Er untersützt mehr Frequenzen und hat eine leicht höhere Sendeleistung. Die größten Neuerungen sind die integrierte AES-Verschlüsselung sowie das eingebaute Paketmanagement, das sich um Prüfsummen, Adressen kümmert.

Es gibt folgende Module:
* RFM69HCW, mit zusätzlicher PA, (+20 dBm TX)
* RFM69HW, mit zusätzlicher PA, (+20 dBm TX)
* RFM69CW, Pinkompatibel zum RFM12B
* RFM69W

Links:
* [https://github.com/LowPowerLab/RFM69 RFM69 Lib zur Ansteuerung mit Arduino]
* [http://www.airspayce.com/mikem/arduino/RadioHead/index.html RadioHead Lib zum Aufbau eines MESH-Netzwerkes]
* [http://www.mikrocontroller.net/topic/332579 Thread im Forum: Wer verwendet RFM69]

=== nRF24L01+ ===

Die wohl billigsten Funkmodule. Funken im 2,4 Ghz Band und haben alles in Hardware integriert für eine einfache Kommunikation. Gibt es schon länger am Markt, daher gibt es schon viele erprobte Bibliotheken für die Ansteuerung vom Arduino, RaspberryPi, ...

Achtung! Nicht mit nRF24L01 (ohne Plus) verwechseln. Diese Module werden nicht mehr hergestellt und sind veraltet!

* [http://tmrh20.github.io/RF24/ Bibliothek für die Ansteuerung über Arduino, RaspberryPi, Intel Galileo...]
* [http://tmrh20.github.io/RF24Network/ Bibliothek für eine ZigBee ähnliche Kommunikation (Mesh Nettwerk)]

=== nRF52 ===
Die [https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF52832#Overview nRF52 SoCs] können für Bluetooth und für Übertragungen auf Basis des proprietären 2.4 GHZ-Nordic-Protokolls (kompatibel zu nRF24) genutzt werden. Für Bluetooth 4.1-Übertragungen steht ein Software Stack ([https://www.nordicsemi.com/eng/nordic/download_resource/33863/4/14045603 Nordic Softdevice 130, specification 0.5]) zur Verfügung.
Das proprietäre 2.4 GHZ-Nordic-Protokoll unterstützt das Übertragen von Packages mit Addressierung, CRC sowie dem ACK und RESEND von Packages.
Die nRF52-SoCs besitzen einen Cortex M4F, 64kB RAM, 512kB integrierten Flash-Speicher, einen NFC-Tag sowie vielfältige weitere Peripherie. Der Cortex ist zur Nutzung für Anwenderprogramme vorgesehen. SDKs, auch für gcc, werden angeboten. Die Bausteine wurden auf die Verwendung mit 2-Lagen-PCBs hin optimiert und werden auch im QFN48 package verfügbar sein (Stand 09/2015).
Für das Empfangen beträgt der Strombedarf ca. 7mA ([http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.pdf.ps/nRF52832_OPS_v0.6.pdf Product Specification 0.6, "radio current consumption", page 224]). Dies ist relativ viel im Vergleich zu kabelgebundenen Übertragungen, entspricht jedoch lediglich 1/8 typischer WLAN-ICs (ESP8266).

=== ESP8266 ===

Das WLAN-Modul kann sowohl Client als auch AP sein. Damals hat der Release einen starken Hype ausgelöst und dementsprechend ist die Community rasant gewachsen, wodurch sich sogar ein eigenes Forum entwickelt hat ([http://www.esp8266.com www.esp8266.com]).

Das Modul kann man über AT-Kommandos steuern, es gibt ein LUA-Skript sowie MicroPython Interpreter und vieles mehr. Zudem kann den integrieten SoC auch direkt programmieren, sodass man für einfache Aufgaben (Temperatur auslesen etc.) keinen extra Mikrocontroller braucht. Für die Programmierung wird vom Hersteller eine fertig eingerichtete VM zur Verfügung gestellt, es gibt aber auch eine Port vom GCC und selbst in die Arduino Umgebung ist der ESP8266 mittlerweile eingepflegt.

* [https://docs.micropython.org/en/latest/esp8266/esp8266/tutorial/intro.html ESP8266 MicroPython]
* [http://www.nodemcu.com/index_en.html NodeMCU LUA Interpreter Website]
** [https://github.com/nodemcu/nodemcu-firmware NodeMCU Firmware]
* [https://github.com/esp8266/Arduino Arduino ESP8266]

=== EMW3162 ===

[http://hackaday.com/2015/03/24/emw3162-wifi-120mhz-needs-attention/ HackADay Eintrag]

[http://www.joinmx.com/uploadfiles/soft/EMW/DS0006E_EMW3162_V2.2.pdf Datasheet]

== Links ==
* [http://www.mikrocontroller.net/topic/354149 Thread zum Artikel (Fragen, Anregungen etc. hier posten)]
* [http://www.hoperf.com/upload/rf/RF12.pdf Datenblatt des ICs RF12] (PDF)
* [http://www.hoperf.com/upload/rf/RFM12.pdf Datenblatt des Moduls RFM12] (PDF)
* [http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf Datenblatt RFM69CW]
* [http://www.hoperf.com/upload/rf/RFM69W-V1.3.pdf Datenblatt RFM69W]
* [http://www.mikrocontroller.net/articles/NRF24L01_Tutorial kleines NRF24L01+ Tutorial in C]

== Fußnoten ==
<references/>

[[Kategorie:Bauteile]]
[[Kategorie:RFM12| ]]
[[Kategorie:Funk]]
[[Kategorie:Datenübertragung]]
[[Category:Hausbus]]