core
core copied to clipboard
home-assistant
ZwaveJS Renames Devices on HA Restart
The problem
When I restart HA, I have multiple devices that rename themselves back to default names and remove the Area. For example my "Master Bedroom Ceiling Lights" renames to "700 Series Toggle Dimmer"
What version of Home Assistant Core has the issue?
2022.10.4
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
zwave_js
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zwave_js/
Diagnostics information
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Nothing seems interesting in the zwave js ui logs. Here is all references to the node since restarting HA:
C:\Users\dmegl\Downloads\z-ui_2022-10-15 (1).log
1866,38: 2022-10-15 18:17:57.187 INFO Z-WAVE: Node 120: value updated: 114-0-manufacturerId 634 => 634
1867,38: 2022-10-15 18:17:57.190 INFO Z-WAVE: Node 120: value updated: 114-0-productType 28672 => 28672
1868,38: 2022-10-15 18:17:57.193 INFO Z-WAVE: Node 120: value updated: 114-0-productId 40964 => 40964
1876,38: 2022-10-15 18:17:57.622 INFO Z-WAVE: Node 120: value updated: 134-0-libraryType 3 => 3
1877,38: 2022-10-15 18:17:57.625 INFO Z-WAVE: Node 120: value updated: 134-0-protocolVersion 7.13 => 7.13
1878,38: 2022-10-15 18:17:57.629 INFO Z-WAVE: Node 120: value updated: 134-0-firmwareVersions 10.0 => 10.0
1879,38: 2022-10-15 18:17:57.632 INFO Z-WAVE: Node 120: value updated: 134-0-hardwareVersion 1 => 1
2309,38: 2022-10-15 18:18:44.782 INFO Z-WAVE: Node 120: value updated: 114-0-manufacturerId 634 => 634
2310,38: 2022-10-15 18:18:44.784 INFO Z-WAVE: Node 120: value updated: 114-0-productType 28672 => 28672
2311,38: 2022-10-15 18:18:44.787 INFO Z-WAVE: Node 120: value updated: 114-0-productId 40964 => 40964
2320,38: 2022-10-15 18:18:45.449 INFO Z-WAVE: Node 120: value updated: 134-0-libraryType 3 => 3
2321,38: 2022-10-15 18:18:45.453 INFO Z-WAVE: Node 120: value updated: 134-0-protocolVersion 7.13 => 7.13
2322,38: 2022-10-15 18:18:45.457 INFO Z-WAVE: Node 120: value updated: 134-0-firmwareVersions 10.0 => 10.0
2323,38: 2022-10-15 18:18:45.460 INFO Z-WAVE: Node 120: value updated: 134-0-hardwareVersion 1 => 1
Additional information
Running zwave js ui
Hey there @home-assistant/z-wave, mind taking a look at this issue as it has been labeled with an integration (zwave_js) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
zwave_js documentation zwave_js source (message by IssueLinks)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
Ok it has something to do with Zwave JS UI overwriting values in HA. I went through and set names for every device in Zwave JS UI via the nodes.json and now only the area gets wiped, not the name. So for certain, just a few nodes, Zwave JS UI is overwriting whatever is set in HA with the default name.
I have the same issue as well. Opened related:
https://github.com/home-assistant/core/issues/80447#issue-1410605814
That does sound very similar. Are you seeing something in the logs that suggests a device is going out of range/reconnecting? I didn't spot anything. For reference I also have a fairly large zwave mesh, 109 devices. So that's another similarity
@dcmeglio I just assumed, based on the distances involved plus the fact that bluetooth and wifi range varies substantially over time in the interference-dense area
@dcmeglio I just assumed, based on the distances involved plus the fact that bluetooth and wifi range varies substantially over time in the interference-dense area
Got it, it does seem reasonable and it's my suspicion too, I was just hoping you had some way to prove it.
Understood. I was just hoping that HomeAssistant would be smart enough to keep the device's hardware addr, name, and area in a database and if it went out of range and back in, find it in that there database - not be like "peekaboo, this right there is a brand new device now"
Totally agree. I use Zwave JS UI. If I set the names in the addon it seems to remember those names and apply them in HA. That causes my entity names to at least not get screwed up when it does this.
Totally agree. I use Zwave JS UI. If I set the names in the addon it seems to remember those names and apply them in HA. That causes my entity names to at least not get screwed up when it does this.
How are those names not symmetrically synced in both directions?
+1 seeing this issue. Currently on 2022.10.4 but I noticed it on 2022.9.x as well
Since I've started using Helpers to be able to control some of the 23 Z-Wave lights as groups in unison, I've also noticed that when a Z-Wave device loses its name, it also gets its entities renamed AND it sometimes gets booted from its groups. If groups include groups (e.g. a "Dimmers A" (side lighting) group includes FloorLamps and WallSconces groups along with some individual members) this makes managing scenes and controlling lights very clean and convenient. When it works.
It's pretty unfortunate a device can just up and lose its identity and get booted from the group. In one case it actually didn't get booted from its group but had its generic name in there, but when I edited its name in UI, the old entities hung around. This feels discouraging in terms of counting on HA for any 3rd party clients, but I'm hopeful the developers will see this & look into it. HA is a fantastic tool - I just wish it weren't moving quite so fast forward at the cost of such bugs. The entire Z-Wave mesh network control experience is unreliable and I wish HA were coded more defensively to deal with that inherent issue of many meshes.
Here's an example of this having happened again yesterday. There are 4 identical floor lamps in the 4 corners of the restaurant dining room. They're grouped together to manage their brightness in unison, by means of a group (UI Settings - Devices - Helpers - Group - Light group).
I noticed that one of the lamps wasn't responding to the group's brightness changes:
Lo and behold, perhaps to a momentary RF interference in the area or another reason for that lamp's Z-Wave mesh node to disappear and reappear, Z-Wave added a misnamed entity instead of the MDR.Dim.Floorlamp.4 - that had no real device.
Note that at that point the correct entity for the 4th lamp, MDR.Dim.Floorlamp.4 was also available on the Entity pull-down menu, and when swapped in, the entire group started working as it should. Until the next glitch, I surmise.
Update for me, I completely pooched my JS device configs, and ended up restoring from a full backup and haven't experienced an issue since.
+1 seeing this in 2022.10.2.
I am having the same issue except I do not use the ZWAVE JS UI add-on; only the "regular" ZWAVE JS add-on (Current version: 0.1.74).
For the ZWAVE JS integration, I have: Driver Version: 10.3.0 Server Version: 1.24.0
Also: Home Assistant 2022.11.4 Supervisor 2022.10.2 Operating System 9.3 Frontend 20221108.0 - latest
I have 100 ZWAVE devices, so this is extremely distressing to experience. Basically, every time I restart HA, it randomly renames entities, adds the wrong entities to devices and marks them unavailable (example, it added kwh to a Ecolink door sensor). It also resets all naming conventions for multisensors, smart switches, and door sensors without any consistency. Its rarely ever the same device that gets impacted.
Can anyone confirm if the solution posted by @deadsquid worked for them? Does "pooched my JS device configs" mean uninstalling the integration or something else?
Would greatly appreciate help with this issue as its the only unstable aspect of HA for me.
Can anyone confirm if the solution posted by @deadsquid worked for them? Does "pooched my JS device configs" mean uninstalling the integration or something else?
@snarlingllama , unfortunately it didn't work for me. I've only a quarter of your Z-wave devices on the larger of my pilot installs (just 24) but already had an uncomfortably tense "conversation" with a client. We both prefer to keep decorum & not raise one's voice - but having added an RGB light ("Zooz Z-Wave Plus S2 12/24 V DC RGBW Dimmer ZEN31 for LED Strips and DC Lighting, Work as a Network Repeater") it had a ~1 sec delay responding to customer input for color change, and customer touching the HA color wheel control may have resulted in multiple "inputs" - which quickly queued up & for good 30 sec the system had a mind of its own with light changes & frantic customer "corrective input" only being added to the back of the queue. The ordeal "resolved itself" when the phone was thrown across the room and the queue eventually cleared.
ALL of my Z-Wave devices are 700 series chip, Z-Wave Plus S2. Latest firmware, network healed. Needless to say this makes it hard to be comfortable with this tech for anything beyond a handful of switches in a couple of adjacent rooms. Which is fine if all this is capable of - but I was going off a premise of 100+ device capability and 1-mile line of sight range (so say 1/4mile would be non-line-of-sight). Ugh. Sorry for the vent but it's context for how milliseconds & signal repeats add up to such real-life situations.
@Chef-de-IT Thank you for the response. Looking at your screenshots, I am having the exact same issues.
What is really strange, one of my Ecolink door sensors (which is installed about 6 feet from my Aeotec Z-Wave stick) suddenly changed its entity ID without any reboots, etc. Just out of the blue it changed the entity ID and was working fine moment before this happened (we have an automation that plays an audio file and sends a push notification to our phones then this door is opened).
Does anyone have any ideas, etc. of what could be happening here? I would imagine more than just 5+ people are experiencing this. There has to be some commonality here. Back in the 2022.8 days, none of this ever happened with my Z-Wave devices. It appears to be related to the recent releases.
What am I missing here?
Follow-up: I was overly optimistic and continue to see the metadata issue on add-on restart. It has happened with multiple devices from Jasco (wall outlet), Innovelli (switch, dimmer, and fan), and Zooz (scene controller), and the chronology of when the devices were added don't seem to matter. Metadata loss (the device remains in the controller) can occur on zwave restart, stop/start, or a HA reboot (all proper shutdowns). I'm happy to instrument the logs as needed, but haven't seen anything that stands out as to when a problem occurs. It's amazingly frustrating, and continues with the latest release.
@snarlingllama - pooched means I tried uninstalling and re-installing ZwaveJS, migrating over to ZwaveJS UI, and a couple other things, and made things considerably worse in the process so simply restored a known-good full backup (which is now a default process on any change or right before I want to restart things for any reason).
Current setup is HA OS an a Generic x86-64 (AcePC AK1 - Celeron), and I use a ZooZ S2 ZST 10 700 with the latest firmware (7.17.2)for the controller
Home Assistant 2022.11.4 Supervisor 2022.10.2 Operating System 9.3 Frontend 20221108.0 - latest
Happy to provide more info, and it's a pretty straight-forward setup. Diagnostic info from the integration attached.
config_entry-zwave_js-fd9de23798136f36e5543a532a561534.json.zip
Does anyone have any ideas, etc. of what could be happening here?
@snarlingllama if I had to guess, it could be a naively coded new device discovery mechanism. A Z-Wave mesh node disappears and then reappears, mesh says, here's a new node, its hardware address isn't first checked against the database of already configured device metadata keyed off their hardware addresses but an "add new device" routine is called, that overwrites any "already taken hardware address" with "new device blank defaults". I doubt it's exactly that in terms of the actual moving pieces, as I didn't look at the code, but it's perhaps something amounting to this.
I would imagine more than just 5+ people are experiencing this.
It's possible for developers to conflate 5 people (only) commenting with just 5 people having an issue, although for every one of us there are perhaps 200 who don't know what github is, 200 who know but can't be bothered, 200 who have the issue and not realize it,100 who just give up and 10,000 who have all their two z-wave switches (in plastic electrical boxes not metal) and a fish feeder running perfectly fine all situated within 36inches of the HA computer in their basement in rural Iowa, 76 lightyears away from the nearest source of radio interference.
@snarlingllama if I had to guess, it could be a naively coded new device discovery mechanism. A Z-Wave mesh node disappears and then reappears, mesh says, here's a new node, its hardware address isn't first checked against the database of already configured device metadata keyed off their hardware addresses but an "add new device" routine is called, that overwrites any "already taken hardware address" with "new device blank defaults". I doubt it's exactly that in terms of the actual moving pieces, as I didn't look at the code, but it's perhaps something amounting to this.
This isn’t how device discovery works. The same device should be detected every time, even if you nuke the cache. That’s how switching between the addons works without causing a rename.
Ok it has something to do with Zwave JS UI overwriting values in HA. I went through and set names for every device in Zwave JS UI via the nodes.json and now only the area gets wiped, not the name. So for certain, just a few nodes, Zwave JS UI is overwriting whatever is set in HA with the default name.
To be clear, this isn’t possible. The zwavejs integration may have a bug causing this but Z-Wave JS UI has no ability to change anything in HA. It just pipes events through the websocket where they’re consumed on the HA side.
All: I recognize that this is an intermittent issue but no one can begin to solve it without logs. Turn on log to file in zwavejs-ui, at the debug level or higher, and be vigilant for the change. (Note that logging is set in two places. You want under Z-Wave.) It’s going to be difficult to pin down where exactly in the log this is happening but that will have to happen. Node exports from before and after will also be crucial. Describing the symptoms over and over again doesn’t help diagnose the issue.
All: I recognize that this is an intermittent issue but no one can begin to solve it without logs. Turn on log to file in zwavejs-ui, at the debug level or higher, and be vigilant for the change. (Note that logging is set in two places. You want under Z-Wave.) It’s going to be difficult to pin down where exactly in the log this is happening but that will have to happen. Node exports from before and after will also be crucial. Describing the symptoms over and over again doesn’t help diagnose the issue.
I'm happy to do my part - please provide HomeAssistant screenshots on which logs you want enabled and what settings in HA UI I should pick. The issue is happening every other day, so there should be no problem getting the logs for it. I've a HomeAssistant with the Z-Wave JS (not JS-UI) integration. Please provide the precise steps for the logs you would like.
You cannot log to file in the vanilla addon (to my knowledge) so you’re unable to help here. I don’t run addons so I could be wrong.
In HA UI > Settings > Add-ons > Z-Wave JS > Settings, I have the log level set to Debug. In In HA UI > Settings > Add-ons > Z-Wave JS > Log, I have the following:
There's a fair bit of:
- Dropping message with invalid payload
- error: Duplicate command
- [Security2CCMessageEncapsulation] [INVALID]
I posted logs with the original report and also confirmed that if you set the name and area in the nodes.json it works around the issue. Nothing in the logs seems to provide any insight to me and no one followed up with any questions on the logs I provided.
2022-11-24T23:47:15.230Z SERIAL « 0x012700a814013....more-hex-string...d8dbe (41 bytes) 6ff645b4d1400d37e 2022-11-24T23:47:15.231Z SERIAL » [ACK] (0x06) 2022-11-24T23:47:15.233Z CNTRLR [Node 053] [~] [Meter] value[65537]: 0.18 => 0.18 [Endpoint 1] 2022-11-24T23:47:15.233Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ type: broadcast │ target node: 255 │ RSSI: -45 dBm └─[Security2CCMessageEncapsulation] │ sequence number: 34 └─[MultiChannelCCCommandEncapsulation] │ source: 1 │ destination: 0 └─[MeterCCReport] type: Electric scale: kWh rate type: Consumed value: 0.18 time delta: 0 seconds 2022-11-24T23:47:16.098Z SERIAL « 0x012700a814....more-hex-string...a1d8dbe (41 bytes) 6ff645b4d1400d37e 2022-11-24T23:47:16.099Z DRIVER Dropping message with invalid payload 2022-11-24T23:47:16.099Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ type: broadcast │ target node: 255 │ RSSI: -45 dBm └─[Security2CCMessageEncapsulation] [INVALID] error: Duplicate command 2022-11-24T23:47:16.100Z SERIAL » [ACK] (0x06) Starting logging event forwarder at debug level Stopping logging event forwarder 2022-11-25T00:27:46.788Z SERIAL « 0x012300a80....more-hex-string...499383d56505 (37 bytes) f9700a71e 2022-11-25T00:27:46.790Z SERIAL » [ACK] (0x06) 2022-11-25T00:27:46.792Z CNTRLR [Node 053] [~] [Meter] value[66049]: 2.8 => 2.6 [Endpoint 1] 2022-11-25T00:27:46.793Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ RSSI: -89 dBm └─[Security2CCMessageEncapsulation] │ sequence number: 35 └─[MultiChannelCCCommandEncapsulation] │ source: 1 │ destination: 0 └─[MeterCCReport] type: Electric scale: W rate type: Consumed value: 2.6 time delta: 0 seconds 2022-11-25T00:27:46.882Z SERIAL « 0x012300a800013....more-hex-string...8499383d56505 (37 bytes) f9700a41d 2022-11-25T00:27:46.883Z DRIVER Dropping message with invalid payload 2022-11-25T00:27:46.884Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ RSSI: -92 dBm └─[Security2CCMessageEncapsulation] [INVALID] error: Duplicate command 2022-11-25T00:27:46.884Z SERIAL » [ACK] (0x06) 2022-11-25T00:27:47.731Z SERIAL « 0x012300a800....more-hex-string...99383d56505 (37 bytes) f9700a61f 2022-11-25T00:27:47.732Z DRIVER Dropping message with invalid payload 2022-11-25T00:27:47.732Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ RSSI: -90 dBm └─[Security2CCMessageEncapsulation] [INVALID] error: Duplicate command 2022-11-25T00:27:47.733Z SERIAL » [ACK] (0x06) 2022-11-25T00:27:47.821Z SERIAL « 0x012300a8000....more-hex-string...9383d56505 (37 bytes) f9700a61f 2022-11-25T00:27:47.822Z DRIVER Dropping message with invalid payload 2022-11-25T00:27:47.822Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ RSSI: -90 dBm └─[Security2CCMessageEncapsulation] [INVALID] error: Duplicate command 2022-11-25T00:27:47.822Z SERIAL » [ACK] (0x06) 2022-11-25T00:27:48.048Z SERIAL « 0x012300a814....more-hex-string...499383d56505 (37 bytes) f9700d37e 2022-11-25T00:27:48.049Z DRIVER Dropping message with invalid payload 2022-11-25T00:27:48.050Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ type: broadcast │ target node: 255 │ RSSI: -45 dBm └─[Security2CCMessageEncapsulation] [INVALID] error: Duplicate command 2022-11-25T00:27:48.050Z SERIAL » [ACK] (0x06) 2022-11-25T00:27:48.598Z SERIAL « 0x012300a8140....more-hex-string...83d56505 (37 bytes) f9700e24f 2022-11-25T00:27:48.599Z DRIVER Dropping message with invalid payload 2022-11-25T00:27:48.599Z DRIVER « [Node 053] [REQ] [BridgeApplicationCommand] │ type: broadcast │ target node: 255 │ RSSI: -30 dBm └─[Security2CCMessageEncapsulation] [INVALID] error: Duplicate command 2022-11-25T00:27:48.600Z SERIAL » [ACK] (0x06)
In HA UI > Settings > Add-ons > Z-Wave JS > Settings, I have the log level set to Debug. In In HA UI > Settings > Add-ons > Z-Wave JS > Log, I have the following:
There's a fair bit of:
- Dropping message with invalid payload
- error: Duplicate command
- [Security2CCMessageEncapsulation] [INVALID]
This is unrelated. It suggests a poor mesh or possibly a misbehaving device.
I posted logs with the original report and also confirmed that if you set the name and area in the nodes.json it works around the issue. Nothing in the logs seems to provide any insight to me and no one followed up with any questions on the logs I provided.
There are no logs of any help in your report. Not at the info level as most things aren’t logged and it’s not clear to me that is the right point in time. We need to see what event in zwavejs is triggering this to happen so it can be traced through.
I’m following up now…