bpwwer

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.

Have you restarted the AC after the plug-in was installed? The AC (not IoX) needs to be restarted after a plug-in is installed for it to understand the new nodes created by the plug-in. The log files are strange, like something is out of sync. The PG3x log ends at 1:11:56pm with the line downloading log. However, the last line in the plug-in's log is at 3:08 and is "invalid API key", and there's nothing after that. Possibly because the log is set to errors only and no errors happen after that. Looks like PG3x is 2 hours behind. I found where the plug-in attempts to create the nodes and it looks like the IoX rejects them with a 404 (not found) error. I don't see anything wrong with what the plug-in is doing, this seems to be something failing in IoX. I'd suggest power cycling and see if that fixes it. If not, you'll have to submit a support ticket to UDI.

It looks like you switched the log level to debug, but didn't wait for a query to happen as there's no query results when in debug in the log snippet above. In most cases, the query failure is related to an invalid API key followed by the location format being incorrect. Your location looks to be correct. Without a complete debug log I can't help.

I suspect that it has something to do with how the Emporia cloud service authenticates and the fact that it is querying a cloud service. This is all happening within the third party library that the plug-in is using to access the cloud service. It looks like for every query, it has to resolve the cloud service host name and because it uses Amazon AWS to authenticate, it needs to resolve the AWS host(s) names as well. The reason why the Vue plug-in seems like it's doing so many more is because it's likely polling much more frequently than any other plug-in. Most plug-ins won't poll a cloud service more than once a minute so that alone accounts for 6x the number DNS queries. Add in that it has to also resolve the AWS name (or names) and that's why it's doing 4 per poll instead of 1 per poll that is more normal.

If you set the log level of the plug-in to debug and look at the log entry for a query, what is OpenWeatherMap returning? It will either return an error (which will point us at what is wrong) or it will return data.

The "No Valid License" is from PG3. All plug-ins require a license to run, even free plug-ins. So at some point you did get a license for plug-in. Probably just a temporary outage when your PG3 tried to verify you had a valid license. API keys from OpenWeatherMap can take as long as 48 hours to become active and work.

Every time I've generated a new key it's been pretty quick to activate. I think the longest I've had to wait has been about 30 minutes. But others have had to wait overnight or longer. Seems strange that they can't activate the key within seconds, but not something I have any control over.

It appears that OpenWeatherMap made changes that broke the requests the plug-in was making to that API. I've updated the plug-in to version 4.0 and changed it to use the OneCall 3.0 API instead of the Professional Collection API.

That's the same as what I did to test. I subscribed to the OneCall 3.0 API, generated a key and changed my configuration to use that key. After a fairly short period of time it started working. How long it takes before the API key starts working is something only OpenWeatherMap can control. Some folks have reported that it has taken a day or two. When the log is set to debug level, any error messages returned by OpenWeatherMap are logged so you can check to see what error is being returned but if it's reporting a 401 (invalid API key), there's nothing I can do about that. If it's some other error related to the formatting of the request, I'll need to see that log and look at what your configuration is doing to generate a bad request.

Version 4.0.0 and later now make use of the OpenWeatherMap OneCall 3.0 API. API keys for previous versions of the API will no longer work with this version (of the API being used and the plug-in). You must subscribe to the OneCall 3.0 API if you have not already done so and generate an API key for this version of the API to use plug-in version 4.0.0 and later.

Create an account on openweathermap.org log in to the account you created. Go to "My Services" from your account menu Go to "Billing Plans" Subscribe to a plan from the Professional Collections Go to "API Keys" Press the "Generate" button to generate a new API key Once you generate the API key, it can take anywhere from 1 to 48 hours before that key is active and usable. Once it has been activated by OpenWeatherMap, it can be used in the plug-in.

The One Call 2.5 API doesn't exist and the plug-in does NOT use the One Call 2.5 or the newer One Call 3.0 API. It uses the Professional Collections API as shown in the screen capture I posted above. If you're subscribed to one of the Professional Collection plans, you should see the following under your account/my services: I'm subscribed to the "free" plan as shown above. I'm able to generate new API keys for this plan and have them work with the plug-in. NOTE: that it can take between 1 and 48 hours for an API key to become active after it has been generated.