bpwwer

Ok, I updated my development system and tested the plug-in. I did have to re-install and then re-pair with the bridge to get it working, but it's working fine now that I've done that.

The log doesn't show anything useful. If it is still repeatedly connecting/disconnecting, I'll need to see a log for the time when that is happening. Better yet would be the log package since that would include the PG3 log as well.

I'm not able to reproduce this on my system. It looks like you may have upgraded the eisy recently, were you using this plug-in before upgrading and was it working fine prior to the upgrade? The error is happening because the network connection between the plug-in and the smart bridge failed which is not something that should ever happen.

Ignore that menu on the admin console. I don't believe it works for any PG3 plug-in. All configuration should be done using the PG3 UI. The configuration instructions for the WLED plug-in aren't very clear. My guess is that you have to create a custom parameter with the key being a name and the value being a comma separated list of ip address for the WLED lights. So something like: key=WLED_LIGHTS value=192.168.1.4,192.168.1.5

What does the plug-in log file show? The only reason it would repeatedly connect/disconnect is if the plug-in is crashing.

When the ISY reports that UUID, it means that something in UDX failed and is not able to supply the ISY with the correct hardware address. You can try power cycling one or two more times and see if it corrects itself (probably give it 5 - 10 minutes after the power cycle before starting the Admin console. If that doesn't work, you'll have to submit a support ticket and get UDI involved.

Yes, at some point I'll have time to investigate the issue more and hopefully find a fix. I'm pretty busy with other things right now so I don't have a timeline yet.

The Roomba plug-in won't work with Python 3.11 (or 3.10). Starting with version 3.10, Python removed support for a feature that the plug-in relies on.

My fault. I tried updating the plug-in to use a newer version of the total-connect-client library and apparently the changes in the library are not compatible with the plug-in. I've reverted it back so re-installing should fix the issue.

ahh, I think only the original author has the ability to modify the PG2 version. I don't have access to the code, but my changes to the PG3 version probably are the same changes needed in the PG2 version.

The code change to preserve those values is pretty simple. I've made the changes in my tree and @bmercier is ok with it, I can push those to the main tree.

No. When doing an update (which is defined by installing in a slot that already has the same plug-in installed), it does a database update vs. a database add. The update does use the plug-in store entries. The exception is for custom parameters, those are not replaced/overwritten by the update. shortPoll and longPoll are not part of the custom parameters so they do get overwritten by the update. So should they be? I can make arguments for having it either way, but I'm leaning towards thinking they should not be overwritten. It would be nice if we had some "smart" control over them. Like a way for the author to control that or away to ask the user if they want them overwritten, but since we can't do anything of that, I think the user would expect them to not be overwritten. Looking over the code, what about LogLevel? That is also overwritten by the default value when re-installing. Maybe that too should be left at whatever level the user has set.

As far as I know, the only way the poll values can be set is via the UI. The only exception is when the plug-in is installed, it will default to either what's in the plug-in store entry or shortpoll=60 and longpoll=300. However, there should always be a store entry as that's not optional. These are the initial settings before the user has a chance to modify them. There is only one place in the PG3 code where it updates the database with new poll values and that is when an update to do so comes from the UI. So the only possible way this could be happening is if: 1) the default value set at install time is 60 seconds. 2) when updated in the UI, the database update fails but PG3's internal timers are updated. If the database update fails for any reason, it should be logging and error message. I'd suggest checking the PG3 log after changing the poll value(s) for errors. Another thing you can check is to try this from the command line: sudo sqlite3 /var/polyglot/pg3/pg3.db "select shortPoll from nodeserver where profileNum=2;" The profileNum is the slot number for the plugin. This command will return the value saved in the database for short poll. And case is important (i.e. shortPoll and profileNum).

Yes, there shouldn't be any visible changes. It's only internal to PG3 where it check for a valid license before starting the plug-in. The screen you showed initially is where you'd see which license is being used. Most of mine seem to show correctly (maybe because I've never activated the trial for those). So you might want to submit a ticket since it seems like a bug in PG3.

