Z-Wave device configuration file changed

Configuration
1

Hi, I remember seeing this message after upgrading to 2022.9 and I fixed (re-interviewed the ones that were showing up).
Today I upgraded to 2022.10 and it seems like it got the rest: all my battery-powered z-wave devices (44 in total).

These are my issues/comments:

  1. The message doesn’t really tell you what’s changing (other than maybe improvements).
  2. If I re-interview the 44 battery powered devices, chances are I’m going to get a lot of failed interviews on the ones that are farther away.
  3. The repair message doesn’t give you an option to “Dismiss”.

Does anybody have any ideas?
Ideally I’d like to dismiss these (I’ve already performed a reboot and they keep showing up).
I really don’t want to spend all day removing the sensors to get them closer to the controller for a re-interview without knowing what the true benefits are (44 would be really time consuming).

Message example:

## Z-Wave device configuration file changed: Fridge Door

Z-Wave JS discovers a lot of device metadata by interviewing the device. However, some of the information has to be loaded from a configuration file. Some of this information is only evaluated once, during the device interview.

When a device config file is updated, this information may be stale and and the device must be re-interviewed to pick up the changes.

This is not a required operation and device functionality will be impacted during the re-interview process, but you may see improvements for your device once it is complete.

If you'd like to proceed, click on SUBMIT below. The re-interview will take place in the background.

Just so you see my dilemma:

image
image960×402 22.3 KB

Thanks!
German

2

It’s impossible for HA to tell you why, it doesn’t have that information. You can attempt to find out by looking up the device in the device DB (or use clickable link from device configuration page), clicking Edit File → Nothing more than a text editor → History (upper right). You’ll see a changelog for the device file. It may not make sense though, some edits are for internal improvements.

Does anybody have any ideas?

I would submit an issue to HA. You’re supposed to be able to ignore repairs.

3

Thank you! I didn’t know how to get to the details, I’ve found it:
chore: extend auto-unsigned rule to exclusive predefined options #6338

I’ll submit an issue, you’re right, it should let me ignore, I’ve seen that for other repairs.

Thanks again!

4

I went almost a year without ever getting one of these messages, now since an update or 2 ago I’m getting them and can’t get them to go away - even after I redo the interview.

image
image697×449 19.1 KB

Sorry, I should explain that better. I the same notification as mentioned above. I click on the submit button and then get a message “The issue is repaired”. But then the same notification shows up a few hours later.

image

The message will also show up right away if I reboot the HA device.

Any suggestions?

5

You’ll have to tell us the version of Z-Wave JS you’re using.

6

Is this what you’re looking for?

image
image700×109 4.49 KB

I keep everything up to date, so pretty safe to assume the most recent version.

Could it be that the interview process is continuing in the background even after the “Success” message?

7

Are these battery devices? If so, the interview won’t occur until the device wakes up, which could be hours or days. If you restart HA or Z-Wave JS before then, the repairs will be flagged again because it hasn’t been fixed yet. I’m not sure why the repair would show up a few hours later, I’m pretty sure it’s only on those two startup events, but maybe I’ve missed it.

8

Hello!
Facing the same, everything is up to date on my side aswell.

image

9

I got this message after last update (2.1.0) and just completed the update to 2.2.0 and have it again for most of my devices. A bit of a PIA with 50+ repair messages but not the end of the world I guess.

10

You should have seen a changelog notification inside ZUI when you upgraded that explained it. If not:

https://github.com/zwave-js/node-zwave-js/releases/tag/v12.1.0

Config file changes

Almost 1000 device configuration files have been reworked to be more consistent, mostly affecting device labels, parameter labels, descriptions and predefined options.
After updating, you should expect to see several notifications for changed device configurations, prompting you to re-interview the affected nodes.
Unless the device is mentioned below, there’s no need to do this immediately.

  • Always set time for Namron 16A thermostats as UTC (#6388)
  • Add Alloy (Zipato) devices (#6331)
  • Parameter 21 of Inovelli VZW31-SN is readonly (#6389)
  • Add Shelly Wave Shutter (#6382)
  • Add Eurotronic Comet Z (700 series) (#6336)
  • Add params 7, 18, 19 to Zooz ZEN71 FW 10.20 (#6375)
  • Add Qubino Shades Remote Controller (#6335)
  • Add fingerprint for new MH8-FC version, add new option for param 1 (#6358)
  • Add Hank HKZW-SO08 (#6383)
  • Add link to manual of Honeywell T6 Pro Thermostat (#6353)

Unfortunately, you cannot ignore the repairs, so they will linger until the interviews are performed.

11

I saw this after updating zwave-js and HA recently as well. I force-interviewed my one device, and woke up the device to be sure (it’s a lock, so unlock/lock). Unfortunately, I still see the message, even after trying several times. It’s nothing more than an annoyance, but I do want to quiet it.

12

I believe you will need to restart HA after the interview has occurred in order to clear the message

13

zwavejs determines if the configuration has changed by comparing a stored hash of the configuration at the time the node was interviewed with a hash calculated from the current configuration file.

This information is stored in the YOURHOMEID.jsonl file in the zwavejs persistent store.

If you edit the file (with zwavejs not running) and remove the lines containing the calculated hashes for the nodes you want to ignore, then on restart it should then decide the configuration is up to date.

pete@rage3:/mnt/c/github_nobak/node-zwave-js$ grep deviceConfigHash /mnt/docker_rage/zwavejs_9_7_1/*.jsonl
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.36.deviceConfigHash","v":"8bd888aadbda270bb4ef5ab6b05e9bb2"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.37.deviceConfigHash","v":"24851bfee77318c21ac99de3098ba5e2"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.38.deviceConfigHash","v":"b502318f6159208a41c34acf5576e82c"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.39.deviceConfigHash","v":"f6363a03d98ee19e0c98a3dc9f38fc7b"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.40.deviceConfigHash","v":"24851bfee77318c21ac99de3098ba5e2"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.41.deviceConfigHash","v":"84924ceca3e31cad4ba76b9ad5efff78"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.42.deviceConfigHash","v":"20637feae97df8db9ff52657c89c8dc3"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.43.deviceConfigHash","v":"8bd888aadbda270bb4ef5ab6b05e9bb2"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.44.deviceConfigHash","v":"f6363a03d98ee19e0c98a3dc9f38fc7b"}
/mnt/docker_rage/zwavejs_9_7_1/d747eed4.jsonl:{"k":"node.45.deviceConfigHash","v":"24851bfee77318c21ac99de3098ba5e2"}
/mnt/docker_rage/zwavejs_9_7_1/ddddeed4.jsonl:{"k":"node.46.deviceConfigHash","v":"24851bfee77318c21ac99de3098ba5e2"}

I would do that only after backing up the file and only for battery powered devices that are difficult to reinterview (as they usually go back to sleep before that process is complete) and if you a confident that the device config file changes are not needed