Reading target temperature after changing modes requires a delay?


#1

I want to change the mode of the thermostat and then read the user’s target temperature for that mode. I’m testing this with curl:

curl --location --request PUT --header "Authorization: Bearer MYTOKEN" --header "Content-Type: application/json" --data '{"hvac_mode":"heat"}' https://developer-api.nest.com/devices/thermostats/MYTHERMOSTAT
curl --location --header "Authorization: Bearer MYTOKEN" https://developer-api.nest.com

When I test this with a thermostat on cool mode with target 75, the mode change completes successfully responding with

{"hvac_mode":"heat"}

but then I get the entire thermostat structure and I see

"hvac_mode":"heat", "target_temperature_f":75

even though the heat target is 65! If I wait 2-3 seconds and repeat the GET, the second response has

"hvac_mode":"heat", "target_temperature_f":65

So unless I put in the delay, Nest returns the new mode with the old target! I can reproduce this 100% of the time with a Nest E. Is this documented somewhere? How am I supposed to know that the target I got is actually up-to-date?


#2

You should not attempt to change both hvac_mode and target_temperature simultaneously. This is states in point 1.6 under Functionality of the Product Review Guidelines.

https://developers.nest.com/documentation/cloud/product-review-guidelines#1_functionality

The reason you are seeing this behavior is because when the thermostat device’s mode is changed it will revert to the last target temperature for the new mode. This will overwrite the target_temperature you are trying to set. The second call where the mode is already set to the new mode, will then set the target_temperature.

The proper implementation will change the mode, verify that new mode has been set and then change the target temperature.


#3

But I’m not setting the mode and target temperature simultaneously. I’m setting only the mode, then reading the entire thermostat structure afterwards (I only showed the mode and target because that’s what I care about).


#4

If you’re not attempting to change both mode and temperature, than you simply need to change mode and wait a couple of seconds. Please keep in mind that the new mode has to propagate to the physical device, the device then switches mode, and updates target temperature to the new setting for the new mode, and then propagates the updates, both new mode and new setpoint, back down to the service and out the API. This back and forth may take a couple of seconds depending on network latencies.


#5

But that is the issue I’m having. I’ve been testing this over and over and it seems like “a couple seconds” (literally 2 seconds) is not enough, but 3 sometimes works? And there’s no way for the API to tell you “This is the latest target temperature but it might be out of date, wait a bit”? How do I know that I’ve waited long enough?

I don’t want to spam your API since it’s rate-limited but I also don’t want to miss the temperature update and end up with a temp/mode mismatch.


#6

If you are using rest streaming or firebase, the API will send out the update automatically once it’s received from the device. If you are polling, depending on your frequency it may take one or two requests to stabilize. Unfortunately, there is no way to know that the device has confirmed the update. You’re product should simply react to the latest data received based on your polling frequency. For example, if a user changes the mode on the device, your polling should pick up these changes, as well.