ZST10 700 Controller Bricked during firmware update thru HA. Can SmartStart provisioning data be obtained from backups.

[john55021]

My Zooz ZST10 stick was bricked while trying to update the firmware through HA. Anyone else have this problem? Any documentation on how to recover from it with the least pain, like not having to factory reset every device.

Anyways, have ordered the new 800. I don't way to have to pop off the covers of all my switches, so is there any way of getting the DSK codes from my SmartStart provisioning files from a backup?

[kpine]

My Zooz ZST10 stick was bricked while trying to update the firmware through HA. Anyone else have this problem? Any documentation on how to recover from it with the least pain, like not having to factory reset every device.

It's really difficult to completely brick a 700 series. At worst, it will be stuck at the bootloader, which some might call a "soft brick". How are you determining that it is "bricked", to start with? What errors are you seeing? See https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs.

If it's stuck in at the bootloader, ZUI has an option to startup in bootloader mode (Z-Wave settings -> Bootloader only). After that you can try the update again.

is there any way of getting the DSK codes from my SmartStart provisioning files from a backup?

The SmartStart provisioning entries can be downloaded from the Smart Start panel. Hamburger Menu -> Export.

[john55021]

Thank you for replying. I'm assuming it's bricked because about 12% thru the uploading of the newest firmware, everything stopped. After waiting an hour I restarted my Pi, and nothing from zwave, the integration says "failed setup". From your advice, I did set it to bootloader, not sure what to do after that, so I restarted HA. In the Zwave integrations, it says "Failed Setup, will retry". In the UI, there is basically nothing there. Although in the UI it says "Bootleader is READY" and indicates connected. Here's the log from HA.

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service base-addon-banner: starting

Add-on: Z-Wave JS UI
Fully configurable Z-Wave JS gateway and control panel

Add-on version: 3.0.2
You are running the latest version of this add-on.
System: Home Assistant OS 10.5 (aarch64 / raspberrypi4-64)
Home Assistant Core: 2023.9.3
Home Assistant Supervisor: 2023.11.6

Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.

s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-zwave-js-ui: starting
s6-rc: info: service init-nginx: starting
s6-rc: info: service init-zwave-js-ui successfully started
s6-rc: info: service zwave-js-ui: starting
s6-rc: info: service zwave-js-ui successfully started
s6-rc: info: service discovery: starting
[19:54:40] INFO: Starting the Z-Wave JS UI...
s6-rc: info: service init-nginx successfully started
s6-rc: info: service nginx: starting
s6-rc: info: service nginx successfully started
2023-11-30 19:54:49.980 INFO APP: Version: 9.3.2
2023-11-30 19:54:50.008 INFO APP: Application path:/opt

---

