Goose66

It’s deja vu all over again! 🤪

You should be able to wire the ratgdo to use the discreet open and close terminals on the gate controller. There is a diagram on the ratgdo wiring page here: https://paulwieland.github.io/ratgdo/03_wiring.html. However, as Guy Lavoie said, monitoring open and close status probably won't work, unless you have the expansion board and use the aux relays or you install separate open and close limit switches (e.g., microswitches or reed switches).

Nodes from plugins should be deleted in the PG3 Dashboard, not from IoX Admin Console. The node list is stored in the PG3 database and most plugins recreate all of the nodes from these database entries when they restart. If you delete a node from the IoX Admin Console, it will just get recreated when you restart the plugin. Deleting it from PG3 deletes it from IoX as well. This is a known limitation in the PG3 system. Once PG3 is absorbed into IoX (v6?), this should be cleaned up.

@Javi Is there a workaround for the missing scroll bar here? Edit: sorry, that should have been for Chris Jahn. Don’t know his handle.

I guess I wasn’t appreciating that there was no scroll bar for the window. Yes, that is a serious UI issue. Very surprised it has gone this long without being fixed. Also a little surprised that the Java UI libraries don’t just automatically handle it. Could it be as simple as a flag in the window creation code? If we could just get Admin Console moved to a web-based UI… maybe IoX 6?

This is one of those "You can’t please all of the people all of the time" sort of things, I think. For those that want the runtimes, then there's no way to make it optional, I'm afraid. But I am surprised that you use the Admin Console for day to day management of your thermostats. The Admin Console is really designed for ... you know ... admin. Try UD Mobile. This should provide a better interface for making day-to-day settings on your thermostat.

Got it. Follow the instructions to the letter - particularly in the listed order. Good luck in the storm and keep your head down!

As Geddy posted, there’s currently a user limit on the Google side because UD’s Device Access project is still in “Commercial Testing” status. This process is not well documented (at least not publicly) so we were unaware. Looks like you may have been user # 11. We can do one of two things: 1) help you set up your own Google Device Access project in a personal sandbox (instructions in the Instructions and Release Notes) or 2) look into getting a refund for your purchase.

Also, remember that you can use the Nest SDM plugin with your own personal Device Access project created in a private Google Developer Sandbox. Instructions for that are in the Instructions and Release notes.

The UD Google Nest Device Access is stuck in "Commercial Testing" status until a number of authentication and API tests can be completed and verified. Until all this can be done, we are limited to 10 users, which we hit several weeks ago. Accordingly, I have taken the Nest Plugin off the Plugin Store List (marked "Inactive"). If and when the various battery of tests are completed, we can move it into the next phase of "testing" (not production yet), requiring even more rounds of verification testing, including a paid 3rd party security audit, evidently. But we should get a higher user limit at that time.

I'm getting that too when I try to reauthenticate. However, the API access and push events all continue to work on the previously obtained tokens. So I think it has something to do with our OAuth Authentication process to the Google Device Access project. None of the settings have change, so I have asked @Michel Kohanim to review the status of the project. Unfortunately, Google never fully integrated Nest Device Access into their Google Cloud Platform, so status of Device Access project is in a different environment that only he has access to. It was done that way for good reasons - just inconvenient sometimes.

Everything from our end shows still active. I would suggest trying to Authenticate again. If the problem is still happening, I can uninstall and reinstall my production version of the plugin and see what I get.

What type of firmware you running? MQTT or ESPHome?

Working on a Shelly plugin.

