Did I fry my UZB-7 dongle?

[bushvin]

Hi,

I performed a Firmware upgrade of my Silicon Labs CP2102N (UZB-7) 700 series controller.

Ever since, all my nodes seem to be dead. Only when a report is triggered from the device, does it seem to work. Pinging a live node marks it Dead.

At some point all my nodes came back (don't ask me how, it just happened), and worked fine, but after rebooting the system, everything went FUBAR again. I am not fluent in zwavejsui logs, so I was hoping if someone could give me some pointers in how to resolve my issue...

Running on Raspi 4, bullseye. Docker v20.10.5 image: zwavejs/zwave-js-ui:8.5.0

Attached are the silly logs of my instance zwavejs_2022-11-21.log.gz

[jmgiaever]

Have you tried to re-interview a node to check if that helps? This should probably be registered with zwave-js and not with zui.

@AlCalzone

[bushvin]

@jmgiaever I spent (lost) all saturday doing just that. Going around and reinterviewing every node, and then healing it, to have it all undone with a reboot of the device. But I'll try that again.

I'm wondering if I should just create a new docker volume, in order to be able to start with a clean slate... I've been using zwave2mqtt ever since v 1.4 I.

[jmgiaever]

Ok, you'll tried that. I guess if it didn't work, it won't help doing it again.

I can be that there's something that got corrupt during the upgrade. Did you take a backup?

Can you check the power output and "measured power output" under the controller node?

[robertsLando]

@bushvin I think that restoring an old nvm backup would be the best in this situation. Hope you had atuomatic nvm backup turned on in settings 🤞🏼

About logs only @AlCalzone could help with them

[bushvin]

Can you check the power output and "measured power output" under the controller node?

this is what it yields:

09:45:55.022 DRIVER » [REQ] [SerialAPISetup]
                        command: GetPowerlevel
                        payload: 0x08
09:45:55.036 DRIVER « [RES] [SerialAPISetup]
                        command:               GetPowerlevel
                        normal powerlevel:     0.0 dBm
                        output power at 0 dBm: 3.3 dBm
09:45:55.059 DRIVER » [REQ] [SerialAPISetup]
                        command: GetRFRegion
                        payload: 0x20
09:45:55.071 DRIVER « [RES] [SerialAPISetup]
                        command: GetRFRegion
                        region:  Europe

[robertsLando]

A quick review of what I noticed in logs:

2022-11-21T00:43:05.173Z DRIVER « [Node 058] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -96 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Security2CC_NoSPAN
2022-11-21T00:43:05.175Z CNTRLR » [Node 058] No SPAN is established yet, cannot decode command. Requesting a non
2022-11-21T00:43:05.177Z CNTRLR » [Node 058] pinging the node...
2022-11-21T00:43:05.242Z SERIAL « 0x011d00a800013a149f03d5002c59f104421607dc51a19f3edb12258c009f8d    (31 bytes)
2022-11-21T00:43:05.244Z DRIVER   Dropping message with invalid payload
2022-11-21T00:43:05.245Z DRIVER « [Node 058] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -97 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Duplicate command
(LOT OF DUPLICATE COMMANDS)

Both this errors are thrown multiple times by nodes 71 and 58.

The other nodes that don't respond just fails the initial ping:

2022-11-21T00:38:53.047Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            2
                                    transmit status:        NoAck, took 7150 ms
                                    routing attempts:       31
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    TX channel no.:         1
                                    TX power:               0 dBm
                                    measured noise floor:   0 dBm
2022-11-21T00:38:53.056Z CNTRLR   [Node 004] The node did not respond after 1 attempts, it is presumed dead
2022-11-21T00:38:53.058Z CNTRLR   [Node 004] The node is dead.
2022-11-21T00:38:53.072Z CNTRLR   [Node 004] ping failed: Failed to send the command after 1 attempts (Status No
                                  Ack) (ZW0204)

Interesting thing here is that all them report TX Power: 0dBm, could be that the reason? @AlCalzone

[bushvin]

@bushvin I think that restoring an old nvm backup would be the best in this situation. Hope you had atuomatic nvm backup turned on in settings 🤞🏼

Actually I did not. I only discovered this functionality after updating the firmware. Talk about shooting oneself in the foot.

About logs only @AlCalzone could help with them I wonder if there's something wrong with my security setup, I'm seeing a lot of these messages: Security2CCMessageEncapsulation] [INVALID]

