在 设备应用服务 里定时调用伴生服务来实现传感器的数据上报

[Anduin2017]

Hello ZEPP team,

I am currently trying to send sensor data from my watch (such as sleep status) to an external HTTP server on a scheduled basis to enable further development possibilities. I am only extending my own device and do not plan to publish it on the app store.

I have read the Fetch API code example and understand that initiating an HTTP request requires a companion service to send the request to the phone's companion service, which then uses the Fetch API to send it to the external HTTP server.

I understand that I need to build a device app service to run in the background every few minutes.

However, what confuses me is that I do not understand how to call the companion service in the device app service. It seems that there is no mention of this possibility in the device app service documentation, and I suspect that it may not be possible.

I noticed in a discussion that @silver-zepp mentioned that the Messaging Builder can be used to communicate using BLE. However, I could not find any code examples applicable to version 3.0 in the documentation.

The documentation references paths such as:

import './shared/device-polyfill'
import { MessageBuilder } from './shared/message'

But it does not explain where these references come from, and I suspect that they may not be applicable to version 3.0.

The documentation refers to a Todo List to introduce the Messaging Builder, but there are no references to the Messaging Builder in the source code.

I have tried to understand our overall architecture, and while I can successfully call the companion service within the program by triggering a button, there is no indication of its feasibility or method in the device app service, and the relevant API (this.request) has no referenced method.

I would like to know if the Messaging Builder is no longer available. If it is not available, what is the best practice for calling the companion service in the device app service?

[MyoungXUE]

你好，你可以参考这篇文章 https://github.com/orgs/zepp-health/discussions/276

在 Zepp OS 3.0 上最推荐的做法是使用 ZML https://github.com/zepp-health/zml/blob/main/README_CN.md

虽然我们可以使用中文交流，但为了能够帮助到世界各地的开发者，建议在讨论区使用英文交流

---

Hello, you can refer to this article https://github.com/orgs/zepp-health/discussions/276

The most recommended practice on Zepp OS 3.0 is to use ZML https://github.com/zepp-health/zml/blob/main/README_CN.md

Although we can communicate in Chinese, it is recommended to use English in the discussion area to help developers around the world

[Anduin2017]

Hi, thank you very much for your quick response! The articles you replied with are very valuable. However, most of the content inside is already known to me and I have tried it. It can successfully send data when the user presses the "send" button on the page during interaction.

However, it does not explain what will happen if this happens in the background app service. As a sleep data collection device, obviously I cannot ask users to open my mini-program when they are sleeping. I need it to be able to run in the background completely after the device screen is turned off. That's why I used AppService.

[MyoungXUE]

Due to power consumption considerations, we cannot communicate with Side Service in AppService. It is recommended to collect data during the sleep phase, write data to the file system, and send system notifications after the user wakes up to guide them into the Mini Program for data reporting.

We will find a way to optimize in the future.

[Anduin2017]

Thank you very much for your reply. Okay, I understand the situation now. It would indeed significantly reduce the battery life if the watch were to send an HTTP request every minute. However, objectively speaking, I really need a feature that triggers certain smart home actions when the watch detects that I have fallen asleep (it seems that only the watch among all my smart devices in my home knows when I am asleep), such as setting all appliances to mute and illuminating a "Do not disturb, I am sleeping" warning sign at the front door.

[MyoungXUE]

I understand your request, which is very reasonable. I think we will open some hooks at certain times in the future to allow network requests to be sent. We will consider it.

[qinyj12]

I understand your request, which is very reasonable. I think we will open some hooks at certain times in the future to allow network requests to be sent. We will consider it.

We indeed need that function.