|___ / \ \ / / | |/ | | | | | |
/ /\ \ /\ / /_ ___ _____ | | (___ | | | | | |
/ /\ / / / ' \ \ / / _ \ _ | |_ \ | | | | | |
/ / \ /\ / (| |\ V / / | || |) | | |__| || |
/| / / _,| _/ _| _/|/ _/|___|
2023-11-30 19:54:50.045 WARN STORE: scenes.json not found
2023-11-30 19:54:50.078 INFO APP: Listening on port 44920 protocol HTTP
2023-11-30 19:54:50.169 INFO MQTT: MQTT is disabled
2023-11-30 19:54:50.174 WARN BACKUP: Store backup is disabled
2023-11-30 19:54:50.177 WARN BACKUP: Nvm backup is disabled
2023-11-30 19:54:50.273 INFO Z-WAVE: Connecting to /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_38aff6294d45eb11bf4da552b003b68c-if00-port0
[19:54:50] INFO: Starting NGinx...
Logging to file:
/data/store/logs/zwavejs_2023-11-30.log
2023-11-30 19:54:50.324 INFO Z-WAVE: Zwavejs usage statistics ENABLED
2023-11-30 19:54:50.326 WARN Z-WAVE: Zwavejs driver is not ready yet, statistics will be enabled on driver initialization
2023-11-30 19:54:52.350 INFO Z-WAVE: Controller status: Bootloader is READY
2023-11-30 19:54:52.354 INFO Z-WAVE: Bootloader is READY
2023-11-30 19:55:06.297 INFO APP: GET /health/zwave 301 13.079 ms - 191
2023-11-30 19:55:36.525 INFO APP: GET /health/zwave 301 4.376 ms - 191
2023-11-30 19:56:06.680 INFO APP: GET /health/zwave 301 2.447 ms - 191
ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
at Object.xForwardedForHeader (/opt/node_modules/express-rate-limit/dist/index.cjs:166:13)
at Object.wrappedValidations. [as xForwardedForHeader] (/opt/node_modules/express-rate-limit/dist/index.cjs:324:22)
at Object.keyGenerator (/opt/node_modules/express-rate-limit/dist/index.cjs:579:20)
at /opt/node_modules/express-rate-limit/dist/index.cjs:629:32
at /opt/node_modules/express-rate-limit/dist/index.cjs:611:5 {
code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
}
2023-11-30 19:56:30.401 INFO APP: GET /api/auth-enabled 304 62.077 ms - -
2023-11-30 19:56:30.453 INFO APP: GET /logo.svg 304 10.226 ms - -
2023-11-30 19:56:30.468 INFO APP: GET /assets/MaterialIcons-Regular-5743ed3d.woff2 304 4.635 ms - -
2023-11-30 19:56:30.588 INFO Z-WAVE: Setting user callbacks
2023-11-30 19:56:31.773 INFO APP: GET /api/settings 200 1263.331 ms - 14008
2023-11-30 19:56:31.813 INFO APP: GET /api/auth-enabled 304 9.240 ms - -
2023-11-30 19:56:32.325 INFO APP: GET /sw.js 304 4.056 ms - -
2023-11-30 19:56:36.833 INFO APP: GET /health/zwave 301 2.314 ms - 191
ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
at Object.xForwardedForHeader (/opt/node_modules/express-rate-limit/dist/index.cjs:166:13)
at Object.wrappedValidations. [as xForwardedForHeader] (/opt/node_modules/express-rate-limit/dist/index.cjs:324:22)
at Object.keyGenerator (/opt/node_modules/express-rate-limit/dist/index.cjs:579:20)
at /opt/node_modules/express-rate-limit/dist/index.cjs:629:32
at /opt/node_modules/express-rate-limit/dist/index.cjs:611:5 {
code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
}
2023-11-30 19:56:50.305 INFO APP: GET /api/store 200 38.289 ms - 2419
2023-11-30 19:56:55.615 INFO Z-WAVE: Calling api _getScenes with args: [ [length]: 0 ]
2023-11-30 19:56:55.621 INFO Z-WAVE: Success zwave api call _getScenes [ [length]: 0 ]
2023-11-30 19:56:58.178 INFO APP: GET /api/settings 304 1147.542 ms - -
2023-11-30 19:56:58.239 INFO APP: GET /api/auth-enabled 304 6.230 ms - -
2023-11-30 19:56:59.945 INFO Z-WAVE: Calling api getProvisioningEntries with args: [ [length]: 0 ]
2023-11-30 19:56:59.953 INFO Z-WAVE: Driver is not ready getProvisioningEntries undefined
2023-11-30 19:57:07.003 INFO APP: GET /health/zwave 301 2.059 ms - 191
2023-11-30 19:57:18.925 INFO Z-WAVE: Removing user callbacks
2023-11-30 19:57:37.157 INFO APP: GET /health/zwave 301 1.901 ms - 191
2023-11-30 19:58:07.337 INFO APP: GET /health/zwave 301 2.230 ms - 191
2023-11-30 19:58:37.503 INFO APP: GET /health/zwave 301 3.869 ms - 191
2023-11-30 19:59:07.663 INFO APP: GET /health/zwave 301 1.831 ms - 191
2023-11-30 19:59:37.832 INFO APP: GET /health/zwave 301 1.459 ms - 191
2023-11-30 20:00:08.013 INFO APP: GET /health/zwave 301 1.743 ms - 191

[kpine]

From your advice, I did set it to bootloader, not sure what to do after that, so I restarted HA.

You can't control Z-Wave with HA in this state. You can try and update the controller firmware again from Z-Wave JS UI's control panel once the bootloader mode is on.

Here's the log from HA.

These aren't the driver debug logs, please see the link I posted before to enable and download those logs.

[john55021]

Sorry, when I said restarted HA, I meant pulled the plug on the PI. After restart, I couldn't get into the store, just get the old twirling wait icon, even though it says connected on the top right. When I pull the 700 from the PI, it recognizes that. Plug it back in, the USB error message goes away, but still waiting.

BTW, I ran Simplicity Studio and it recognized the device but couldn't connect.

I'm not a Linux guy at all, but didn't pay attention to what USB port (4 of them) I had the device plugged into on the PI when I tried Simplicity Studio on my PC. Does that make a difference if I accidently put it in a different USB port?

[kpine]

After restart, I couldn't get into the store, just get the old twirling wait icon, even though it says connected on the top right.

I'm not sure what the waiting icon is in regards to, haven't seen it. The Store should always be accessible, I can access it even if nothing is configured, but admittedly I haven't tried in this state.

BTW, I ran Simplicity Studio and it recognized the device but couldn't connect.

I'm not sure whether Simplicity Studio can handle a controller that is stuck at the bootloader menu, if that's what is happening.

I'm not a Linux guy at all, but didn't pay attention to what USB port (4 of them) I had the device plugged into on the PI when I tried Simplicity Studio on my PC. Does that make a difference if I accidently put it in a different USB port?

It should not, unless your USB path is referencing the physical port (e.g. /dev/serial/by-path). Using the /dev/serial/by-id/... path will ensure it always finds the device. If you use /dev/ttyUSB0, it's possible plugging and re-plugging could change it to /dev/ttyUSB1.

[john55021]

Thank you so much for trying to help me. At this point, I"m resigned to a new stick, and just trying to see if anyone has some steps to ease the pain.