Again - new sensor added as unknown id and unknown type

Configuration Z-Wave
1

Hi,

I got a new sensor, one of the “famous” Aeotec Multisensor 6 ones.
I added it (securely) using HA’s zwave.node_add_secure service through the WebUI, removed it again later and finally re-added it using domoticz, also in secure mode.
I also set the device to binary mode.
The result is always the same: though domoticz instantly recognizes the sensor by name, it only shows up as
“unknown_idXXXX_unknown_typeYYYY” in HA, e.g.

sensor.unknown_id0086_unknown_type0002_id0064_temperature_20_1
sensor.unknown_id0086_unknown_type0002_id0064_ultraviolet_20_27

Restarting HA doesn’t change that and the actual naming also does not “magically appear” after some uptime.
It just stays that way.

I already had this problem a while ago with a different sensor, as documented here:
https://community.home-assistant.io/t/openzwave-config-files-how-do-they-work/

I haven’t gotten any new sensors since then - until today.

I don’t know what’s going wrong here, but to me it looks like “something” is broken since the 0.36 release.
Maybe someone with deep knowledge of the HA <-> openzwave internals could have a look at this issue?

Did anyone else have this problem when adding new Zwave devices since 0.36?

Unfortunately, I can’t (temporarily) downgrade to 0.35.3 (which worked the last time) due to all the config changes since then.

Sebastian

2

I just downloaded 0.35.3 (docker), commented out the conflicting parts of my config file and started it.
I removed the sensor and re-added it. Bam. Everything’s showing up with an actual name now:

binary_sensor.aeotec_zw100_multisensor_6_sensor_21_0
sensor.aeotec_zw100_multisensor_6_luminance_21_3
sensor.aeotec_zw100_multisensor_6_relative_humidity_21_5
[...]

More than ever looks to me like something broke starting at 0.36.

Sebastian

3

Given that my first install wasn’t until 0.36, and my Multisensor 6 shows up just fine, I suspect that isn’t the problem. More likely it’s to do with the OZW configuration (zwcfg*.xml) since that’s where the names come from. You can edit that, or just use the rename option in HA, to fix the name.

4

Well… im all out of ideas…lol thats all that seems to work for me. Z-wave is annoying…

5

Hmm, strange.
The names in the zwcfg_*.xml file need to come from somewhere, so maybe something’s broken with the mechanism that creates the content for this file?
In 0.35.3 the sensor name was picked up immediately after adding the sensor, so this can’t be a thing where “you just have to wait it out”.
@Tinkerer: are you by any chance running the Docker image of HA?
I do so since I started using HA - maybe it’s limited to the Docker version.

I remember that in 0.36 the docker image was missing the zwcfg.xsd file and I had to map it inside the container manually.
Any chance that this has something to do with it?

See my old thread that unfortunately didn’t get any replies:

To this day, I’m running my docker containers with the mapped zwcfg.xsd file.

Sebastian

6

Nah, I’m running on a Pi (AOI). The names come from Open Z-Wave, so it could be an issue with the way OZW is installed in the Docker image.

7

Ok, I suspected as much.
I just checked and removed the zwcfg.xsd mapping.
At least in 0.40 the file is included again in /usr/src/app/build/python-openzwave/openzwave/config/ inside the container, so I can remove the workaround.
There’s no difference though between the included zwcfg.xsd and the one I mapped.

Sebastian