bpwwer

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.

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.