Zum Hauptinhalt springen

Fehlerbehebung und Sicherheit

Die meisten Fehler sind Konfigurationsfehler

Wenn ein Busylight-Skript nicht funktioniert, liegt die Ursache meist nicht an der Sprache. Meist ist HTTP nicht aktiviert, die Prioritätszeile nicht aktiv oder es besteht eine falsche Annahme über lokalen vs. Remote-Zugriff.

1. Skript läuft, aber das Licht ändert sich nicht​

PrĂĽfe:

  • kuandoHUB läuft.
  • HTTP ist in den Advanced Settings aktiviert.
  • der Listener ist weiterhin http://localhost:8989/.
  • der HTTP-Prioritätseintrag ist aktiviert.
  • keine andere höher priorisierte Quelle ĂĽberschreibt deine Ă„nderung.
  • das Busylight-Gerät ist angeschlossen und von der App erkannt.

2. Browser-Anfrage schlägt fehl​

PrĂĽfe:

  • der Browser erreicht localhost,
  • die App läuft auf demselben Rechner wie kuandoHUB,
  • lokale Netzwerkrichtlinien blockieren den Loopback-Zugriff nicht,
  • deine Anfrage nutzt genau den von kuandoHUB konfigurierten Port.

3. POST funktioniert inkonsistent​

PrĂĽfe:

  • parameter ist so codiert, wie kuandoHUB es erwartet,
  • du nutzt die dokumentierten Feldnamen exakt,
  • deine Werte fĂĽr sender, eventtype und eventname bleiben stabil,
  • du hast deine eigene Datenquelle registriert, wenn du dich auf Prioritäten verlässt.

4. Überraschungen im Prioritätsmodell​

Denk daran, dass kuandoHUB nicht nur ein simpler Lichtserver ist. Es hat ein Quellen-Prioritätsmodell.

Das bedeutet:

  • eine manuelle oder UC-Quelle kann dein Skript ĂĽberschreiben,
  • dein Skript braucht möglicherweise seine eigene registrierte Datenquelle,
  • HTTP allein zu aktivieren reicht nicht immer fĂĽr dauerhafte Kontrolle.

Wenn deine Integration betrieblich wichtig ist, nutze RegisterDataSource und CreateInitialPriority, statt nur anonyme Lichtaufrufe zu senden.

5. Lokaler vs. Remote-Zugriff​

Das öffentliche Manual gibt an:

  • lokale Anfragen benötigen kein Token,
  • das HTTP-Zugriffstoken ist nur fĂĽr den Remote-Zugriff von anderen Geräten erforderlich.

Praktische Empfehlung:

  • bevorzuge nur localhost,
  • vermeide es, den Listener auf einer breiteren Schnittstelle freizugeben, sofern du es nicht wirklich brauchst,
  • wenn du ihn remote freigibst, nutze die dokumentierte Token-UnterstĂĽtzung und behandle ihn als interne Steuerungsschnittstelle.

6. Deployment-Hinweise​

FĂĽr interne Tools:

  • halte kuandoHUB lokal auf jeder Workstation installiert,
  • halte die Automatisierung wenn möglich lokal auf der Workstation,
  • protokolliere fehlgeschlagene Anfragen,
  • gib in deiner App nur einfache Lichtzustands-Abstraktionen frei.

FĂĽr teamweiten Rollout:

  • standardisiere die Farbsemantik,
  • dokumentiere die Prioritätsverantwortung,
  • teste Rechner-Standby, App-Neustarts und Reconnect-Verhalten,
  • ĂĽberlege, ob ein lokaler Helper-Dienst nötig ist.

7. Sinnvolle Standardwerte​

Nutze ein kleines Standard-Zustandsmodell:

  • green: verfĂĽgbar
  • yellow: abwesend oder Vorsicht
  • red: beschäftigt oder Incident
  • blue: klingelnd oder aktiver Anruf
  • off: inaktiv

Das hält die App-Logik lesbar und verhindert, dass die Busylight-Integration zu einem Farbverwaltungsproblem wird.