Also tried to update version 1.05 but nothing happens.

NestSDM_3-10-2025_93938_PM.zip

Current version 1.0.5 [Beta]

Status: Connected

IoX Version: 5.8.4 Connected

When Authenticate is clicked the response is: 

{"error":"Authentication Error"}

Thanks for any help

Stew

Nest PlugIn authentication response 20250120.pdf

Hi @Goose66 & @Michel Kohanim

I noticed that my nest devices were not updating in iox and when I check the plugin it is disconnected.  I've tried restarting, no change and nothing appears in the log even on debug setting.  I've tried to authenticate again and that seems to run fine but still no connection and nothing in the log.  I then noticed that the NestSDM does not appear in the store or my purchases.  Is this no longer available?

Thanks!

I really appreciate this plugin!  Would it be possible to add thermostat sensor status and the ability to change it in a future release?  A shortcoming of Nest is that it only allows you select which sensor to use from the choices of morning, afternoon, evening and night.  This does not give flexibility as to what time each segment starts and ends and does not allow for different sensor changes on different days.  I was hoping to control this with a program.

Thanks for considering this!

Joe 

When I observe my nest app, what is actually happening when i press the button is that all four setting will reflect the change, but then one of them (I haven't figured out a pattern yet) will then revert back to it's previous setting.  For example, when I just ran it, both thermostats changed to reflect the desired setpoint, but then my Master Bedroom Thermostat cool setpoint changed back from 78 to 75.  Here is my program.  Seemed pretty simple.  And I added the "waits" in between based on reading that it may take time to process each command.  But it is odd to me that it is reflecting the desired change and then changing back.

Away - [ID 001B][Parent 0019]

If
        'Entry Hall Keypad - Garage Li / Entry Hall Keypad - Goodbye' is switched Off
 
Then
        Set 'Tom’s House / Back Hallway' Mode Auto
        Wait  2 seconds
        Set 'Tom’s House / Back Hallway' Cool Setpoint 78°F
        Wait  2 seconds
        Set 'Tom’s House / Back Hallway' Heat Setpoint 64°F
        Wait  2 seconds
        Set 'Tom’s House / Master Bedroom Thermostat' Mode Auto
        Wait  2 seconds
        Set 'Tom’s House / Master Bedroom Thermostat' Cool Setpoint 78°F
        Wait  2 seconds
        Set 'Tom’s House / Master Bedroom Thermostat' Heat Setpoint 64°F
 
Else
   - No Actions - (To add one, press 'Action')
 

Thanks so much for writing this!  I have installed (and dented and reinstalled) the trial today.  The authentication went very smoothly.  I have four thermostats in the house.  2 heat only, 1 cool only and one Heat & Cool.  On discovery it shows 5 nodes, the house and the four thermostats.  For 3 of the thermostats all the data elements are listed below the node entry and load fine into the iox.  For the heat & cool thermostat it shows in the PG3x screen with the first line looking just ;ike the others with its unique name, a unique address and in the hint column, the same hint as the three other thermostats but with a trailing ".0".  There are no other lines and this thermostat does not load in the iox admin console.  Again, I deleted the node and reinstalled it into a new slot but the condition is the same. 

I'd appreciate any advice or insight.

Thanks again!

Joe

NOTE:THIS PLUGIN REQUIRES AT LEAST IoX FIRMWARE v5.8.3 and its associated platform updates (PG3, UDx, Python 3.11, etc.). In some cases, users have had to go to IoX 5.8.4.

This release includes some code changes that, along with changes made to the Portal service, address the latency problems with state changes and events from the Google Nest service. THERE IS STILL SOME LATENCY, averaging ~2 seconds between when commands are sent from IoX until the corresponding state changes are processed, so if you are making adjustments in the Admin Console, be patient and allow a few seconds for the state to settle down after each command before trying again or moving to another command. 

This discussion will inevitably bring up the question of why we don't immediately update the node states after a command to reflect the expected states once the command is processed. While this approach gives the illusion of zero latency to the user, it is ultimately bad for programming. This is because, if we prospectively update the states after a command and an intervening state change is processed before we get the actual result from the command, then the node states may jump back to a state before the command, only then to change back again to the expected state once the corresponding event is received. In other words, the state values can get "jumpy" when you do it this way, which makes writing programs that trigger on state changes hard. 

Also, there is one command (Fan On) that still seems to have a latency of 5 to 6 seconds and often exhibits some weird, out-of-sequence behavior. I believe this is some type of bug in the system.

In addition, there are a couple of fixes and some new features:

• fixed bug in processing state change events before initial state vector is established
• added manual timeout of detection events (person, motion, sound) for legacy devices
• added plugin status tracking to primary (first) structure node

When restarting the plugin, it waits until the next shortpoll after the authentication and discovery to poll and update all the state values. This is because of a code change that was put in place to reduce the number of API calls to prevent hitting rate limits. But it means after a restart (or authentication and/or discovery), it may take up to 60 seconds before the state is reflected correctly. Also, if a state change event comes in with a specific state change before that first poll, the state values may go pear shaped (since the node doesn't have a current state vector). It should all settle in after the first shortpoll. In the long term, once we hit Commercial Product status on UD's Device Access project, the rate limits should be removed, and I can go back to a more straightforward way of initializing state for each node.

Also, remember me saying with v1.0.6 that ongoingly you shouldn't have to re-discover nodes with updates? Well I lied. Because this version adds the plugin status tracking to one of your structure nodes, then you have to delete all of your nodes and rediscover them for that selection to be made and saved to the database.

1. There is a serious latency problem. Actions taken in the Admin Console may have a 1 to 3 second delay in being reflected in the state values when using your own Device Access project. With the UD Nest SDM Plugin, that delay is more like 10-25 seconds. I am working on it....

2. The plugin does not have any internal logic for managing detection state values (motion, person, sound, doorbell) for cameras and doorbells, i.e., it doesn't monitor "Detected" states and return them to "Clear" after some time. For newer devices this is not a problem because the SDM API will send appropriate END messages for the detection events. However, for legacy devices, once "Detected," they will currently remain in this state indefinitely. It's on the list...

3. There is no "heartbeat" or other functionality to ensure the whole pathway (IoX->PG3->Plugin->SDM API->Google Home->GCP Pub/Sub->UD Nest Event Service->Portal->Plugin->Iox) is up so you can't really know if something breaks until you notice you aren't receiving state updates. This is also on the list...

What is "final" (knock on wood) is the node hierarchy, and as long as you continue to use the UD Nest SDM Plugin project your user ID and device IDs should remain consistent. Therefore, once you install this version you should be able to install updates without having to uninstall and reinstall the plugin, re-authorize via oAuth, and rediscover your devices again.

Hopefully a number of people can take the plunge here and we can work through the issues.

The Beta version currently requires the user to create their own Google Cloud project and Device Access project on the Google Cloud platform (GCP). The process is quite involved, but I have endeavored to document it the best I can. The release notes (including a link to the GCP/Device Access project setup and configuration instructions) can be found here: https://goose66.github.io/nsdocs/nestsdm-pg3.html. I encourage you to read through them before endeavoring to try the plugin.

The hope is that (soon) a version can be released to the Production Plugin Store that will utilize UD's Google Cloud back-end and should be considerably easier to setup and use (as well as not require any per-user fees for Google). But I wanted to rollout a version for testers to test with IoX and PG3 and see what bugs and or enhancements we can identify as we move forward with the production version.

You will need to reinstall this new version - probably in a new slot. This is because this version changes the oAuth parameters that are installed with the Plugin. MAKE SURE YOU COPY YOUR THE CUSTOM CONFIGURATION PARAMETERS KEYS AND VALUES from the old version before uninstalling it, because you will need to reenter them for the newly installed version and the new version doesn't put the Custom Configuration Parameter keys in place by default (since they won't be needed for the UD Device Access project implementation). 

This version includes new node definitions for Doorbell and Cameras that has both state values and commands for motion/person/sound detection. It also has a Structure node that provides a node hierarchy for folks that have multiple structures. The state values for motion and person detection events clear automatically (from generated ENDED events) in newer devices (no sound support in newer devices), but I will be interested in seeing if this is the case with older, legacy devices. Let me know how it goes and I can add plugin-managed clearing of state values for detection events if necessary.

However, to install this version (and prevent the reauthentication problem) you need to delete and reinstall the plugin. This will restore the default installation data (including the oauth configuration data). It should also give you the opportunity to pick up the correct node names.