New Release v1.0.7 in Production Plugin Store

[Goose66]

A new release (v1.0.7) of the plugin has been uploaded to the Production Plugin Store. You can view the release notes at https://goose66.github.io/nsdocs/nestsdm-pg3.html.

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.

Edited August 26 by Goose66