Add zwave_js.reset_meter service

[raman325]

Proposed change

It's been discussed in the past to add a meter reset service. With the introduction of the invoke_cc_api command, we can now add support for this.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request: Document zwave_js.reset_meter service home-assistant.io#18587

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @home-assistant/z-wave, mind taking a look at this pull request as its been labeled with an integration (zwave_js) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[MartinHjelmare]

Is this something that users want to automate or is it enough with a manual form per device page?

[kpine]

Can a node have multiple meters (via multi-channel endpoints), and if so want would you want to reset them individually? FYI, the legacy zwave implementation of this includes an instance (endpoint) attribute in the service call, and the zwave-js code also seems to be endpoint aware. I assume this is the case, but I don't have any devices with meters.

Assuming multiple meters, then this change actually only finds one meter reset instance, meaning it wouldn't be possible to reset the others. The endpoint could be derived if the actual sensor entity for the meter value was passed into the service call instead, so the user doesn't need to be aware of endpoints.

[raman325]

Is this something that users want to automate or is it enough with a manual form per device page?

I don't use this CC so I can't say for sure, but I can imagine a scenario where a user wants the meter to be reset on a regular basis, like at the beginning of every month (or some other period). There may be some other use cases I am not aware of.

The reason I went for a service call is because it's listed as one in the roadmap issue. With that being said, this would be easy enough to flip into a WS API call if that's what we think is best

[raman325]

Can a node have multiple meters (via multi-channel endpoints), and if so want would you want to reset them individually? FYI, the legacy zwave implementation of this includes an instance (endpoint) attribute in the service call, and the zwave-js code also seems to be endpoint aware. I assume this is the case, but I don't have any devices with meters.

Assuming multiple meters, then this change actually only finds one meter reset instance, meaning it wouldn't be possible to reset the others. The endpoint could be derived if the actual sensor entity for the meter value was passed into the service call instead, so the user doesn't need to be aware of endpoints.

Hmm good points. There are two options here:

• Parse the unique ID of each entity provided, find the endpoint in the value ID (we'd have to drop support for device's as an input), and use that to call the API
• Add an endpoint parameter - This is extremely simple but then requires a service call to be specific to a particular endpoint.

The fallback, if an endpoint isn't provided, is to use the existing logic.

The fixtures that are available in the project do not have meters on multiple endpoints, but that doesn't mean it's not possible

[kpine]

If HA had an entity for a momentary switch, e.g. "button", this would be the perfect application. All the meter reset capabilities, whether it's per-endpoint or per-meter-type, are already implemented with zwave-js values. You would just need a button per reset value, and some custom service to set the initial meter reset value (for those values with CC version >= 6).

What about Device Actions, could those be an alternative? I'm imagining you could create an action corresponding to each zwave-js meter reset value. That would support all possible reset scenarios. It would also be completely obvious when the device supports only resetting all meter types, or allows resetting individual meter types. The only twist would be allowing the setting of that initial meter reset value for that specific case.

[cgarwood]

I think reset_meter may be a better name than meter_reset, and reads more like the other services like set_value and such

[raman325]

If HA had an entity for a momentary switch, e.g. "button", this would be the perfect application. All the meter reset capabilities, whether it's per-endpoint or per-meter-type, are already implemented with zwave-js values. You would just need a button per reset value, and some custom service to set the initial meter reset value (for those values with CC version >= 6).

What about Device Actions, could those be an alternative? I'm imagining you could create an action corresponding to each zwave-js meter reset value. That would support all possible reset scenarios. It would also be completely obvious when the device supports only resetting all meter types, or allows resetting individual meter types. The only twist would be allowing the setting of that initial meter reset value for that specific case.

Yes we can add these as device actions, and then to your point we can explicitly discover what's supported for each device and show a relevant action.

Is there a proposal for a button platform anywhere or are you just brainstorming? If there's any legs on that idea, I would then vote to close this and wait until that's been created.

[firstof9]

@kpine requested this dump with multiple endpoint meters.
zooz26.zip

[kpine]

Is there a proposal for a button platform anywhere or are you just brainstorming? If there's any legs on that idea, I would then vote to close this and wait until that's been created.

There's no proposal AFAIK, that was just an idea. I'm sure there are other use cases out there for momentary switches besides z-wave, and I don't know what the usual solution is. Of course you could make these things switch entities too, they just don't have any real state, and can only be turned on. Not sure that would be acceptable.

[raman325]

Is there a proposal for a button platform anywhere or are you just brainstorming? If there's any legs on that idea, I would then vote to close this and wait until that's been created.

There's no proposal AFAIK, that was just an idea. I'm sure there are other use cases out there for momentary switches besides z-wave, and I don't know what the usual solution is. Of course you could make these things switch entities too, they just don't have any real state, and can only be turned on. Not sure that would be acceptable.

Got it. I think a service call is effectively our "button" at the moment. Can anyone confirm whether or not this is useful as a service call (pro: automatable, con: only feedback is through logging) vs something that can be manually triggered in the UI (pro: better feedback, con: not automatable)?

[firstof9]

Can we do both?

[raman325]

when you say both, do you mean service and device action? or service and UI in config panel? I was planning to do the first one, not sure if the second pair makes all that much sense since the developer tools will already give you a service UI

[cgarwood]

I think service makes the most sense. People will likely want to reset meters on a schedule (monthly/weekly/etc)

[firstof9]

Ya a service is perfect really.

[raman325]

I'm wondering if we should make this an entity service that's registered off an entity with the Meter CC. That would reduce the instances of the service to those that actually may need it.

[raman325]

Turns out we can't selectively enable it. If I attempt to register the service in the callback that creates the entities, the code can't get the current platform. So we'll just have to register it if the sensor platform gets created

[MartinHjelmare]

Looks good!