Connection and adapter start
Why doesn't the adapter start after an update, or why does it stop responding?
In short: Look at the log of the instance wled.<instance> first. The known causes are: requirements such as the Node.js version not met, an incompletely installed update, bugs in older adapter versions, and in v0.9.2 a polling interval of 0 or devices that were added after the start. The table below matches the log lines to their causes.
How to proceed
- In Admin, open the "Log" tab and look for the lines of the instance
wled.<instance>and thehost.<host>lines right after the instance starts. If the adapter doesn't start at all, the error is often in the host lines withCaught by controller. - Compare the lines with the table below and follow the solution.
- Restart the instance afterwards.
- If the error remains, set the log level of the instance to "debug", restart it and attach the log excerpt to a GitHub issue. Replace IP and MAC addresses first.
Known causes and log lines
| Log line (excerpt) | Cause | Solution |
|---|---|---|
| No start after the update; the installation reports a Node.js version that is too old | In v0.9.2 the adapter needs Node.js 20 or newer, js-controller 6.0.11 or newer and Admin 7.6.17 or newer. | Update Node.js, js-controller or Admin. |
Caught by controller[0]: Error: Cannot find module 'axios' | The update wasn't installed completely; a library of the adapter is missing. | Install the adapter again in the "Adapters" tab, or install a newer version. |
[handleStates] TypeError: Cannot read property 'initialized' of undefined | Bug in versions before v0.6.7, fixed in v0.6.7. | Update the adapter. |
Caught by controller[0]: State attribute definition missing for …, after which the instance stops | Bug in v0.5.x. Since v0.7.1 the message is only a debug message without consequences. | Update the adapter. |
Many lines Unable to initialise 192.168.x.y will retry in scheduled interval ! and Device 192.168.x.y unavailable (attempt n/5), will retry in … seconds | A device is switched off or can't be reached. The adapter keeps running, but the log fills up with every attempt. | Switch the device on, or delete it if you no longer use it. |
After every error, a second line Sentry disabled, error caught : … | The adapter reports every error twice. It is the same error. | Only look at the first line. |
| No error message, but the adapter stops responding and the load is high | "Intervall in seconds" is set to 0. The requests then run without a pause. | Set the interval to at least 1 second; the default is 30 seconds. |
| No error message, but a device no longer responds after an outage | The device was added after the adapter started, via "Discover new devices", by IP, or because the Bonjour search only found it later. In v0.9.2 no monitoring starts for such devices, so they don't reconnect after an outage. | Restart the instance. |
The two lines about State attribute definition missing and Cannot read property 'initialized' come from old versions. If you still see them today, you are running an old adapter version.
NOTE
The setting "Max retry attempts" applies to all devices of the instance together. There is no setting per device.
From v0.9.3
From v0.9.3: The adapter needs Node.js 22 or newer and Admin 7.6.20 or newer. Check this before updating.
From v0.9.3: If the polling interval is below 1 second or the number of retries is invalid, the adapter replaces it with the default at startup and warns once: Invalid polling interval "0", using 30 seconds or Invalid number of retry attempts "0", using 5 (#924). Correct the setting so that the warning goes away.
From v0.9.3: An outage appears in the log as a single warning, for example Unable to initialise 192.168.x.y will retry in scheduled interval ! or Heartbeat of device 192.168.x.y failed, will try to reconnect. The further attempts only appear at the level "debug" (#903, #788).
From v0.9.3: Every error appears in the log only once. The hand-over to Sentry only appears at the level "debug" (#913).
From v0.9.3: Devices that are added after the start are monitored as well and reconnect after an outage without a restart (#901). _info._online becomes false if a device doesn't answer for two polling intervals (#900).
From v0.9.3: The adapter discards a command to a device that is offline, with the warning Device <MAC> (192.168.x.y) is offline, command for <State> discarded (#904). on and bri keep their last value when the device goes offline and when the adapter starts (#899).
See also: Why doesn't my script set ps or on? · Which requirements does the adapter need? · How often does the adapter try to reach an offline device again? · What does "State attribute definition missing" mean?
Why does the adapter stop working after a WLED firmware update, or segments only work on one device?
This section is still being written.
Why is WLED shown as offline after a restart or update and takes a long time to reconnect?
This section is still being written.
Why do all WLED devices show red or offline, or the ESP crashes?
This section is still being written.
What do I do about multiple adapter processes, "already running" or onUnload errors?
This section is still being written.