Commands and scripts have no effect

Why isn't the on/off state updated?

This section is still being written.

Why doesn't my script set ps or on, or why does WLED ignore the commands?

In short: It is usually one of five causes: the value was written as an acknowledgement (ack=true) instead of a control command, the device was offline for the adapter at that moment, the same preset was already active, the data type is wrong, or too many commands came too quickly one after another. The checklist below takes you through them in order.

This is how a command reaches the device: the adapter only reacts to writes with ack=false. It turns them into a JSON command, for example {"ps":3} or {"on":true}, and sends it right away: over the WebSocket connection if it is up, otherwise via HTTP to http://192.168.x.y/json. There is no queue and no retry.

Checklist

1. Control, don't update. In Blockly, the block must be "control", not "update". In JavaScript, write setState(id, value) without true as the third argument. A value with ack=true counts as feedback from the device and is not sent.

2. Test by hand. Write the same value to the state in the Admin object tree. If WLED reacts, the error is in the script, for example nested triggers or a wrong object ID. The device IDs are their MAC addresses; they don't change when you rename the device.

3. Is the device online? Look at wled.0.<MAC>._info._online. Commands to a device that can't be reached are lost. The adapter doesn't buffer anything and doesn't retry.
   • Up to v0.9.2: The log shows an error "Sending command to WLED device … failed with error …". If the adapter doesn't know the device at all at that moment, a TypeError appears there instead, which is also reported to Sentry.
   • From v0.9.3: The adapter discards the command with the warning Device <MAC> (192.168.x.y) is offline, command for … discarded (#904).

4. Too soon after switching on? If WLED has only just been powered, for example via a smart plug, it takes a few seconds before it can be reached over Wi-Fi. Commands sent before that are lost.
   • From v0.9.3 there is one more point: the adapter only sends to devices it knows to be connected (#904). It only notices that a device is back at the next check. By default this runs every 30 seconds ("Intervall in seconds"). If the device was off for longer, it checks less often: the intervals double up to a maximum of 10 minutes, and after 5 failed attempts ("Max retry attempts") only once an hour. Until then it discards commands.
   • So let your script wait until wled.0.<MAC>._info._online becomes true, and only then send the command.

5. Same preset already active? If ps already shows the number you write, WLED doesn't load the preset again. This also happens if you switched the light off via on in between. In that case, send {"on":true,"ps":3} to wled.0.<MAC>.action.

6. Is the data type right? on expects true or false, ps a number. If you write on as text, WLED does something other than you expect: a text starting with t (so "true" too) toggles the light, and "false" as text does nothing at all. ioBroker also logs a wrong data type as a warning.

7. Too many commands in a row? Every changed state is a separate command. If your script writes on, bri, color and ps right after each other, WLED can lose commands or answer with a timeout. Combine values that belong together in one JSON command via action, for example {"on":true,"bri":128,"ps":3}, or store them in a preset and only set ps. If they have to be single commands, leave a short pause between them.

8. Feedback over WebSocket. If the connection runs over WebSocket, the adapter up to v0.9.2 doesn't set ack=true itself and doesn't report a sending error either. The ack only comes when WLED reports its new state. If a value stays at ack=false, the command probably didn't arrive. From v0.9.3: The adapter sets ack=true as soon as the command has been sent, and writes a warning "Sending command for … failed" to the log if sending fails (#904).

9. Segment commands. If you set a value in a segment, such as wled.0.<MAC>.seg.0.fx, the command only goes to that segment. Check that you picked the right segment and that it is switched on.

10. Look at the debug log. Set the instance to log level "debug". For every command, "Sending state change by websocket …" or "Sending state change by http-API …" then appears with the JSON that was sent. If the line is missing, the command never reached the adapter.

NOTE

If your script reads on, keep in mind: up to v0.9.2 the adapter sets on to false and bri to 0 when a device goes offline, and when the adapter starts. From v0.9.3: Both keep their last value; the real values come from the device when it reconnects (#899).

See also: Switch presets via the ps state · Send a complete JSON command · Several commands lead to ETIMEDOUT · How can I tell whether a device is online · Retries for offline devices · Warnings about a wrong data type

Why do several commands in quick succession lead to ETIMEDOUT?

This section is still being written.

Why does ps jump to -1 or not show the selected preset?

This section is still being written.

Why do some LEDs stay on after switching off?

This section is still being written.

Why does the cct state have no effect?

This section is still being written.