2022.4: Groups! Groups! Groups!

Thanks for the suggestion I have tried these operations without success I don’t know how to update the release is it possible that nobody has this problem?

I’ve seen people have this issue (on and of) never seen it was persistent, 1 time an update “vanished” for me but the next day it was there , latest 2022.4.3 i clicked(on 1 laptop), and nothings seemed to happend, when i looked direct on the “server” it was updated, and a “complete” clear History-Cache, solved it on the other laptop(from where i installed it)
Anyhow, if above dont solve it, and you aint got other problems, i would wait to another update shows up

Thank you boheme61

From what I can see, there is no breaking change. There’s a hardware issue with conbee II sticks that breaks the network that can randomly happen on a restart. I don’t use zigbee though, but that’s what I’ve gathered from reading all these posts with and without solutions.

Excellent work everyone!

A couple of suggestions for making Groups even better :slight_smile:

  1. Can we have Groups as a heading next to Automations | Scenes | Scripts | Helpers please? If creating a lot of groups it would be very helpful to have them separated from the other Helpers.

  2. Can we have a People type added to the Groups types please?

No way…
The message does not change because of hardware and/or a restart.

Have a look here at the arguments:

Message structure from link above:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "ec:1b:bd:ff:fe:39:63:da",
        "unique_id": "ec:1b:bd:ff:fe:39:63:da:1:0x0008",
        "device_id": "a6e2928ee51d31c25e7afa6d1f55dbc9",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "move",
        "args": [
            0,
            195,
            0,
            0
        ],
        "params": {
            "move_mode": 0,
            "rate": 195,
            "options_mask": 0,
            "options_override": 0
        }
    },
    "origin": "LOCAL",
    "time_fired": "2022-04-12T21:03:00.224206+00:00",
    "context": {
        "id": "ad76032c18e711ee9757881b8ad66973",
        "parent_id": null,
        "user_id": null
    }
}

the same event in 2022.3.3, same remote:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "5c:02:72:ff:fe:40:af:22",
        "unique_id": "5c:02:72:ff:fe:40:af:22:1:0x0008",
        "device_id": "f594d0a16628c130b023f476a35c0091",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "move",
        "args": [
            0,
            195
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2022-04-14T11:42:59.725750+00:00",
    "context": {
        "id": "8797f70a0ae25787f8af15180bace373",
        "parent_id": null,
        "user_id": null
    }
}

I do not believe this is due to hardware or restarts.
That data is from ZHA, there is no way the remote has any context of “time_fired” for instance.

Uh, your unique_id is different which is based on hardware information. That means the hardware info changed. :man_shrugging:

No… That is because one remote is owned by the guy in the link, the other by me. So obviously they would be different

That’s comparing apples to oranges. Are they on the same firmware? The only event difference here is the data supplied in the event, which is the params dictionary.

And the arguments, ehrm…, Which is the important part.
There is no other difference you can argue whatever you want.

Someone made a change to ZHA that lead to a different message structure, that is a breaking change!

1 Like

well, it looks like the underlying library was downgraded 2 days ago. So it’s possible that zigpy-deconz changed events from 0.14.0 to 0.15.0

FYI events are forwarded from underlying libraries. 9 times out of 10, events are just passed directly through to HA from the hardware or the controller. It seems like you’re personally attacking me when I’m just trying to explain how things typically work. I.e. there’s no feeling behind my words. I’m explaining what I see.

1 Like

I’m not attacking you, I’m just saying that if everyone (or a vast majority) has problems after an upgrade and nobody that is still on the old version have problems then I do not believe it is due to hardware.
In my opinion it’s very obvious something got changed in the upgrade that was not announced.

If that is the library or ZHA integration. It doesn’t really matter to me, there is a breaking change that is not listed in the release notes

Yes, but we are also speaking about 2 different issues here. All of the issues i’ve read about so far aside from your event issue are related to the entire network dying. I assumed this is what you were talking about. I was wrong for assuming that, however that’s the issue I was referencing. Which, from what I can tell is 100% related to conbee II sticks.

Anyways, it appears as if that was a bug which is why it wasn’t listed as a breaking change. It’s already fixed

Not sure when it will be delivered. It was delivered in 2022.4.1

EDIT: Here’s a link to the PR, not the actual change

1 Like

Reading the comments, there still seems to be issues.
And just after people voice these issues the discussion is locked.

Move new zha_event command parameters into a params key to ensure backwards compatibility by puddly · Pull Request #69631 · home-assistant/core (github.com)

That’s an autobot locking the PR because it was merged. There isn’t some conspiracy. If it breaks something, then an issue should be written up.

2 Likes

Let me say this loud and clear: The devs are not out to make your life miserable. They are trying to provide fixes, enhancements, and updates. Sometimes breaking changes due to bugs squeak through.

5 Likes

Part of the problem here is the definition of breaking change. It does not mean “a change which caused something to break.” It does not include what the rest of us would call a bug.

In the HA world, “breaking change” means a change which was designed in advance to require that the user make some sort of re-configuration or adjustment, or things will break.

There is definitely something going on with Zigbee and ZHA in release 2022.4. I’m watching 7 issues and 9 pull requests on Github. Granted, I can’t comprehend most of them, but it does signify a lot of activity.

At this point it might not be a bad strategy to wait for the dust to settle a bit before updating to 2022.4. It’s frustrating. I like to be up-to-date. But I have confidence our best people are on it!

4 Likes

It seems like puddly (Assuming that’s the main dev as he has the most activity everywhere) is working pretty hard at whatever changed.

2 Likes