bmercier

Hello everyone, This is the support thread for PG3x v3.2.22. These features were planned for 3.2.21 but did not make it to the package, so they are released here as part of 3.2.22.

Some features planned for 3.2.21 did not make it to the package. 3.2.22 is now released and includes all the planned features.

Hello everyone, Here's the latest PG3x release. Release notes for: 3.2.22 - 04/16/2024 Make Plugin license check tolerant of connectivity failure on startup Change logs time format after midnight from 24:xx:xx to 00:xx:xx Developers: Add capability to update the plugin name

Yes, please open a ticket. I will need to know: Portal user logged in with Which plugin you tried to update & which store Copy of the browser console log showing when you do the plugin name change PG3 log & time you did the plugin name change

Sorry, good question. Normally in a browser you can just enter spaces instead of the dot, which translate to %20 (space = %20). But if you struggle with that, just use https://polisy.local:8443/rest/nodes and find your device in the list.

Hello everyone, This is the support thread for PG3x v3.2.21.

Hello everyone, Here's the latest PG3x release. Release notes for: 3.2.21 - 04/15/2024 Add capability to upload a zip file to the "data" plugin directory (For selected plugins such as the Audio Player

Please open a ticket, and include the following: Your polisy uuid The device address you are testing with Open a browser, try this url when there is contact and when there is none, and post the content of both cases in the ticket: https://polisy.local:8443/rest/nodes/yourdeviceaddress

So did you delete that Alexa device? If it still does not work after recreating using a "Discover devices", then check the mapping in Select Tool | Connectivity | Amazon Echo. It might be pointing to an incorrect device address on ISY. I would suggest to delete that device mapping and recreate it as well.

That would be a different problem - This is not specific to routines. Based on your problem description, I would recommend to: Delete the contact sensor in the Alexa app Ask "Alexa, discover my devices" - This will recreate the device in Alexa based on the configuration you have on ISY Portal Make sure your ISY/Polisy/eisy is online on portal Make sure you have an active license If that still does not work, make sure that the device or variable you are testing with in AC is the same that you have mapped in ISY Portal (Select Tool | Connectivity | Amazon Echo)

Alexa routines triggered by Alexa contact sensors sometimes would stop working. I have investigated this in great details and found a case where it may stop working. I just made a fix to this. At this time, it should be working for everyone. Time will tell if the fix is successful. Please let me know if it stops working for you.

I can't see how 3.2.20 would impact this. I see your other post. Let's see what Goose thinks.

That's very odd. Were you on 3.2.19 before? The changes between version is minimal. The only possible impact would be that it may be running faster. I would recommend a post in the MagicHome forum. I have no clue what may be causing this.

Every MQTT messages coming to PG3x go through up to 2 queues which are used to rate limit the requests; 1. MQTT messages from plugins are in their own queues, in order to prevent a plugin to take up all resources, and frontend messages are also in their own queues, to prevent attack. These queues have their own rate limit sets. 2. A global Queue, which applies system wide limits. This is the latter that has been disabled as it has been observed to cause problems on some systems.

Hello everyone, This is the support thread for PG3x v3.2.20. Starting with PG3x 3.2.19, if you are using the Backup or ELK plugin, please make sure to select the "Allow ISY Access By Plugin" in the configuration page.

Hello everyone, Here's the latest PG3x release. Release notes for: 3.2.20 - 03/12/2024 Disable the global MQTT queue (Fix to the Auto-Logout) Minor fixes

Please check if you still have the problem. I have reports from another user that it started working today. You may have to recreate the routine. If not, please open a ticket and let us know: The uuid The type of ISY "device" you are using. Is it an ISY state Variable? Insteon IOLinc? Something else? The device address What time you did the test and in what time zone (Or better, the UTC time you did the test)

Updating PG3 does not update the interface. Reinstall all is used to update the interface & the plugins versions.

@TJF1960@macjeff Looks like this plugin needs access to the rest API. The author needs to edit his store entry and check "Require ISY Access". Then, in the configuration page, PG3x will display the "Allow ISY Access" checkbox. Not sure who the author is, and if this plugin is still maintained.

This applies to plugins that want to make rest requests. Other apps can still use rest requests the same way as before.

Hello everyone, This is the support thread for PG3x v3.2.19. If you are using the Backup or ELK plugin, please make sure to select the "Allow ISY Access By Plugin" in the configuration page.

Hello everyone, Here's the latest PG3x release. Release notes for: 3.2.19 - 02/26/2024 Enforce ISY access security - For plugins that require ISY access, user has to click Allow ISY Access PG3x Logging to syslog now only includes the startup and shutdown sequence On addnode, if creating the node on IoX fail, log the error If oAuth authorization code exchange fails, log the token endpoint response ISY Access security Starting with this release, plugins can no longer directly access your eisy/polisy using the rest API unless you allow it. Most plugins don't need direct access. Some plugins like Backup and ELK may need it. If the plugin needs direct ISY access, a checkbox "Allow ISY Access By Plugin" will appear in the configuration page. If you are using the Backup plugin, you need to enable ISY Access. If you are using the ELK plugin, and if you are using ELKID or ELKNAME you must enable ISY Access as well.

Please open a ticket and write your uuid and a reference to this thread. I will take a look at the server logs. The 994 is no longer supported, but I will take a look for you.

First of all, there is no "ISY Portal Event log" or "ISY Portal Error log". Those are the ISY Error log and ISY event log. They are just accessible from ISY Portal. There is nothing in there that relates to Alexa. Please try what I suggested: Delete the Alexa routine and re-create it.

In my opinion, either your 994 is not sending events, or Alexa is not processing them. Let's take the Alexa side first. You did not mention how you exposed your state variable to Alexa. Could be as a light, a contact sensor, etc. But regardless, I'm assuming that you are using said Alexa device to trigger an Alexa routine which does not work. My suggestion would be to delete the routine and re-create it. I have seen cases where a routine would stop working and it had to be recreated. On the ISY side, I do now know what the problem would be, but I would say that the messages -170001 UDQ: Queue(s) full is suspicious.I think something might be overloaded. Are you able to login to the Admin console? Does it show your 994 as busy?