Simulator and Eco set points


We are updating our CQC driver for the Nest interface. Also adding support for the Eco mode, which wasn’t there last time we updated it. The documentation indicates that there are three sets of set points. Normal, away, and eco. The simulator never returns eco set points, so I’m not sure which is correct.

Also, it’s not necessarily clear which set points to use in all circumstances. If in both away and eco modes, does Eco win or away? If it’s a heat or cool only thermos, how do those get assigned set points? There are normal type single mode set points, but no single mode set points for away or Eco.

These things need to be addressed in the documentation so that we can create solid integrations to the Nest ecosystem.


Hi @Dean_Roddey, do you know what version your thermostat read/write permission is? To find this, go to and check the permission tab. Near Thermostat read/write there should be v2 or later.


Energy and cams are V2 smoke and thermos are V4.


How does one update the simulator? Maybe the version I have is out of date? Or is the latest version just always served up? I installed initially quite some time ago.


BTW, there is a dirth of documentation on which set points to use in which conditions. When in heat or cool only mode, there is a single target set point. But, if you are in away or eco mode should you show the user the away or eco mode set point for that heat/cool state instead of the single mode target set point? If you are in away and eco mode, should eco be the active one or should away be active? Which of those should win?

And the same for setting setpoints, even more important of course, so as not to set the wrong ones. Apparently we should disallow setting set points in Eco mode, but similar to above, if in away mode and in heat or cool only mode, should we consider a write to the set point to be a write to the away set point for that heat/cool state or should we always write to the single heat/cool target set point?

These things really need to be spelled out.


Hi @Dean_Roddey,

The latest version of the Nest Home Simulator is 2.1.4.

You can get it here:



Thanks for the documentation feedback. I have created a bug to track this issue.

Also, I’m checking with the dev team to see if I can get an answer for your question.



I am running 2.1.4, so that’s not the problem.

BTW, I was sort of misreading some of the docs. If you click on the i button for the away set points, the permissions required show read and read/write permissions, so I was assuming earlier that they were writable. But the actual access indicator shows read only, and the blue/orange dots indicate read only. So there may be a little discrepancy there as well. I would assume if they are read only that only read permissions are actually required for those?

And of course it indicates you shouldn’t allow any set points to be set while in eco mode, and those eco set points are read only. So the question about writing to set points sort of answered itself. You can only write to the normal set points.

So the main question is, in what circumstances should what set points be shown to the user as the active ones?


Oh, and of course why doesn’t the simulator ever send eco set points.

And it should be closely checked that the simulator ONLY send those set points that the actual thermo will send under any given circumstances, so that people using the simulator to write a driver can know for sure what set of set points will be available to them in a given combination of modes.

It would be fine if all set points were sent all the time, and there’s a good argument for that, and the simulator seems to do that. But it should only do that if the actual thermostat also does that.


@Dean_Roddey you don’t need to update the simulator. In this case (to get eco temperatures) you need to upgrade the scope version for your Thermostat read/write permission in console @ To do so, simply click on “Edit permissions” > Thermostat read/write > Edit > Ok (no need to modify anything). Save and see that your scope version now appears as v6 or higher.

Regarding your question about Away/Eco temperatures:

Away state has been moved from thermostat level to a structure level and no longer applies for thermostats. When you upgrade your scope version, you will be able to see eco temperatures in the JSON returned as well as away temperatures. If you look closer, Away and Eco temperatures are the same values, just named differently. This is created on purpose, to support users with older and newer software on their thermostats.
“away_temperature_high_c”: 24.0,
“away_temperature_high_f”: 76,
“away_temperature_low_c”: 12.5,
“away_temperature_low_f”: 55,
“eco_temperature_high_c”: 24.0,
“eco_temperature_high_f”: 76,
“eco_temperature_low_c”: 12.5,
“eco_temperature_low_f”: 55,

These set points are read only. When thermostat is in ECO you need to display two values: eco_temperature_high & eco_temperature_low.


I did that, though it looks like it was already on V6 for the thermo before I did it. I saved those changes, then I restarted the simulator and our driver. The thermo is now in eco mode, but I’m still not seeing any eco set points.

Is there anything else that I have to do? I mentioned something about re-authorizing? Is that necessary?


Nevermind, I went ahead and did the re-authorization and it seems to be working now.


OK, I think we are all good now. Thanks for the help.


@Dean_Roddey glad I could help! :slight_smile:


I guess there still is one potential question… If you are dealing with a single mode thermo (heat only or cool only) and you are in eco mode, should you still display the eco setpoint for that mode as the active one, just as you would for a heat/cool type thermo? I’m assuming so, but that’s one of those things that’s not explicitly laid out in the docs that I can see.


