Shelly Wave Plug S (qnpl-0A112EU): Error_InvalidFirmwareTarget after successful fragment transfer (10.4.0 → 12.2)

[kayloehmann]

Device

Field	Value
Brand	Shelly
Model	Wave Plug S (EU)
Catalog file	firmwares/shelly/qnpl-0A112EU.json
manufacturerId	0x0460
productType	0x0002
productId	0x0087
Current firmware	10.4.0
Target firmware	12.2

Symptom

Firmware update is offered by the OTA registry and starts successfully. All fragments are transmitted (100% progress), but the device then rejects the update:

[Node 009] Sending firmware fragment 9856 / 9856
[Node 009] Firmware update (part 1 / 1) failed with status Error_InvalidFirmwareTarget

HA entity update.steckerleiste_firmware reports in_progress: false, installed version remains 10.4.0.

Context

• Z-Wave JS Add-on: 1.4.0 (Home Assistant Core 2026.6.2)
• The update attempt was triggered via Home Assistant's update entity
• The catalog entry for qnpl-0A112EU.json does not specify an explicit target field in the upgrade files (defaults to target 0 per _example.json)

Possibly related

This failure pattern is identical to #107 (Aeotec ZW187), where all fragments transfer successfully but the device returns Error_InvalidFirmwareTarget. The root cause in that issue remains unresolved.

I'm not sure whether the issue lies in the catalog entry (e.g. incorrect/missing target field) or in the firmware binary itself. Happy to provide additional Z-Wave JS debug logs if that helps diagnose — what information would be most useful?

Additional notes

