Companion-Protokoll
- Zuletzt aktualisiert: 2026-03-08
- Protokollversion: Companion-Firmware v1.12.0+
HINWEIS: Dieses Dokument befindet sich noch in Entwicklung. Einige Informationen könnten ungenau sein.
Dieses Dokument bietet eine umfassende Anleitung zur Kommunikation mit MeshCore-Geräten über Bluetooth Low Energy (BLE).
Es ist plattformunabhängig und kann für Android, iOS, Python, JavaScript oder jede andere Plattform verwendet werden, die BLE unterstützt.
Offizielle Bibliotheken
Eine Liste der bestehenden Bibliotheken für das MeshCore Companion-Protokoll finden Sie in den folgenden Repositories.
- JavaScript: https://github.com/meshcore-dev/meshcore.js
- Python: https://github.com/meshcore-dev/meshcore_py
Wichtiger Sicherheitshinweis
Alle Geheimnisse (Secrets), Hashes und kryptografischen Werte, die in dieser Anleitung gezeigt werden, sind nur Beispielwerte.
- Alle Hex-Werte, öffentlichen Schlüssel und Hashes dienen ausschließlich Demonstrationszwecken.
- Verwenden Sie niemals Beispielgeheimnisse (Secret) in der Produktion.
- Generieren Sie immer neue kryptografisch sichere Zufallsgeheimnisse (Secret).
- Bitte implementieren Sie angemessene Sicherheitspraktiken in Ihrer Implementierung.
- Diese Anleitung dient ausschließlich der Protokolldokumentation.
Inhaltsverzeichnis
- BLE Verbindung
- Paketstruktur
- Befehle
- Kanalverwaltung
- Nachrichtenverarbeitung
- Antwort-Parsing
- Beispielimplementierungsfluss
- Best Practices
- Fehlerbehebung
BLE Verbindung
Dienst und Merkmale
MeshCore Companion-Geräte stellen einen BLE-Dienst (Bluetooth Low Energy Dienst) mit den folgenden UUIDs (Universally Unique Identifiers) bereit:
- Dienst-UUID:
6E400001-B5A3-F393-E0A9-E50E24DCCA9E - RX-Merkmal (App → Firmware):
6E400002-B5A3-F393-E0A9-E50E24DCCA9E - TX-Merkmal (Firmware → App):
6E400003-B5A3-F393-E0A9-E50E24DCCA9E
Verbindungsschritte
- Nach Geräten suchen
- Mit GATT verbinden
- Dienste und Merkmale entdecken
6E400001-B5A3-F393-E0A9-E50E24DCCA9E.
- Entdecken Sie das RX-Merkmal 6E400002-B5A3-F393-E0A9-E50E24DCCA9E.
- Ihre App schreibt darauf, die Firmware liest davon.
- Entdecken Sie das TX-Merkmal 6E400003-B5A3-F393-E0A9-E50E24DCCA9E.
- Die Firmware schreibt darauf, Ihre App liest davon.
- Benachrichtigungen aktivieren
- Erste Befehle senden
CMD_APP_START, um Ihre App bei der Firmware zu identifizieren und Funkeinstellungen zu erhalten.
- Senden Sie CMD_DEVICE_QUERY, um Geräteinformationen abzurufen und unterstützte Protokollversionen auszuhandeln.
- Senden Sie CMD_SET_DEVICE_TIME, um die Firmware-Uhrzeit einzustellen.
- Senden Sie CMD_GET_CONTACTS, um alle Kontakte abzurufen.
- Senden Sie CMD_GET_CHANNEL mehrfach, um alle Kanalslots abzurufen.
- Senden Sie CMD_SYNC_NEXT_MESSAGE, um die nächste in der Firmware gespeicherte Nachricht abzurufen.
- Richten Sie Listener für Push-Codes ein, wie z.B. PUSH_CODE_MSG_WAITING oder PUSH_CODE_ADVERT.
- Weitere Informationen zu Befehlen finden Sie im Abschnitt Befehle.
Hinweis: MeshCore-Geräte können sich nach Inaktivität trennen. Implementieren Sie eine automatische Wiederverbindungslogik mit exponentiellem Backoff (Staffelung der Wartezeit).
BLE Schreibtyp
Beim Schreiben von Befehlen an das RX-Merkmal geben Sie den Schreibtyp an:
- Schreiben mit Antwort (Standard): Wartet auf Bestätigung vom Gerät.
- Schreiben ohne Antwort: Schneller, aber ohne Bestätigung.
- Android: Verwenden Sie
BluetoothGattCharacteristic.WRITE_TYPE_DEFAULToderWRITE_TYPE_NO_RESPONSE. - iOS: Verwenden Sie
CBCharacteristicWriteType.withResponseoder.withoutResponse. - Python (bleak): Verwenden Sie
write_gatt_char()mitresponse=TrueoderFalse.
MTU (Maximale Übertragungseinheit)
Die Standard-BLE-MTU beträgt 23 Bytes (20 Bytes Nutzdaten). Für größere Befehle wie SET_CHANNEL (50 Bytes) müssen Sie möglicherweise:
- Eine größere MTU anfordern: Fordern Sie eine MTU von 512 Bytes an, falls unterstützt.
gatt.requestMtu(512)
- iOS: peripheral.maximumWriteValueLength(for:)
- Python (bleak): MTU wird automatisch ausgehandelt.
Befehlssequenzierung
Kritisch: Befehle müssen in der richtigen Reihenfolge gesendet werden:- Nach der Verbindung:
- Befehl-Antwort-Abgleich:
CMD_GET_CHANNEL → RESP_CODE_CHANNEL_INFO).
Befehlswarteschlangenverwaltung
Für einen zuverlässigen Betrieb implementieren Sie eine Befehlswarteschlange.
Warteschlangenstruktur:- Verwalten Sie eine Warteschlange mit ausstehenden Befehlen.
- Verfolgen Sie, welcher Befehl gerade auf eine Antwort wartet.
- Senden Sie den nächsten Befehl erst, nachdem eine Antwort empfangen oder ein Timeout aufgetreten ist.
- Bei einem Timeout: Löschen Sie den aktuellen Befehl, verarbeiten Sie den nächsten in der Warteschlange.
- Bei einem Fehler: Protokollieren Sie den Fehler, löschen Sie den aktuellen Befehl, verarbeiten Sie den nächsten.
Paketstruktur
Das MeshCore-Protokoll verwendet ein binäres Format mit folgender Struktur:
- Befehle: Werden von der App über das RX-Merkmal an die Firmware gesendet.
- Antworten: Werden von der Firmware über TX-Merkmal-Benachrichtigungen empfangen.
- Alle Mehrbyte-Ganzzahlen: Little-Endian-Byte-Reihenfolge (außer CayenneLPP, das Big-Endian ist).
- Alle Zeichenketten: UTF-8-Codierung.
Das erste Byte gibt den Pakettyp an (siehe Antwort-Parsing).
---
Befehle
1. App-Start
Zweck: Initialisiert die Kommunikation mit dem Gerät. Muss nach der Verbindung zuerst gesendet werden. Befehlsformat: Beispiel (hexadezimal): Antwort:PACKET_SELF_INFO (0x05)
---
2. Geräteabfrage
Zweck: Abfragen von Geräteinformationen. Befehlsformat: Beispiel (hexadezimal): Antwort:PACKET_DEVICE_INFO (0x0D) mit Geräteinformationen
---
3. Kanalinfo abrufen
Zweck: Abrufen von Informationen über einen bestimmten Kanal. Befehlsformat: Beispiel (Kanal 1 abrufen): Antwort:PACKET_CHANNEL_INFO (0x12) mit Kanaldetails
---
4. Kanal einstellen
Zweck: Erstellt oder aktualisiert einen Kanal auf dem Gerät. Befehlsformat: Gesamtlänge: 50 Bytes Kanalindex:- Index 0: Reserviert für öffentliche Kanäle (kein Geheimnis).
- Indizes 1-7: Verfügbar für private Kanäle.
- UTF-8-codiert.
- Maximal 32 Bytes.
- Mit Null-Bytes (0x00) aufgefüllt, falls kürzer.
- Für private Kanäle: 16-Byte-Geheimnis.
- Für öffentliche Kanäle: Alle Nullen (0x00).
PACKET_ERROR zurück.
Antwort: PACKET_OK (0x00) bei Erfolg, PACKET_ERROR (0x01) bei Fehler.
---
5. Kanalnachricht senden
Zweck: Sendet eine Textnachricht an einen Kanal. Befehlsformat: Zeitstempel: Unix-Zeitstempel in Sekunden (32-Bit vorzeichenlose Ganzzahl, Little-Endian). Beispiel (sendet "Hello" an Kanal 1 mit Zeitstempel 1234567890): Antwort:PACKET_MSG_SENT (0x06) bei Erfolg
---
6. Kanal-Datagramm senden
Zweck: Sendet ein binäres Datagramm an einen Kanal. Im Gegensatz zu Kanal-Textnachrichten tragen Datagramme keine integrierte Absenderidentität und keinen Zeitstempel – Anwendungen, die eines von beiden benötigen, müssen diese innerhalb der binären Nutzdaten codieren. Befehlsformat: Beispiel (Flood-Modus,DATA_TYPE_DEV, Nutzdaten A1 B2 C3, Kanal 1):
Datentyp / Transport Mapping:
0x0000(DATA_TYPE_RESERVED) ist ungültig und wird mitPACKET_ERRORabgewiesen.0xFFFF(DATA_TYPE_DEV) ist der Entwickler-Namensraum für Experimente und App-Entwicklung.- Die Werte
0x0001–0xFFFEsind für registrierte Anwendungs-/Community-Namensräume verfügbar. Siehe die Tabelle Registriertedata_type-Werte unten.
- Die maximale Nutzdatenlänge beträgt
MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 163Bytes. - Größere Nutzdaten werden mit
PACKET_ERROR(ERR_CODE_ILLEGAL_ARG) abgewiesen.
PACKET_OK (0x00) bei Erfolg, oder PACKET_ERROR (0x01) mit einem der folgenden Codes:
ERR_CODE_NOT_FOUND(2) — unbekannterchannel_idxERR_CODE_ILLEGAL_ARG(6) — ungültigepath_len, reservierterdata_type(0x0000), oder Nutzdaten größer alsMAX_CHANNEL_DATA_LENGTHERR_CODE_TABLE_FULL(3) — die Warteschlange für ausgehende Übertragungen ist voll; später erneut versuchen
RESP_CODE_CHANNEL_DATA_RECV (0x1B) zugestellt; siehe Kanal-Datagramm empfangen.
Registrierte data_type-Werte
data_type ist ein Anwendungsbezeichner, kein Nutzdatenformat-Bezeichner. Jeder registrierte Wert identifiziert eine Anwendung, die ihre eigenen internen Nutzdatenschemata besitzt. Die Firmware inspiziert den Inhalt der Nutzdaten nicht – data_type wird undurchsichtig transportiert.
| Wert | Konstante | Zweck |
|---|---|---|
| 0x0000 | DATA_TYPE_RESERVED | Reserviert; ungültig beim Senden |
| 0x0001 – 0x00FF | — | Reserviert für interne Verwendung |
| 0x0100 – 0xFEFF | — | Registrierte Anwendungs-Namensräume (siehe number_allocations.md) |
| 0xFF00 – 0xFFFE | — | Testen/Entwicklung; keine Registrierung erforderlich |
| 0xFFFF | DATA_TYPE_DEV | Entwickler-/Experimentier-Namensraum |
Um eine neue Anwendung zu registrieren, reichen Sie einen PR (Pull Request) ein, der eine Zeile zur Tabelle in docs/number_allocations.md hinzufügt. Interne Unterformate innerhalb einer zugewiesenen Anwendungs-ID gehören dieser Anwendung und werden weder in der MeshCore-Firmware noch in diesem Dokument verfolgt.
---
Kanal-Datagramm empfangen
Eingehende Gruppendatagramme (Radio-Ebene PAYLOAD_TYPE_GRP_DATA, 0x06) werden dem Host als RESP_CODE_CHANNEL_DATA_RECV-Benachrichtigungen weitergeleitet.
RESP_CODE_CHANNEL_DATA_RECV, 0x1B):
Pfad-Bytes werden nicht weitergeleitet: Nur path_len wird im Empfangsrahmen gemeldet — der Pfad selbst wird nicht zum Host kopiert. Es gibt keine Pfad-Bytes zwischen Byte 5 und dem data_type-Feld bei Byte 6–7, ungeachtet von path_len.
Die Semantik der Pfadlänge unterscheidet sich zwischen Senden und Empfangen:
| Richtung | path_len = 0xFF | path_len ≠ 0xFF |
|---|---|---|
| Senden | Überflutet das Netzwerk (Flooding) | Direkte Route; der kodierte Pfad folgt (niedrige 6 Bit = Hash-Anzahl, obere 2 Bit + 1 = Hash-Größe; On-Wire Byte-Zahl = hash_count × hash_size) |
| Empfangen | Paket kam über direkten Weg an | Paket wurde geflutet (Flooding); dies ist das kodierte pkt->path_len-Feld wie beobachtet (keine Pfad-Bytes folgen) |
Mit anderen Worten, die Bedeutung von 0xFF ist zwischen den beiden Richtungen invertiert, und beim Empfang trägt das Feld nur Metadaten – niemals einen routbaren Pfad. path_len ist ein kodiertes Byte (siehe Packet::isValidPathLen / Packet::writePath in src/Packet.cpp), keine rohe Byte-Anzahl.
PACKET_MESSAGES_WAITING (0x83) senden, um den Host darüber zu informieren, dass Datagramme in der Warteschlange liegen; fragen Sie diese mit CMD_SYNC_NEXT_MESSAGE (0x0A) ab, um sie abzurufen.
Parsing-Pseudocode:
---
7. Nachricht abrufen
Zweck: Fordert die nächste in der Warteschlange befindliche Nachricht vom Gerät an. Befehlsformat: Beispiel (hexadezimal): Antwort:PACKET_CHANNEL_MSG_RECV(0x08) oderPACKET_CHANNEL_MSG_RECV_V3(0x11) für Kanalnachrichten.PACKET_CONTACT_MSG_RECV(0x07) oderPACKET_CONTACT_MSG_RECV_V3(0x10) für Kontaktnachrichten.PACKET_CHANNEL_DATA_RECV(0x1B) für Kanal-Datagramme.PACKET_NO_MORE_MSGS(0x0A), wenn keine Nachrichten verfügbar sind.
PACKET_MESSAGES_WAITING (0x83) als Benachrichtigung senden, wenn Nachrichten verfügbar sind.
---
8. Batterie und Speicher abrufen
Zweck: Fragt die Gerätespannung der Batterie und die Speichernutzung ab. Befehlsformat: Beispiel (hexadezimal): Antwort:PACKET_BATTERY (0x0C) mit Batteriemillivolt und Speicherinformationen.
---
Kanalverwaltung
Kanaltypen
- Öffentlicher Kanal
8b3387e9c5cdea6ac9e5edbaa115cd72
- Jeder kann diesem Kanal beitreten, Nachrichten sollten als öffentlich betrachtet werden.
- Wird als Standard-Gruppenchat verwendet.
- Hashtag-Kanäle
sha256("#test").
- Zum Beispiel hat der Hashtag-Kanal #test den Schlüssel: 9cd8fcf22a47333b591d96a2b848b73f.
- Der Verkehr ist in der Luft verschlüsselt, aber jeder, der den Kanalnamen kennt oder errät, kann den Schlüssel ableiten. Hashtag-Kanäle sollten nicht als privat behandelt werden.
- Wird als themenbasierter öffentlicher Gruppenchat verwendet, getrennt vom Standard-Öffentlichen Kanal.
- Private Kanäle
Kanal-Lebenszyklus
- Kanal einstellen:
CMD_SET_CHANNEL mit Namen und einem 16-Byte-Geheimnis.
- Kanal abrufen:
CMD_GET_CHANNEL mit dem Kanalindex.
- Parsen Sie die RESP_CODE_CHANNEL_INFO-Antwort.
- Kanal löschen:
CMD_SET_CHANNEL mit leerem Namen und einem nur aus Nullen bestehenden Geheimnis.
- Oder überschreiben Sie ihn mit einem neuen Kanal.
---
Nachrichtenverarbeitung
Nachrichten empfangen
Nachrichten werden über das TX-Merkmal (Benachrichtigungen) empfangen. Das Gerät sendet:
- Kanalnachrichten:
PACKET_CHANNEL_MSG_RECV (0x08) – Standardformat
- PACKET_CHANNEL_MSG_RECV_V3 (0x11) – Version 3 mit SNR (Signal-Rausch-Verhältnis)
- Kontaktnachrichten:
PACKET_CONTACT_MSG_RECV (0x07) – Standardformat
- PACKET_CONTACT_MSG_RECV_V3 (0x10) – Version 3 mit SNR
- Benachrichtigungen:
PACKET_MESSAGES_WAITING (0x83) – Zeigt an, dass Nachrichten in der Warteschlange sind.
Kontaktnachrichtenformat
Standardformat (PACKET_CONTACT_MSG_RECV, 0x07):
V3-Format (PACKET_CONTACT_MSG_RECV_V3, 0x10):
Parsing-Pseudocode:
Kanalnachrichtenformat
Standardformat (PACKET_CHANNEL_MSG_RECV, 0x08):
V3-Format (PACKET_CHANNEL_MSG_RECV_V3, 0x11):
Parsing-Pseudocode:
Nachrichten senden
Verwenden Sie den Befehl SEND_CHANNEL_MESSAGE (siehe Befehle).
- Nachrichten sind gemäß MeshCore-Spezifikation auf 133 Zeichen begrenzt.
- Lange Nachrichten sollten in Abschnitte (Chunks) aufgeteilt werden.
- Fügen Sie einen Chunk-Indikator hinzu (z.B. "[1/3] Nachrichtentext").
Antwort-Parsing
Terminologie
Dieses Dokument verwendet eine spezifikationskonforme Namenskonvention (PACKET_*) für Bytes, die die Firmware an den Host zurücksendet. Im Firmware-Quellcode sind dieselben Werte nach Zweck in zwei #define-Familien aufgeteilt:
RESP_CODE_*— direkte Antworten auf einen Befehl (z. B.RESP_CODE_CHANNEL_DATA_RECV=PACKET_CHANNEL_DATA_RECV= 0x1B).PUSH_CODE_*— asynchrone Benachrichtigungen, die nicht an einen bestimmten Befehl gebunden sind (z. B.PUSH_CODE_MSG_WAITING=PACKET_MESSAGES_WAITING= 0x83).
RESP_CODE_X / PUSH_CODE_X dem PACKET_X dieses Dokuments mit demselben numerischen Wert.
Pakettypen
| Wert | Name | Beschreibung |
|---|---|---|
| 0x00 | PACKET_OK | Befehl erfolgreich |
| 0x01 | PACKET_ERROR | Befehl fehlgeschlagen |
| 0x02 | PACKET_CONTACT_START | Start der Kontaktliste |
| 0x03 | PACKET_CONTACT | Kontaktinformationen |
| 0x04 | PACKET_CONTACT_END | Ende der Kontaktliste |
| 0x05 | PACKET_SELF_INFO | Geräte-Eigeninformationen |
| 0x06 | PACKET_MSG_SENT | Bestätigung gesendeter Nachricht |
| 0x07 | PACKET_CONTACT_MSG_RECV | Kontaktnachricht (Standard) |
| 0x08 | PACKET_CHANNEL_MSG_RECV | Kanalnachricht (Standard) |
| 0x09 | PACKET_CURRENT_TIME | Antwort auf aktuelle Uhrzeit |
| 0x0A | PACKET_NO_MORE_MSGS | Keine weiteren Nachrichten verfügbar |
| 0x0C | PACKET_BATTERY | Batteriestand |
| 0x0D | PACKET_DEVICE_INFO | Geräteinformationen |
| 0x10 | PACKET_CONTACT_MSG_RECV_V3 | Kontaktnachricht (V3 mit SNR) |
| 0x11 | PACKET_CHANNEL_MSG_RECV_V3 | Kanalnachricht (V3 mit SNR) |
| 0x12 | PACKET_CHANNEL_INFO | Kanalinformationen |
| 0x1B | PACKET_CHANNEL_DATA_RECV | Kanal-Datagramm |
| 0x80 | PACKET_ADVERTISEMENT | Werbepaket |
| 0x82 | PACKET_ACK | Bestätigung (Acknowledgement) |
| 0x83 | PACKET_MESSAGES_WAITING | Benachrichtigung über wartende Nachrichten |
| 0x88 | PACKET_LOG_DATA | RF-Protokolldaten (können ignoriert werden) |
Antworten parsen
PACKET_OK (0x00): PACKET_ERROR (0x01): PACKET_CHANNEL_INFO (0x12): Hinweis: Das Gerät gibt in dieser Antwort das 16-Byte-Kanalgeheimnis zurück. PACKET_DEVICE_INFO (0x0D): Parsing-Pseudocode: PACKET_BATTERY (0x0C): Parsing-Pseudocode: PACKET_SELF_INFO (0x05): Parsing-Pseudocode: PACKET_MSG_SENT (0x06): PACKET_ACK (0x82):Fehlercodes
PACKET_ERROR (0x01) enthält einen ein-Byte-Fehlercode in Byte 1. Die Werte entsprechen den ERR_CODE_*-Konstanten, die in examples/companion_radio/MyMesh.cpp definiert sind:
| Code | Konstante (Firmware) | Beschreibung |
|---|---|---|
| 1 | ERR_CODE_UNSUPPORTED_CMD | Unbekannter oder nicht unterstützter Befehlsbyte / Unterbefehl |
| 2 | ERR_CODE_NOT_FOUND | Ziel nicht gefunden (Kanal, Kontakt, Nachricht usw.) |
| 3 | ERR_CODE_TABLE_FULL | Interne Warteschlange oder Tabelle ist voll — später erneut versuchen |
| 4 | ERR_CODE_BAD_STATE | Operation im aktuellen Gerätezustand nicht gültig (z. B. Iterator läuft bereits) |
| 5 | ERR_CODE_FILE_IO_ERROR | Dateisystem- oder Speicher-I/O-Fehler |
| 6 | ERR_CODE_ILLEGAL_ARG | Ungültiges Argument (falsche Länge, Wert außerhalb des Bereichs, reserviertes Feld usw.) |
PACKET_ERROR-Antwort und behandeln Sie unbekannte Codes als generische Fehler.
Frame-Verarbeitung
BLE-Implementierungen reihen auf der Firmware-Ebene pro BLE-Schreib-/Benachrichtigung einen Protokollrahmen ein und liefern ihn aus.
- Apps sollten jede Merkmals-Schreib-/Benachrichtigung als genau einen Companion-Protokollrahmen behandeln.
- Apps sollten die Frame-Längen vor dem Parsen weiterhin validieren.
- Zukünftige Transporte oder Firmware-Revisionen können abweichen, daher sollten Sie bei variablen Antworten nicht von festen Nutzdatengrößen ausgehen.
Antwort-Handling
- Befehl-Antwort-Muster:
- Asynchrone Nachrichten:
PACKET_MESSAGES_WAITING (0x83), indem Sie den GET_MESSAGE-Befehl abfragen.
- Parsen Sie eingehende Nachrichten und leiten Sie sie an die entsprechenden Handler weiter.
- Validieren Sie die Frame-Länge vor dem Dekodieren.
- Antwort-Abgleich:
APP_START → PACKET_SELF_INFO
- DEVICE_QUERY → PACKET_DEVICE_INFO
- GET_CHANNEL → PACKET_CHANNEL_INFO
- SET_CHANNEL → PACKET_OK oder PACKET_ERROR
- SEND_CHANNEL_MESSAGE → PACKET_MSG_SENT
- GET_MESSAGE → PACKET_CHANNEL_MSG_RECV, PACKET_CONTACT_MSG_RECV, PACKET_CHANNEL_DATA_RECV, oder PACKET_NO_MORE_MSGS
- SEND_CHANNEL_DATA → PACKET_OK oder PACKET_ERROR
- GET_BATTERY → PACKET_BATTERY
- Timeout-Handling:
SET_CHANNEL benötigt möglicherweise 1-2 Sekunden).
- Berücksichtigen Sie ein längeres Timeout für Kanaloperationen.
- Fehlerbehebung:
PACKET_ERROR: Fehlercode protokollieren, aktuellen Befehl löschen.
- Bei Verbindungsverlust: Befehlswarteschlange löschen, Wiederverbindung versuchen.
- Bei ungültiger Antwort: Warnung protokollieren, aktuellen Befehl löschen, fortfahren.
---
Beispielimplementierungsfluss
Initialisierung
Erstellen eines privaten Kanals
Nachricht senden
Nachrichten empfangen
---
Best Practices
- Verwaltungs-Verbindung:
- Geheimnisverwaltung:
- Nachrichtenverarbeitung:
CMD_SYNC_NEXT_MESSAGE, wenn PUSH_CODE_MSG_WAITING empfangen wird.
- Implementieren Sie eine Nachrichten-Deduplizierung, um zu vermeiden, dass dieselbe Nachricht zweimal angezeigt wird.
- Kanalverwaltung:
- Fehlerbehandlung:
RESP_CODE_ERR-Antworten entsprechend.
---
Fehlerbehebung
Verbindungsprobleme
- Gerät nicht gefunden: Stellen Sie sicher, dass das Gerät eingeschaltet ist und sendet (Adverstising).
- Verbindungs-Timeout: Überprüfen Sie Bluetooth-Berechtigungen und die Gerätenähe.
- GATT-Fehler: Stellen Sie die korrekte Dienst-/Merkmalerkennung sicher.
Befehlsprobleme
- Keine Antwort: Vergewissern Sie sich, dass Benachrichtigungen aktiviert sind, überprüfen Sie den Verbindungsstatus.
- Fehlerantworten: Überprüfen Sie das Befehlsformat und den Fehlercode.
- Timeout: Erhöhen Sie den Timeout-Wert oder versuchen Sie es erneut.
Nachrichtenprobleme
- Nachrichten werden nicht empfangen: Fragen Sie den Befehl
GET_MESSAGEregelmäßig ab. - Doppelte Nachrichten: Implementieren Sie die Nachrichten-Deduplizierung unter Verwendung von Zeitstempel/Inhalt als eindeutige ID.
- Nachrichtentruncierung: Senden Sie lange Nachrichten als separate, kürzere Nachrichten.