Zwave Devices - Incorrect, Non Applicable, Non Functional Entities created automatically

aruffell · February 8, 2023, 6:53pm

I put a lot of work in keeping my devices and entities tidy, and named following a standard. I keep running into zwave devices that have entities that should NOT be there. Below are a few examples…

Zooz ZSE44 - ZSE44 Temperature | Humidity XS Sensor

Partial list of entities that most likely should NOT be discovered:
Battery is disconnected
Battery temperature is low
Charging status
Fluid is low
Overheating (of the battery?)
Recharge or replace
Rechargeable
Used as backup

ZOOZ ZAC36 - Water Shut Off Valve Actuator

Partial list of entities that most likely should NOT be discovered:
Battery Back-up disconnected
Back-up battery is low
Back-up battery level status
Mains status
AC mains re-connected

ZOOZ ZSE40 - 4-in-1 Sensor

Partial list of entities that most likely should NOT be discovered:
Indicator value
Cover status
Alarm level
Alarm status

As I write this post, it appears that the only or worst offenders (I did not check all my devices) are Zooz. Is there something wrong with the features the devices advertise which causes Zwave-JS to create all those extraneous entities or is it a driver issue?

In other words, who would be the right entity to fix this? The folks at Zooz, ZwaveJS or HA?

freshcoast · February 8, 2023, 6:56pm

There’s nothing obvious from the screen shots. Do you have specifics? The answers will depend on which entities you are concerned with.

If you don’t like them, you can just disable them.

aruffell · February 8, 2023, 9:52pm

@freshcoast I edited my first post to add a partial list of entities I am quite sure should not be there. While some functionality may be present but not advertised, what I listed is very unlikely. For example, the ZSE44 has no means to recharge a battery and report all the other entities I listed…

The ZAC36 is powered by a 12V power supply with a barrel connector. It also has a 3.5mm jack connector for the leak sensor. Why are there entities for battery, mains, etc.?

I know I can disable them but I ask why they are being discovered in the first place. When reviewing my devices I keep finding new entities that got discovered, and often just don’t work. I also believe I have seen the same device with very different sets of entities created for it, many of which not applicable for the device.

freshcoast · February 8, 2023, 10:04pm

Ok, let’s start with the ZSE44 which is a Battery device. What version of the Battery CC is reported? Is it 1 or 3? I think 1, but the full answer depends on that. You can see the version in the device diagnostic file.

For the ZAC39, check your driver debug logs during an interview. The device is most likely reporting that it supports these notifications. In my experience, Zooz devices do a poor job of this and often report wrong or invalid values, but a driver log would confirm that.

For the ZSE40, those are all valid entities, why do you think they should not be? They are disabled by default because they aren’t as useful for most people, but they are still functional and represent functionality provided by the device.

aruffell · February 8, 2023, 10:37pm

@freshcoast The ZSE44 report 1 as the version for Battery CC:

            {
              "id": 128,
              "name": "Battery",
              "version": 1,
              "isSecure": true
            },

Should it be reporting 3 instead? I am glad to email Zooz to suggest the fix if so.

With regards to the ZSE40, how would “Cover status” be applicable? It only has sensors for temperature, humidity, motion, illumination, battery and tamper. All are already accounted for with applicable entities. When enabled it shows “idle” but I have not tested to see what may make it change.

Edit: Cover status goes from “idle” to “Tampering, product cover removed” (is this a standard state?!?) when you open it. I very much prefer the Diagnostic one that just says “on” when open. Easier to write code to use it.

Overall, you confirmed what I was suspecting…

While the fix is easy (disable entities), I am for helping Zooz get their firmware sorted out so that we don’t have to. I am hunting for that information to then relay it to them (at this point I am understanding that this (IMO) mess is due to their low quality firmware (I say this due to many fw related issues I’ve had with zooz, not just this).

freshcoast · February 8, 2023, 11:11pm

No, I think it should be reporting 1. The extra entities you see exist for version 3. There are three reasons this can occur:

The device actually support Battery CC V3. These values are all defined by the Z-Wave specification. There is no way for a device to indicate which of the properties it supports, so they are all created. As a general design philosophy, Z-Wave JS and HA do not implement device specific workarounds to remove them for particular devices when they aren’t supported.
There is an error during interview and Z-Wave JS cannot determine the version number, in that case it assumes the latest supported version (3), go to step 1.
You hit a bug that caused Z-Wave JS to choose the incorrect CC version (go to step 1), which was coincidentally fixed in zwave-js 10.10.0 released a short time ago today.

For now, you can re-interview the device and those entities will become unavailable and you can delete them.

With regards to the ZSE40, how would “Cover status” be applicable?

Cover status is the tampering notification, it’s the “raw” value. The binary sensor is the user-friendly version that wraps this raw value and makes it more convenient (i.e. so you don’t need to create your own templates like in OZW days). That’s why it’s hidden by default. But the option to use it is still there, maybe someone else has a need for it.

I’ve seen these exact problems with my ZEN17 and ZSE42 and ZSE44.

PeteRage · February 9, 2023, 12:15am

I have 3 zse44. This is what they look like

I have seen weird things pop up on other zwave devices. Reinterviewing and restarting everything usually fixes it, I suspect their is a bug somewhere causing node metadata from one device to be loaded into wrong device.

Do you have a device that should have those entities? It may be helpful to get the diagnostics from it.

freshcoast · February 9, 2023, 12:28am

Sorry, I meant ZSE41 door sensors.

In my case, it’s usually the lack of functionality being reported.

aruffell · February 9, 2023, 12:50am

For some maybe, but definitely nothing that has all those advanced battery management features (temp, fluid level, charge status, etc.). I often have issues with adding new devices likely due to traffic. I have been trying to reduce the devices by shifting load to Zigbee, and now to ESPHome where applicable. I am down to 90 zwave devices and will shed a few more over time.

worm5406 · February 9, 2023, 1:12am

I too have lost a few zwave devices with a last connect of last night just before upgrade. Others are fine.

dbolyard99 · February 13, 2023, 6:13pm

With the old zwave integration, we could ignore zwave entities via device_config and device_config_glob options under zwave:

What takes the place of this configuration with zwave_js? I pull it in as an integration from a stand alone zwave-js-ui instance.

Here’s a view from zwave-js-ui. Those with values of “undefined” are the ones I would like to set up to ignore. With the old zwave integration, I would of set an ignore pattern up via device_config_glog.