2022-11-21T00:43:05.173Z DRIVER « [Node 058] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -96 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Security2CC_NoSPAN
2022-11-21T00:43:05.175Z CNTRLR » [Node 058] No SPAN is established yet, cannot decode command. Requesting a non
2022-11-21T00:43:05.177Z CNTRLR » [Node 058] pinging the node...
2022-11-21T00:43:05.242Z SERIAL « 0x011d00a800013a149f03d5002c59f104421607dc51a19f3edb12258c009f8d    (31 bytes)
2022-11-21T00:43:05.244Z DRIVER   Dropping message with invalid payload
2022-11-21T00:43:05.245Z DRIVER « [Node 058] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -97 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Duplicate command
(LOT OF DUPLICATE COMMANDS)

These two nodes are the only 2 I have of that brand and model: Popp Smart Outdoor Plug - IP44 rated

Maybe they're somehow flooding the mesh? I'll try to remove them and see if it improves things.

[robertsLando]

Maybe they're somehow flooding the mesh? I'll try to remove them and see if it improves things.

Wait a bit if possible, let's see if @AlCalzone can tell us more

[bushvin]

Wait a bit if possible, let's see if @AlCalzone can tell us more

Will do

I seem to have no group information on the controller and most of the devices.

also, my controller doesn't seem to have any neighbors

{
  "id": 1,
  "name": "silabs_zst10_700_00",
  "loc": "",
  "values": [],
  "groups": [],
  "neighbors": [],
  "ready": true,
  "available": true,
  "hassDevices": {},
  "failed": false,
  "inited": true,
  "eventsQueue": [
    {
      "time": "2022-11-21T08:35:59.001Z",
      "event": "alive",
      "args": [
        0
      ]
    },
    {
      "time": "2022-11-21T08:35:59.008Z",
      "event": "ready",
      "args": []
    }
  ],
  "status": "Alive",
  "interviewStage": "Complete",
  "hexId": "0x0000-0x0004-0x0004",
  "dbLink": "https://devices.zwave-js.io/?jumpTo=0x0000:0x0004:0x0004:7.18.3",
  "manufacturerId": 0,
  "productId": 4,
  "productType": 4,
  "deviceConfig": {
    "filename": "/usr/src/app/store/.config-db/devices/0x0000/700_series_controller.json",
    "isEmbedded": true,
    "manufacturer": "Silicon Labs",
    "manufacturerId": 0,
    "label": "ZST10-700",
    "description": "700 Series-based Controller",
    "devices": [
      {
        "productType": 4,
        "productId": 4
      }
    ],
    "firmwareVersion": {
      "min": "0.0",
      "max": "255.255"
    },
    "metadata": {
      "comments": []
    }
  },
  "productLabel": "ZST10-700",
  "productDescription": "700 Series-based Controller",
  "manufacturer": "Silicon Labs",
  "firmwareVersion": "7.18.3",
  "sdkVersion": "7.18.3",
  "protocolVersion": 3,
  "endpointsCount": 0,
  "endpointIndizes": [],
  "isSecure": "unknown",
  "supportsSecurity": false,
  "supportsBeaming": true,
  "isControllerNode": true,
  "isListening": true,
  "isFrequentListening": false,
  "isRouting": true,
  "keepAwake": false,
  "maxDataRate": 100000,
  "deviceClass": {
    "basic": 2,
    "generic": 2,
    "specific": 1
  },
  "firmwareCapabilities": {
    "firmwareUpgradable": false
  },
  "deviceId": "0-4-4",
  "lastActive": 1669022394324,
  "statistics": {
    "messagesTX": 16,
    "messagesRX": 189,
    "messagesDroppedRX": 14,
    "NAK": 0,
    "CAN": 3,
    "timeoutACK": 0,
    "timeoutResponse": 0,
    "timeoutCallback": 0,
    "messagesDroppedTX": 0
  },
  "powerlevel": 0,
  "measured0dBm": 3.3,
  "RFRegion": 0,
  "_name": "silabs_zst10_700_00",
  "lastReceive": 1669022394324,
  "errorReceive": false,
  "errorTransmit": false
}