This issue was discovered after fixing a separate KeyError: 'continuesToFunction' crash in zwave-js-server-python that was preventing the update attempt from even starting (fixed in zwave-js-server-python#1435, available in 0.72.0). With that bug fixed, the Error_InvalidFirmwareTarget now surfaces as the actual failure.

[AlCalzone]

@QubinoHelp any idea?

[AlCalzone]

@kayloehmann can you share a log with the first few seconds of the firmware update attempt?

[kayloehmann]

Here are the logs from the first few seconds of the firmware update attempt (first of three attempts that all failed identically):

2026-06-11 08:54:59.595 CNTRLR   [Node 009] OTA firmware update started, downloading 1 updates...
2026-06-11 08:54:59.597 CNTRLR   [Node 009] Downloading firmware update 0 of 1...
2026-06-11 08:54:59.808 CNTRLR   [Node 009] All updates downloaded, validating device IDs...
2026-06-11 08:55:00.070 CNTRLR   [Node 009] Device IDs match, installing firmware updates...
2026-06-11 08:55:00.271 CNTRLR   [Node 009] Updating firmware (part 1 / 1)...
2026-06-11 08:55:00.273 CNTRLR » [Node 009] Starting firmware update...
2026-06-11 08:55:00.880 CNTRLR » [Node 009] Sending firmware fragment 1 / 9856
2026-06-11 08:55:00.947 CNTRLR » [Node 009] Sending firmware fragment 2 / 9856
[... all 9856 fragments sent ...]
2026-06-11 09:05:18.445 CNTRLR « [Node 009] Firmware update (part 1 / 1) failed with status Error_InvalidFirmwareTarget

Three attempts total (08:54, 09:58, 10:59), all with the same result — all fragments transmitted successfully, then the device rejects with Error_InvalidFirmwareTarget.

The standard Z-Wave JS log level doesn't show which firmware target was selected. The catalog entry for qnpl-0A112EU doesn't specify an explicit target, so target 0 is used by default. However, the device reports additional firmware IDs: [2] during the interview, meaning it has two firmware slots (target 0 and target 1).

Would it help if I enabled Z-Wave JS debug logging and triggered another update attempt? Or is the target selection visible at a lower log level you'd like me to enable?

[AlCalzone]

I should have specified - debug loglevel. Just the first few frames (e.g. until fragment 2) are enough.

[kayloehmann]

After further analysis, I believe I've found the root cause without needing debug logs.

Key findings:

The GBL firmware binary (Wave_PlugS_800_EU_LR_20260205_1034_QLPL-0A112EU_[12.02]_0FE4B35C.gbl) is AES-encrypted (Silicon Labs Secure Boot). The ApplicationProperties_t struct — which declares the target in the encrypted blob — is not readable. The GBL header's type field (0x0101) does not encode the target.

Why target 0 is wrong:

The device reports additional firmware IDs: [2] during the node interview. Per Z-Wave spec, this means the device has two OTA firmware targets:

• Target 0: main firmware (firmware ID from the main version report)
• Target 1: secondary firmware with firmware ID 2

The current catalog entry for version 12.2 has no target in the files array, so Z-Wave JS defaults to target 0. All 9856 fragments transmit successfully (so the image downloads fine and the target 0 slot accepts the transmission), but then the device rejects with Error_InvalidFirmwareTarget — the classic symptom of sending an image intended for another slot.

Proposed fix:

Add "target": 1 to the files entry in qnpl-0A112EU.json:

"files": [
  {
    "target": 1,
    "url": "...",
    "integrity": "..."
  }
]

I'll open a PR for this. Please let me know if you want me to first try this locally to confirm, or if you can verify which target the firmware image is designed for through your Shelly contacts.

[AlCalzone]

Yes please confirm this locally by manually specifying the target.

[kayloehmann]

Here are the debug logs from the firmware update initiation (Z-Wave JS Add-on 1.4.0, debug log level):

2026-06-11 14:06:03.011 CNTRLR   [Node 009] OTA firmware update started, downloading 1 updates...
2026-06-11 14:06:03.455 CNTRLR   [Node 009] All updates downloaded, validating device IDs...
2026-06-11 14:06:03.910 CNTRLR   [Node 009] Device IDs match, installing firmware updates...

2026-06-11 14:06:04.041 DRIVER « [Node 009] FirmwareUpdateMetaDataCCMetaDataReport
                                     manufacturer id:         1120 (0x0460)
                                     firmware id:             647  (0x0287)
                                     checksum:                0
                                     firmware upgradable:     true
                                     max fragment size:       28
                                     additional firmware IDs: [2]
                                     hardware version:        1

2026-06-11 14:06:04.112 CNTRLR   [Node 009] Updating firmware (part 1 / 1)...
2026-06-11 14:06:04.115 CNTRLR » [Node 009] Starting firmware update...

2026-06-11 14:06:04.133 DRIVER » [Node 009] FirmwareUpdateMetaDataCCRequestGet
                                     manufacturer id:     0x0460
                                     firmware id:         0x0287
                                     checksum:            0x5c1e
                                     firmware target:     0        ← sent to target 0
                                     fragment size:       28
                                     activation:          false
                                     resume:              false

Key observation: the device reports additional firmware IDs: [2], meaning it has two firmware targets — target 0 (firmware ID 0x0287 = 647) and target 1 (firmware ID 2). Z-Wave JS sends the update to target 0 (default, since the catalog entry doesn't specify a target).

My hypothesis: maybe the 12.2 firmware file in the catalog is actually intended for target 1 (firmware ID 2), and sending it to target 0 causes the device to reject it with Error_InvalidFirmwareTarget. Could the catalog entry be missing "target": 1?

[kayloehmann]

Here are the debug logs as requested. Z-Wave JS version: 15.24.2, server: 3.9.0.

Key observations from the logs:

1. Device reports via FirmwareUpdateMetaDataCCMetaDataReport:

   • firmware id: 647 (= 0x0287)
   • additional firmware IDs: [2]
   • max fragment size: 28

2. Z-Wave JS sends FirmwareUpdateMetaDataCCRequestGet with:

   • firmware id: 0x0287
   • firmware target: 0

3. Device responds with status: OK — then all 9856 fragments are transmitted successfully

4. After all fragments: device sends FirmwareUpdateMetaDataCCStatusReport with status: Error_Checksum

Note on error inconsistency: Earlier attempts (with an older Z-Wave JS add-on container, same 1.4.0 image) failed with Error_InvalidFirmwareTarget instead of Error_Checksum. Today's attempts consistently produce Error_Checksum. Not sure what changed — possibly the firmware binary was re-fetched/updated in the catalog.

Debug log (from OTA start to fragment 2):

2026-06-11 14:06:03.011 CNTRLR   [Node 009] OTA firmware update started, downloading 1 updates...
2026-06-11 14:06:03.015 CNTRLR   [Node 009] Downloading firmware update 0 of 1...
2026-06-11 14:06:03.455 CNTRLR   [Node 009] All updates downloaded, validating device IDs...
[ManufacturerSpecificCCGet → ManufacturerSpecificCCReport]
2026-06-11 14:06:03.576 CNTRLR   [Node 009] [~] [Manufacturer Specific] productId: 135 => 135      [Endpoint 0]
2026-06-11 14:06:03.583 CNTRLR   [Node 009] [~] [Manufacturer Specific] productType: 2 => 2        [Endpoint 0]
2026-06-11 14:06:03.588 CNTRLR   [Node 009] [~] [Manufacturer Specific] manufacturerId: 1120 => 1120 [Endpoint 0]
  └─[ManufacturerSpecificCCReport]
      manufacturer id: 0x0460
      product type:    0x02
      product id:      0x87
[VersionCCGet → VersionCCReport]
2026-06-11 14:06:03.717 CNTRLR   [Node 009] [~] [Version] hardwareVersion: 1 => 1                  [Endpoint 0]
2026-06-11 14:06:03.723 CNTRLR   [Node 009] [~] [Version] firmwareVersions: 10.4,2.4 => 10.4,2.4   [Endpoint 0]
  └─[VersionCCReport]
      library type:      Enhanced Slave
      protocol version:  7.21
      firmware versions: 10.4, 2.4
      hardware version:  1
[VersionCCZWaveSoftwareGet → VersionCCZWaveSoftwareReport]
  └─[VersionCCZWaveSoftwareReport]
      SDK version:                  7.21.4
      application version:          10.4.0
      application build number:     1685
2026-06-11 14:06:03.910 CNTRLR   [Node 009] Device IDs match, installing firmware updates...
[FirmwareUpdateMetaDataCCMetaDataGet → FirmwareUpdateMetaDataCCMetaDataReport]
2026-06-11 14:06:04.034 CNTRLR   [Node 009] [~] [Firmware Update Meta Data] additionalFirmwareIDs: 2 => 2 [Endpoint 0]
  └─[FirmwareUpdateMetaDataCCMetaDataReport]
      manufacturer id:         1120
      firmware id:             647
      max fragment size:       28
      additional firmware IDs: [2]
      hardware version:        1
2026-06-11 14:06:04.112 CNTRLR   [Node 009] Updating firmware (part 1 / 1)...
2026-06-11 14:06:04.115 CNTRLR » [Node 009] Starting firmware update...
  └─[FirmwareUpdateMetaDataCCRequestGet]
      manufacturer id:     0x0460
      firmware id:         0x0287
      checksum:            0x5c1e
      firmware target:     0
      fragment size:       28
      activation:          false
      resume:              false
      non-secure transfer: false
      hardware version:    1
  └─[FirmwareUpdateMetaDataCCRequestReport]
      status: OK
[Node requests fragment 1]
  └─[FirmwareUpdateMetaDataCCGet]
      total # of reports: 7
      report number:      1
2026-06-11 14:06:04.752 CNTRLR » [Node 009] Sending firmware fragment 1 / 9856
  └─[FirmwareUpdateMetaDataCCReport]
      report #: 1
      is last:  false
2026-06-11 14:06:04.873 CNTRLR » [Node 009] Sending firmware fragment 2 / 9856
  └─[FirmwareUpdateMetaDataCCReport]
      report #: 2
      is last:  false
[... 9854 more fragments ...]
  └─[FirmwareUpdateMetaDataCCStatusReport]
      status:    Error_Checksum
      wait time: 2 seconds

The firmware binary used has checksum 0x5c1e and Z-Wave JS sends it to target 0 with firmware ID 0x0287. The device accepts the request (status: OK) and receives all 9856 fragments before rejecting with Error_Checksum.

Since additional firmware IDs: [2] indicates target 1 exists with firmware ID 2 — could the wrong firmware file be matched for this device? The device has two firmware targets (firmwareVersions: 10.4, 2.4).

[AlCalzone]

Can you download the gbl file manually if you haven't already? Then do not use the OTA update panel to perform the update, but rather the advanced menu -> OTA button.

That should allow you to specify target 1 to test your hypothesis.

The odd thing about this is that the firmware version looks like it should be for target 0 though, and target 0 is also by definition the Z-Wave chip.

[kayloehmann]

I tested your suggestion using the Z-Wave JS WebSocket API directly (Z-Wave JS UI was not accessible programmatically, but the server WebSocket at port 3000 gave equivalent results).

Target 1 result:

ZW1501: Failed to start the update: Firmware target #1 is not upgradable!

Z-Wave JS queries the device capabilities before initiating the transfer, and the device explicitly reports target 1 as not upgradable. So target 1 is ruled out.

Target 0 result (for reference):
All 9856 fragments transmit successfully, then the device rejects with Error_Checksum in recent attempts. Earlier attempts (with the add-on running Z-Wave JS 15.24.2, same container) produced Error_InvalidFirmwareTarget instead — the change between errors is suspicious and may indicate the firmware binary on GitHub was quietly updated between attempts.

Current state:

• Target 0 = main Z-Wave chip firmware (upgradable), but the binary fails post-transfer with checksum or target error
• Target 1 = secondary component, explicitly NOT upgradable via OTA

Would it be worth verifying the integrity of the current GBL binary in the catalog? The checksum Z-Wave JS reports for the file is 0x5c1e (CRC-16 of the 275968-byte GBL). The file hash in the catalog is sha256:d6ff2545198f52f075d3024bebd7ce56d212dc65551eac874233eaf9503580a8.

Also noting a side bug: parseFirmwareFile in @zwave-js/server 3.9.0 does not wrap tryUnzipFirmwareFile in a try-catch, so sending a raw .gbl file via the WebSocket API throws invalid zip data (fflate error) instead of falling through to the GBL parser. The workaround is wrapping the GBL in a ZIP first — but this is a separate issue.

[QubinoHelp]

Hi to both,

Sorry for the delayed response.

I've tested the upgrade process from firmware version 10.04 to 12.2 and confirmed that there appears to be an issue. We also attempted the update using the PC Controller and observed the same behavior.

I've also tried performing the firmware update using Target 1, but this had no effect. The other target does not appear to be valid, including when tested through the PC Controller.

We will open a task for our developers to investigate the issue further.