Window Covering cluster: ZAP configuration updated.

[rcasallas-silabs]

Problem

Window Cluster configuration is outdated.

Change overview

The following attributes where added to examples/window-app/common/window-app.zap:

• TargetPositionLiftPercent100ths
• TargetPositionTiltPercent100ths
• CurrentPositionLiftPercentage
• CurrentPositionTiltPercentage
• OperationalStatus
• TargetPositionLiftPercent100ths
• TargetPositionTiltPercent100ths
• EndProductType
• CurrentPositionLiftPercent100ths
• CurrentPositionTiltPercent100ths

Testing

• Window Cover compiled and run on the EFR32MG12 board. Currently this sample is only supported for the EF32 platform.

[github-actions]

Size increase report for "esp32-example-build" from 6628298

File	Section	File	VM
chip-all-clusters-app.elf	.flash.text	24	24
chip-lock-app.elf	.flash.text	64	64

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-all-clusters-app.elf and ./pull_artifact/chip-all-clusters-app.elf:

sections,vmsize,filesize
.xt.lit._ZN4chip6System5Mutex6UnlockEv,0,128
.xt.lit._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE10_PostEventEPKNS0_15ChipDeviceEventE,0,80
.xt.prop._ZN4chip11DeviceLayer8Internal26GenericPlatformManagerImplINS0_19PlatformManagerImplEE14_InitChipStackEv,0,40
.flash.text,24,24
.xt.prop._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE14_LockChipStackEv,0,-12
.xt.prop._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE15_StartChipTimerEj,0,-12
.xt.prop._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE16_UnlockChipStackEv,0,-12
[Unmapped],0,-24
.xt.lit._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE14_LockChipStackEv,0,-48
.xt.lit._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE15_StartChipTimerEj,0,-48
.xt.lit._ZN4chip11DeviceLayer8Internal35GenericPlatformManagerImpl_FreeRTOSINS0_19PlatformManagerImplEE16_UnlockChipStackEv,0,-48
.xt.prop._ZN4chip6System5Mutex6UnlockEv,0,-108

Comparing ./master_artifact/chip-persistent-storage.elf and ./pull_artifact/chip-persistent-storage.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-temperature-measurement-app.elf and ./pull_artifact/chip-temperature-measurement-app.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-lock-app.elf and ./pull_artifact/chip-lock-app.elf:

sections,vmsize,filesize
.flash.text,64,64
[Unmapped],0,-64

Comparing ./master_artifact/chip-pigweed-app.elf and ./pull_artifact/chip-pigweed-app.elf:

sections,vmsize,filesize

Comparing ./master_artifact/chip-shell.elf and ./pull_artifact/chip-shell.elf:

sections,vmsize,filesize

[bzbarsky-apple]

Seems fine, but does all-clusters-app need similar updates?

[jmeg-sfy]

Thanks @ricardo-casallas, @jmartinez-silabs @bzbarsky-apple just to let you know why i renamed Stop as StopMotion . This was done to avoid conflict with another function with the same name from another cluster. Since Zap namespace is not working nicely/properly yet on all part of the code, here by renaming Stop the handler gonna call Stop from another cluster, you can't detect it because the CI wont catch this error. I was willing to rename this command in the specs. This is not a big deal i will correct in a newer PR

[jmartinez-silabs]

@jmeg-sfy Do we have a ticket to track this issue in ZAP. There was another error with commands with the same names over different clusters that didn't get generated but that got fixed some time ago. This seems related but we will need to track this issue.

[bzbarsky-apple]

Yes, @jmeg-sfy please make sure there is an issue filed with a very clear description of the ZAP problem and that @tecimovic and @vivien-apple are aware of it.