I’m trying to work on some logic in SharpTools that is based on information from my nest thermostat. Sadly, google blocks the nest thermostat from being imported into sharptools. It was suggested to me to make a virtual thermostat and have it mirror my nest. The virtual thermostat CAN be imported into sharptools.
I was able to make a virtual thermostat with vEdge Creator, however, I can’t figure out how to get it to mirror my nest.
I can’t figure out any way to get it so that the desired temp and room temp on the nest are mirrored on the virtual thermostat.
Any suggestions?
Ultimately the goal is to have a notification sent to me if the room temp and the thermostat set temp are more than, 4degrees different…i.e. possible problem with the unit.
Another method is to use a Sharptools rule to set a variable to the real thermostat’s temp when it changes and then set the virtual thermostat’s temp to that variable. Will require the paid level of Sharptools to use variables.
So this doesn’t work. Nest is not visible within SmartThings API Broswer+. I try to make a rule, but it kicks back an error of “at least one device used is not found in the location”…I’m assuming because according to API Broswer+, the nest thermostat is not connected to smart things.
The Nest is 100% added to SmartThings. I can view and change settings for it within the Smart Things app. It however, due to google blocking, CANNOT be added to 3rd party extensions of SmartThings. In other words, in my SharpTools, it doesn’t show up as a device even though it is does show up as a device in Smart Things. Same goes for the API Broswer+
Yeah, the issue in the new architecture is that the CLI uses the public API which is the same as the one used by API Browser+. The mobile app and AWA use a private API and I don’t know what you can do from a Rules perspective, if anything, with that. @orangebucket is familiar with a lot of the private APIs and can speak to it more authoritatively than I.
Basically the public API, documented public API and the Core SDK library that is made freely available to exploit the public API only partially overlap with each other. Some of the details in the documentation are also wrong.
There are also what I call platform versions that tweak the API response and rather surprising the Core SDK uses one, meaning the CLI does too. I use three but there are more. I’ve no idea what they do.
The API reference refers to some security scopes that are simply not available to end users to use in apps and in PATs and you can see lots more being used by ST apps. I’ve no idea what they do.
There is also what I call the Client API that partially overlaps with the public API and where it does it it includes significant tweaks to meet the needs of the client apps and also presents things from their perspective. So /rules in the Client API gives the Routines and Smart lighting etc. Apart from nosing at the latter, which is educational, I found something seemingly only available there which I’d been after for years to make my own app work better.
Routines use a different version of the Rules API which includes some extra functionality that would be game changing if available to the public API as well as more obscure stuff for templates and the routines on the device pages.
Putting that lot together is like doing a jigsaw without the picture.
Oh and I don’t have any Nest stuff in SmartThings so I simply don’t know how it fits in. I know it can be revealed in listings easily enough but making it available to Rules and third-party apps might not be possible.
