Smart Home & Report State: what happens if the current known state is not in sync with the reality?
Asked Answered
C

1

18

I implemented a basic Smart Home service by implementing the SYNC, EXECUTE and DISCONNECT actions. In the SYNC action, all devices have willReportState set to false.

However, on https://developers.google.com/actions/smarthome/report-state I read that it is required for us to report state changes ourselves. This means that all devices must have willReportState set to true, I assume?

My main question is what happens if the last reported state is not in sync with the reality?

For example, let's assume we reported 5 minutes ago that a certain device (having the OnOff trait) is powered off. A few seconds ago, the customer powered the device manually by pressing the power on button. Let's assume that this fact is not yet reported to or known by the Smart Home Graph.

What happens now if the customer asks to the Assistant: turn off my device? Will this request be rejected or not? That is, will the fulfillment service receive this backend, even though the Graph Home service thinks the device is already powered off?

Also, do we still have to implement the QUERY action if we implement Report State? Or are both required?

On a sidenote, this document does also not really address the frequency in which state changes must be reported. Is it documented somewhere else?

Consubstantiation answered 20/7, 2018 at 8:8 Comment(4)
I added a bounty worth 100 reputation points to this question!Consubstantiation
Why would you use the report state if your service cannot support it? If you cannot support the report state you can simply set willReportState to false. Your service will not be eligible for the visual Assistant as described in the link that you published. In case you set the willReportState to false every time you ask for an action, the action will be executed, every time you ask for the state, the query will be executedNotochord
@Notochord Your commend describes the desired flow. But the documentation says Report State implementation is a requirement for public launch of a Smart Home agent (see link in question), so I am wondering what this exactly means. I interpret it as Report State must be implemented, unfortunately. If that is true, I have some questions or concerns regarding that requirement.Consubstantiation
I think (I hope that someone could confirm) that they mean for the public launch of the new Google Assistant that has more visual than before. See what they showed at the last IO with for example this article in which they show the new way to interact with smart device (such as the thermostat)Notochord
I
2

Yes, you need to support ReportState and return willReportState: true for devices which have traits with states. Refer to the trait documentation for the states which a trait needs to report back.

Regarding on your main question, you need to be able to report back changes in OnOff trait (such as the user turns on the device) including state changes triggered from other surfaces (such as hardware switch or any other smart home platform). Failure to report the most recent state may result in errors when users try to execute commands if the command is state dependent. In this example trying to turn off the light will work (since on/off is not state dependent) but any other state dependent command (such dimming or brightening) may fail.

You still need to implement QUERY, since anytime Google may Query your fulfillment url instead of using the state reported.

Finally, regarding on the frequency, you need to report the states as soon as there is a state change. If there is a series of rapid state changes leading to a terminal state, such as adjusting a dimmer switch until you reach the desired brightness, you may wait until the terminal state is reached.

Ingraft answered 25/7, 2018 at 17:34 Comment(3)
Thank you. Regarding the main question, where exactly in the trait documentations is stated that the trait in question needs to report back? I fail to locate that information. Although you mention that turning on/off a device is not state dependent, that is not obvious. I cannot find that in the documentation? For instance, one could implement the on command which only propagates the request to the device if the state is off (and vice versa)?Consubstantiation
Every trait doc has a section listing states associated with the trait. Every state in a trait needs to be reported regardless of thinking if the execute will be state dependent or not. In on/off example it is obvious it is not state dependent because the following action can be executed without checking the states, such as turning off a light which is already off. However, some actions such as brightening the lights can not be performed at all without checking the current state of the device else brightening might result in actually dimming or even turning on the lights if they were off.Ingraft
Once again, the partner needs to report all states of the supported traits and shouldn't worry about if the action will be state dependent or not. That's something Assistant will figure out and decide to use the reported data or query your backend if necessary.Ingraft

© 2022 - 2024 — McMap. All rights reserved.