feat(attributePicker): support custom attributes (nurikk/zigbee2mqtt-frontend#2001)

[LaurentChardin]

This change is linked to Koenkk/zigbee2mqtt#22583 which will update the device definition.
This change is aiming to enable using Custom Clusters attributes in the dev-console, which are not available through ZH.

Updates:

• Update type definition to introduce Custom Clusters
• Remove zh and zhc dependencies
• Duplicate Cluster.ts file as this is becoming static
• Updating references in components
• TODO: updating zigbee2mqtt with bridge.ts extension to publish custom clusters as part of bridge/devices topic: (feat) Expose Custom Clusters in MQTT Koenkk/zigbee2mqtt#22583

Notes:

• @Koenkk with this change, only relevant cluster list are displayed based on the declated clusters in the endpoints. It will not display clusters that cannot be used by the device (in the reporting tab or the dev tab).

[nurikk-sa]

Hi @LaurentChardin! I really appreciate your work and looking forward to merge this pr! 👍

[LaurentChardin]

Updated with the latest change of Koenkk/zigbee2mqtt#22583

[nurikk]

is it ready to be reviewed?

[nurikk]

package lock is outdated

[LaurentChardin]

package lock is outdated

I think i have a different version of pnpm, and since i updated package.json, i didn't check the impact of the build automation. Might have to update .github/workflows/node.js.yml

I am pushing an update with an updated version of pnpm as well as updated version of the github action lib. But i can't test it (or more : i dont know how to :) )

[LaurentChardin]

@nurikk Is there a way to automate the build test to check the configuration ? or maybe you can have a look ? i am trying to fix it blind :)

Or i should try it on my own repo i guess. Build is working locally of course.

[nurikk]

@nurikk Is there a way to automate the build test to check the configuration ? or maybe you can have a look ? i am trying to fix it blind :)

Or i should try it on my own repo i guess. Build is working locally of course.

1. remove version specificator from github action cofigs
2. "packageManager": "pnpm@9.1.1"
3. pnpm install

this should fix the problem

[nurikk]

you should be able to see how your branch is building in Checks tab

[LaurentChardin]

you should be able to see how your branch is building in Checks tab

Yes but it seems you need to trigger it to execute it. I think we could have a workflow that is building it automatically on every PR and update of PR, without the need of a manual action or review.

[nurikk]

I guess github requres approvals when you change actions config. now it should run on every commit.

latest commit failed due to linting issues. can be fixed by pnpm run pretty
https://github.com/nurikk/zigbee2mqtt-frontend/actions/runs/9126981170/job/25096489332?pr=2019

[LaurentChardin]

issues

Yes learning how it works the hard way :)

[LaurentChardin]

The latest commit didnt touch the github action file : still requires your approval to test the build phase.

@Koenkk // @nurikk ( or @nurikk-sa :) ) : can you activate the build test ? The main change has been merged into the z2m dev branch.

[Koenkk]

@LaurentChardin Looks like the tests fail, after that I guess this can be merged?

[LaurentChardin]

@LaurentChardin Looks like the tests fail, after that I guess this can be merged?

The vitest is testing the UI component in a stateless manner. However now we are dependant on the websocket message to retrieve the cluster definition, since we don't have the dependency on ZH anymore : i am not sure how to inject a fake websocket to create the store object in a test case. I am not even sure the test setup is ready for that at all.

Right now, the attribute picker UI component is dependant on the store :

    const { bridgeDefinitions } = store.getState();

There are very little UI test cases defined and none of them are designed to fake a state retrieved from websocket: i believe we need to revamp the whole test suite to enable those kind of tests.

[LaurentChardin]

I found a way to test the UI component by injecting the clusters definition through the component attributes.

There might be a better way to test the component with a global state initiated with some server payload, but it does the trick.

@nurikk Happy to do things differently if you have a better approach.

[Koenkk]

@LaurentChardin can you run npm run pretty? After that this can be merged.

[LaurentChardin]

@LaurentChardin can you run npm run pretty? After that this can be merged.

Done

[Koenkk]

Thanks!