Skip to main content

Troubleshooting and Security

Most failures are configuration failures

When a Busylight script does not work, the cause is usually not the language. It is usually HTTP not enabled, the priority line not active, or the wrong assumption about local vs remote access.

1. Script runs but light does not change​

Check:

  • kuandoHUB is running.
  • HTTP is enabled in Advanced Settings.
  • the listener is still http://localhost:8989/.
  • the HTTP priority entry is enabled.
  • another higher-priority source is not overriding your change.
  • the Busylight device is connected and recognized by the app.

2. Browser request fails​

Check:

  • the browser can reach localhost,
  • the app is running on the same machine as kuandoHUB,
  • local network policies are not blocking loopback access,
  • your request is using the exact port configured by kuandoHUB.

3. POST works inconsistently​

Check:

  • parameter is encoded the way kuandoHUB expects,
  • you are using the documented field names exactly,
  • your sender, eventtype, and eventname values stay stable,
  • you registered your custom data source when relying on priorities.

4. Priority model surprises​

Remember that kuandoHUB is not only a dumb light server. It has a source-priority model.

That means:

  • a manual or UC source can override your script,
  • your script may need its own registered data source,
  • enabling HTTP alone is not always enough for durable control.

If your integration matters operationally, use RegisterDataSource and CreateInitialPriority instead of only sending anonymous light calls.

5. Local vs remote access​

The public manual states:

  • local requests do not need a token,
  • the HTTP access token is only required for remote access from other devices.

Practical recommendation:

  • prefer localhost only,
  • avoid exposing the listener on a broader interface unless you truly need it,
  • if you do expose it remotely, use the documented token support and treat it as an internal control surface.

6. Deployment advice​

For internal tools:

  • keep kuandoHUB installed locally on each workstation,
  • keep automation local to the workstation when possible,
  • log failed requests,
  • expose only simple light-state abstractions in your app.

For team-wide rollout:

  • standardize color semantics,
  • document priority ownership,
  • test machine sleep, app restarts, and reconnect behavior,
  • consider whether a local helper service is needed.

7. Sensible defaults​

Use a small standard state model:

  • green: available
  • yellow: away or caution
  • red: busy or incident
  • blue: ringing or active call
  • off: inactive

That keeps app logic readable and avoids turning Busylight integration into a color-management problem.