Food for thought: how about an NVM backup and restore to an identical device? I happen to have one lying around.

[robertsLando]

Food for thought: how about an NVM backup and restore to an identical device? I happen to have one lying around.

Could be a try but let me ask to @AlCalzone if he can give this a look

[AlCalzone]

1. RF region Europe is correct?
2. Is the stick on a USB extension?

[bushvin]

• RF region Europe is correct?

yes.

• Is the stick on a USB extension?

no, straight on the USB3 port of the raspberry pi 4. No ssd in the immediate vicinity (~30cm). Network is over wifi, not wired.

[jmgiaever]

USB ports are the reason for putting it on an extension cord. Suggest to give it a go, and then report back.

[robertsLando]

USB extension

USB extension is the solution of 90% of connectivity issues 😆

[bushvin]

USB extension

USB extension is the solution of 90% of connectivity issues 😆

Will do, keep you posted.

any other considerations? Away from iron cable ducts for instance?

[AlCalzone]

Away from iron cable ducts for instance?

Can't hurt 👍🏻

Don't forget to do a network heal after moving the stick.

[bushvin]

USB extension

USB extension is the solution of 90% of connectivity issues 😆

Out of sheer curiosity and a hunger to learn, do you have anything which explains this?

DDG doesn’t find anything useful for me.

[robertsLando]

Out of sheer curiosity and a hunger to learn, do you have anything which explains this?

I think it's caused by some electromagnetic 'noise' that is created near the USB port, I know @AlCalzone also did some tests in depth with aeotec 700 series and that's even worse then the 500 as the stick is smaller and seems more affected by them

[AlCalzone]

There is an Intel white paper about USB (3 especially) noise affecting Wi-Fi, but the noise graph actually has the main peak around 900 MHz (Z-Wave frequencies).

https://www.usb.org/sites/default/files/327216.pdf

[bushvin]