It worked fine, my fears were unfounded. Version 2.0.5 has been pushed to the store. This should fix the error.

Looks like the library being used by the plug-in has a bug. Likely, that bug was not something that older versions of Python flagged but newer versions do. The library was released in Oct. 2020 so It's now 4 years old and has had many, many changes since them. The TotalConnect plug-in will need to be updated to use a newer version of the library, but there's a high probability that attempting to do so, will cause more issues and require more debugging/updates to the plug-in. I believe this plug-in is currently unmaintained. However, I can make a quick attempt to update the library and see what happens.

The trial and the perpetual purchase are two different licenses. If you activated the trial and installed it. That installation will only be good for the length of the trial (1 month in this case). After purchasing the perpetual license, I believe you need to re-install for that license to take effect. You can do that by clicking the "Install" button and then selecting the "Reinstall here?" button to install it to the same slot. Using the reinstall option is, in almost every case, perfectly safe. PG3 will remember any configuration you did previously and re-use that for the re-install. In this case, everything should be the same except for the license being used, after the re-install it will use the perpetual license instead of the trial license.

It shows that you can install it because you have purchased it. If you didn't already have a license the button would show "Purchase" (or "Activate" in the case of the trial) instead of "Install". Like this: Although if you have it installed, it should show the slot it's installed in on the "Installed" column so something seems wrong there.

Not really a direct answer. My interpretation of that is that the older versions of the plug-in will stop working when they turn off version 2.5 of the one call API.

Yes, it is very confusing. And again, I doubt anyone on this forum can answer your question since we don't work for OpenWeatherMap. The plug-in has been using version 2.5 of the onecall API since sometime in 2020 (which was pre-PG3). This version of the API does not work with API keys for the 3.0 version of the onecall API, however, it seemed to be working with API keys from the professional collections. Given the messaging from OpenWeatherMap, my assumption is that version 2.5 of the onecall API will cease working in June (for all/any API keys).

@johnnyt That's not really something that can be answered here. My interpretation of the messaging sent out by OpenWeatherMap was that the older versions of the API were being discontinued and would stop working. The only way forward was to migrate to the latest version of the API. You can certainly continue to use the older version of the plug-in for as long as OpenWeatherMap allows it to work. Yes, OpenWeatherMap now wants a credit card for the OneCall 3.0 plans, even if you never plan to exceed the free limits. That's one of the reasons I was resisting switching the plug-in to use the OneCall 3.0 API. But the message I got from OpenWeatherMap indicated that using the older API would not longer be an option.

The main file didn't get updated with the new version number. But that's the only change in that file so even though it still says 2.0.6, it really is running the 2.0.7 version. 2.0.8 is now in the store that fixes this and adds some better error reporting.

This appears to be a problem at WeatherBit's end. There isn't any difference in the API used to query for the data for the different plans. The plans differ in the limits and what types of data are available. When requesting a new API key, I see the following: - While the key is being provisioned, a query will return a message that the key is being provisioned and to wait for that to complete. - After the key has been provisioned, a query returns an error status of 429. This is supposed to mean that the request limit has been exceeded, but this is for the first request after provisioning, so the limit has not been reached. Also, there should be an error message returned, but there is not. Querying the API key status shows no data, just null values for the key request counts. This leads me to believe that there is something broken at WeatherBit.io You can check your API key usage status from a browser with: http://api.weatherbit.io/v2.0/subscription/usage?key=<your api key> My original free account/API key is working fine as long as I stay under the query limits.

Done!

@tmorse305 from the log you posted, Climacell is returning this when the plug-in made the query 'The request limit for this resource has been reached for the current rate limit window. Wait and retry the operation, or examine your API request volume.' There is a limit to how many queries you can make in a given period of time. This limit depends on the plan you are subscribed to. Once you exceed that limit, it stops providing data until the time limit has passed. You control how often the plug-in queries using the short poll and long poll times Short Poll * How often to poll the climacell weather service for current condition data (in seconds). Long Poll * How often to poll the climacell weather service for forecast data (in seconds). Note that the data is only updated every 10 minutes. Setting this to less may result in exceeding the free service rate limit.