Goose66

It looks like clicking the button in IoX is calling the correct piece of code, and the plugin is subsequently sending the right command to the EVL successfully. The recent update didn't change this particular piece of code, or any of the code for the partition node. Some things to clarify: 1. Do ALL of the other arming options work? 2. Have you recently updated your EVL firmware? 3. Have you set the logging level for the plugin to "Debug" and retried to see what additional info there is? NOTE: I believe the three, identical log entries is a bug in the PG3x front-end ("Dashboard") and not something actually being produced by the plugin. This can be confirmed if you are seeing every log entry repeated three times.

Ok, there are no errors starting the plugin in the PG3 log file. In fact, PG3 logs "2025-03-16 17:25:34.703 [pg3] info: startNs:: Schlage started." Yet it appears that the plugin is not starting. I am pretty sure I have seen this situation before -- I think with a different plugin -- but for the life of me can't remember how we debugged it. I will have to dive a little deeper.

Not that it matters here since you have no Else statements, but be aware that this program will also run every time the Gates_ProgON variable is changed.

The web pages on Paul Weilands site aren’t structured the best for sure, but for many that just follow the instructions from the beginning, it all goes off without a hitch. I think the fact that you were trying to Download the OTA binary instead of using the ESPHome firmware installation tool was throwing things off. Also, if you were getting shocked when touching the board, that means you were handling an unenclosed circuit board while it was powered up - not a good idea. In the “Installation Error” screenshot you posted, there were some troubleshooting steps. Did you try those?

@tjmeiner Can you send the log file for the plugin, not the PG3x log file. It is available in the PG3x Dashboard, under "Details" for the plugin by selecting the under "Log" button. That's also where you set the logging level to "Debug" for the plugin.

My Schlage plugin is working fine with my two locks on my production Polisy running IoX v.5.90.1 and PG3x 3.3.18. Please set the logging level for the plugin to Debug in the PG3x Dashboard, restart your plugin, let it run for 5 minutes or so, and then send me a log file. You may want to DM the log file directly to me because it may have your password in it.

I haven't upgraded my test polisy to see if the schlage plugin has an issue. I should be able to check it this weekend.

Sorry I can’t help with any of that. Perhaps others can share their experience.

I would suggest factory resetting your device and start again from scratch following the directions at https://paulwieland.github.io/ratgdo from the beginning. If you can open and close the door through the web interface but the plugin still doesn’t discover the device, we can go from there.