Output power level is still 0dB after putting in an extension cable: :(

17:52:12.350 DRIVER « [RES] [SerialAPISetup]
                        command:               GetPowerlevel
                        normal powerlevel:     0.0 dBm
                        output power at 0 dBm: 3.3 dBm

[AlCalzone]

Yeah that's configuration, not a measurement.

[bushvin]

I was setting up my test controller to check for differences, and I've already found an interesting difference. My production controller doesn't have any values associated.

-  "values": [],
+  "values": [
+    {
+      "id": "1-114-0-manufacturerId",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 114,
+      "commandClassName": "Manufacturer Specific",
+      "endpoint": 0,
+      "property": "manufacturerId",
+      "propertyName": "manufacturerId",
+      "type": "number",
+      "readable": true,
+      "writeable": false,
+      "label": "Manufacturer ID",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "min": 0,
+      "max": 65535,
+      "list": false,
+      "value": 0,
+      "lastUpdate": 1669283430812,
+      "newValue": 0
+    },
+    {
+      "id": "1-114-0-productType",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 114,
+      "commandClassName": "Manufacturer Specific",
+      "endpoint": 0,
+      "property": "productType",
+      "propertyName": "productType",
+      "type": "number",
+      "readable": true,
+      "writeable": false,
+      "label": "Product type",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "min": 0,
+      "max": 65535,
+      "list": false,
+      "value": 4,
+      "lastUpdate": 1669283430812,
+      "newValue": 4
+    },
+    {
+      "id": "1-114-0-productId",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 114,
+      "commandClassName": "Manufacturer Specific",
+      "endpoint": 0,
+      "property": "productId",
+      "propertyName": "productId",
+      "type": "number",
+      "readable": true,
+      "writeable": false,
+      "label": "Product ID",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "min": 0,
+      "max": 65535,
+      "list": false,
+      "value": 4,
+      "lastUpdate": 1669283430812,
+      "newValue": 4
+    },
+    {
+      "id": "1-134-0-firmwareVersions",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "firmwareVersions",
+      "propertyName": "firmwareVersions",
+      "type": "string[]",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave chip firmware versions",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "value": [
+        "7.18"
+      ],
+      "lastUpdate": 1669283430812,
+      "newValue": [
+        "7.18"
+      ]
+    },
+    {
+      "id": "1-134-0-sdkVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "sdkVersion",
+      "propertyName": "sdkVersion",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "SDK version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "value": "7.18.3",
+      "lastUpdate": 1669283430812,
+      "newValue": "7.18.3"
+    },
+    {
+      "id": "1-134-0-libraryType",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "libraryType",
+      "propertyName": "libraryType",
+      "type": "number",
+      "readable": true,
+      "writeable": false,
+      "label": "Library type",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": true,
+      "states": [
+        {
+          "text": "Unknown",
+          "value": 0
+        },
+        {
+          "text": "Static Controller",
+          "value": 1
+        },
+        {
+          "text": "Controller",
+          "value": 2
+        },
+        {
+          "text": "Enhanced Slave",
+          "value": 3
+        },
+        {
+          "text": "Slave",
+          "value": 4
+        },
+        {
+          "text": "Installer",
+          "value": 5
+        },
+        {
+          "text": "Routing Slave",
+          "value": 6
+        },
+        {
+          "text": "Bridge Controller",
+          "value": 7
+        },
+        {
+          "text": "Device under Test",
+          "value": 8
+        },
+        {
+          "text": "N/A",
+          "value": 9
+        },
+        {
+          "text": "AV Remote",
+          "value": 10
+        },
+        {
+          "text": "AV Device",
+          "value": 11
+        }
+      ],
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-protocolVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "protocolVersion",
+      "propertyName": "protocolVersion",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave protocol version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-hardwareVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "hardwareVersion",
+      "propertyName": "hardwareVersion",
+      "type": "number",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave chip hardware version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-applicationFrameworkAPIVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "applicationFrameworkAPIVersion",
+      "propertyName": "applicationFrameworkAPIVersion",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave application framework API version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-applicationFrameworkBuildNumber",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "applicationFrameworkBuildNumber",
+      "propertyName": "applicationFrameworkBuildNumber",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave application framework API build number",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-hostInterfaceVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "hostInterfaceVersion",
+      "propertyName": "hostInterfaceVersion",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Serial API version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-hostInterfaceBuildNumber",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "hostInterfaceBuildNumber",
+      "propertyName": "hostInterfaceBuildNumber",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Serial API build number",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-zWaveProtocolVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "zWaveProtocolVersion",
+      "propertyName": "zWaveProtocolVersion",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave protocol version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-zWaveProtocolBuildNumber",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "zWaveProtocolBuildNumber",
+      "propertyName": "zWaveProtocolBuildNumber",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Z-Wave protocol build number",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-applicationVersion",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "applicationVersion",
+      "propertyName": "applicationVersion",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Application version",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    },
+    {
+      "id": "1-134-0-applicationBuildNumber",
+      "nodeId": 1,
+      "toUpdate": false,
+      "commandClass": 134,
+      "commandClassName": "Version",
+      "endpoint": 0,
+      "property": "applicationBuildNumber",
+      "propertyName": "applicationBuildNumber",
+      "type": "string",
+      "readable": true,
+      "writeable": false,
+      "label": "Application build number",
+      "stateless": false,
+      "commandClassVersion": 0,
+      "list": false,
+      "lastUpdate": 1669283430812
+    }
+  ],

device class is also different

-  "deviceClass": {
-    "basic": 2,
-    "generic": 2,
-    "specific": 1
-  },
+  "deviceClass": {
+    "basic": 2,
+    "generic": 2,
+    "specific": 7
+  },

Maybe it is related to this? Would it be worthwhile to remove all from /usr/src/app/store? Or is there a way to force the controller to re-interview itself?

[AlCalzone]

Those values should get queried on every startup, so I'm not sure why they are missing on the other controller. Maybe the startup doesn't actually complete?

[bushvin]

Since my z-wave network wasn't going anywhere, I've restored the nvm backup from the faulty controller to the other, on a different system, without settings.json and the lot. It seems to be doing better, as it's working (hard) to get all the info from the devices, and it seems to connect correctly.

I'm guessing 48 devices will take a while to interview and getting things straightened.

Keep you posted on the progress.

[bushvin]

I'm throwing in the towel.

I believe my flashing the devices has irrevocably broken them, as they exhibit the same behaviour.

Even resetting one controller to factory defaults and pairing a device doesn't seem to work the way it should.

I've ordered a new controller, and I'll start from scratch.

[robertsLando]

@bushvin I'm sorry for that :( Did you tried to contact Silicon Labs support? I dunno what could help you with that...

[AlCalzone]

What do you mean by flashing? Restoring the backup?

[robertsLando]

What do you mean by flashing? Restoring the backup?

Yeah he did an nvm backup of the old controller in a new one

[bushvin]

@bushvin I'm sorry for that :( Did you tried to contact Silicon Labs support? I dunno what could help you with that...

I'm past the 2 year hardware support, so I do not have high hopes. Right now I need my z-wave network as my heating depends on it. Running around and manually turning on/off my heating is not my idea of a fun time. I know, FirstWorldProblems.

What do you mean by flashing? Restoring the backup?

I have 2 UZB-7, one to test, the other to use. I flashed the firmware as it possibly had the bug (firmware 7.17.something) to my test device. Didn't fully test on my test device, and only discovered my controller can't connect to the devices after also flashing my production controller. So now I have 2 identical controllers which basically are unable to connect to devices without the devices phoning home. I can't even use them as fancy paperweights as they are too light.

So yeah, I fucked up.

[robertsLando]

BTW it's strange that the firmware update fucked up things in that way, at least this should be investigated by them to prevent others to experience the same. We could also inform other users about this issue with UZB 7.

If the NVM restore reproduced the same problem to the other fw this is sure something related to that. Did you tried downgrading firmware? At least that should restore the previous state

[bushvin]

I can't confirm nor deny if the NVM backup/restore caused the issue, as I only validated the firmware upgrade by checking if all devices I joined prior to updating were still there. I didn't check if I could turn them off/on. In hindsight, I should have.

I did try to downgrade to a previous version, but to no avail. The Region was unset, and I could not set it manually for whatever reason.

One thing I want to do is setup a windows machine to see if using minicom somehow had an impact vs the windows way. But not today, because deadlines.

[robertsLando]

Let me know if we can help someway and keep us updated 🤞🏼

[AlCalzone]

The Region was unset, and I could not set it manually for whatever reason

I've seen that happen before, it's related to the NVM backup stuff. Before you throw out your stick, make an NVM backup and send it to me. I might be able to edit the region settings in that backup so you can configure it again.

Which firmware version was the original backup from?

[bushvin]

So... I got my new z-wave controller (Aeotec Z-Stick 7) and it is essentially identical to my fried stick:

lsusb:

Bus 001 Device 006: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

First thing I checked was the fw version, and it was at 7.11. Which is what I wanted to upgrade in the first place. So checking on Aeotec website, I discovered they support fw updating through Linux! YAY!!!!

Running the risk of frying my new controller, I updated the FW, and lo and behold: it worked!!!

Now, as both have identical device IDs, I couldn't help but wonder that I might be able to use the working fw to update my broken stick, in hopes to recover it... any thoughts?

[bushvin]

Now, as both have identical device IDs, I couldn't help but wonder that I might be able to use the working fw to update my broken stick, in hopes to recover it... any thoughts?

I have my answer: no

I was able to use the firmware, my old device showed up with the same version as the new one, but still, it cannot send (?) packets...

[robertsLando]

Are you using an extension usb cable? is the fw of the stick reported to be 7.17.2+ now in UI?

[AlCalzone]

@bushvin Care to share the info I asked for in my previous comment? Also before you try to restore an NVM onto the new stick, make a backup first.

[bushvin]

Are you using an extension usb cable? is the fw of the stick reported to be 7.17.2+ now in UI?

No, the new stick is connected straight to my laptop.

Connecting the old (dev) stick in the same way.

Firmwares on both old and new stick are 7.18.1, using the same gbl.

after flashing the old stick, I performed a hard reset, to clean everything. Tried to pair a factory resetted device, but same as before: no joy…

[bushvin]

@bushvin Care to share the info I asked for in my previous comment? Also before you try to restore an NVM onto the new stick, make a backup first.

I’m not going to be performing a restore on the new stick. I do not want to run the risk breaking it (as well). Most of my devices are not built in, so I don’t have to start breaking stuff…

I will make sure to backup correctly.

[AlCalzone]

There's a good chance I can modify your existing backup to get the other sticks working again. If you want to try, you can send me the existing backups (and ideally the one from the working stick as a comparison).

[bushvin]

Hey @AlCalzone I appreciate your willingness to help me out. I created a backup of the faulty device and the working one, and uploaded it here

I'll send the password to your emailaddress mentioned on your github page

There's 4 files:

• faulty-nodes.json
• faulty-NVM_20221201080540.bin
• working-nodes.json
• working-NVM_20221201080642.bin

If it wasn't obvious enough: the files prefixed with faulty are the node and NVM backup of the USB devices which doesn't work anymore, the others are the ones from the USB device which works correctly.

I already started migrating off a couple of devices before I read your message:

device	old id	new id
aeotec_zw189_c15_00	49	2
aeotec_zw189_c15_01	3	3
fibaro_fgwp101_03	77	4
fibaro_fgwp101_04	23	5
fibaro_fgwp101_02	51	6

I don't care if I need to re-pair them again.

Many, many thanks in advance!

[bushvin]

So I needed heating this weekend, so I moved all my devices over to my new USB stick.

Thanks you for the effort you have put into this, but editing the binary files will not be necessary anymore.

Let me know if you want me to do some more tests on my broken devices.

[AlCalzone]

Seems like you're not the only one with that issue on 7.18. Something must have changed. Fortunately I was provided with a clean NVM file so I should be able to figure out what. Once I have, we can get your other sticks working again.

[bushvin]

This is really weird. I'm wondering if it has anything to do with the method of updating it using minicom. I did see there's a difference between what was fond on @kpine 's repo and aeotec's procedure

If I can do anything, just give me a shout, or if you like I can send you one of my broken dongles.

[kpine]

This is really weird. I'm wondering if it has anything to do with the method of updating it using minicom. I did see there's a difference between what was fond on @kpine 's repo and aeotec's procedure

I found that doubtful. However, care to share what's different exactly?

[bushvin]

@kpine apologies for my delay...

I am by far an expert on these matters, but these are the immediate differences I see:

your script:

send "\1\3\0\10\364"
...
send "\1\3\0\47\333"

Aeotec's procedure

printf '\x01\x03\x00\x08\xf4' >/dev/ttyUSB0 && sleep 10
printf '\x01\x03\x00\x27\xDB' >/dev/ttyUSB0 && sleep 10

I have no exact idea what these do, but as far as I understand, these are to reboot the chip and/or perform a soft reset. I'm not sure if the commands in your script are HEX or DEC, but even if they are DEC, they do not correspond to the HEX provided by Aeotec.

Again, I am not versed, at all, in these things. Just an observation.

[kpine]

The values in the Minicom script are in octal, while the Aeotec ones are hex. Not sure if Minicom accepts hex values (the script was provided by another user), but they're the same values.

❯ python3
Python 3.11.0 (main, Oct 24 2022, 18:26:48) [MSC v.1933 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "\1\3\0\10\364" == '\x01\x03\x00\x08\xf4'
True
>>> "\1\3\0\47\333" == '\x01\x03\x00\x27\xDB'
True
>>>