Goose66

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.

My Polisy upgraded fine except for it stopped responding to polisy.local. But everything else went smoothly. PG3x and all the plugins seem to work fine as well.

The Local Connection Settings for my Polisy in UD Mobile was set to "http://polisy.local" and worked fine for literally years. After the 5.9.1 upgrade the Polisy is no longer responding to "polisy.local" so I substituted "http://polisy.lan" for the hostname in Local Connection settings. ".lan" is the default DNS extension on my local network and all devices that have a hostname respond to <devicename>.lan whether they have mDNS capability or not. However, with "http://polisy.lan," it says "ERROR: Could not finish Synchronization. The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." But if you try and set the hostname to "https://polisy.lan," it says "URL must be fully qualified starting with http:// for local connection (not https)." Simply using "http://<ip address>" works, but requires fixed or assigned IP addresses (like we are all college geeks running Ethernet between our dorm rooms in the 80s). Is this the intended functionality or do I have something set incorrectly?

I will log it. I know getting mDNS to work in the first place came in fits and starts. Could just be a missed configuration setting in the updated package. Also could be something that works fine on eisy but not on Polisy. I will upgrade my eisy next.

Yes, it appears that the updated Polisy (5.9.1) will no longer respond on the network to "polisy.local", but my non-updated Test-Polisy (5.8.4) still responds to "test-polisy.local". Are you saying they know about this problem? EDIT: non-updated eisy still responds to "eisy.local".

@Guy Lavoie Do you have your local connection set to an IP address or hostname, e.g., "polisy.local?"

Updated and IoX (via Admin Console) and PG3 all appear to be working correctly. However, now UD Mobile cannot connect to the controller. Just says "Attempting Connection" in the header, and if I attempt to manually synchronize I get a "Error: Could not finish Synchronization. The request timed out." error. Tried shutting down and restarting UD Mobile on my iPhone.

May be a memory corruption problem in the offending T7900. Maybe a factory reset and reconfiguration?

Both thermostats are T7900s, and one's working and one is not, correct? Are they showing the same firmware? Can you rollback the T7900 with the problem to a previous firmware version?

The problem is with the API on your stat. But according to hart2hart it’s working on other stats, so we can’t just patch it. You may want to see if there is a firmware update available for your stat that you could try.