First, I will point out that the instructions I posted say this: Make sure each ratgdo device is flashed with ESPHome firmware (see https://paulwieland.github.io/ratgdo/flash.html), are connected to your LAN (Wifi), and are online. From the Polyglot V3 Dashboard, install the ratgdo Standard edition plugin from the Plugins Store. Once the plugin is running, click the "Discover" button in the Polyglot V3 Dashboard for the plugin to discover and load nodes for the garage door openers with connected ratgdo devices. It seems you are getting hung up in step #1, so a better place to seek help for this may be over on Paul Wieland's ratgdo pages. The best place to start is the beginning: https://paulwieland.github.io/ratgdo/ However, it appears that you are not following the instructions posted there for installing and configuring your ratgdo 32 disco. The "Download OTA Firmware" button is to download the binary file for updating a ratgdo already on your Wi-fi with the latest firmware "Over the Air" (i.e., "OTA"). What you should be doing on the "ESPHome ratgdo" page (https://ratgdo.github.io/esphome-ratgdo/), after selecting your GDO Control Protocol and ratgdo control board, is clicking the "CONNECT" button. This button will start a tool that will connect to your ratgdo disco 32 through the USB connection, allow you to install the latest firmware, allow you to configure your Wi-fi, and then allow you to connect to the device's web interface to finish configuration (see https://paulwieland.github.io/ratgdo/02_configuration.html for that last step). If you cannot connect to your ratgdo with this tool, then scroll on down the "ESPHome ratgdo" page to the "Drivers" section to debug (however, with the ratgdo 32 disco, you should not need to do this step). Once fully configured, you should connect your ratgdo 32 disco to your GDO and access the onboard web interface (http://<ip address>) to test the device and the connection to the GDO. If that is all working properly, you can then move on to step 2 above to install and run the ratgdo plugin in PG3x.

See the instructions for the plugin here: https://goose66.github.io/nsdocs/ratgdo-pg3.html These instructions contain a link to a ratgdo-specific web page that has instructions for installing the ESPHome-based firmware on your ratgdo. You must have the ESPHome-based firmware installed and working on your ratgdo and have it connected to your Wi-fi (and I suggest testing it with your GDO) before proceeding with configuring and using the plugin. EDIT: It looks like the new ratgdo 32 and ratgdo 32 disco already come with ESPHome firmware installed. So you may be able to skip that step. Just get the ratgdo device installed and working on your GDO using the instructions and wiring diagrams that came with it, and then start the plugin and press the "Discover" button on the PG3x Dashboard as indicated in the plugin instructions linked above. I always suggest updating to the latest firmware before using when you get a new device, however.

There could be a number of errors here - it's a big log file with lots of restarts. Let's address the missing events subscription first. As mentioned in the installation instructions, the steps need to be performed exactly as described in the very specific order described or it just doesn't work. I think this is because the Device Access project for the NEST SDM API is not truly integrated into Google Cloud Console but is still a red-headed step child. Believe me, it took a lot of work to come up with a description of steps that worked on a repeatable basis. What appears to have happened here is that you didn't enable "Events" during creation of the Device Access project. From step 7 (yes, 7) of the installation instructions found here: While the interface of the Device Access Console makes you think you can go back and enable "Events" for your Device Access project after creation, in my experience it doesn't work when you do it this way. My suggestion is to delete your Device Access project from the Device Access Console, give it a day or so to actually get cleaned up, then create a new Device Access project in the Device Access console using the step 7 procedure above exactly as described. Then, after an hour or so, restart the plugin and generate a new log file.

If your GDO had a (controllable) light or motion sensor, they would also appear as child nodes under the ratgdo node.

The door node is a child node of the ratgdo node. You see that “>” character just to the left of the ratgdo node? Click that and it will expand the tree to show the child nodes. The door node should be there.

Can you add some screenshots?

I don’t expect a new smarthome “expert” or any of the other experts to be available right away. The existing Smart Home Skills API (which UDI uses) should continue to work just fine with the agentic Alexa. If and when they migrate the Smart Home Skills API to some new smarthome expert, I imagine there will be a roadmap for Smart Home Skills API users to (hopefully easily and quickly) migrate their integrations.

Yes, it was truncating whatever was in the Custom Configuration Parameter down to six characters otherwise there was a communication failure in the EnvisaLink 3 and the EnvisaLink would disconnect. When the EnvisaLink 4 came out, that truncating was left in place so regardless of what you put in the Custom Configuration Parameter, only 6 characters got sent. Now it sends whatever is in the custom configuration parameter. So if you try and send the wrong characters to an EVL4, it will give you an invalid login error, but if you send 9 characters to an EVL3, it will yack.

Also, PG3x hosts “plugins.” They are no longer called “node servers.” And they were NEVER CALLED “NODES.” A node is an element in the node tree in IoX/ISY/Admin Console that represents a device. There are nodes representing Insteon and Zwave (and now Matter) devices in the node tree created and managed natively by IoX. A plugin interfaces with other devices and creates nodes in IoX to allow the devices to be controlled and statuses to be obtained. /rant 🤪

Those are indeed the zone timers (“Timed Closed”) status reports. Don’t know why they aren’t properly named in IoX log. If you’re not using the timers then just turn them off. It will not affect any other functionality.

I am assuming that the DSC-EnvisaLink events you are referring to as overwhelming your IoX log file are the Zone Timer values. As is shown in the plugin Release Notes available here: https://goose66.github.io/nsdocs/evldsc-pg3.html, the "zone timer values ('Time Closed') represent the time since the last closing of the zone, in seconds, and are calculated in 5 second intervals." While the plugin can't control if or how often IoX logs the zone timer value updates, you can change the frequency at which updates are sent by the plugin using the "zonetimerdumpflag" Custom Configuration Parameter. Again, from the Release Notes: If you add/change this Custom Configuration Parameter while the plugin is running, the change should take place immediately.

I put in a ticket and UD confirmed it was a bug. They asked me to make an adjustment in a file to debug, but I haven't done it yet. I will try and get back to them today. But there is an easy workaround (IP address) so I imagine they will just wait to the next point release to address it. My point in this post is, even if they fix mDNS in the Polisy/eisy, will UD Mobile no longer allow us to use hostnames in the connection, i.e., is the user interface (in conjunction with Apple Transport Security, evidently) limiting the value here to IP Address. I will note that the name of the field is, in fact, "IP Address." Don't know if it's always been that but in hindsight it's pretty clear that's what UD Mobile user interface wants in this field (albeit with an "http://" in front of it).

So IP address only? Polisy.local worked for years.

@guyhamelin However, I am pretty sure you can install the plugin again in another slot and just set it up for your second panel. It shouldn't charge you again since you already have a license. It won't make any difference on the IoX side, and only a minor resource hit on the PG3x side in running two plugins.

The plugin only supports one panel node via a single EnvisaLink. Perhaps in a next version.

There is a plugin for Nest thermostats, but you have to create your own developer sandbox and Device Access project at Google to use it. It’s free and in the Non-production store. A production version of the plugin was finished but not rolled out because using it with more than a couple of users requires a complex verification process (including security audits) with associated costs that are just not worth the effort. Also, it was cloud based and Matter support should be local - much better solution.