Skip to main content

WH66 and BLT60 Status

Publicly, this is presence-driven

The public Yealink story for BLT60 is synchronization with work state and presence, not a direct JavaScript or Python API.

Yealink publicly describes BLT60 as:

  • easy to use,
  • plug-and-play,
  • synchronized with working state,
  • designed for use with WH series headsets,
  • displaying desk phone or softphone presence state by color.

Yealink publicly describes WH66 as a UC workstation and lists BLT60 as an optional accessory.

2. What that means technically​

The safe conclusion is:

  • BLT60 is driven by the headset or UC host context,
  • it reflects presence or call state,
  • but there is no public Yealink developer page here exposing a direct local LED control API.

3. Can you control it indirectly​

Probably yes, through the UC layer.

If the light follows:

  • softphone call state,
  • desk phone state,
  • or Yealink-managed device presence,

then your app may still influence it by changing the state of the system that Yealink listens to.

That is not the same as calling setColor(red) from a public SDK.

4. Practical recommendation​

If your real goal is "show busy or free from my app":

  1. Prefer a product with a documented local control surface.
  2. For Yealink, assume indirect state signaling unless support gives you a headset SDK.
  3. If you need direct light control from JS or Python, BLT60 is not publicly verified as that kind of device.

5. Honest bottom line​

For WH66 and BLT60, I could verify the accessory relationship and the presence-sync behavior, but not a public programmable interface.