STM32CubeExpansion_MATTER_V1.0.3 Window Covering is not working properly

[AkihiroN]

After debugging Window Covering with STM32CubeExpansion_MATTER_V1.0.3, after commissioning with Apple's HomePod, it shows "no response" on the iPhone and cannot be controlled.

I debugged that it is calling CHIP_ERROR WiFiDiagosticsAttrAccess::ReadWiFiRssi(AttributeValueEncoder & aEncoder) in wifi-network-diagnostics-server.cpp. Why is it calling this function when it is a threaded device?

[EPASZ.1 · Accepted solution]

Hello,

as I see it in debug mode, the Wifi diagnostic module is called only at the beginning of execution / startup of the stack. The cluster responsible for this has been left inside the project but, as it is not called after initialization, it doesn't have a big impact on speed, etc.

The issue here seems to be more on Apple side, the device itself doesn't look to be 'busy' with anything. In debug, the callback from the Matter stack in ZclCallbacks.cpp is never called. When I e.g. use the generic switch project on another WB device and use it to control the window, it works well. And after the first command from the switch, the phone app starts showing the correct state and not 'no response'.

I'd suggest using a second device as a switch or trying with a different ecosystem.

[AkihiroN]

Thanks for the confirmation.
In my environment as well, if I multi-admin Window App to Google's ecosystem and control it from Google side, I can control it from iPhone side as well.
I understand that this is an issue on the Apple side, but does this mean that Apple cannot control the Window-App?
Also, unrelated, but sometimes when I check the UART output logs after commissioning for both Lighting-App and Window-App
[REGION UNDEF] [W] Mle-----------: Failed to process UDP: Duplicated
is sometimes outputted. Is there any relation between these logs?

[EPASZ.1]

I'd say it is somehow related to the GUI functionality of the Apple app. Blocking the message sending until the GUI 'realizes' that the device is online. For some further debug, you might try to contact Apple support.

For the point of duplicated messages - it is not completely uncommon. It might happen e.g. when the device takes a bit more time to respond so the OTBR sends the message again and thus it appears to be duplicated on the device's side. Shouldn't be an issue.

[AkihiroN]

Thank you for your confirmation.
I will contact Apple as well.

On a separate note, we have implemented Window-App based on Lighting-App and confirmed that it responds immediately after commissioning even in Apple's ecosystem environment.
Could you please investigate this?

[EPASZ.1]

Based on this issue Default value of attributes of window covering with Apple. · Issue #26440 · project-chip/connectedhomeip · GitHub, I did a small modification to the Window project and it seems to have solved the issue, at least on my side. I basically make sure that the position values of the cover are set to some non-empty value during initialization (even though they are already set in the ZAP configuration file).

You can try it by adding this code to ZclCallbacks.cpp:

void emberAfWindowCoveringClusterInitCallback(chip::EndpointId endpoint)
{
    const auto logOnFailure = [](EmberAfStatus status, const char *attributeName) {
        if (status != EMBER_ZCL_STATUS_SUCCESS) {
            ChipLogError(Zcl, "Failed to set WindowCovering %s: %x", attributeName, status);
        }
    };

    app::DataModel::Nullable<chip::Percent100ths> currentPercent100ths;
    app::DataModel::Nullable<chip::Percent100ths> targetPercent100ths;
    app::DataModel::Nullable<chip::Percent> currentPercentage;
    EmberAfStatus status;

    status = Attributes::CurrentPositionLiftPercentage::Get(endpoint, currentPercentage);
    if (currentPercentage.IsNull()) {
        logOnFailure(Attributes::CurrentPositionLiftPercentage::Set(endpoint, 0),
                 "current position lift percentage");
    }

    status = Attributes::CurrentPositionTiltPercentage::Get(endpoint, currentPercentage);
    if (currentPercentage.IsNull()) {
        logOnFailure(Attributes::CurrentPositionTiltPercentage::Set(endpoint, 0),
                 "current position tilt percentage");
    }

    status = Attributes::CurrentPositionLiftPercent100ths::Get(endpoint, currentPercent100ths);
    if (currentPercent100ths.IsNull()) {
        currentPercent100ths.SetNonNull(0);
        logOnFailure(Attributes::CurrentPositionLiftPercent100ths::Set(endpoint, 0),
                 "current position lift percent 100ths");
    }

    status = Attributes::TargetPositionLiftPercent100ths::Get(endpoint, targetPercent100ths);
    if (targetPercent100ths.IsNull()) {
        logOnFailure(Attributes::TargetPositionLiftPercent100ths::Set(endpoint, currentPercent100ths),
                 "target position lift percent 100ths");
    }

    status = Attributes::CurrentPositionTiltPercent100ths::Get(endpoint, currentPercent100ths);
    if (currentPercent100ths.IsNull()) {
        currentPercent100ths.SetNonNull(0);
        logOnFailure(Attributes::CurrentPositionTiltPercent100ths::Set(endpoint, 0),
                 "current position tilt percent 100ths");
    }

    status = Attributes::TargetPositionTiltPercent100ths::Get(endpoint, targetPercent100ths);
    if (targetPercent100ths.IsNull()) {
        logOnFailure(Attributes::TargetPositionTiltPercent100ths::Set(endpoint, currentPercent100ths),
                 "target position tilt percent 100ths");
    }
}

Hope this solves it.

[AkihiroN]

Thank you very much. Thank you very much for your help.
I now have it working properly in my environment.

I see that in the case of NULL, I need to replace it with 0. Is it correct to think that this is a problem on the CHIP side?

[EPASZ.1]

I'm not sure about this 100%. As far as I understand, the parameters should get initialized to the values specified in ZAP - which we have correctly set up.

But maybe my understanding is bad here and it is always up to the user application. But in that case, it is weird that e.g. in Light app, we do not need to do it manually. The bottom line is that Apple should be able to handle "unknown" initial value and not block the whole device in GUI.

[AkihiroN]

Thank you for your confirmation. Is it possible for you to contact Apple regarding this matter? If not, I will contact them myself. Also, does this project have a factory reset function?

[EPASZ.1]

We can try to talk internally about this. But for sure, there will be no hurt if you contact them as well.

For factory reset - you can hold the button B1 for some time (10+ seconds).