Goose66

Also, because of the nature of the unauthorized API usage, if you poll too frequently, you could cause your ip address (or even the entire pyschlage access) to be locked out.

Make sure the logging is set to debug level to get full logging of communications between the plugin and the pyschlage API. As far as state updates from the plugin to ISY, these should be logged in both debug and info logging levels. If they’re not showing up, it’s likely a PG3 thing and not a plugin thing. Open a ticket with UD. The state updates are individual and not “atomic.” Because of the threading implemented in PG3 and the nature of the RESTful interface between PG3 and ISY, the order of the state updates may further be non-deterministic. I’m not 100% sure how or when you are forcing updates with the UPDATE command, but you could consider having two programs: a first that is enabled and triggers on last message time (guaranteed to change) that would wait for 1 or 2 seconds and then run the if branch of the second program (disabled), which checks the last message and last access code used and unlocks the lock accordingly

There's a lot of information here and I have to admit I am not following a lot of it. Two responses after a quick review: As far as the plugin not writing to the log, I am not aware of any change in PG3 that would prevent a plugin from writing to the log file. The log file viewer in PG3, though, has always been a little squirly (or just broken depending on how you look at it). Generally, once a plugin is running, you should go back to the Dashboard and then drill down to the plugin log file to see the latest log entries. Or better yet, download the log and view in a text viewer. As far as what you are trying to accomplish, it seems to me you are trying to get the Schlage plugin to do something it is not designed to do. The plugin uses a third-party API that accesses the same cloud-based service as the Schlage app. Accordingly, the capabilities of the plugin are limited to what is possible/implemented through the third-party API. Most notably, there is no "push" functionality for state in the API - it requires periodic polling for state update. And, as you noted, some items like messages don't update every poll interval and require the plugin to force an update in the API. So using this plugin to trigger realtime events is just not contemplated in the design. What the plugin is good at is locking and unlocking the locks, because those commands are executed substantially immediately. Now, there is an "official" Schlage API and it does have push functionality for state. But that API requires subscription by the HA vendor (UD in this case) and associated fees be paid, and while we tried to get them to grant us access to the official API, they were unwilling to do so, presumably because the number of users involved didn't meet their standards. On the other hand, the EVL-DSC plugin does have realtime status updates. So one thing to look at would be triggering your programming on disarm of a partition at an alarm keypad, and based on the user code used to disarm, unlock the deadbolt. Of course, that would require external alarm keypads. Also, I believe there are ZWave and Matter deadbolts that operate locally with realtime status updates. They may be more suited for your purpose.

If you can access the locks via Matter/thread , you shouldn’t need the plugin (node server).

Alternatively, reconnect the motion detector zones so they are the last zones in numerical order then set the “numzones” Custom Configuration Parameter so that they are excluded from the nodes created at the start of the plugin.

You can delete the nodes for the motion detector zones in the Admin Console or in the PG3 Dashboard, but they will reappear each time you restart the plugin. As far as excessive traffic, what are we talking about hear? Several times a second? Every 5 seconds? Every 30 seconds? How many are there?

Since Alexa+ is based on LLM, how cool would be if we could add our own system prompts that would stay in context. Like someone could say “when I issue a home automation or device command, first look for an exact match for the device name before searching for the best match in based on context” and it would keep that as a system prompt added to every spoken command.

I have inconsistent problems with Alexa+ as well, with the UD Skill and other skills, like Roku. In one common problem, I will ask it to turn something on or off, and it will do it, but then it will say “device x is not responding.” I know Alexa+ is still beta or pre-release, but I can’t imagine too many organizations in the world that have more resources to throw at something like this than Amazon. Why is Amazon’s progress here so painfully slow?!?

I imagine “dude” is making zero money on the device given the cost of the boards, shipping, support, hosting the website, etc. Like the community members developing plugins, it’s probably much more a passion project than a money-making opportunity. There are certainly challenges working with the security protocols on the MyQ GDOs and I know it can get “out of sync” with rolling codes and all. My RatGDOs working in dry contact mode have been rock solid.

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.