WiZ

localby ALYT

What it adds to a house

adds lights.

How a person connects it

Method: discover. Nothing to type: WiZ lights answer on the local network.

What it can look for

Yes: “Look for lights”.

What stops working when it is disconnected

The things it brought stop answering until it is connected again.

The descriptor

Connection fields are served for a program at /connectors/wiz.json.

{
  "source": "built-in",
  "visibility": "public",
  "listed": true,
  "version": "1.0.0",
  "docsUrl": "https://developers.alyt.com/connectors/wiz",
  "kind": "WIZ",
  "logo": {
    "url": "/integrations/logos/wiz.png",
    "color": "#006FB9",
    "ratio": 1,
    "background": "#007EC8",
    "inset": 0,
    "scale": 1
  },
  "name": "WiZ",
  "icon": "lightbulb",
  "connectivity": "local",
  "brings": [
    "light"
  ],
  "connect": {
    "method": "discover",
    "fields": [],
    "help": "Nothing to type: WiZ lights answer on the local network."
  },
  "discovery": {
    "verb": "Look for lights"
  },
  "disconnect": {
    "consequence": "{count} {things} stop answering until it is connected again."
  },
  "author": {
    "kind": "alyt",
    "name": "ALYT",
    "url": "https://alyt.com"
  }
}

The guide

WiZ is a local connector for lights and plugs. It discovers devices on the household network, then reads and writes them over UDP without an account, cloud, or key. The normal workflow is: discover the device, read its current pilot, and write a new pilot, then read it back so the stored state matches what the device reports.

How connection works

Connecting uses discover. There is nothing to type, and nothing is stored from a form. The connector sweeps the configured subnet and looks for WiZ lights that answer on the LAN. When discovery succeeds, each device is added with its network address and identity, and a light that changes IP is found again on the next discovery.

The connector uses one subnet only. If a device stops answering, reconnecting means running discovery again. Because this connector is local, it depends on the household network and the light itself; it does not rely on a cloud path.

What it exposes

WiZ exposes lights with light controls and plugs with switch controls.

For lights, the exposed state includes:

• light.power
• light.brightness
• light.colorTemp when the module supports tunable white
• light.color when the module supports colour
• light.sceneId as reported by the bulb
• link.value and link.unit from the bulb’s Wi‑Fi signal, when present

For plugs, the exposed state includes:

• switch.power

Supported writes follow the same shape. A light accepts power, brightness, warmth, and colour. A plug accepts power only. Brightness is clamped to the device floor of 10 through 100, and a brightness value of 0 turns the light off. Setting colour or warmth on a light that is off turns it on.

What it cannot do

WiZ does not support cloud features in this connector path. It does not expose scenes or rhythms as controls, even though a sceneId may be reported in state. It does not need a login, and discover does not validate credentials.

The connector also does not invent capabilities from the room or the name. What a device can do comes from its module name: RGB modules expose colour and tunable white, TW modules expose tunable white, DW modules are dimmable, and SOCKET modules are plugs.

Failure and recovery

A state read or control fails per item, not for the whole group. If a light does not answer, the item is reported unreachable for that refresh or write. On control, the connector writes the new pilot, then reads the pilot back. If the light does not confirm the requested state, the command fails.

When a command fails, check these first:

• The device still has the same LAN address. A changed address requires discovery again.
• The device is on the configured subnet.
• The module name still matches the features you expect.
• The light is reachable on the local network and not blocked by Wi‑Fi isolation.
• For colour or warmth writes, the bulb actually supports that mode.

If discovery returns nothing, the subnet sweep is the usual issue: the configured subnet is wrong, the light is not on the LAN, or the light is offline. If a state read works but control fails, the device is answering but not confirming the write, so recheck the address and the supported control type.

Access boundaries

This connector is local. Household permissions apply to the installed devices in that home, and live credentials are only for the connector they belong to. DEV credentials act in the developer sandbox. LIVE credentials are scoped to their own installed connector.

Practical workflow

1. Run discover to sweep the subnet.
2. Review the found devices and keep the returned address.
3. Read state with state.
4. Write with control.
5. If a device stops answering, run discovery again before treating it as gone.