You'll need to enable driver debug logs and post those instead of the application ones for a proper diagnosis.

I've been using the Minimote for years, including with Z-Wave JS, and the "undefined" values have no impact on behavior for me.

I feel like I looked at this in the past and found the the parameters are write-only, e.g. the device fails to respond when reading the values (could be the failure you've listed) and as a result nothing is saved in the driver cache. Driver logs would clarify that.

I don't believe I configured mine the same way as you did though, I think I set each button (params 241 to 244) to "Scene Mode" and left 250 unset. The user guide does seem to indicate only setting param 250 is necessary.

And how are you using scenes in HA? MQTT? Z-Wave integration? Event entity or event triggers? I am using event triggers with the Z-Wave integration:

trigger:
  platform: event
  event_type: zwave_js_value_notification
  event_data:
    device_id: !input minimote_device
    command_class: 43   # Scene Activation
    property: sceneId

I will work on the logs and post them when I have more detail.

i use the scene buttons to interface with Node Red, which monitors the Home Assistant entity "Scene ID" for each of two Minimotes. That worked flawlessly when the Zwave controller was a Vera Edge and never needed to be reconfigured. I recently implemented ser2net on the Vera Edge and use it as a network attached Zwave controller, with Zwave JS UI linked to the remote interface. That also works flawlessly once i have configured the Minimotes as secondary controllers in Scene Mode, but as reported the configuration is not 'sticky' and is lost on restarting Zwave JS UI or Home Assistant.

I had for a while set the individual buttons to Scene Mode but that also did not seem to be sticky.

The only reason the Minimote stops working is that the Scene ID entity for the remote becomes unavailable in Home Assistant - nothing has been reconfigured in the remote as it is in sleep mode most of the time and is therefore not reconfigured when Zwave JS UI restarts. Immediately after that restart though, Scen ID is flagged as Unavailable.

As I say, I will provide logs as soon as I have done some more tests but my gut feeling is that Zwave JS UI should use its cached values for these often-sleeping battery powered devices and should assume that the existing values apply unless a new configuration is received.

I will try an automation using the YAML you provided and report back on whether that proves to be 'sticky' across restarts.

That worked flawlessly when the Zwave controller was a Vera Edge and never needed to be reconfigured. I recently implemented ser2net on the Vera Edge and use it as a network attached Zwave controller, with Zwave JS UI linked to the remote interface. That also works flawlessly once i have configured the Minimotes as secondary controllers in Scene Mode, but as reported the configuration is not 'sticky' and is lost on restarting Zwave JS UI or Home Assistant.

Switching to Z-Wave JS while retaining the original controller and network would not have changed the Minimote configuration. Everything would have transferred over as-is. Unlike other software, Z-Wave JS does not modify config parameters without user input.

The only reason the Minimote stops working is that the Scene ID entity for the remote becomes unavailable in Home Assistant

I presume you mean your automations stop working. No Z-Wave device is dependent on the availability of the HA entity.

Just as a check I just restarted ZUI and the Scene ID entity only goes unavailable while ZUI is restarting (expected). I should also say I'm still on an older version of the driver, I haven't migrated to v14 yet.

As I say, I will provide logs as soon as I have done some more tests but my gut feeling is that Zwave JS UI should use its cached values for these often-sleeping battery powered devices and should assume that the existing values apply unless a new configuration is received.

Z-Wave JS already does use cached values (for every type of device). The Scene Activation values are not cached because they are events, it would make much sense to cache a scene event that happened minutes/hours/days ago. Additionally, the cached value of the configuration parameter (250) has no effect on how the device behaves, the configuration is stored on the device. Z-Wave JS does not use the config parameter value for any logic related to the scene notifications.

The only reason the Minimote stops working is that the Scene ID entity for the remote becomes unavailable in Home Assistant

I presume you mean your automations stop working. No Z-Wave device is dependent on the availability of the HA entity.

The HA entity is a product of (created by) the zwave integration and is dependent on the zwave code for its availability. If I understand the code correctly, the zwave integration iterates over the Zwave-JS devices from the code embedded in Zwave JS UI to create the Home Assistant devices and their entities. Because the Minimote is not considered to be in scene mode the Scene ID field is flagged "unavailable".

Just as a check I just restarted ZUI and the Scene ID entity only goes unavailable while ZUI is restarting (expected). I should also say I'm still on an older version of the driver, I haven't migrated to v14 yet.

In my case, it remains unavailable.

Z-Wave JS already does use cached values (for every type of device). The Scene Activation values are not cached because they are events, it would make much sense to cache a scene event that happened minutes/hours/days ago. Additionally, the cached value of the configuration parameter (250) has no effect on how the device behaves, the configuration is stored on the device. Z-Wave JS does not use the config parameter value for any logic related to the scene notifications.

i would not expect the scene activation values to be cached, but the configuration value for field 250 should be consistent across restarts for these battery powered devices as they cannot be polled at startup.

trigger:
  platform: event
  event_type: zwave_js_value_notification
  event_data:
    device_id: !input minimote_device
    command_class: 43   # Scene Activation
    property: sceneId

I tried an automation with your code but as expected it does not work after a restart of Zwave JS UI because property sceneid is no longer available. Time to work on the debug log.

buttons_pressed.log

A first debug log, and quite interesting. I restarted Zwave JS UI (ZJSUI) and "event SceneId" became unavailable in the HA zwave integration, as usual. With ZJSUI debug logging enabled i pressed buttons on each of my two remotes and the scene ID for the buttons was recorded in the ZJSUI log and shows as an event in the zwave integration log. But because the integration shows scene ID as unavailable my automations are not triggered.

Does this suggest that the problem may be with the integration rather than Zwave JS UI?

This screenshot is of details of the unavailable SceneID in the integration.

ZJSUI logs

1_buttons_pressed.log
2_interview.log
3_scene_mode_enabled.log
4_interview2.log
5_scene_mode_disabled.log

Details of the attached logs:

1: Although the sceneID event is disabled in the zwave integration, button presses show in the logs of both ZJSUI and the integration.
2: No changes made, but the minimote node was interviewed. No change was seen in the integration.
3: Scene mode turned on in field 250. No apparent change in the integration but this may be inaccurate as I did not press any buttons.
4: Another interview of the node. Still no apparent change to the availability of sceneID but when I pressed a button on the remote sceneID then showed as available and my Node Red scenes started working
5: Scene mode disabled via field 250. After this, button presses were not registered in either log and my automations no longer worked but sceneID remained available in the zwave integration.

There is a clear difference between (1) and (5) in that when I specifically set field 250 to disabled I get no button presses logged, but if I enable scene mode in field 250 and then restart ZJSUI the zwave integration shows sceneID as unavailable yet button presses are registered in the logs. I think that this shows:

• if scene mode is enabled in the remote it generates events which are seen by ZJSUI
• if scene mode is disabled in the remote it does not generate events
• if scene mode is enabled in the remote and ZJSUI is restarted then the remote still knows that scenes are enabled and generates events; those events are seen by ZJSUI and the Zwave integration but sceneID is no longer flagged as available so the events are not passed to automations, whether they be coded in Node Red or Home Assistant.

The only conclusion I can draw from this is that ZJSUI is not configuring the node correctly after a restart.

One final test: I enabled scene mode in field 250 but also for each of the four buttons. My automations worked as normal. I then restarted ZJSUI with the same result as before: sceneID became unavailable and my automations stopped working. Setting the buttons to scene mode therefore makes no difference.

zwave_js-01JF7SE7B4HRK5Z7R95C000ZJ6-Minimote White-851f8cf40b09086212a9dfa662417d57.json

Apologies for bombing you with information but I just downloaded diagnostics for one remote from the Zwave integration after enabling scene mode in field 250 and waking the remote to ensure that the value was set there. The diagnostics include the following which incorrectly claims that scene mode is disabled:

      {
        "domain": "select",
        "entity_id": "select.minimote_white_scene_mode_secondary_controller",
        "original_name": "Scene Mode (Secondary Controller)",
        "original_device_class": null,
        "disabled": true,
        "disabled_by": "integration",
        "hidden_by": null,
        "original_icon": null,
        "entity_category": "config",
        "supported_features": 0,
        "unit_of_measurement": null,
        "value_id": "50-112-0-250",
        "primary_value": {
          "command_class": 112,
          "command_class_name": "Configuration",
          "endpoint": 0,
          "property": 250,
          "property_name": "Scene Mode (Secondary Controller)",
          "property_key": null,
          "property_key_name": null
        }
      }

This explains why the sceneID event field is disabled. The question remains: why does ZJSUI or ZJS think that scene mode is disabled when it is not?

Unfortunately none of the new logs you attached are driver debug logs, so there is no new information provided by the logs. We would really need to see those driver logs to possibly know more. Despite that, I can provide some clarifications based on the other new information.

The diagnostics include the following which incorrectly claims that scene mode is disabled

Actually the diagnostic provided says it's enabled. The select entity points to value ID 50-112-0-250. Look under the values field and you find:

      "values": {
        "50-112-0-250": {
          "endpoint": 0,
          "commandClass": 112,
          "commandClassName": "Configuration",
          "property": 250,
          "propertyName": "Scene Mode (Secondary Controller)",
          "ccVersion": 1,
          "metadata": {
            "type": "number",
            "readable": true,
            "writeable": true,
            "label": "Scene Mode (Secondary Controller)",
            "default": 0,
            "min": 0,
            "max": 1,
            "states": {
              "0": "Disable",
              "1": "Enable"
            },
            "valueSize": 1,
            "format": 1,
            "allowManualEntry": false,
            "isFromConfig": true
          },
          "value": 1
        }

"value": 1 means it thinks Scene Mode is "Enabled". This metadata and value are basically the source of the state for the select entity. Of course, this will change on ZUI restart when parameter 250 goes "undefined" and you should see the value field is missing. But as I've been saying, this is not related to your actual problem.

This explains why the sceneID event field is disabled.

No, the event entity state is independent of the config parameter value, there is no relationship. The config parameter value ID is from the Configuration Command Class and the sceneId value ID is from the Scene Activation Command Class. There is no relationship between these values in Z-Wave JS.

The question remains: why does ZJSUI or ZJS think that scene mode is disabled when it is not?

It doesn't think it's disabled (see above), so your attention should focus on the event entity. Here's your event entity from the diagnostic:

      {
        "domain": "event",
        "entity_id": "event.minimote_white_scene_id",
        "original_name": "Scene ID",
        "original_device_class": null,
        "disabled": false,
        "disabled_by": null,
        "hidden_by": null,
        "original_icon": null,
        "entity_category": null,
        "supported_features": 0,
        "unit_of_measurement": null,
        "value_id": "50-43-0-sceneId",
        "primary_value": null
      }

The event entity state is determined by the 50-43-0-sceneId value ID. You'll see this doesn't exist in the file. If the value ID doesn't exist, then then the entity will be non-functional in HA (it becomes unavailable). Again, this has nothing to do with the "undefined" config parameter value.

• if scene mode is enabled in the remote it generates events which are seen by ZJSUI
• if scene mode is disabled in the remote it does not generate events
• if scene mode is enabled in the remote and ZJSUI is restarted then the remote still knows that scenes are enabled and generates events; those events are seen by ZJSUI and the Zwave integration but sceneID is no longer flagged as available so the events are not passed to automations, whether they be coded in Node Red or Home Assistant.

This is exactly what I have been saying all along. The configuration remains on the device and it's irrelevant whether ZUI/HA thinks/knows it's enabled or not. So the problem is the metadata of the "sceneId" value ID is lost on restart and only re-generated during the re-interview. Normally the Scene Activation value IDs will be persisted in cache, this part is required for battery devices. The diagnostic shows 50-43-0-dimmingDuration is retained, so it's strange that the sceneId is not.

I tried an automation with your code but as expected it does not work after a restart of Zwave JS UI because property sceneid is no longer available.

Event triggers have nothing to do with the event entity, so no that is not expected. The event triggers have pre-existed the event entity by several years, completely unrelated except that the source is the same event (Scene Activation Set). If you copied and pasted the trigger exactly as I posted it won't work, you need to fill in your device ID and the desired scene ID (button). You can also go to the Dev Tools event viewer, copy/paste zwave_js_value_notification into the "Event to subscribe to" text field and press "START LISTENING". Press buttons on the remote and you'll see the events with the actual fields and values. Switching to the event trigger will fix your problem, but it's just a workaround.

Since you're using an add-on, there's not a good way to downgrade to 9.26.0 which is the last version that used driver v13. That could show whether there is a problem in the newer driver code. I might try an upgrade to reproduce if I can find the time. Otherwise, hopefully you can grab the correct driver logs.

Also, I completely ignored your device screenshot.

You can clearly see the Scene Activation events are sent by the device and received by HA regardless of the state of the entity.

OK, so clearly I have a lot to learn!

I have successfully used the information in your last response to add code to Node Red which responds to zwave_js_value_notification for the two Minimotes and this works irrespective of the availability of Scene ID. For me the current bug becomes moot - thanks for your help there.

I attach a device debug log filtered for node 050 (one of my Minimotes). The log contains:

• 22:23 - restart ZJSUI - Scene ID becomes unavailable
• 22:25 - re-interview node 050 - Scene ID becomes available
• 22:26 - general log level (not device log) changed to "info" - Scene ID becomes unavailable
• 22:29 - re-interview node 050 - Scene ID becomes available

zwavejs_2025-01-12.log

Undefined Configuration Parameters

Regarding the config parameter values, all of them except 250 are marked as write-only. PR zwave-js/node-zwave-js#2555 is responsible for that, however it neglected to update parameter 250. Here are the Device DB parameters (derived from the config file):

Write only:

Read/write:

During the interview, you can see the read-back of parameters 241-249 are skipped (because they are write-only), and only 250 is queried. The read of 250 fails, so clearly it is also write-only.

2025-01-11T22:25:18.180Z CNTRLR   [Node 050] Interviewing Configuration...
2025-01-11T22:25:18.180Z CNTRLR   [Node 050] ConfigurationCC: Loading configuration parameters from device confi
                                  g
2025-01-11T22:25:18.181Z CNTRLR   [Node 050] [+] [Configuration] isParamInformationFromC [Endpoint 0] [internal]
                                  onfig: false
2025-01-11T22:25:18.182Z CNTRLR   [Node 050] [Configuration] 241: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.184Z CNTRLR   [Node 050] [Configuration] 242: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.186Z CNTRLR   [Node 050] [Configuration] 243: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.188Z CNTRLR   [Node 050] [Configuration] 244: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.189Z CNTRLR   [Node 050] [Configuration] 245: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.191Z CNTRLR   [Node 050] [Configuration] 246: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.192Z CNTRLR   [Node 050] [Configuration] 247: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.193Z CNTRLR   [Node 050] [Configuration] 248: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.194Z CNTRLR   [Node 050] [Configuration] 250: metadata updated                  [Endpoint 0]
2025-01-11T22:25:18.195Z CNTRLR   [Node 050] [~] [Configuration] isParamInformationFromC [Endpoint 0] [internal]
                                  onfig: false => true
2025-01-11T22:25:18.196Z CNTRLR » [Node 050] querying parameter #250 value...
2025-01-11T22:25:18.216Z SERIAL » 0x010a001332037005fa253c41                                          (12 bytes)
2025-01-11T22:25:18.216Z DRIVER » [Node 050] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      60
                                  └─[ConfigurationCCGet]
                                      parameter #: 250
2025-01-11T22:25:18.235Z SERIAL « [ACK]                                                                   (0x06)
2025-01-11T22:25:18.237Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2025-01-11T22:25:18.238Z SERIAL » [ACK]                                                                   (0x06)
2025-01-11T22:25:18.239Z DRIVER « [RES] [SendData]
                                    was sent: true
2025-01-11T22:25:18.273Z SERIAL « 0x011800133c00000200be7f7f7f7f000103000000000201000075              (26 bytes)
2025-01-11T22:25:18.274Z SERIAL » [ACK]                                                                   (0x06)
2025-01-11T22:25:18.283Z DRIVER « [REQ] [SendData]
                                    callback id:            60
                                    transmit status:        OK, took 20 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -66 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         1
2025-01-11T22:25:19.377Z CNTRLR   [Node 050] Timed out while waiting for a response from the node (ZW0201)
2025-01-11T22:25:19.378Z CNTRLR « [Node 050] received no value for parameter #250
2025-01-11T22:25:19.378Z CNTRLR   [Node 050] [+] [Configuration] interviewComplete: true [Endpoint 0] [internal]

So I think this is just a missing setting from the device config file, parameter 250 should be set to write-only. Since the device fails to respond, you will never see a valid value, except maybe temporarily after you set it. Also, neither the Home Assistant UI nor ZUI give any indication that the parameters are write only, it would be nice if they indicated it some way.

Missing sceneId value ID

Regarding the sceneId value, this part is bringing back some memories. When the device is interviewed, it doesn't report any support for Scene Activation.

2025-01-11T22:25:16.379Z CNTRLR « [Node 050] node info received
                                  supported CCs:
                                  · Version
                                  · Manufacturer Specific
                                  · Configuration
                                  · Association Command Configuration

Since Scene Activation is not reported, Z-Wave JS has no idea the device supports it and never queries it for any information. Normally a device reports that it's supported, and the interview process automatically creates the sceneId value ID, as these are "static" value IDs that always exist (https://github.com/zwave-js/node-zwave-js/blob/545432d1502c55cd092cd382b3ba6a5c2b101099/packages/cc/src/cc/SceneActivationCC.ts#L38-L59).

The driver will also create the entities on demand when the command is seen. However, it appears that the metadata and value are never persisted to the cache files. That means on restart they are lost. Not sure if this is expected or not. Here's how it's persisted:

$ grep sceneId d73ecdff.metadata.jsonl 
{"k":"{\"nodeId\":9,\"commandClass\":43,\"endpoint\":0,\"property\":\"sceneId\"}","v":{"type":"number","readable":true,"writeable":true,"min":1,"max":255,"label":"Scene ID","valueChangeOptions":["transitionDuration"]}}

And as for bringing back memories, I just realized I created a custom device config file (about a year ago!) to force Scene Activation support.

$ ls config
dsa03202.json  vision_test.json

@@ -86,6 +86,10 @@
 	"compat": {
 		"commandClasses": {
 			"add": {
+				"Scene Activation": {
+					"isControlled": true,
+					"version": 1
+				},
 				"Wake Up": {
 					// To fix issue #1536
 					"isSupported": true,

This creates and persists the sceneId value correctly, so it explains why my event entity doesn't have the same problem. Mystery solved.

Now I remember I wanted to add this since it was supported but not detected, but never followed through because I didn't have any problems with the event. I can look at submitting a PR. I attached the device config file if you want to drop this into your own override directory, it should allow to use the event entity if you want (after re-interview). However, as you've found the HA event works without it.

dsa03202.json

I installed your override configuration and that does solve the problem with scene ID. I will revert my Node Red code to use that, but keep the new code in reserve in case of future problems.

If you have the time to do a PR to fix the issue permanently it would be appreciated and will save you and others having to go through all this again in future. I have learnt a few things but would have preferred to remain in the dark and just have a working system.

Thanks for all your efforts on this issue.