Goose66

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.

First, check the EnvisaLink website to make sure your alarm panel is supported. Also, make sure you have the installer passcode or be prepared to factory reset the unit.
If the Evisalink 4 will work with your panel, then the plugin will work as well.

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.

TLDR, this boils down to a design decision.
Nodes can both receive commands and send commands. So for, e.g., shades I would have the plugin process received DON commands to open the shades and close the shades, but the shades node would not send any commands. However, the keypad nodes in the Bond plugin send commands, e.g., DON commands, when pressed, but don't receive any commands. Generally, in my plugins, if it is a button, switch, or sensor, it will send commands and if it is a relay, dimmer, motor, etc. it will receive commands. If it is both (like an Insteon light switch) then it will both send and receive commands. There are a few exceptions: thermostats and garage door openers that are kind of both sensors and relays. In those I have to add a layer of complexity to ensure I am not sending a command back to IoX when the status change is a result of command received from IoX. The type of connection to the device (synchronous vs. async) drives how complex this actually turns out to be.
If you want to sync a KeypadLinc with your shades position, I suggest using programs with the status value, much like you would synching a KeypadLinc with, e.g., a FanLinc.

You may find more answers on the ratgdo github pages or in a HomeAssistant forum.

There is no way to query the panel (at least through the EnvisaLink) to determine which zones are “used.” The only way is to set the “numzones” Custom Configuration Parameter to 18 and restart the plugin. Upon restart, it will generate 18 zones in the node tree. Unfortunately, even if you delete the unused zones in the Admin Console, they will be regenerated when the plugin is restarted.
Perhaps I can add a to-do to only generate new nodes based on the Custom Configuration Parameter settings when the user clicks the “Discover” button in the Polyglot Dashboard.

The EnvisaLink does not report the number of configured zones or partitions for your panel. The number of zones and partitions present are driven by Custom Configuration Parameters. From the Nodeserver Configuration instructions (read the "NOTE" at the end):
Custom Configuration Parameters: Required: - key: hostname, value: locally accessible hostname or IP address of EnvisaLink or DUO device (e.g., "envisalink.local" or "192.168.1.145") - key: password, value: password for EnvisaLink device - key: usercode, value: user code for disarming alarm panel (e.g., "5555") Optional: - key: numpartitions, value: number of partition nodes to generate (defaults to 1) - key: numzones, value: number of zone nodes to generate (defaults to 8) - key: numcmdouts, value: number of command output nodes to generate (defaults to 2) - key: disablewatchdog, value: 0 or 1 for whether EyezOn cloud service watchdog timer should be disabled (defaults to 0 - not disabled) - key: zonetimerdumpflag, value: numeric flag indicating whether dumping of the zone timers should be done on shortpoll (1), longpoll (2), or disabled altogether (0) (defaults to 1 - shortpoll) NOTE: On nodeserver start, the child nodes for the Alarm Panel are created based on the numbers configured. The disablewatchdog should be enabled if the EnvisaLink is firewalled to prevent the EnvsiaLink from rebooting after 20 minutes. Sounds like these are missing in your configuration.
However, you said it used to show 1-16. Had it been configured to generate 16 nodes at any point, the plugin itself would have never deleted them - it would have just stopped updating them with status values when the "numzones" configuration parameter was changed (or removed). The only way nodes for zones 9-16 could have been deleted would have been if you explicitly deleted them in IoX or PG3x Dashboard or if you deleted and reinstalled the plugin.

There should be battery information related to your "Front Door" node, even if it is powered by the 12V doorbell transformer. See below for mine of the same type:

Motion detection is facilitated by the "Front Door (Motion)" node, not through a state change but through a command ("Motion") that is received from the node when motion is detected. Use a "Control" condition from the "Front Door (Motion)" node instead of a "Status" condition, like the following:
Front Entry on Doorbell - If ( 'Perimeter / Ring / Front Door' is switched Ding Or 'Perimeter / Ring / Front Door (Motion)' is switched Motion ) And From Sunset + 15 minutes To Sunrise (next day) Then Set 'Perimeter / Front Entry' On Wait 12 minutes Set 'Perimeter / Front Entry' Off Else Set 'Perimeter / Front Entry' Off Also, I think I did notice when I first added this plugin that the states were not populated until one or more events were received from the Ring service, but that was a while ago.

This is solved by using two programs, the first enabled and executing the other, disabled program. This approach is discussed in many (many) places in these forums.

