Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move new zha_event command parameters into a params key to ensure backwards compatibility #69631

Merged
merged 6 commits into from Apr 7, 2022

Conversation

puddly
Copy link
Contributor

@puddly puddly commented Apr 7, 2022

Breaking change

No.

Proposed change

A recent ZHA dependency upgrade (#68921) changed zigpy's response type to a list-compatible object that had attached type schemas. While the responses superficially worked, they caused problems with some types of comparisons. This change brings back the old behavior of keeping ZHA event data in a list object while migrating named ZHA event parameters into a new key:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "90:fd:9f:ff:fe:fe:d8:a1",
        "unique_id": "90:fd:9f:ff:fe:fe:d8:a1:1:0x0008",
        "device_id": "51e3449d17f2fd47abebd16b6721d470",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "step_with_on_off",
        "args": [
            0,
            43,
            5
        ],
+       "params": {
+           "step_mode": 0,
+           "step_size": 43,
+           "transition_time": 5
+       }
    },
    "origin": "LOCAL",
    "time_fired": "2022-04-07T17:55:49.966102+00:00",
    "context": {
        "id": "a92cda22a798ea82c6d0b7c7e4500dd9",
        "parent_id": null,
        "user_id": null
    }
}

If you feel this new params key should be split off into a separate PR, let me know.

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

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:

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 link to the changelog, or at minimum a diff between library versions is added to the PR description.
  • 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:

@probot-home-assistant
Copy link

Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)

@project-bot project-bot bot added this to Needs review in Dev Apr 7, 2022
Dev automation moved this from Needs review to Reviewer approved Apr 7, 2022
@balloob balloob merged commit fab1f29 into home-assistant:dev Apr 7, 2022
Dev automation moved this from Reviewer approved to Done Apr 7, 2022
@balloob balloob added this to the 2022.4.1 milestone Apr 7, 2022
balloob pushed a commit that referenced this pull request Apr 7, 2022
@balloob balloob mentioned this pull request Apr 7, 2022
@bernikr
Copy link

bernikr commented Apr 8, 2022

This change still doesn't make every comparison backwards comaptible: my ikea switch was sending [0, 43, 5] before, but is now sending [<StepMode.Up: 0>, 43, 5]

@JoryHogeveen
Copy link

This change still doesn't make every comparison backwards comaptible: my ikea switch was sending [0, 43, 5] before, but is now sending [<StepMode.Up: 0>, 43, 5]

Had the same issue here

@puddly
Copy link
Contributor Author

puddly commented Apr 8, 2022

@bernikr StepMode.Up == 0 so any comparisons will still work. What is being broken for you?

@bernikr
Copy link

bernikr commented Apr 8, 2022

If used in a template the args will translate to a string with the content '[<StepMode.Up: 0>, 43, 5]'. All further comparisons with this then break.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Dev
  
Done
Development

Successfully merging this pull request may close these issues.

zha_event with array args doesnt fire automation with matching array args
7 participants