bpwwer

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.

I'm not sure why you tagged me for this. It sounds like this is about the Notification plug-in which was authored by @Jimbo.Automates

Did version 2.0.12 work for you?

@SHM Ambient's API is not very easy to work with. They tend to simply add data fields to the query results as by new hardware and don't document it very well. There's also no versioning. So stuff just suddenly appears. There's also no way to know what data fields will be present because they don't provide any type of mapping from a hardware type to data fields. Given the number of different stations and sensors that are available there are way too many combinations to try and have pre-defined node definitions for each. So the plug-in looks at the data fields and dynamically creates node definitions to match what's being sent. There are (again, not well defined) rules they mostly use for naming conventions. Like the field name will end in 'in' if it is a field for an indoor sensor. All this is to say that plug-in is really just making guesses at what it should be creating. Your station is the first one that has had a field called 'windgustdir'. Many stations have a field called 'windgustmph' and given that Ambient could start using 'windgustkph' or 'windgustms' at any time to represent wind gust speed in different units, the plug-in simply looked for a field that started with 'windgust'. Thus the plug-in thought your station was reporting two windgust speed fields and the AC fails when there are two fields with the same type. I've modified the plug-in to recognize 'windgustdir' as a wind direction field and create the appropriate node value for that. It should work for you now. The new version is 2.0.12

@Mike Carron You are missing the 'Units' parameter. It appears to be missing entirely, which is strange because the install should set that to a default value.

plug-in details for the OpenWeatherMap plug-in, log, download log package.

Sorry, I should have been more explicated about what I wanted. I was looking for the plug-in log package that included the plug-in starting after you power cycled the eisy. I want to see what's happening when both PG3x and the plug-in start.

That still looks very wrong. Can you download a log package and either pm it to me or attach it here.

@Mike Carron Something is really wrong with that log info. How many queries did you do? It shows 5 in that small bit of log. Also, it's not showing any of the log messages that I would expect at debug level for a query. I'd suggest power cycling the eisy and see if that helps.

version 4.0 of the plug-in uses the One Call 3.0 API and requires a subscription to the One Call 3.0 API. Previous version used a different version of the API that is no longer supported by OpenWeatherMap. The One Call 3.0 API allows for 1000 calls per day and if you exceed that, they will charge you. I don't believe you can sign up for a subscription without providing a payment method any longer.

The AC is just an app, you exit and then re-launch. However, that won't effect IoX, when you restart IoX from configuration section, I don't know if that re-launches the AC or not. Because you're seeing 404 errors when PG3 asks the IoX to create nodes, it means something isn't working right on the box. That issue may also prevent IoX from restarting from AC so I recommend you power cycle the box to force it to restart. If that doesn't work, you'll need to submit a ticket to UDI.