Fortgeschrittene Integrationswege

Es gibt mehr, als das öffentliche Manual zeigt

Die aktuelle Entwicklungsseite von Plenom bewirbt mehrere Busylight-Developer-Tool-Bundles jenseits des öffentlichen kuandoHUB-Manuals. Wichtig ist der Vorbehalt: Diese sind zugriffsbeschränkt und nicht in gleicher Weise offen dokumentiert wie die HTTP-API.

1. Was Plenom derzeit anbietet

Die Entwicklungsseite vom 2. März 2026 listet:

• SDK - Busylight UC
• USB API - Busylight UC
• HTTP Windows - Busylight UC
• HTTP Mac - Busylight UC
• Chrome WebHID SDK - Busylight UC
• JavaScript SDK - Busylight UC
• Browser Extension SDK - Busylight UC

Dieselbe Seite sagt:

• das Busylight UC SDK gibt .NET-Entwickelnden programmatische Kontrolle und enthält DLLs, Beispiele und Dokumentation,
• die USB API ist für hardwarenahe Gerätesteuerung gedacht,
• das JavaScript SDK zielt auf die Integration in Webanwendungen,
• das Browser Extension SDK enthält eine Native-Messaging-Host-App,
• das Chromium WebHID SDK unterstützt browser-native Integration ohne native App oder Middleware.

2. Was öffentlich verifizierbar ist vs. herstellerbeschränkt

Option	Öffentliche Doku aktuell verfügbar	Was wir mit Sicherheit sagen können
kuandoHUB HTTP API	Ja	Real, dokumentiert, skriptbar
Busylight UC SDK	Keine öffentliche technische Doku auf der Website	Existiert und ist auf Anfrage verfügbar
USB API	Keine öffentliche Protokoll-Doku auf der Website	Existiert und ist auf Anfrage verfügbar
JavaScript SDK	Keine öffentliche technische Doku auf der Website	Existiert und ist auf Anfrage verfügbar
Browser Extension SDK	Keine öffentliche technische Doku auf der Website	Existiert und enthält Native-Messaging-Host-Werkzeuge
Chromium WebHID SDK	Keine öffentliche technische Doku auf der Website	Existiert und zielt auf Chromium-Browser

3. Wann du Herstellerzugriff anfragen solltest

Frage bei Plenom nach den umfangreicheren Developer-Tools, wenn:

• kuandoHUB in deinem Deployment nicht akzeptabel ist,
• du direkten HID-Zugriff im Browser benötigst,
• deine App den Gerätelebenszyklus selbst besitzen muss,
• du tiefere native Kontrolle brauchst, als lokales HTTP bietet,
• du eine verteilbare kommerzielle Integration baust.

4. Beste Einschätzungen zur Eignung

Dies sind Schlussfolgerungen aus den Beschreibungen von Plenom, keine bestätigte öffentliche SDK-Doku:

• Busylight UC SDK: am besten geeignet für C#-, C++- oder Windows-Desktop-Integrationen.
• USB API: am besten geeignet für Embedded-, Treiber-Level- oder Nicht-Standard-Plattform-Arbeit.
• JavaScript SDK: wahrscheinlich am besten für Web-Apps, in denen Hersteller-Middleware oder Helper-Werkzeuge akzeptabel sind.
• Browser Extension SDK: wahrscheinlich am besten für Browser-Add-ons, die Native Messaging benötigen.
• Chromium WebHID SDK: wahrscheinlich am besten für Web-Apps, die Gerätezugriff ohne lokale Helper-App wollen.

5. Praktische Strategie

1. Baue den ersten Prototyp mit der öffentlichen HTTP-API.
2. Entscheide, ob kuandoHUB betrieblich akzeptabel ist.
3. Frage die tieferen SDKs nur an, wenn die Middleware-Abhängigkeit oder die API-Einschränkungen zu echten Blockern werden.

Das hält das Risiko gering und bringt dich am schnellsten zu einem funktionierenden Prototyp.