The plugin uses Simple Service Discovery Protocol (SSDP) to discover the thermostats which should work as long as the thermostats are on the same LAN segment as the Polisy/eISY. Once discovered, the plugin stores the IP address for each discovered thermostat, and when restarted, uses the IP address to access the thermostat so they don't have to be discovered again. So if your thermostats' IP addresses change, you will have to rediscover them. That said, simply assigning them a fixed IP address (assuming you mean DHCP reservation) shouldn't stop SSDP from working. Here are some things that could make SSDP discovery stop working: 1. Setting the thermostat to a fixed IP address in the thermostat setup screen, if you either a) set it to an IP address that's not on the same LAN segment, or b) accidentally disabled the "Local API" setting when making the change; 2. Have a Custom Configuration Parameter with key of "hostname" set to anything, such as one or more of the old IP addresses. If the "hostname" Custom Configuration Parameter is present, the plugin will bypass SSDP discovery instead try to contact a thermostat at the hostname(s) or IP address(es) listed in the parameter's value. You can either delete the Custom Configuration Parameter and try Discover again, or set the "hostname" Custom Configuration Parameter value to a list of the new, fixed IP addresses of your thermostats (separated by semicolon - no leading or trailing spaces).

Two problems: 1. It appears you are not getting event notifications from the Google Nest service. The only update of status values for your thermostats are coming from status queries performed every 60 seconds (shortpoll interval). This creates problem # 2: 2. The Google/Nest SDM API for changing temperature requires both the heat and cool setpoints to be specified if the mode is "Auto." When a "Set Heat Setpoint" or "Set Cool Setpoint" command is received from IoX, the plugin uses whichever setpoint (heat or cool) is provided in the command along with the last known value of its counterpart to call the API. Because you are not getting event notifications from the service, the last API call has effectively changed the specified setpoint, but the current status is not updated. So when the subsequent command comes it, the counterpart setpoint it uses is not reflective of the change just made. As to #2, this is not so much a bug as it is a design flaw. Had you not been putting in the two seconds between steps in your program, there is no way the current code would've worked correctly even if you were receiving status updates. The approach here has to change - look for a new version soon. As to #1, you need to make sure "PG3 Remote Connection" is configured and active for your eISY/Polisy. To configure this, login to https://my.isy.io, and from the "Select tool..." dropdown next to your eISY or Polisy, select "PG3 > Remote Connection." Make sure "Remote connection configured" and "Remote connection active" are both "Yes". If these are active and you are still not getting event messages, we can continue debugging. I will also be sure that this is put into the Installation Instructions, if it's not already in there.

Sounds like could be a bug in the plug-in. To debug, please: 1. Change the logging level for the plugin to “Debug” in the PG3x Dashboard 2. verify temps in Admin Console match temps on tstat (or use Google Home app) 3. Push keypad button 4. After a minute, check whether temps on tstat (or in Google Home app) match new temps in Admin Console. 5. If not matching, please DM me the log package.

Can you send a screen shot of the Nodes screen from the PG3x Dashboard? Also, change the Log Level to “Debug” for the plugin, restart the plugin, then DM me a log package.

A new release of the Tasmota plugin (v3.1.7) has been upload to the Plugins Store. This release fixes the paho-mqtt client compatibility problem introduced with IoX firmware 5.8.3 or higher.

No worries. I only added the bold text note to the instructions and the release post after I realized this was probably your problem! 😀

Also, please note that this plugin requires at least IoX firmware 5.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.

Did the plugin ever show as running, i.e., "Current Status" showed as "Connected" in the PG3 Dashboard? What version of PG3 and IoX do you have? Were there any notifications? Can you change the logging level to "Debug" in the PG3 Dashboard under "Log," restart the plugin, and download and DM me a "Log Package?"

It's available in the production store for those that want to try it. I highly suggest the one month trial.

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.

As to # 1, in order for the automagic discovery process to work (i.e., no manual specification of hostname/IP addresses and tokens in Custom Configuration Parameters), your Bridges and/or SBB devices must be "unlocked" in order for the local access token values to be discoverable. This is done by power cycling the device (see the installation instructions in the release notes for more info). As to #2, when using the automagic discovery process, if the mDNS query returns an IP address, the discovery process will use it. If not, it will use the hostname, which is usually a *.local (zeroconf) name. While this has always worked flawlessly on my network, for some reason many don't have much luck with .local names, so IP address is the preferred method. As to #3, I have updated the code to strip spaces from the hostnames and tokens in the Custom Configuration Parameter values. That code should roll out in the next release.