Hi Dean, whatever mode the thermostat is in, is what you should display on your integration. The thermostat will either be in eco, heat, cool, heat-cool or off modes. You can’t be in eco and heat at the same time, it’s one or the other.

So if you’re in eco mode, use the eco temperature setpoints Luva mentioned.

It’s explained in the docs here:


Thanks. Our driver has been updated now and seems to be all happy with the new eco stuff.

While I have you, just to provide some feedback, which I know will be spitting into the ocean but nonetheless… From the perspective of an automation system vendor, and knowing what is going out there in the professional automation world, I have to say that the smarter you guys (who are making these types of devices) make them, the more of a PITA they are to support in a useful way.

The thing is, when it comes to installing automation systems, the biggest single problem that we have is that of defining generic semantics for various type of devices via which we can expose them in a way that makes them interchangeable. Without that, every system becomes a bespoke, customized operation. When we can fit all devices of a given type into a generalized view of such things and expose them in standardized way, then the integrator can create generic logic and touch screen interfaces and voice control and so forth that will work with any device of that type.

That is the only way to make real automation (as opposed to standalone islands of functionality) available for a lower price. If every system has to be customized, it remains where it is, pricey and marginal. And it’s that lack of standardization that is the bane of the automation world.

We have worked so hard over the last four’ish years to create a set of ‘device classes’ via which we can expose various types of devices (or fractional parts of functionality such as volume control.) The benefits that this work has generated are immense for the person setting up the solution (either for himself or for his customer.) The further a device strays from the commonality of its type, the harder and harder it becomes to make it fit within that generalized view, and at some point we just give up and don’t try to do so. And that device gets left out of a whole raft of benefits, which makes the customer a lot less likely to select it.

From the point of view of the automation system vendor and integrator, who is looking for real integration, not just a screen for this device, a screen for that device which is trivial and of limited value, we frankly would do better with dumb devices that do what they are told and report what they know, because those are almost always easier to expose via a generic device type.

I know that this is probably not something anyone at Nest wants to hear. I’m guessing that selling to individuals who use them outside of any integration is the primary business of Nest. I have to remind people all the time that the IoTs and automation are at opposite ends of the spectrum, the former being about selling standalone widgets and the latter being about creating a powerful team of devices designed to be subservient to a global controller. But, to the degree that use in automation systems in a non-trivial way matters, and to the degree that furthering the goal of highly integrated automation becoming more accessible is desired, all of the above needs to be kept in mind. With integration, it’s the team that matters, not the individuals.

Dean Roddey


Charmed Quark Systems, Ltd


Hi Dean,

This response is late and may not be completely relevant, but I’m wondering if OpenThread and OpenWeave go any distance toward addressing your points.



My rant above wasn’t so much about the means of interfacing, though we’ll take a local connection over a cloud based connection any day of the week. The ever increasing use of cloud based control interfaces is really a PITA, and there is a growing backlash against them out there.

But, anyway, my post above was more about the semantics of devices, and how difficult it is to create a consistent view of devices as they try to be smarter and smarter. That leads to more and more standalone islands of functionality and less and less integration (that isn’t of the very expensive, hand hewn sort.)

It becomes pretty much impossible to create reusable control logic, touch screens, etc… if the automation system cannot hide the details of a device of a given type behind an abstraction that can be reasonably applied to all devices of that type. Or, sometimes it’s fractional bits of functionality not the whole device (e.g. audio control or transport control.) Without those types of abstractions, we can never have a world where non-trivial integration can be done without extensive manual effort, and all of the costs that involves.

That is a fine line to walk. Set the abstraction’s bar too high, and too many devices cannot get above it, and so cannot be supported via the abstract view. Set it too low and it’s not of much use because you can’t really create serious automation solutions in terms of that abstract interface.

You have to remember that the touch screen interfaces and automation logic that are built with most any automation system are not dynamic systems. They aren’t applications, they are built using high level tools by end users or installers. They cannot adopt willy nilly to all kinds of possible options and re-write themselves at runtime based on what they find out there. So the abstractions we build cannot be full of optional ways of doing things.

Anyhoo, that was the point. That what you guys are doing, and what so many IoTs oriented companies are doing is the antithesis of what is needed for highly integrated, non-hand hewn automation solutions. And, without that possibility, automation remains a house divided, of low end, simplistic stuff on one end and high end, manually created stuff on the other, and almost nothing in between (which is where the money ultimately is.)