bpwwer

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.

If you're signed in, you should see something like this: Then going to "Billing plans" will show which plan(s) you're subscribed to and "API Keys" will let you generate keys for the plan(s) you're subscribed to.

No, that log doesn't help at all. You need to provide the plug-in log, not the IoX log. But, I'll re-iterate, the plug-in only works with the Professional Collections API, NOT the One Call (either 3.0 or 2.5) API. Once an API key is generated for your OpenWeatherMap account, it can take anywhere from 1 to 48 hours before it becomes active.

If they show up in the PG3 interface, first try deleting them there. That should delete them in PG3 and IoX. If they're not in the PG3 interface, but just the IoX, then delete them from the admin console.

The One Call 2.5 API being closed has no effect on the OpenWeatherMap plug-in. The Plug-in is using the current weather/forecast API from the their Professional Collection of API's.

Do you mean that the value is empty or that it doesn't exist? In the PG3 node list for the plug-in, it should show up like this: In the admin console, it's the second to last entry, followed by battery voltage. Make sure your admin console window is large enough to show all the values, it will truncate those that don't fit in the current window size (no scaling or scrolling in the AC).

No need, it doesn't work locally with eisy wireless. The wireless network is a different subnet internally on the eisy.

@Morris Hansen It's hard to draw any conclusions from that log. The Tempest hub sends out data packets every 60 seconds. The log shows that the plug-in starts listening from those at 1:45:11pm and the last entry is at 1:45:15, 4 seconds later. Without knowing how long you waited before downloading the log it could be that you downloaded the log before the Tempest hub sent an update or if it was sitting for while without any log updates, it could be that something is blocking the plug-in from seeing the Tempest hub data. The Tempest hub sends out UDP packets using port 50222. UDP packets won't typically cross subnet boundaries so if the hub is on a different subnet form the eisy/Polisy, then it won't work. If you have some firewall rule that blocks UDP packets then it won't work.

That's a lot more helpful. It seems to be your Tempest is not sending data to WeatherFlow. Running the query the plug-in is making, all the data coming back looks like this: [1712062080,null,null,null,null,20,null,null,null,null,null,null,0,0,0,0,2.39,1,0,0,0,0] All those 'null' fields should have actual data. The structure of the returned data is: timestamp = 1712062080 Wind lull = null Wind Speed = null Wind Gusts = null wind Direction = null Wind sampele interval = 20 Pressure = null Temperature = null Humidity = null Illumination = null UV Index = null Solar Radiation = null Rain = 0 precipitation type = 0 Lightning striks = 0 Lightning distance = 0 Battery = 2.39 volts Reporting interval = 1 This is why the plug-in is showing all those errors (It does't like null values) and why you're not seeing any data. There's no data to show.

I really need to see the debug log after restarting the plug-in. However, from the log, it looks like it's getting a response but all the values are "None" instead of actual numeric values. I can't really tell if it's getting the response from the local hub or the WeatherFlow servers or both. Given that it seems to be invalid data being received from WeatherFlow, it doesn't seem like it has anything to do with the IoX update.

It's failing with "Invalid API key. Please see https://openweathermap.org/faq#error401 for more info." OpenWeatherMap has multiple types of subscription plans and the API keys for the different types of plans aren't interchangeable. The OpenWeatherMap plug-in was written to use the plans that are under the "Professional Collection". It won't work with API keys for the "One Call API 3.0" subscription plan. I suspect that your key is for this plan. The other thing that causes issues is that when you request an API key, it doesn't immediately become active. They say it can take a few hours. In some cases, it seems that "few" can translate to over 24 hours.

Switch to debug level logging and then wait a few minutes or restart the plug-in. Then download the log package and PM it to me.

Anything that blocks network broadcasts. I don't know anything about pfSense or Unifi

The auto-discovery is done using a network broadcast and waiting for the devices to respond. How well it works is dependent on how your network/router is set up. I have one room set up with MagicHome bulbs so I have a vested interest in making sure the node server/plugin works. However, I don't upgrade my Polisy/PG3 unless I think the upgrade will fix something. If it's not broken, I tend to leave it alone. Thus, I'm not running the latest version of PG3 so I don't know if that broke something.

There's a type called "SerenaRollerShade" that is supported but I don't have those so I have not personally tested them. If the shades are controllable via the Lutron App/Caseta smartbridge, then I can add support for them if the existing node server doesn't work for some reason.

I've looked into this more and it's not so simple. If I switch the plug-in to use the 3.0 API version, the API keys for my existing subscription don't work. I have to get a new 3.0 subscription. So releasing this would cause all existing user's installation to break and they would need to get a new subscription. I don't have a good way to notify existing users that an upgrade of the plug-in will break their installation so I'm very hesitant to do this. My subscription is the free professional collection plan. Generating a new key for that subscription still works with the existing version. Are you sure an API key for a professional collection plan isn't working for you? They do say it can take a few hours for the API key to become active.

I didn't know that. It seems like that's a recent thing as I believe it was working just last month. I'll update the plug-in shortly.

You don't want the 3.0 one call API. You want an API key for one of the professional plans at https://openweathermap.org/price