Architektur und SDK-Übersicht

Beginne mit der Steuerungsschnittstelle

Für die meisten Teams ist die erste Frage nicht „welche Sprache?", sondern „spreche ich mit kuandoHUB, mit einer Browser-Bridge oder direkt mit dem Gerät?"

1. Integrationsebenen

Your app or script
        |
        +-- HTTP requests to kuandoHUB
        |
        +-- Vendor JS SDK / Browser Extension SDK / WebHID SDK
        |
        +-- Vendor Busylight UC SDK
        |
        +-- Vendor USB API
        |
Busylight hardware

Das öffentliche Manual dokumentiert den kuandoHUB-HTTP-Weg am besten. Das macht ihn zum sichersten Weg für die reale Entwicklung, sofern du nicht bereits Zugriff auf die Developer-Pakete von Plenom hast.

2. Entscheidungstabelle

Bedarf	Bester Weg	Warum
Das Licht heute aus einem Skript umschalten	HTTP API	Öffentlich dokumentiert, funktioniert aus jeder Sprache
BusyLight schnell in eine interne Web-App einbauen	HTTP API aus dem Browser oder lokalem Desktop-Helper	Geringste Reibung
Eine reine Browser-Native-Erfahrung bauen	Chromium WebHID SDK	Vielversprechend, aber Herstellerzugriff ist erforderlich
In eine native Windows-Desktop-App integrieren	Busylight UC SDK	Wahrscheinlich am besten geeignet für C# / C++
Hardwarenahe Steuerung durchführen	USB API	Am flexibelsten, aber auch am spezialisiertesten
Etwas plattformübergreifend mit minimaler Herstellerreibung bauen	HTTP API	Geprüfte Doku, einfaches Deployment

3. Wann JavaScript sinnvoll ist

Nutze JavaScript oder TypeScript, wenn:

• der Steuerungspunkt eine Web-App oder Electron-App ist,
• du schnelle Automatisierung in Node.js willst,
• dein System bereits lokale Webhooks oder Dashboards hat,
• du dich darauf verlassen kannst, dass kuandoHUB lokal läuft.

JavaScript eignet sich besonders gut für HTTP-basierte Integrationen, weil die Payloads einfach sind und die API lokal ist.

4. Wann Python sinnvoll ist

Nutze Python, wenn:

• du lokale Automatisierungs-Tools baust,
• du Cron-Jobs, Daemons oder Service-Monitore willst,
• du bereits Monitoring- oder Ops-Skripte in Python hast,
• du APIs, Datenbanken und Busylight-Zustand schnell verbinden willst.

Python ist die beste Skripting-Wahl für serverähnliche lokale Automatisierung rund um Busylight.

5. Wann native SDKs sinnvoll sind

Nutze das Hersteller-SDK oder die USB API, wenn:

• kuandoHUB als Middleware nicht akzeptabel ist,
• du engere Gerätesteuerung brauchst, als die dokumentierte HTTP-API bietet,
• du eine Enterprise-Windows-Desktop-Integration benötigst,
• du browser-nativen HID-Zugriff ohne lokalen HTTP-Dienst willst,
• du bereit bist, die Developer-Tool-Bundles von Plenom anzufragen.

6. Praktische Empfehlung

Starte zuerst mit kuandoHUB und der HTTP-API.

Wechsle nur zum Hersteller-SDK-Zugriff, wenn:

• du auf eine dokumentierte HTTP-Einschränkung stößt,
• du direkte Gerätesteuerung brauchst,
• deine Deployment-Architektur die Abhängigkeit von der lokalen App verbietet,
• du browser-nativen HID statt eines lokalen HTTP-Listeners willst.