JDY-24M BLE Bluetooth Mesh Dokumentation

[Christof R. (prediger)]

Hallo Forengemeinde,
ich habe mal begonnen meine Erfahrungen mit dem JDY-24M zu 
dokumentieren.
Das Modul besitzt tatsächlich eine nicht unbrauchbare Firmware. Es ist 
für Leute interesant die nicht jedes mal Microcontroller mit Software 
beladen wollen.
Das Wiki ist noch am Anfang. Ich versuche es möglichst zügig weiter zu 
führen.

https://www.mikrocontroller.net/articles/JDY-24M_BLE_Bluetooth_Mesh_I/O

[Christof R. (prediger)]

Konnte heute ein Stück weiter schreiben.

[Christof R. (prediger)]

Hi,
Mein Testaufbau macht plötzlich Probleme. Alle Kommandos zum Schalten 
der Ausgänge von der Seriellen Schnittstelle gesendet werden trotz 
Moduladressierung wie ein Broadcast behandelt. Muss das Problem erst 
finden.

[Christof R. (prediger)]

Ich habe mittlerweile den Verkäufer kontaktiert, er hat mir weitere 
Unterlagen zur Verfügung gestellt, diese sagen aber nicht mehr aus, als 
das Datenblatt, was mir vor liegt. Also habe ich nicht mehr als die 
Aussage von ihm, dass ich wohl was falsch mache. Hiebei geht es um 
Befehle, die mit dem MESH Befehl gesendet werden. Den habe ich noch 
nicht im WIKI beschrieben. Der sieht aber im Prinziep so aus:
AT+MESH[Binärdaten]\r\n und antwortet meist mit OK\r\n
Hier geht es um die Befehle mit denen ich Ausgänge an entfernten Modulen 
ein und Ausschalten kann. Ich schreibe hier die Binärdatenfolge 
Hexadezimal auf.
Byte 2 und 3 Bilden die Moduladresse des entfernten Moduls
Byte 7 entspricht dem Ausgang
Byte 8 01:Hoher Pegel 00:Niedriger Pegel
10  00 03  aa b1 e7  02 01
Also hier soll am Modul 3 der Ausgang 2 Eingeschaltet werden.
Dummer Weise schaltet der Befehl auch den entsprechenden Ausgang am 
Modul 2 mit ein. Die Ausgänge kann man mit folgender Sequence lesen
31  00 03  f0 b1 00
Hier halt für Modul 3, aber auch hier bekomme ich nicht unbedigt nur 
Antworten vom Modul 3, kann sein, dass Modul 1 und 2 zusätzlich 
antworten.
Die Antworten sehen dann so aus, sie sind reine Binärdaten, die auf der 
Seriellen Schnittstelle ankommen.
f0 00  07  00 03  00 01 00 00 00
f0 00 zeigt an, dass die Zustände der Ausgänge übertragen werden.
07 zeigt an, dass nun 7 weitere Bytes folgen.
00 03 ist die Adresse des antwortenden Moduls.
Die letzen 5 Bytes entsprechen den Zuständen der Ausgänge 1 bis 5
Frage ich dann das Modul 2 ab so bekomme ich u.a.
f0 00  07  00 02  00 01 00 00 00
und sehe, dass auch hier der Ausgang 2 gesetzt ist, was er aber nicht 
sein darf.
Arbeitet man über zugeordnete Eingänge mit KEY oder LEAVAL so kommt es 
zu keinen Adressierungsproblemen.
Ich habe mir Mittlerweile eine Workaround ausgedacht mit dem ich über 
den Befehl CUIO einen Ausgang am Servermodul schalte, der wiederum mit 
einen Eingang verbunden wird. Denn ich dann triggere, um einen konkreten 
Ausgang eines anderen Moduls schalten zu können. Vieleich hat noch 
jemand ausser mir noch diese Module und vl. mach ich ja auch wirklich 
noch was falsch.
LG.
Christof

[Christof R. (prediger)]

Habe die Beschreibung des MESH handlings zugefügt.

[Christof R. (prediger)]

Habe den Workaround versucht in meinem Artikel zu beschreiben. Es gibt 
aber bestimmt noch andere Lösungen.

[Christof R. (prediger)]

Hier mal ein Foto der ersten Aufbauten und ein kleines Video. Dient nur 
für den ersten Eindruck. Nicht über die JSON ähnlichen Formate wundern, 
ich habe schon ein wenig Software drumherum gebastelt, die unter anderem 
den Workaround unterstützt.
https://youtu.be/Uw8xpepDV2c

[Christof R. (prediger)]

Das Schaltbild für das Client-Board

[J. S. (jojos)]

Das Modul sieht interessant aus, ich suche gerade etwas um 
Weihnachtsbeleuchtung zu steuern. Lässt sich das mit ioBroker 
(Zigbee2Mqtt) steuern?