Partial POST /json/cfg resets settings it does not mention (linked remotes, FPS, auto-white mode, gamma)

[Tycorc]

What happened?

After I sent a small POST /json/cfg that only changed the LED power cap, the WiZmote I had paired stopped working. GET /json/cfg showed "linked_remote": [] where it had shown my remote's MAC before, and the empty list survived a reboot.

Reading wled00/cfg.cpp (deserializeConfig), this seems to be what the code does when the posted document has no nw object: linked_remotes.clear() runs before the lookup of nw.linked_remote, and the list is only refilled when that key is present.

  JsonObject nw = doc["nw"];
#ifndef WLED_DISABLE_ESPNOW
  CJSON(enableESPNow, nw[F("espnow")]);
  linked_remotes.clear();
  JsonVariant lrem = nw[F("linked_remote")];
  if (!lrem.isNull()) {

The neighbouring lists in the same function (nw.ins, dns, hw.btn.ins, bus ins, timers) appear to be guarded by an isNull() check, so a partial POST leaves them alone. I may be missing a reason why the remote list is handled differently; if the JSON API is expected to always send the complete nw block, this is a documentation question rather than a bug, and I would be glad to know.

As far as I can tell from the history, the earlier single-remote code used getStringFromJson, which does not touch the variable when the key is absent, and the behaviour changed with the multi-remote support in #4654. I have not bisected that, it is from reading the diff.

To Reproduce Bug

1. Pair a WiZmote via WiFi settings → Linked MACs, confirm GET /json/cfg shows the MAC under nw.linked_remote.
2. curl -X POST -H 'Content-Type: application/json' -d '{"hw":{"led":{"maxpwr":4000}}}' http://<wled>/json/cfg
3. GET /json/cfg → "linked_remote": [], remote no longer reacts, still empty after reboot.

Sending the same POST with "nw":{"espnow":true,"linked_remote":["<mac>"]} included keeps the remote, which is what I do now as a workaround.

Expected Behavior

I expected a /json/cfg write to leave settings it does not mention unchanged, as it does for the WiFi list and the buttons. If that expectation is right, moving the clear() inside the if (!lrem.isNull()) block, or guarding the block with if (!nw.isNull()), would be one possible fix. Happy to open a PR if a maintainer confirms the intended behaviour.

Install Method

Self-Compiled

What version of WLED?

16.0.0 (build 2605030) on the device; the same lines are present in the 16.0.1 tag and in main as of 2026-10-03, which I only checked by reading, not by flashing.

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

GET  /json/cfg  -> "nw":{"espnow":true,"linked_remote":["4cebd6203de7"], ...}
POST /json/cfg  {"hw":{"led":{"maxpwr":4000}}}  -> {"success":true}
GET  /json/cfg  -> "nw":{"espnow":true,"linked_remote":[], ...}

Anything else?

Seen from home automation that writes single settings over the JSON API. The settings web form is not affected as far as I can see, since it submits the whole list every time.

Update 2026-10-04

Same function, 4 more settings reset on a partial POST, different cause: hw.led.rgbwm, hw.led.fps, light.gc.bri and light.gc.col fall back to a constant when the key is missing (cfg.cpp L183, L189, L531, L532 on main). After a POST with only hw.led.maxpwr: fps 30 back to 42, auto-white mode back to disabled, Brightness Gamma off, a disabled colour Gamma on again, all written to cfg.json. Confirmed on ESP8266 with 16.0.1 and main. Details in the comments, fix is in #5885 as a second commit.

[DedeHai]

The cfg endpoint is tailored to the config htm pages, I dont think it is cosidered an API to be used as it can mess things up, as you discovered. I think KB even states not to use that endpint.

Edit: I cant currently check code, so there may be a legit bug here

Edit2: @Tycorc can you check how other vector lists differ from the remote wrt the code you posted above? I.e. clear and rebuild?

[willmmiles]

The cfg endpoint is tailored to the config htm pages, I dont think it is cosidered an API to be used as it can mess things up, as you discovered. I think KB even states not to use that endpint.

We should probably keep tabs on this, given the intent to replace the settings UI. Native JSON cfg writing is the obvious alternative.

[blazoncek]

/json/cfg is a configuration endpoint for JSON capable configurators (like xLights, LedFX, etc). Configuration JSON submitted should work with partially filled config keys.

This is a bug. Cause: cfg.cpp L:65

[Tycorc]

@DedeHai checked against main (1252853). linked_remotes is the only list in deserializeConfig whose clear runs outside the key's presence check. The others clear and rebuild only when their array is in the document:

list	guard	clear
strip.panel	if (!matrix.isNull())	strip.panel.clear() inside the guard (cfg.cpp ~L195/199)
buttons	if (!hw_btn_ins.isNull())	buttons.clear() inside the guard (~L367/370)
timers	if (!timersArray.isNull())	clearTimers() inside the guard (~L705/706)
busConfigs	if (!ins.isNull())	cleared only in the else if (fromFS) branch (~L264/267), so a partial POST leaves the buses alone
multiWiFi	if (!nw_ins.isNull())	never cleared, resized and overwritten in place (~L87/89)
linked_remotes	if (!lrem.isNull())	linked_remotes.clear() before the guard (L65)

Before #4654 the single remote was read with getStringFromJson(linked_remote, nw[F("linked_remote")], 13), which leaves the variable untouched when the key is absent, so the partial-POST case used to be safe. The vector port moved the reset in front of the lookup.

Minimal fix is to move the clear inside the guard, matching the other lists:

  JsonVariant lrem = nw[F("linked_remote")];
  if (!lrem.isNull()) {
    linked_remotes.clear();
    if (lrem.is<JsonArray>()) {

An explicit "linked_remote": [] still empties the list, so the settings page's unpair path is unchanged. I can open the PR against main if that shape is what you want.

[softhack007]

@Tycorc you are an AI agent? I've never seen humans who use tables to explain a simple fix.

But it might be a correct fix, we can check.

[Tycorc]

Sry didn't Double check the post, only the proposed fix.

…

On Sun, Oct 4, 2026, at 14:10, Frank Möhle wrote: *softhack007* left a comment (wled/WLED#5883) <#5883 (comment)> @Tycorc <https://github.com/Tycorc> you are an AI agent? I've never seen human who use tables to explain a simple fix. But it might be a correct fix, we can check. — Reply to this email directly, view it on GitHub <#5883?email_source=notifications&email_token=AJFGXFVH3NH47B2RF7EPALL5SI4ZVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJXHE3TOMJSGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5979771244>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJFGXFUZSRZ6RN6SYR6FHL35SI4ZVAVCNFSNUABEKJSXA33TNF2G64TZHM3TMOJZGAZDAOJ3JFZXG5LFHM2TMOJRHE3TSMJSGCQXMAQ>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AJFGXFTKTQAMWOXHO3MLTY35SI4ZVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJXHE3TOMJSGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AJFGXFR52NYOWVM3HTGBB4L5SI4ZVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJXHE3TOMJSGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[softhack007]

I can open the PR against main if that shape is what you want.

@Tycorc if your suggested change solves it for you, yes feel free to open a PR. We can continue our discussion when reviewing the PR.

Please be sure to read though our contributor guidelines https://github.com/wled/WLED?tab=contributing-ov-file first, especially in case you want to use AI assistance for the PR.

[Tycorc]

While testing #5885 i found 4 more Settings that get resetted on a partial /json/cfg post, same function, different cause. They fall back to a constant when the key is missing instead of the current value like CJSON does for the rest. cfg.cpp on main:

L183: Bus::setGlobalAWMode(hw_led[F("rgbwm")] | AW_GLOBAL_DISABLED);
L189: unsigned targetFPS = hw_led["fps"] | WLED_FPS;
L531: float light_gc_bri = light["gc"]["bri"] | 1.0f;
L532: float light_gc_col = light["gc"]["col"] | gammaCorrectVal;

Result after a post with only hw.led.maxpwr: fps 30 back to 42, rgbwm back to disabled, Brightness Gamma off, and a disabled colour Gamma turns on again. All written to cfg.json. Confirmed on my 8266 with 16.0.1 and main. The constants came from the fresh install fixes #5225 and #5408, Brightness Gamma is resetted since 0.14 and #5225 fixed only the colour half.

Fix is the same 4 lines with fallback = current value, fresh install still gets the defaults cause nothing wrote the variables at that point. Tested on the 8266, builds for esp32dev and nodemcuv2.

Kinda the same bug i would assume. Will wait for advise how to proceed, seperate issue + Pull request or add it to #5885.

[Aircoookie]

Will wait for advise how to proceed, seperate issue + Pull request or add it to #5885.

Given that the proposed fixes aim to solve more instances of the same underlying issue, feel free to add it to #5885 :)

[Tycorc]

@Aircoookie done.