A new version of the EnvisaLink-HW plugin has been released that should fix your problem. Malformed data messages like the one you are consistently experiencing should be ignored. Of course, because I was unable to reproduce the error, I await your feedback that the problem has been fixed.

An update to the PG3 interface (3.3.2) has been made that should fix the error. In PG3x, you can do "System->Reinstall all Plugins" and it should install the new interface (along with the latest versions of all your plugins).

I see the problem. It uses the first 14 characters from the  "name" from the ratgdo for the node address. For the light, it lops off 3 trailing characters and adds "_lt". So while that's enough characters to distinguish "housegarage" and "housegarage2," it's not enough to distinguish "housegarage_lt" and "housegarage_lt".
Rookie mistake. I will put something in the next release.

But yes, I will put a note in the plugin to add in the next release a "Stop" command for all blinds. The plugin will just ignore it for blinds that don't support stop, or maybe go ahead and send it and let the Bond bridge deal with the lack of support.

I've had  put in a note to fix it in next release. But as I mentioned, it is a non-fatal connection error very infrequently returned from the Schlage API the plugin uses, and the data is updated on the next poll. But it adds the notification when the error occurs. So even though it's logged as a warning and the plugin recovers on the next poll, the notification just hangs out until you clear it. Shouldn't cause any issues in the operation of the plugin.

From the symbol at the top of the attached PDF file, I am guessing you installed the ESPHome firmware. You need the MQTT firmware.
Looking at the firmware installation page now, it appears that it has changed substantially since I flashed my first ratgdo and subsequently wrote the plugin directions. I will need to update the release notes to make sure folks are selecting the MQTT firmware option for flashing. Specifically, under the MQTT option on the firmware page, choose "ratgdo v2.57, Security + 1.0, 2.0 & Dry Contact" from the dropdown.

Cleanest solution here (and just about all other instances with motion/presence triggering events and timed activities) is the two program solution:
First program: Utility Room Motion (Enabled) 
If 'Wireless Tags / Utility Room Sensor' Event State is Detected Movement Then Run Program 'Utility Room Lights on Motion' (Then Path) Else - No Actions - (To add one, press 'Action') Second program: Utility Room Lights on Motion (Disabled)
If - No Conditions - Then Set 'Basement / Utility Room' On Wait 15 minutes Set 'Basement / Utility Room' Off Else - No Actions - (To add one, press 'Action') When the Wireless tag sends movement, the first program starts the second program, and the second program turns on the lights, starts the timer, and turns off the lights when the timer expires. Subsequent motion from the Wireless tag turns the lights on again and resets the timer. 15 minutes after the last motion detected, the lights turn off.
An advantage to this structure is that it works whether or not your Wireless Tag (or other motion detector) sends a DOF (No Motion) command after some delay.

Also, did you change the "MQTT Topic Prefix" on your ratgdo to "ratgdons/" as instructed in the very detailed release notes here: https://github.com/Goose66/NSDocs/blob/main/ratgdo-pg3.md

The node “Front Door” should generate a DON command on button press. It shows up in programs as “Ding” command. It is supposed to be able to drop into scenes as a controller.

I see a "failed due to bad credentials" in your log four or five times over the course of the day. But it always succeeds a minute later on the next longpoll. I actually got one of these today myself. Based on the timing (the few in your log are exactly one hour apart) it appears to me that the oAuth token is expiring before automatically refreshed, so the pyschlage library just refreshes it on the next call. 
I will put it in the To-do for the node server to remove the warning message from the PG3 dashboard, but since the node server remains functional (it's just a warning), you can just ignore these errors for now.

When I was required to have OpenJDK on my PC, I started the finder like this:
java -jar .\downloads\isyfinder-2.0.jar Put it in a "startiox.bat" file. I didn't have too hard of a time finding a copy of isyfinder-x.jar  file on the web, but you may have to put in a support ticket to get @Michel Kohanim or @Chris Jahn to post a copy.

Currently goes through the Cloud, and in a very circuitous route at that.

Afraid not. Neither setting nor determining the current controlling sensor is supported by the API. I don't believe you can in the Honeywell Thermostats, either. You may want to ask @Jimbo.Automates about Ecobee.

Update to the latest version (v3.2.23) and see if it works for you.

BTW, I followed the chain starting here:
You may need one or two more reboots than what's specified in the Wiki before everything is done.