Move values polling configurations to a dedicated table instead of gateway values

[AlCalzone]

Just having the labels can make it hard to know which is which for more capable devices.

[robertsLando]

Values added there will never have a nodeID, they work for all devices with same deviceId (same manufacturer and product ids). I can add the CC name BTW

[AlCalzone]

And what if there are two different firmware revisions of a device with completely different values? And what about endpoints with the same values?

And writeonly values should be filtered out, you can't poll this:

[robertsLando]

I cannot filter out the polling values as that devices values table isn't only used for polling but in general for all device specific customization like also mqtt topics, custom parse send/receive function and more. What I can add anyway is a field to manually specify the nodeIds that value config should be applied to (instead of all) or maybe the opposite is better, like excludeNodes array prop to say what nodes shouldn't use that. What do you think?

[AlCalzone]

I'm thinking polling may need a separate configuration. IMO the current approach is a bit too generic. https://github.com/zwave-js/node-zwave-js/issues/6229 alone is a good example. My plug needs no polling at all, or just for 1 value. The older variants may need polling for 3-4 values.

This could be done very similar to the current dialog:

• select one or more nodes -> Z-UI determines which readable value IDs those have in common
• from those, select one or more value IDs
• set polling interval for those

Edit: If I understand correctly, the current table uses the fingerprint of the device to identify the different types. Problem with that is that some devices are available with different fingerprints, but behave the same, so you'd end up configuring them twice.

[robertsLando]

Yeah the fingerprint for me is the deviceId:

https://github.com/zwave-js/zwave-js-ui/blob/c8386982417dea662be7448965adcb3d3bcbd494/lib/ZwaveClient.ts#L6146-L6150

Changing how polling works would be a breaking change BTW.

Otherwise, about the polling of write only values, I could disable polling or show an error when the selected value is a write only value

[AlCalzone]

Changing how polling works would be a breaking change BTW

Can we phase it out?

• Keep the current table as-is until v9 or v10
• Add a new table only for polling with the proposed changes
• Add a notification to the current table that polling should be configured with the new table?
• Or maybe add a checkbox [x] use legacy polling configuration, default false if there is no polling configured, and only show the legacy polling config if that is checked

[robertsLando]

Can we phase it out?

Sure! I will change the title of the issue so

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label