fix(ignore): move ubisys clusters/attributes out of zh

[sjorge]

Depends on modernExtend added in #7450, rebase and merge after that one.

Also depends on #7463, this PR needs a rebase merge.

After this, merge Koenkk/zigbee-herdsman#1034

[sjorge]

I don't understand the test failure, I don't think I've changed that code ?
It also of course prevent me from actually testing the whole PR.

Edit this is also used in more locations, which does not seem to trip the assert???

src/devices/bitron.ts:        exposes: (device, options) => {
src/devices/bosch.ts:        exposes: (device, options) => {
src/devices/busch_jaeger.ts:        exposes: (device, options) => {
src/devices/custom_devices_diy.ts:        exposes: (device, options) => {
src/devices/danfoss.ts:        exposes: (device, options) => {
src/devices/develco.ts:        exposes: (device, options) => {
src/devices/imhotepcreation.ts:        exposes: (device, options) => {
src/devices/legrand.ts:        exposes: (device, options) => {
src/devices/legrand.ts:        exposes: (device, options) => {
src/devices/lixee.ts:        exposes: (device, options) => {
src/devices/ls.ts:        exposes: (device, options) => {
src/devices/moes.ts:        exposes: (device, options) => {
src/devices/moes.ts:        exposes: (device, options) => {
src/devices/profalux.ts:        exposes: (device, options) => {
src/devices/siglis.ts:        exposes: (device, options) => {
src/devices/siglis.ts:        exposes: (device, options) => {
src/devices/tuya.ts:        exposes: (device, options) => {
src/devices/tuya.ts:        exposes: (device, options) => {
src/devices/tuya.ts:        exposes: (device, options) => {
src/devices/tuya.ts:        exposes: (device, options) => {
src/devices/ubisys.ts:        exposes: (device, options) => {

Edit2: It seems this is triggered because J1 now has an 'extend: []' block, which it did not have before.
@Koenkk I think the fact that exposes is a function still makes sense here. It changes what is exposed based on the devices configuration which is highly variable.

[sjorge]

I'll rebase after #7450 lands.

[sjorge]

All seems good, I tested both TRV vacationMode changes, S1+C4+S2 input_action configuration and a full J1 calibration

[2024-04-28 22:05:01] warning:  zhc:ubisys: ubisys:   Done - will now read back the results.
[2024-04-28 22:05:01] warning:  zhc:ubisys: ubisys: Cover configuration read: {"windowCoveringType":0,"physicalClosedLimitLiftCm":65535,"physicalClosedLimitTiltDdegree":65535,"installedOpenLimitLiftCm":0,"installedClosedLimitLiftCm":240,"installedOpenLimitTiltDdegree":0,"installedClosedLimitTiltDdegree":900}

All seems to still work, but the J1 calibration is the most complex so I focused mostly on that.

I tested this with both ZH's cluster definition unchaged and with the ubisys entries removed in ZH.

[burmistrzak]

@sjorge So the idea here is for ZH to eventually only include what's actually in the ZCL spec, right?
What do you think, does it still make sense to add new Bosch-specific definitions to ZH, or should I wait until I can also refactor bosch.ts in a similar fashion?

[sjorge]

@sjorge So the idea here is for ZH to eventually only include what's actually in the ZCL spec, right? What do you think, does it still make sense to add new Bosch-specific definitions to ZH, or should I wait until I can also refactor bosch.ts in a similar fashion?

You can probably start by adding the new ones in zhc on the devices that need them, then moving the other ones out of zh into zhc can come after. It's fine to have some in zhc and some still in zh, so new ones don't get added to zh IMHO.

Once @Koenkk merges #7463 I will rebase this PR and this one should be ready for merging too.

[Koenkk]

Merged #7463 !

[sjorge]

I only give it another quick retest after changing the casing of the DataType, I just turned on/off some of the switches. I did not do a full J1 reconfigure as it's rather noisy to make the blinds go up and down a few times during calibration and it's already pretty late.

[burmistrzak]

You can probably start by adding the new ones in zhc on the devices that need them, then moving the other ones out of zh into zhc can come after. It's fine to have some in zhc and some still in zh, so new ones don't get added to zh IMHO.

Yea, sounds good. 👌
Will eventually give it a try with something low-risk. 😅

[Koenkk]

Thanks!