Repository navigation
cloud_service: make DP report async on the mqtt, lan and ble channels - #723
Open
jianning773 wants to merge 4 commits into
Open
jianning773 wants to merge 4 commits into
jianning773 wants to merge 4 commits into
Conversation
Switch tuya_iot_dp_obj_report from tuya_iot_dp_report_json_with_notify (inline QOS1 publish on the caller thread) to the _async variant, so the TLS/TCP write is done by the mqtt loop task instead of blocking the caller (typically WORKQ_HIGHTPRI handling the DP-receive echo) and no longer races with MQTT_ProcessLoop on the shared mqtt client context. The completion path is unchanged: PUBACK -> dp_sync_cb marks the DPs PV_STAT_CLOUD, timeout/failure schedules the PV_STAT_LOCAL resync. Also give publish_list a real mutex (the LOCK/UNLOCK markers were placeholders with no actual lock): producers append from caller threads while the mqtt loop task flushes and completes entries. Completion callbacks are invoked outside the critical section so a callback that publishes again cannot deadlock. Co-Authored-By: Claude Code <noreply@anthropic.com>
LAN DP reports were sent inline on the caller's thread, blocking wq_highpri for the per-session socket writes. Queue the packed json strings on a dedicated queue and let the lan_sock_loop thread flush them, so the caller only pays for the enqueue. - tuya_lan.c: add tuya_lan_dp_report_async/_flush backed by a 16-slot queue; create it in tuya_lan_init, drain and release it in tuya_lan_exit - lan_sock.c: flush the queue in tuya_sock_loop_run and shorten the select timeout to 100ms so a queued send leaves within 100ms - tuya_iot_dp.c: hand the lan obj/raw reports to the async queue A full queue drops the report with a warning; dp sync covers the loss, matching the mqtt channel's timeout-drop semantics. Co-Authored-By: Claude Code <noreply@anthropic.com>
BLE DP reports ran inline on the caller's thread and blocked it for the whole GATT transfer (20ms sleeps between subpackets). Queue a deep copy of the report and let WORKQ_SYSTEM flush it; BLE has no thread of its own. - ble_dp.c: add tuya_ble_dp_report_async/_flush backed by a 16-slot queue; the queued copy owns the dps array and any PROP_STR/raw payloads (deep-copied on enqueue, freed after send) - ble_mgr.c: create the queue in tuya_ble_init, drain and release it in tuya_ble_deinit - tuya_iot_dp.c: hand the ble obj/raw reports to the async queue The ble path is only reachable while the cloud link is down, so this is verified by build + elf symbols and no regression in cloud-online tests. Co-Authored-By: Claude Code <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
DP reports were sent inline on the caller's thread: every report blocked on the transport write — the mqtt TLS publish, the per-session LAN socket writes, and the BLE GATT transfer (subpackets with 20ms sleeps in between). Downlink DP commands are parsed and echoed on the high-priority work queue (
wq_highpri), so one slow client or congested link stalled the whole business pipeline behind it, and the inline mqtt publish also raced withMQTT_ProcessLoopon the shared client context.Change
One pattern applied to all three channels: the caller only validates, deep-copies and enqueues; the channel's own context drains and sends.
tuya_lan_dp_report_async/_flushbacked by a 16-slot queue; the packed json string is copied on enqueue and drained by thelan_sock_loopthread each loop. The sock-loop select timeout is shortened to 100ms so a queued send leaves within 100ms.tuya_ble_dp_report_async/_flushbacked by a 16-slot queue; the queued copy owns the dps array and any PROP_STR/raw payloads (deep-copied on enqueue, freed after send). Drained onWORKQ_SYSTEM— BLE has no thread of its own.A full queue drops the report with a warning; dp sync covers the loss, matching the mqtt channel's existing timeout-drop semantics.
Verification (T5AI / BK7258 chat-bot board)
lan channel report → LAN send → mqtt channel reporttolan channel report → mqtt channel report → LAN send; zero queue-full drops, zero socket faults, session lifecycle (30s heartbeat close) unchanged.🤖 Generated with Claude Code