T5AI doorbell_demo: rtc stream.push.start returns SING_VALIDATE_FALED, App records doorbell event but no incoming call UI

[fei56670]

Summary

I am bringing up a TuyaOpen apps/tuya_cloud/doorbell_demo based visual doorbell on T5AI. After the device is paired successfully, pressing the doorbell button reports the doorbell event and the Tuya App can show a doorbell call record, but the App does not pop up the incoming video-call/ringing UI.

When the device tries to request the RTC/cloud-storage resources required before sending the video doorbell popup payload, the cloud API returns SING_VALIDATE_FALED / SING_VALIDATE_FALED_4.

I would like to confirm whether this is an SDK API/signing issue, a product advanced-feature/license issue, or whether doorbell_demo should use a different interface for App video intercom.

Environment

• Repository: tuya/TuyaOpen
• Upstream master checked: e5f03d0d (Feat/ai components to src (#604), 2026-06-09)
• Example app: apps/tuya_cloud/doorbell_demo
• Board config:
  • CONFIG_BOARD_CHOICE_T5AI=y
  • CONFIG_TUYA_T5AI_BOARD_EX_MODULE_35565LCD=y
• Product ID: kdjbf7p7pctv0yr2
• Device UUID/AuthKey: valid production authorization code is written and the device can pair successfully. Full UUID/AuthKey are not posted here for security.
• Tuya App: device can be added successfully and can receive normal device state / call records.

Product DP / advanced feature configuration

From the product service DP export for PID kdjbf7p7pctv0yr2:

• DP 53 exists:
  • Name: 门铃呼叫
  • Identifier: doorbell
  • Type: bool
  • Description: supports reporting when someone presses the doorbell (1 means doorbell pressed)
• The exported DP sheet does not expose DP212, door_lock_video, door_lock_video_cover, or similar video-call resource DP.
• The product advanced-feature sheet includes:
  • 可视对讲门锁云存储
  • Description: visual-intercom door-lock cloud storage, for visual intercom door lock category.

This matches the runtime behavior: DP53 seems enough to create an App call record, but the incoming App video call UI appears to require a successful RTC/cloud-storage resource request first.

What I tried

Before sending the video doorbell popup payload, I request RTC stream resources using both service names:

1. thing.lock.rtc.stream.push.start
2. tuya.device.rtc.stream.push.start

I tried both paths:

1. TuyaOpen SDK ATOP helper path (atop_service_comm_post_simple)
2. A compatibility/manual ATOP signing path using legacy HMAC + AES-GCM response decrypt, based on the device credentials

All four attempts fail with sign validation errors.

Relevant log excerpt

The device time was already synchronized before this request. The timestamp below is real device local time.

[06-11 00:04:54] doorbell button pressed
[06-11 00:04:54] request RTC stream resource
api: thing.lock.rtc.stream.push.start
body includes: fileName=1781107494.jpg, t=1781107494

OpenSDK ATOP response:
errorMsg: SING_VALIDATE_FALED

legacy/manual ATOP decrypted response:
{"success":false,"errorCode":"SING_VALIDATE_FALED_4","errorMsg":"SING_VALIDATE_FALED_4"}

api: tuya.device.rtc.stream.push.start
OpenSDK ATOP response:
errorMsg: SING_VALIDATE_FALED

legacy/manual ATOP decrypted response:
{"success":false,"errorCode":"SING_VALIDATE_FALED_4","errorMsg":"SING_VALIDATE_FALED_4"}

cloud resource incomplete, skip doorbell call popup img=0 media=0

The App side can still show a doorbell call record at this time, which appears to come from DP53. However, the incoming ringing/video-call UI is not displayed because the device cannot obtain imgCloudStorage / cloudStorage from the cloud resource request.

Previously, if I force the doorbell popup payload without these resources, the App can show a call screen but the answer button is gray/unavailable because there is no video resource. Therefore the device now intentionally skips the popup when cloud resources are missing.

Expected behavior

For a paired T5AI visual doorbell product with DP53 and the advanced feature 可视对讲门锁云存储 enabled, pressing the doorbell should allow the device to obtain the RTC/cloud-storage stream resource and then trigger the Tuya App incoming video-call/ringing UI.

Actual behavior

• Pairing succeeds.
• Doorbell press can generate an App call record through DP53.
• thing.lock.rtc.stream.push.start and tuya.device.rtc.stream.push.start fail with SING_VALIDATE_FALED / SING_VALIDATE_FALED_4.
• Because imgCloudStorage and cloudStorage are missing, the device cannot safely trigger the App incoming call UI.

Questions

1. Is thing.lock.rtc.stream.push.start the correct API for TuyaOpen doorbell_demo on T5AI to request resources for App video intercom / incoming doorbell call UI?
2. If yes, what is the correct request body and signing/encryption method expected by TuyaOpen for this API?
3. Does this API require product-level advanced feature enablement only, or must the issued UUID/AuthKey/license also be bound to 可视对讲门锁云存储 / visual-intercom capability?
4. For PID kdjbf7p7pctv0yr2, DP53 is present but DP212/video-call DP is not visible in the service DP export. Is the video-call popup supposed to be implemented through a hidden/internal DP/protocol payload, or through another public TuyaOpen API?
5. Can the cloud team check why requests around 2026-06-11 00:04:54 for this product/device return SING_VALIDATE_FALED_4? I can provide the full masked device id / request details privately if needed.

Thanks.

[shiliu-yang]

Unfortunately, we do not have anyone on our team who is familiar with the doorbell business at the moment, so we are unable to assist you with this.