Decode-config fails to restore unmodified backup on tasmota 15.5.0

[ryaske]

Describe the bug

using decode-config on latest version 15.5.0 to export the config, and then restore it (without modification) causes warning and a failure to restore the config.

To Reproduce

Steps to reproduce the behavior:
PS C:\Users\S\Downloads> python decode-config.py --source 192.168.1.160 --backup-file clean-av-receiver-v15.json
INFO: Load data by http from device '192.168.1.160'
INFO: Backup successful to '.\clean-av-receiver-v15.json' (JSON format)

PS C:\Users\S\Downloads> python decode-config.py --source 192.168.1.160 --restore-file clean-av-receiver-v15.json
INFO: Load data by http from device '192.168.1.160'
WARNING 9: file '.\clean-av-receiver-v15.json' - {'ds3502_state': 255} (valid range exceeding)
Premature exit - #9 Restore data error
WARNING 9 (@6068): file '.\clean-av-receiver-v15.json' array 'ds3502_state' couldn't restore, format has changed! Restore value contains <class 'list'> but an array of size [4] is expected
Premature exit - #9 Restore data error

Expected behavior

I expect the unmodified backup file to restore without issue to the same version of tasmota

Version Information

PS C:\Users\S\Downloads> python decode-config.py -V --debug
decode-config.py v15.5.0.2 [36f92ed] by Norbert Richter pypi.org@ricno.de

Script: decode-config.py
Version: 15.5.0.2 [36f92ed]
Python: 3.13.13
Platform: Windows-11-10.0.26200-SP0 - AMD64
OS: Windows 11 10.0.26200
Time: 2026-08-19 17:40:35

System' information of your Tasmota data

Append -g System to your decode-config parameter, e. g. decode-config.py -s myconfig.dmp -g System

PS C:\Users\S\Downloads> python decode-config.py --source 192.168.1.160 --restore-file clean-av-receiver-v15.json -g System
INFO: Load data by http from device '192.168.1.160'
INFO: Restore skipped, configuration data unchanged

*** I am not sure this is the intended output? Might be a second bug here.... I even went back, made a [small, IP address last octet] change to the JSON, and attempted to restore it with -g System exactly like I tried above, and I receive the same [incorrect] INFO line claiming the configuration data is unchanged. ***

Additional context

I spent a lot of time trying to upgrade a tasmota v7 on Sonoff S31 to the latest v15. I was successful after having to make many manual modifications to the .json backup as I went. However, as a final step, i wanted to change the IP address, so I made one last modification to the config file and tried uploading it back, and ran into this problem even trying to restore the same exact config back to the same esp on the same version of tasmota. So I am pretty sure it must be a bug in decode-config.py

[curzon01]

Dupilcate: see #84, #116

Your issue cause is well described:

WARNING 9: file '.\clean-av-receiver-v15.json' - {'ds3502_state': 255} (valid range exceeding)

Solutions (one of these, not all together):

• Use the --ignore-warnings (or -w).
• Correct the value for ds3502_state in your JSON backup file
• To change only the IP address, why not use decode-config’s ability to use partial JSON backups as described in Restore subset of data?
  Create a JSON file with only the following content:

{
  "config_version": x,
  "ip_address": [
    "a.a.a.a", 
    "x.x.x.x.", 
    "x.x.x.x", 
    "x.x.x.x", 
    "x.x.x.x"
  ]
}

a.a.a.a is the new IP-address, x are the values from your JSON backup. You only need the config_version key if your target ESP is an ESP32. Finally restore this JSON.

[ryaske]

I solved my specific problem simply by using ipaddress1 command in console, which was much faster.

I have never used a ds3502 sensor in any of my configurations so I never set that value intentionally. Per the upgrade instructions I was using reset 3 command before every firmware upgrade step. So I don't understand how this is not a bug in the current tasmota version, given a) I never set this value manually, b) the firmware did accept the value at one point (as it is currently set), and c) the UI backup and restore buttons deal with this value without complaint.

If the value is not valid configuration, how did it manage to be set in the first place, and why is it only decode-config.py that complains about it? That is the bug I was reporting.

I understand that it's not currently a feature but it would save a lot of time if there was a command like --fix-warnings which would reset bad values to something acceptable for that version rather than just ignoring them or preventing restore altogether

[curzon01]

Per the upgrade instructions I was using reset 3 command before every firmware upgrade step. So I don't understand how this is not a bug in the current tasmota version

This may be, but then it's an issue for Tasmota, not decode-config for Tasmota

If the value is not valid configuration, how did it manage to be set in the first place,

I can't tell you

and why is it only decode-config.py that complains about it? That is the bug I was reporting.

because Tasmota and decode-config does not verify each value in your settings when you handle binary configs (see different config formats).
You only notice that because decode-config checks the values from JSON files one by one.
decode-config also has no way of knowing where a JSON file comes from; it might be from a decode-config backup, or it might have been created entirely by hand when you read it back, since — unlike binary configs — it can be edited individually.

I understand that it's not currently a feature but it would save a lot of time if there was a command like --fix-warnings which would reset bad values to something acceptable

what is a "something acceptable" value?
decode-config just doesn't know that. It might be trivial for this particular value, but there are settings that you can't just set to any value.

for that version rather than just ignoring them or preventing restore altogether

user must determine what went wrong when values outside the permissible range were set.