bmercier

Depends where you installed it. You choose the slot when you install.

I'm not sure where TTS files are located. I was referring to the location where the upload of files is done, and that is in the "data" folder of the node server. So, the complete path would be /var/polyglot/pg3/ns/<NS Folder>/data <NS Folder> is <uuid>_<slot> The only exception would be if a plugin is installed in developer mode. The data folder will be where the plugin is being developed. The command to download everything would be something like this: scp -r root@eisy.local:/var/polyglot/pg3/ns/<Ns Folder>/data/* /local/path

They are stored in the node server folder under "data". They can't be downloaded through the UI, but you could access it through SCP. They are included in the PG3 backup.

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.