Goose66

I see the plugin is in a GitHub repo and it's free. The quick fix for you would be to ssh into your eisy or policy, navigate to the /var/polyglot/pg3/ns/0021b9026aaf_9/roomba.py file, and change from collections import Mapping to from collections.abc import Mapping using a text editor, like ee or vi. A better solution would be to fork the repository in GitHub, make the fix and make a pull request to Bob to merge it back in and upload a new version of the plugin. That way, it should work for anyone who needs it.

Hmm. This is not my plugin, but I recognize this error. The Mapping class is in collections.abc, not collections. And it's been that way since Python 3.3. I think Python 3.3-3.9 had an alias that allowed imports from collections, but that was removed in Python 3.10. But that was like 4 years ago. And udx has included Python 3.10 or 3.11 for most of that timeframe. So it doesn't make a lot of sense that it would just now be cropping up now. I guess it's possible that the Roomba plugin (or the roomba library it depends on) hasn't been updated in A LONG TIME.

I am getting similar messages, and with other skills too. Like Alexa+ can still turn off my Roku but it afterwards it still says it’s having problems controlling Roku.

Third time’s the charm!

The version is supplied to PG3 by the code. I wish it was just metadata. The move from 3.2.5 to 3.2.6 was simply a file format switch made by git commands. I specifically avoided touching code because I didn’t want to have to retest, but the version had to be changed in the Plugins Store to force the upgrade over the 3.2.5 with the install.sh file in the wrong format. However, I forgot about the version issue, so I will try to get a 3.2.7 version tested and uploaded tonight.

Sorry, I had to make a simple change (take out CRLF from install.sh) so I changed it to 3.2.6 in case anybody had downloaded the previous one. But I forgot to update the version in the code. I will try to push a 3.2.7 this evening.

@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.

I only did it once. It was the DSC1832 I had when I wrote the original PG1 version of the plugin. It had been installed by an alarm monitoring company (Loud). The keypads and everything was branded. The factory reset via pin jumpering technique took it back to default factory settings.

There is a way to factory reset the 1832 boards to default values (including passwords) by jumpering two pins in the controller chip.

Run the plugin with “Debug” logging level so we can see what it’s doing differently.

I think you need an EyezOn UNO4 expander as well. Never tested the plugin with this setup, though.