Kapazität und Wiederverbindung von BLE-Gateways mit mehreren Sensoren testen
Die Antwort auf „Wie viele BLE-Sensoren unterstützt ein Gateway?“ braucht eine zugehörige Lastbeschreibung. Zehn Sensoren mit einer Meldung pro Minute sind ein anderes Problem als zehn Geräte mit Datenbursts alle 20 Millisekunden. Eine belastbare Kapazitätsspezifikation benennt Funk- und Softwaregrenzen, weist die Datenaktualität unter geforderter Last nach und misst die Erholung, wenn mehrere Sensoren gleichzeitig verschwinden.
Zwischen verbundener Erfassung und Advertising-Erfassung wählen
Ein verbundenes GATT-Gateway hält Verbindungen, abonniert Characteristics und kann Konfigurationsbefehle senden. Ein Advertising-Empfänger hört verbindungslose Meldungen mit. Bluetooth Mesh verwendet ein weiteres Kommunikations- und Provisionierungsmodell. Diese Architekturen unterscheiden sich bei Discovery, Zustellung und Sicherheit; ihre Knotenzahlen sind nicht austauschbar.
Beginnen Sie mit einem Geräteverzeichnis: Protokoll- und Firmware-Version, Meldungsformat, Abtastfrequenz, Burstlänge, Verbindbarkeit, Pairing-Anforderungen und zulässiges Datenalter. Entscheiden Sie, ob fehlende historische Messwerte nachgeliefert werden müssen oder der neueste Messwert genügt. Bei Advertising-Erfassung müssen auf Anwendungsebene zudem Authentizität, Duplikatunterdrückung und Replay-Behandlung definiert werden, sofern der Einsatz dies verlangt.
Obeitas Fallbeschreibung des ausgelieferten ESP32-Wi-Fi- und Bluetooth-Gateways beschreibt unterschiedliche Wi-Fi- und SIG-Mesh-Richtungen. Sie bietet hilfreichen Architekturkontext, liefert aber keine gemessene Kapazität für verbundene GATT-Sensoren. Ein GATT-Gateway benötigt eine eigene Validierung der Endgeräte und Last.
Harte Verbindungsgrenzen von nutzbarer Kapazität trennen
Prüfen Sie den konkreten Chip, die Controller-Firmware, den Host-Stack, die SDK-Version und die Build-Konfiguration. Host-Verbindungsobjekte, Controller-Verbindungen, ACL-Puffer, Bond-Speicher und Anwendungswarteschlangen besitzen unterschiedliche Grenzen. Das Erhöhen eines Parameters beseitigt die anderen Grenzen nicht.
Als konkretes, versionsgebundenes Beispiel nennt Espressifs ESP-IDF-v6.0.3-Mehrverbindungsleitfaden für ESP32 jeweils neun gleichzeitige Verbindungen für ESP-NimBLE und ESP-Bluedroid, mit entsprechenden Host-Einstellungen und passender Controller-Einstellung. Das ist eine Implementierungsobergrenze, keine garantierte Sensorzahl für jede Last oder jeden Chip der ESP32-Familie. Auch Zephyr stellt CONFIG_BT_MAX_CONN bereit. Prüfen Sie die Dokumentation der tatsächlich eingesetzten Produktversion. Quellen: Espressifs Mehrverbindungsleitfaden und Zephyr-GAP-Shell-Dokumentation.
Bei einem Linux-Gateway belegen mehr RAM oder eine schnellere CPU keine höhere Grenze des Funkcontrollers. Erfassen Sie USB-/UART-Controllermodell, Firmware, Kernel und BlueZ-Version. Halten Sie Notification-Callbacks kurz: Daten prüfen und einreihen; Datenbankschreibzugriffe und Uplink-Arbeit außerhalb des Bluetooth-Callback-Pfads ausführen.
Ein Verkehrsbudget mit gemessener Reserve aufstellen
Berechnen Sie zunächst die Anwendungsbytes. Als Dimensionierungsbeispiel erzeugen acht Sensoren mit jeweils einem 16-Byte-Datensatz bei 5 Hz insgesamt 640 Byte pro Sekunde vor Protokoll-Overhead. Diese Rechnung ist keine Funkdurchsatzprognose. Paketaustausch, leere Verbindungsereignisse, Bestätigungen, Wiederholungen, Scannen und Planung benötigen zusätzliche Zeit.
Eine nützliche erste Abschätzung ist die Summe der geschätzten Sendezeit eines Verbindungsereignisses jeder Verbindung, jeweils geteilt durch ihr Verbindungsintervall. Lassen Sie Reserve für Scannen, Wiederverbindung und Uplink-Koexistenz. Diese Abschätzung ist weder eine Bluetooth-Planungsgarantie noch ein Ersatz für Messungen: überlappende Ereignisse, Controller-Strategie und eintreffende Bursts können auch bei scheinbar großzügigem Durchschnittsbudget Fehler verursachen.
Messen Sie ausgehandeltes Verbindungsintervall, Peripheral Latency, Überwachungszeitlimit, PHY, ATT-MTU und Link-Layer-Datenlänge. Eine größere ATT-MTU garantiert weder längere Link-Layer-Pakete noch mehr Pakete in jedem Ereignis. Ein längeres Verbindungsintervall kann die Planung erleichtern, aber Latenz oder Burst-Pufferbedarf verschlechtern. Ändern Sie Parameter anhand eines Aktualitätsziels, nicht anhand einer pauschalen Einstellung für „maximalen Durchsatz“.
Die Wiederverbindung als begrenzten Zustandsautomaten auslegen
Verfolgen Sie jeden Sensor getrennt durch Discovery, Verbindung, Sicherheit, Service-Auflösung, Abonnement und Streaming. „Verbunden“ ist nicht der Bereitschaftszustand. Ein sinnvolles Bereitschaftskriterium ist der erste gültige und korrekt zugeordnete Anwendungsmesswert nach dem Abonnement.
DISCOVER -> CONNECT -> SECURE -> RESOLVE -> SUBSCRIBE -> STREAM
failure -> RELEASE_RESOURCES -> BACKOFF -> DISCOVER
# Illustrative full-jitter backoff, seconds:
delay = random_uniform(0, min(60, 2 ** min(attempt, 6)))
# Reset attempt after a defined healthy-stream interval.
# Limit simultaneous connection/setup attempts globally.Die obigen Zeitwerte sind Designbeispiele, keine vorgeschriebenen BLE-Einstellungen. Geben Sie jedem Zustand ein Zeitlimit, einen Abbruchpfad und einen Ursachencode. Begrenzen Sie Wiederholungen bei Fehlern, die Eingreifen erfordern, etwa inkompatiblen Protokollversionen oder wiederholten Authentifizierungsfehlern. Zeigen Sie einen handlungsfähigen Fehler an, statt unbegrenzt mit voller Geschwindigkeit weiterzuversuchen.
Geben Sie nach einem Abbruch veraltete Handles und Callback-Registrierungen angemessen frei, brechen Sie überholte Arbeit ab und stellen Sie erforderliche Sicherheit und Abonnements wieder her. Erhalten Sie eine dauerhafte Identität über unterstützte Bonding-/Privacy-Mechanismen oder eine authentifizierte Anwendungskennung. Behandeln Sie eine wechselnde private Adresse nicht automatisch als dauerhaft neuen Sensor. Verwenden Sie unter BlueZ die unterstützte Notification-Schnittstelle und behandeln Sie deren dokumentierte Fehler. Siehe BlueZ-GATT-API.
Verwenden Sie Startkennungen und Messwertsequenzen, um Neustarts, Lücken und Duplikate zu unterscheiden. Speichern Sie dauerhaft nur den Zustand, den die Wiederherstellungsvereinbarung des Produkts erfordert. Ein Gateway-Neustart während der Übertragung zurückgestauter Daten darf alte Messwerte nicht stillschweigend zu Live-Daten umetikettieren.
Konkurrenz und Fehler unter voller Verbindungsbelastung testen
Bei gemeinsam genutztem Funk konkurrieren BLE-Erfassung und Wi-Fi-Verkehr um Funkressourcen. Espressif dokumentiert prioritätsbasierte Koexistenz und Änderungen der Planung je nach Wi-Fi-Zustand. Testen Sie sowohl einen gleichmäßigen Uplink als auch Wi-Fi-Scans und Wiederverbindungen; eine ruhige Laborverbindung deckt diese Bedingungen nicht ab. Beachten Sie den ESP32-Koexistenzleitfaden und anschließend die entsprechende Dokumentation für das gewählte SDK und den Chip.
Verwenden Sie Seriengehäuse, geplante Antennenposition und Stromversorgung. Variieren Sie unterstützte Sensorzahlen und Melderaten und wiederholen Sie dann die Prüfung an der vorgesehenen Betriebsgrenze mit kontrollierter Dämpfung oder repräsentativer Anordnung. RSSI allein ist kein Bestehenskriterium. Behalten Sie eine Vergleichsgruppe mit starkem Signal bei, damit Warteschlangen- oder CPU-Fehler von Funkproblemen getrennt werden können.
| Szenario | Fehlereinspeisung | Erforderliche Beobachtung |
|---|---|---|
| Stabile Kapazität | Aktive Sensorzahl und Melderate bis zur angegebenen Grenze erhöhen | Aktualität je Sensor, Zustellquote eindeutiger Werte, Warteschlangenspitze und CPU-/Speichertrend |
| Synchronisierter Burst | Alle Sensoren gleichzeitig melden lassen | Hohe Latenzperzentile, Überlaufverhalten und Fairness |
| Ausfall eines Knotens | Einen Sensor außer Reichweite bringen oder aus- und einschalten | Erkennungs- und Erholungszeit; übrige Knoten bleiben im Zielbereich |
| Wiederverbindungssturm | Alle Sensoren oder das Gateway neu starten | Erster und letzter wiederhergestellter Strom, Einrichtungsparallelität und Wiederholungsverteilung |
| Uplink-Konkurrenz | Wi-Fi-Scan, Wiederverbindung und dauerhafte Übertragung | BLE-Lücken und Erholung bei begrenzten Warteschlangen |
| Uplink-Ausfall | Server oder Netzwerkpfad blockieren | Speichergrenze, Überlaufalarm und Nachlieferungszählung |
| Gemischte Versionen und Sicherheit | Unterstützte Versionen und abgelehnte Zugangsdaten kombinieren | Korrekte Zustände je Gerät ohne Benachteiligung gesunder Teilnehmer |
| Langzeitlauf | Fehler über einen Zeitraum wiederholen, der erforderliche Betriebszyklen abdeckt | Keine Ressourcenlecks, festhängenden Zustände oder unerklärlichen Datenverluste |
Abnahme anhand nutzbarer Daten definieren
Legen Sie Bestehensgrenzen vor dem Test fest. Eine beispielhafte Spezifikation könnte ein 99. Perzentil des Messwertalters unter zwei Sekunden, eine definierte Zustellquote eindeutiger Messwerte und die Wiederherstellung aller erreichbaren Sensoren innerhalb eines vereinbarten Zeitfensters verlangen. Das sind beispielhafte Anforderungen, keine berichteten Ergebnisse. Ein langsamer Sensor mit einem Messwert pro Minute braucht ein anderes Aktualitätsziel.
Definieren Sie den Nenner: erwartete, im Messfenster erzeugte Messwerte, im Sensor gespeicherte Messwerte und zur Übertragung berechtigte Messwerte sind unterschiedliche Größen. Zählen Sie Duplikate getrennt von eindeutig zugestellten Messwerten. Dokumentieren Sie, wie bekannte Offline-Zeiten das Ziel beeinflussen. Erfassen Sie auch Erfolgsquote beim ersten Versuch und Verhalten des schlechtesten Knotens, damit Gesamtdurchschnitte keinen benachteiligten Sensor verdecken.
Messen Sie das Messwertalter ab dem Erfassungszeitstempel des Sensors nur, wenn die Uhren synchronisiert sind oder Versatz und Drift begrenzt sind. Andernfalls melden Sie die Verzögerung vom Gateway-Empfang bis zum Uplink getrennt und kennzeichnen das Ende-zu-Ende-Alter als unbekannt. Verwenden Sie eine monotone Uhr für lokale Zustandsdauern und erfassen Sie die vollständige Fehlerzeitachse: Ausfall, Erkennung, Verbindung, Abonnement und erster gültiger Messwert.
Die tatsächlich ausgefallene Schicht untersuchen
- Verbindungen stehen, aber Daten fehlen: Prüfen Sie Service-Auflösung, Abonnementstatus, Berechtigungen und Datenerzeugung im Sensor.
- Nur höhere Sensorzahlen scheitern: Prüfen Sie Controller-Grenzen, Puffermangel, Ereignisplanung und globale Einrichtungsparallelität.
- Der Fehler folgt auf Uplink-Aktivität: Vergleichen Sie Wi-Fi-Koexistenzspuren, Callback-Dauer und Warteschlangenwachstum.
- Ein fehlerhafter Sensor verzögert alle anderen: Prüfen Sie gemeinsame Sperren, seriell ausgeführte unbegrenzte Wiederholungen und Warteschlangenfairness.
- Wiederverbindung gelingt nur nach Neustart: Suchen Sie nach verlorenen Verbindungsobjekten, veralteten Callbacks und Zuständen ohne Zeitlimit-Ausgang.
Eine nützliche Projektbeschreibung umfasst Sensormuster, Firmware-Versionen, Verkehrsprofile, Topologie, Uplink-Verhalten und numerische Abnahmeziele. Obeitas Gateway-Integrationsservice bietet einen passenden Rahmen zur Eingrenzung dieser Arbeit. Das Ergebnis sollte ein versionierter Kapazitätsbereich und Wiederherstellungsbericht für die gewählte Konfiguration sein, belegt durch Protokolle. Architekturkontext bietet die zugehörige Fallbeschreibung des ausgelieferten ESP32-Wi-Fi- und Bluetooth-Gateways. Die Zahlenbeispiele und der Testplan dieses Artikels sind keine Messergebnisse aus diesem Fall.
