Z-Wave.me: Allow updating entities

[Tomeamis]

Proposed change

Makes entities from the Z-wave.me integration support being explicitly updated

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)
• Deprecation (breaking change to happen in the future)
• 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:
• Link to developer documentation pull request:
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• 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
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

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.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

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

[home-assistant]

Hi @Tomeamis

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[home-assistant]

Hey there @lawfulchaos, @Z-Wave-Me, @PoltoS, mind taking a look at this pull request as it has been labeled with an integration (zwave_me) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zwave_me can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign zwave_me Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the pull request.

[home-assistant]

Hi @Tomeamis

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

Stale

[mib1185]

Which use case or bug will this solve or fix?

[joostlek]

CI is failing, can you take a look?

[Tomeamis]

Which use case or bug will this solve or fix?

I have a dimmable light that doesn't push updates to the controller. The controller seems to expect that, so after it issues a Set command, it also tries to get the value from the device. Unfortunately, if the change is slow enough, the update happens before the value changes, so the controller seems to think that nothing has changed. I tried to force the update from a HA script, but it did nothing. This ensures that the update command actually goes to the device, thus alerting the controller that changes are happening.

[Tomeamis]

CI is failing, can you take a look?

Done. Now the only failure is the test coverage, and there were no tests for this to begin with.

[mib1185]

I have a dimmable light that doesn't push updates to the controller. The controller seems to expect that, so after it issues a Set command, it also tries to get the value from the device. Unfortunately, if the change is slow enough, the update happens before the value changes, so the controller seems to think that nothing has changed. I tried to force the update from a HA script, but it did nothing. This ensures that the update command actually goes to the device, thus alerting the controller that changes are happening.

This sounds more like it should be solved in the zwave_me_ws library, rather than here in the consuming application (Home Assistant) 🤔

[Tomeamis]

This sounds more like it should be solved in the zwave_me_ws library, rather than here in the consuming application (Home Assistant) 🤔

How so? You can't force update from HA if the HA integration ignores the command. The library you linked is just a wrapper around their websocket API, which does nothing on its own. The attempted update logic is in the controller, which indeed has many places that could be improved, but sadly, they aanounced that there will be no new versions. Also, what exactly is bad about Home Assistant being able to solicit an update from the device?

[mib1185]

Besides the update method should be placed in the base ZWaveMeEntity class, so all possible faulty devices could be manually updated, this is still not a good user experience - the user should not be in charge to check if a config change on the device arrived, the data are correct updated and if not manually force an update - this should be done by the integration automatically, so no user intervention is necessary

[Tomeamis]

Besides the update method should be placed in the base ZWaveMeEntity class, so all possible faulty devices could be manually updated, this is still not a good user experience - the user should not be in charge to check if a config change on the device arrived, the data are correct updated and if not manually force an update - this should be done by the integration automatically, so no user intervention is necessary

I have thought about putting it there, but I wasn't sure that I should do that with all device types, since I can only test a few. But if you think it's better, I can move it. AFAIK all the device types either support the "update" command or ignore it, so it shouldn't break anything.
And I agree that the user experience is not the best, but the best user experience would be if the device actually reported the brightness change. But since I can't make it do that, the next best thing is if I have the tools to work around the defects. It's not like this forces the user to manually update, it just gives them the option. And I thought the whole point of Home Assistant was putting the power in the hands of the user.

EDIT: Also, most devices do report the changes themselves, so it's not like the integration should just call the "update" command after every change command.

[PoltoS]

The update process should not be in the integration, but rather in Z-Way itself.

Z-Way is smart enough to detect that the device supports Supervision and LifeLine. If so, it won't do additional updates. Otherwise, it will poll the device itself after the update.

If the device, on getting a Set and then a Get, will return the old value and no unsolicited report, it is a big device issue. You can write a script to poll such a device on Get (tricky, but doable).

But better to check first:

• does it support Supervision
• is it a Z-Wave Plus device with LifeLine
• is Z-Way in LifeLine Association group?

[Tomeamis]

The update process should not be in the integration, but rather in Z-Way itself.

Z-Way is smart enough to detect that the device supports Supervision and LifeLine. If so, it won't do additional updates. Otherwise, it will poll the device itself after the update.

If the device, on getting a Set and then a Get, will return the old value and no unsolicited report, it is a big device issue. You can write a script to poll such a device on Get (tricky, but doable).

But better to check first:

• does it support Supervision
• is it a Z-Wave Plus device with LifeLine
• is Z-Way in LifeLine Association group?

It doesn't support Supervision.

And yes, it does poll the device after the Set. But it doesn't seem to take the Set duration into account, it just issues a Get immediately, and if that returns a different value, (apparently) every 2 seconds thereafter until it returns the same value. Unfortunately, if the duration is, for example, 10 minutes, that makes for one tick every 6 seconds, so the 2 second Get interval returns the same value and the polling ends.

Also, in your opinion, would it cause any issues if I just put the update method in the ZWaveMeEntity? AFAIK HA wouldn't call it by itself, since the Integration is Local Push, so it should just give the user the option of forcing an update.

[PoltoS]

I got your point about a very slow Set. Make sense, I'll check if we can improve Z-Way to change 2s to depend on the duration (if it is set). Good idea! Issue created.

Also, in your opinion, would it cause any issues if I just put the update method in the ZWaveMeEntity? AFAIK HA wouldn't call it by itself, since the Integration is Local Push, so it should just give the user the option of forcing an update.

Won't harm if it is not called periodically.

[Tomeamis]

I moved the update to ZWaveMeEntity, tested it with some other devices and it seems to work fine.

I got your point about a very slow Set. Make sense, I'll check if we can improve Z-Way to change 2s to depend on the duration (if it is set). Good idea! Issue created.

Also, in your opinion, would it cause any issues if I just put the update method in the ZWaveMeEntity? AFAIK HA wouldn't call it by itself, since the Integration is Local Push, so it should just give the user the option of forcing an update.

Won't harm if it is not called periodically.

Oh, nice. I thought the development was over. I looked in the GitHub repos and couldn't find it, would you mind linking it?