node-zwave-js
node-zwave-js copied to clipboard
zwave-js
Missing device configuration: Building 36 Technologies ADC-SWM150 (ValueError)
Checklist
-
[X] It is not in the configuration DB
-
[X] It was not merged recently or has a pending PR
-
[X] The device was interviewed completely and has no missing or
undefinedIDs
Which device is missing?
Building36 Smart Water Valve & Meter ADC-SWM150
Manufacturer ID
0x0190
Product Type
0x0007-0x0001
Product ID
0x0001
Firmware Version
1.30
Is the device listed on the Z-Wave Alliance website?
No response
Do you have a manual?
problem is when temperature of water goes below 5oC a temperature alarm is given but its not handled correctly in z-wave js
Logger: homeassistant
Source: components/sensor/__init__.py:623
First occurred: 12:16:58 PM (1 occurrences)
Last logged: 12:16:58 PM
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 752, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1278, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 941, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1062, in _async_write_ha_state
state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 999, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 947, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 623, in state
raise ValueError(
ValueError: Sensor sensor.smart_water_valve_meter_water_temperature_alarm_status provides state value '8', which is not in the list of options provided
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:507
Integration: Sensor (documentation, issues)
First occurred: 12:16:58 PM (1 occurrences)
Last logged: 12:16:58 PM
Error adding entities for domain sensor with platform zwave_js
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 752, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1278, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 941, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1062, in _async_write_ha_state
state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 999, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 947, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 623, in state
raise ValueError(
ValueError: Sensor sensor.smart_water_valve_meter_water_temperature_alarm_status provides state value '8', which is not in the list of options provided
Logger: homeassistant.components.zwave_js
Source: components/zwave_js/__init__.py:891
Integration: Z-Wave (documentation, issues)
First occurred: 12:16:50 PM (1 occurrences)
Last logged: 12:16:50 PM
Unexpected exception: Sensor sensor.smart_water_valve_meter_water_temperature_alarm_status provides state value '8', which is not in the list of options provided
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zwave_js/__init__.py", line 891, in client_listen
await client.listen(driver_ready)
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/client.py", line 284, in listen
await self.receive_until_closed()
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/client.py", line 443, in receive_until_closed
self._handle_incoming_message(data)
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/client.py", line 532, in _handle_incoming_message
self.driver.receive_event(event) # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/model/driver.py", line 86, in receive_event
self.controller.receive_event(event)
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/model/controller/__init__.py", line 854, in receive_event
node.receive_event(event)
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/model/node/__init__.py", line 462, in receive_event
self.emit(event.type, event.data)
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/event.py", line 65, in emit
listener(data)
File "/usr/src/homeassistant/homeassistant/components/zwave_js/entity.py", line 250, in _value_changed
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 941, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1062, in _async_write_ha_state
state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 999, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 947, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 623, in state
raise ValueError(
ValueError: Sensor sensor.smart_water_valve_meter_water_temperature_alarm_status provides state value '8', which is not in the list of options provided
This could be an issue with the home assistant configuration. Does the sensor have an option for "8" in the .py for water?
The device could be sending "8" as it is a valid Zwave notification.
"0x05": {
"name": "Water Alarm",
"variables": [
{
"name": "Sensor status",
"states": {
"0x01": {
"label": "Water leak detected (location provided)",
"description": "The event parameters contain a location report"
},
"0x02": {
"label": "Water leak detected"
}
}
},
{
"name": "Maintenance status",
"states": {
"0x05": {
"label": "Replace water filter"
}
}
},
{
"name": "Water flow alarm status",
"states": {
"0x06": {
"label": "Water flow alarm",
"params": {
"type": "enum",
"values": {
"0x01": "No data",
"0x02": "Below low threshold",
"0x03": "Above high threshold",
"0x04": "Max"
}
}
}
}
},
{
"name": "Water pressure alarm status",
"states": {
"0x07": {
"label": "Water pressure alarm",
"params": {
"type": "enum",
"values": {
"0x01": "No data",
"0x02": "Below low threshold",
"0x03": "Above high threshold",
"0x04": "Max"
}
}
}
}
},
{
"name": "Water temperature alarm status",
"states": {
"0x08": {
"label": "Water temperature alarm",
"params": {
"type": "enum",
"values": {
"0x01": "No data",
"0x02": "Below low threshold",
"0x03": "Above high threshold"
}
}
}
}
},
Hi! sorry, I was not sure where to submit this issue, and was going to submit in core.
I don't know how to answer your question, might be able to provide driver logs if I can catch it, if you like?
This could be an issue with the home assistant configuration. Does the sensor have an option for "8" in the .py for water?
HA is dynamically looking up the valid states from the value metadata provided by the driver, it's not checking any constant values or otherwise hard-coded values.
if self.info.primary_value.metadata.states:
self._attr_device_class = SensorDeviceClass.ENUM
self._attr_options = list(info.primary_value.metadata.states.values())
This is easily confirmed by examining the device diagnostic file (attach file to comment, not copy and paste). You can download the diagnostic file by going to Settings -> Devices & services -> Z-Wave "Devices" -> The Device -> Device info -> ... -> Download diagnostics (feel free to attach the file). You should see the state corresponding to 8 is missing for this entity's value. You can also re-interview the device and provide the driver logs, it should show which states are being detected as supported.
Here it is:
driver logs...coming
Here's the relevant info from the dump:
"57-113-0-Water Alarm-Water temperature alarm status": {
"endpoint": 0,
"commandClass": 113,
"commandClassName": "Notification",
"property": "Water Alarm",
"propertyKey": "Water temperature alarm status",
"propertyName": "Water Alarm",
"propertyKeyName": "Water temperature alarm status",
"ccVersion": 8,
"metadata": {
"type": "number",
"readable": true,
"writeable": false,
"label": "Water temperature alarm status",
"ccSpecific": {
"notificationType": 5
},
"min": 0,
"max": 255,
"states": {
"0": "idle",
"1": "No data",
"2": "Below low threshold",
"3": "Above high threshold"
},
"stateful": true,
"secret": false
},
"value": 0
},
You can see there's no 8 event value in the states metadata, and it matches the notification values posted above:
{
"name": "Water temperature alarm status",
"states": {
"0x08": {
"label": "Water temperature alarm",
"params": {
"type": "enum",
"values": {
"0x01": "No data",
"0x02": "Below low threshold",
"0x03": "Above high threshold"
}
}
}
}
},
8 is simply not a valid event value. So we'll need to see the driver debug logs when the water temperature notification with event data 8 is being reported. It should be reporting one of 0-3.
ok, I was able to catch it in the logs, I ran some water device LED flashed "5 times" indicated a water temp alarm.
Core gave this error.
Logger: zwave_js_server
Source: /usr/local/lib/python3.11/site-packages/zwave_js_server/event.py:68
First occurred: 6:36:49 PM (1 occurrences)
Last logged: 6:36:49 PM
Error handling event: value updated
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/zwave_js_server/event.py", line 66, in emit
listener(data)
File "/usr/src/homeassistant/homeassistant/components/zwave_js/entity.py", line 250, in _value_changed
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 941, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1062, in _async_write_ha_state
state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 999, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 947, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 618, in state
raise ValueError(
ValueError: Sensor sensor.smart_water_valve_meter_water_temperature_alarm_status provides state value '8', which is not in the list of options provided
and driver logs gave this when it was in alarm state:
2024-01-10T01:36:49.410Z DRIVER « [Node 057] [REQ] [BridgeApplicationCommand]
│ RSSI: -64 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 123
│ security class: S2_Authenticated
└─[SupervisionCCReport]
session id: 13
more updates follow: false
status: Success
duration: 0s
2024-01-10T01:36:49.414Z DRIVER all queues idle
2024-01-10T01:36:49.952Z SERIAL « 0x012600a80000010039189f037c003d9b2aa3303851f280de17394e8c0177c9f48 (40 bytes)
09000c0007f7f1c
2024-01-10T01:36:49.957Z SERIAL » [ACK] (0x06)
2024-01-10T01:36:49.964Z CNTRLR [Node 057] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2024-01-10T01:36:49.967Z CNTRLR [Node 057] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2024-01-10T01:36:49.970Z DRIVER « [Node 057] [REQ] [BridgeApplicationCommand]
│ RSSI: -64 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 124
│ security class: S2_Authenticated
└─[NotificationCCReport]
notification type: Water Alarm
notification status: 255
notification state: Water temperature alarm
2024-01-10T01:36:49.974Z CNTRLR [Node 057] [~] [Notification] Water Alarm[Water temperature alarm [Endpoint 0]
status]: 0 => 8
and this when the water warmed up:
2024-01-10T01:38:10.427Z DRIVER all queues idle
2024-01-10T01:38:10.957Z SERIAL « 0x012400a80000010039169f037e00ca1598e40f5b3570d11fba332d5bc53605d00 (38 bytes)
0c1007f7fdb
2024-01-10T01:38:10.961Z SERIAL » [ACK] (0x06)
2024-01-10T01:38:10.965Z CNTRLR [Node 057] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2024-01-10T01:38:10.968Z CNTRLR [Node 057] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2024-01-10T01:38:10.972Z DRIVER « [Node 057] [REQ] [BridgeApplicationCommand]
│ RSSI: -63 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 126
│ security class: S2_Authenticated
└─[NotificationCCReport]
notification type: 5
notification status: 255
notification state: idle
event parameters: 0x08
2024-01-10T01:38:10.974Z CNTRLR [Node 057] [~] [Notification] Water Alarm[Water temperature alarm [Endpoint 0]
status]: 8 => 0
I have the whole log if you need more information or if I missed someting
by the way, if this matters, this was a water alarm for the water being too cold or below the set low temp setting.
HA is dynamically [looking up](https://github.com/home-assistant/core/blob/8181fbab5ccc369a6ca5f0c3f9a45910e7a65c48/homeassistant/components/zwave_js/sensor.py#L733-L735) the valid states That is good to know. I've never used HA, just some of HA JSON "configs" that get published to MQTT and they seem to be fixed (like door open = 22).
I can't decipher the serial, probably because of S2, but it is reading the water temperature alarm state (0x08) as the event. The format is supposed to be;
The serial byte string is hex should contain 71 05 00 00 00 FF 05 08 01 02 (cold). My guess is the device may only be sending
71 05 00 00 00 FF 05 08 00 00 (just the alarm event, but no additional info), but I can't really tell with the encryption. Edit: the Off sequence appears to be 71 05 00 00 00 FF 05 00 01 08, in effect saying that I'm now idle, but 08 was the last reason I wasn't.
I would agree, the device is probably only reporting the notification (8) but not adding on any event data. I don't think there's any requirement that event data be provided, i.e. Door sensors aren't required to report position.
My guess is that the state metadata is not being encoded correctly. Based on how the Door open/close states work, and additional info in the diagnostic dump, the sensor's state metadata should probably look like this:
"states": {
"0": "idle",
"8": "Water temperature alarm",
"2049": "No data",
"2050": "Below low threshold",
"2051": "Above high threshold"
},
Something's fishy, because the device diagnostic shows binary_sensor entities based on the same value were created:
{
"domain": "binary_sensor",
"entity_id": "binary_sensor.smart_water_valve_meter_no_data",
"original_name": "No data",
"original_device_class": "problem",
"disabled": true,
"disabled_by": "user",
"hidden_by": null,
"original_icon": null,
"entity_category": null,
"supported_features": 0,
"unit_of_measurement": null,
"value_id": "57-113-0-Water Alarm-Water temperature alarm status",
"primary_value": {
"command_class": 113,
"command_class_name": "Notification",
"endpoint": 0,
"property": "Water Alarm",
"property_name": "Water Alarm",
"property_key": "Water temperature alarm status",
"property_key_name": "Water temperature alarm status",
"state_key": 2049
}
},
which means at some point in the past, the metadata was correct (it found state key 2049, aka "No data"), as these specific sensors are created for each state seen.
Now there are duplicates of these:
{
"domain": "binary_sensor",
"entity_id": "binary_sensor.smart_water_valve_meter_no_data_2",
"original_name": "No data",
"original_device_class": "moisture",
"disabled": false,
"disabled_by": null,
"hidden_by": null,
"original_icon": null,
"entity_category": null,
"supported_features": 0,
"unit_of_measurement": null,
"value_id": "57-113-0-Water Alarm-Water temperature alarm status",
"primary_value": {
"command_class": 113,
"command_class_name": "Notification",
"endpoint": 0,
"property": "Water Alarm",
"property_name": "Water Alarm",
"property_key": "Water temperature alarm status",
"property_key_name": "Water temperature alarm status",
"state_key": 1
}
},
Based on the entity suffix being _2, this entity was created after the other one.
I don't think there's any requirement that event data be provided, Agree spec shows state parameters as optional.
I'm afraid I can't help much more because of lack of knowledge about HA and Zwave-js. ;-( My only parting comment is I'm not sure how Zwave-js is handling the bytes (which are included, which are read as the "state"). To me (0x08, 0x00) taken together are 2048 and maybe could mean "no data" (i.e. no optional state parameter). Once optional state parameters are included the relevant Byte string increases to 3 (0x08, 0x01, (0x01 || 0x02 || 0x03), so I can't get to 2049, 2050 2051 unless the parameter length byte is skipped. If it (zwave-js) just skips to the last Byte then the _2 suffix states make sense. However, it does seem odd that the spec would add a parameter length byte only to say there is no data, but I haven't researched that.
so I can't get to 2049, 2050 2051 unless the parameter length byte is skipped
These state values are how Z-Wave JS provides the event data to applications, with the notification state value in the upper byte, and the event value in the lower byte ("extend"). They aren't Z-Wave message payload values.
0 # idle (0)
8 # Water temperature alarm (8) + no event
2049 = 0x0801 # Water temperature alarm (8) + event No Data (1)
2050 = 0x0802 # Water temperature alarm (8) + event Below low threshold (2)
2051 = 0x0803 # Water temperature alarm (8) + event Above high threshold (3)
https://github.com/zwave-js/node-zwave-js/blob/86b137ef54357e84fc7e50df8a558a7b2f540525/packages/cc/src/cc/NotificationCC.ts#L410-L415
The metadata states are assigned at:
https://github.com/zwave-js/node-zwave-js/blob/86b137ef54357e84fc7e50df8a558a7b2f540525/packages/cc/src/cc/NotificationCC.ts#L422-L455
It looks like it's going down the path of "replace" instead of "extend", but the actual value of the notification is not following suit?
Maybe #6282 is related.
I think the intent of the code is to go down the "replace" path, since there's only one state (8), but does that work properly if there's no event data? Or, the device is actually including event data with value 8.
FWIW I think your table above is correct and the duplicate entity suffix _2 (3x) are in error (but maybe don't come into play, so do not cause harm?). Similar to the door there is 0x16, 0x1600 and 0x1601. With my minimal understanding Line 414 moves the alarm from 0x08 to 0x0800 and appends the 01,02,03 to get the values in your table. The "state" that needs to be added is your second line. Looking at the log posted by @Anto79-ops (the one with cold water) does not show an event parameter, but the return to idle log shows the alarm number as an event. I have seen this in my Zsniffer logs with a dome leak detector.
FWIW I think your table above is correct and the duplicate entity suffix _2 (3x) are in error (but maybe don't come into play, so do not cause harm?)
The duplicate sensors (_2) exist because of the change in #6282. Before the change, the sensors were created with the "extended" state keys. After the change, the new entities were created with the "replaced" state keys, they have the same name so the suffix is appended. HA will never delete entities even if the underlying Z-Wave JS value has been removed. Enabling these disabled entities in the UI will probably show them to be unavailable and they could be deleted.
Similar to the door there is 0x16, 0x1600 and 0x1601. With my minimal understanding Line 414 moves the alarm from 0x08 to 0x0800 and appends the 01,02,03 to get the values in your table.
The difference with door is that the door has two state values, 0x16 and 0x17. This Water temperature alert has a single state, aside from idle. Looks to me like the metadata lookup does a "replace" when there's only a single state (again, it's not counting idle), so from #6282 the state keys and the enum values are equivalent (replaced). The behavior is documented in the test code: https://github.com/zwave-js/node-zwave-js/blob/master/packages/zwave-js/src/lib/test/cc-specific/notificationEnums.test.ts
Looking at the log posted by @Anto79-ops (the one with cold water) does not show an event parameter
Yep, if the "bad" payload contained an event parameter, we would see event parameters in the log, so the problem seems to just be the outcome of no event data. Instead of assigning the notification event enum (line 4454), it assigns the notification event value (8) (line 4456), and 8 is not one of the state keys (1, 2 and 3).
https://github.com/zwave-js/node-zwave-js/blob/86b137ef54357e84fc7e50df8a558a7b2f540525/packages/zwave-js/src/lib/node/Node.ts#L4437-L4457
@kpine First thanks for all the references! They are really helping me learn more about zwave-js and maybe in the future I can actually help solve some issues on github rather than be a pest.
However, one more ;-). By Spec the enum is optional and Zwave-js handles that in line 4456. So far so good. Since HA is dynamically looking up states provided by the driver why isn't it dynamically picking up "8"? Both the valueWithEnum and value are valid. It seems that is where the problem lies. agree?
Both the
valueWithEnumandvalueare valid. It seems that is where the problem lies. agree?
I would disagree. Z-Wave JS defines the valid states, and it is sending invalid ones.
According to the dump:
"states": {
"0": "idle",
"1": "No data",
"2": "Below low threshold",
"3": "Above high threshold"
},
No 8 to be found.
I'm stating this based on how other notification values work. Here's the Water Alarm "Sensor status" variable, for example:
"57-113-0-Water Alarm-Sensor status": {
"endpoint": 0,
"commandClass": 113,
"commandClassName": "Notification",
"property": "Water Alarm",
"propertyKey": "Sensor status",
"propertyName": "Water Alarm",
"propertyKeyName": "Sensor status",
"ccVersion": 8,
"metadata": {
"type": "number",
"readable": true,
"writeable": false,
"label": "Sensor status",
"ccSpecific": {
"notificationType": 5
},
"min": 0,
"max": 255,
"states": {
"0": "idle",
"2": "Water leak detected"
},
"stateful": true,
"secret": false
}
},
Or, referring back to the Door sensor:
"19-113-0-Access Control-Door state": {
"endpoint": 0,
"commandClass": 113,
"commandClassName": "Notification",
"property": "Access Control",
"propertyKey": "Door state",
"propertyName": "Access Control",
"propertyKeyName": "Door state",
"ccVersion": 4,
"metadata": {
"type": "number",
"readable": true,
"writeable": false,
"label": "Door state",
"ccSpecific": {
"notificationType": 6
},
"min": 0,
"max": 255,
"states": {
"22": "Window/door is open",
"23": "Window/door is closed",
"5632": "Window/door is open in regular position",
"5633": "Window/door is open in tilt position"
},
"stateful": true,
"secret": false
},
"value": 23
},
In that case, the open state without event data is encoded as 22 and the open state with event data is encoded as 5632 and 5633.
I think @kpine is on point. The door sensor is the only one where the list of states is extended by the event parameters. All others should operate in "replace" mode. So even without the event parameters in the received payload, Z-Wave JS should use one of the defined states (1,2,3) , not the original notification event (8).
No problem for me; it is up to you guys (obviously ;-) what to do with Z-Wave JS.
My perspective was just that the state parameter is optional by the ZW spec and deemed "invalid" (only?) by HA. My concern was just that other device mfgs might opt not to add the state parameter and there are other notifications (e.g. "Meter") with optional state parameters, so the simplest (IHMO) would be add a few lines of code allow the original notification event in HA. (Not to mention your availability to address in ZWave JS.
As a MQTT user of Zwave JS, either way makes no difference as I can handle any value in the topic once I know what to expect from the device.
My perspective was just that the state parameter is optional by the ZW spec and deemed "invalid" (only?) by HA.
In the defense of HA, its code to use the value states was added before v12, where the states were in the "extended" form, and it was working fine then. It was only after the v12 release where the problem started, as the change referenced above is technically a breaking change to the public API.
The "replace" mode does cause some inconsistencies, as some Z-Wave JS notification values support the actual Z-Wave Notification value, while others will use the event values. That's kind of the point of the metadata though, so you don't need to be concerned with the raw values. However, a benefit is that it removes duplicate states. There's no difference between "Water temperature alarm status" without event data, and "Water temperature alarm status" + event "No data". For applications like HA, which auto-generate sensors based on the metadata, the replace mode removes a duplicate entity.
There are several notifications though that look as if they do require the event data to make any sense. Consider the Valve operation status notification, event 0 is off and event 1 is on. What does it mean if the notification is sent w/o any event data, is it on or off?