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.