Goose66

@Diggerules so no response from anybody here. Based on everything we’ve looked at though I am assuming you have a similar problem to @tjmeiner, i.e., pip not installed. I will try to get a version of the plugin out that utilizes the latest pyschlage library (one that restored Python 3.11 support), but if this is a Python infrastructure problem on your eISY, that’s not going to work either, i imagine. If you can’t get it working, we can arrange for a refund.

The Plugin is discovering your ratgdo at ratgdov25i-18fe31.local, however when it turns around and queries it for details via HTTP, it can’t connect. Not to be cynical, but the cause of this is likely that UD blew up mDNS and its ability to resolve *.local addresses with a recent update (sorry - this has all been very frustrating for plugin developers). Try adding a ‘gdodevice’ entry to your Custom Configuration Parameters (i.e., value '192.168.0.224;ratgdov25i-18fe31’) and then re-perform discovery. See note # 2 from the Release Notes at goose66.github.io/nsdocs/ratgdo-pg3.html (recreated below). 2. The plugin utilizes mDNS service disovery to discover the ratgdo devices on the LAN. If a GDO device cannot respond to broadcasts, e.g., is on a different LAN segment or network, then you can add a Custom Configuration Parameter for each such device before performing the Discovery process to force the plugin to connect to the devices. Add a Custom Configuration Parameter with a key of "gdodevice" and a value of "<host>;<devicename>" for the ratgdo device, e.g., "ratgdov25i-fc64f3.local;ratgdov25i-fc64f3" or "192.168.1.135;ratgdov25i-618d30". Additional Custom Configuration Parameters can be specified for additional devicecs with key values of "gdodevice" with an index, e.g., "gdodevice0", "gdodevice1", etc. NOTE: the "devicename" is utilized to generate the node address and a specific value should be consistently used for each device, e.g., the name of the device with periods removed and space replaced with dash, in order to prevent subsequent Discovery processes from generating duplicate nodes with different addresses.

@Michel Kohanim can you shed some light on what the solution for @tjmeiner above was? @Diggerules is having very similar problem but when he submitted a ticket he was told pyschlage required Python 3.12. However, this problem was fixed in the last versions of the plugin going back to March, so I do t think that is the problem here. Sounds like diggerules problem is the same missing pip to me.

I’m out of the country for a few weeks. I’ll looK at it when I get back. But you may want to see if you can open and close the door from the built in Web interface in the ESPHome firmware. If not, then it’s your ratgdo’s connection to the opener.

Is it repeating the error or was it just the one. Did it recover the setpoints?

Unfortunately reading through this topic I can’t tell what the final solution was. Perhaps @tjmeiner can clarify how they fixed it.

Polisy or eISY? What version of the Schlage plugin?

Never mind. The information originally posted was for Gen 1.0 devices, which won't be supported.

I started on a MQTT version of the plugin that would require every Shelly device to be configured to connect to the eISY MQTT broker. But you can sort of already do that with the MQTT plugin. So was going to try something more native so you could discover and use installed Shelly devices “out-of-the-box,” but never really made much progress. The Shelly devices I have installed here actually have Tasmota flashed on them. Perhaps I can complete the MQTT version and roll it out and followup with a version 2 for more native support. The capabilities and node definitions would basically be the same - just more plugin-specific configuration of each Shelly device needed for the MQTT version.

I think ecobee is a @Jimbo.Automates plugin.

Many of the plugins have what you are asking. The plugins I have developed that use cloud services (iAquaLink, Schlage, MyQ, Nest, ipool) should all have a node that represents the cloud service connection with connection status. Others have done the same.

This is a design decision made by each plugin author. IMHO, the right answer is for each plugin to report statuses (running, connected to cloud service, authenticated, stopped, failed, etc.) that are common across most plugins and have this displayed and managed in the Admin Console, e.g. under the Plugins menu. Unfortunately this require a rework of the Plugin interface - preferably by ripping out the old Node Server REST API layer and linking the plugins directly to IoX via MQTT (a layer that already exists). The nodes are supposed to represent devices.

Don’t know what to tell you. Obviously the plugin hasn’t changed in 14 months, including the “profile” files, and it seems to have been working before. I would think something has changed in UD Mobile and the way it interprets profiles from a recent update, and that is likely the problem. If there is some new format for plugin profile files that UD Mobile has changed to, I am not aware of it. Please open a ticket with UD to investigate, reminding them that the last code changes to the plugin was 14 months ago.

The erase is not as important as going through the setup steps to get the initial settings right so the Discovery process will work. See here and here.

The original issue just sounds like the “profile” for the plugin didn’t get successfully loaded. You could have loaded the profile from the PG3 dashboard and restarted the Admin Console to see if that straightened it out. However, now it sounds like the plugin setup is corrupt once you updated your ratgdo. I would suggest factory reset ratgdo, delete plugin, and then follow all the instructions again to install and discover.