bpwwer

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.

First, I don't agree with your assumption that there's "rapid industry shift away from FreeBSD". FreeBSD has been around for a long time and while it may be that the number of FreeBSD installations vs. Linux is significantly less, and has been and continues to decrease of time. It's not a "rapid" shift. Second, the eisy (or really the IoX software stack) is not tied so intimately with FreeBSD that it can't be moved to Linux if/when the time comes that FreeBSD is no longer a viable solution. It's not obvious, but the wireless network stack on the eisy is running on a Linux VM. UDI chose FreeBSD over Linux for a few reasons. Michel would be able to enumerate those but one of the main ones is that FreeBSD tends to be more stable over time than Linux (at least mainstream Linux distributions like Fedora and Ubuntu).

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

I don't have an Ambient Weather station myself so all of the node server development was done using data from other people's stations. I had to have them provide me with an API key to do that development. I have not looked into Lacrosse stations, I've seen them, but know nothing about them. A quick search and don't find anything documenting an API to get data from Lacrosse stations.

Node server authors don't have access to the licenses or the licensing mechanism. Only UDI can look at or investigate licensing issues so you may have to submit a ticket. PG3 is getting a 403 (forbidden) error when it queries the UDI portal for the license information. So that's either because you aren't logged into the portal or something is wrong on the portal end. I'd first try logging out from PG3 and then logging back in. If it still doesn't work, you'll have to submit a ticket.

First, there should be almost no reason to reboot the box after reinstalling the plug-in. During plug-in development I may delete/re-install a plug-in 10's maybe even a hundred times without ever rebooting. Don't confuse rebooting with restarting the AC. After first installing a plug-in (any plug-in) you do need to restart the AC so it can read the files that the plug-in sent to the IoX. You may have to restart the AC after a re-install if any of those files have changed (which is more likely with an upgrade than with just a re-install). Will rebooting the box cause the UDX service to fail? Not normally. However, if you don't wait long enough (and that time could vary) after rebooting, then you could have attempted to delete the plug-in before the UDX service was fully started which would also give the timeout error. Given the additional info the time that's elapsed, it's probably not worth submitting a ticket at this time. However, if you have the same issue in the future, please do.

Possibly. The plug-in is specifically for Ambient Weather personal weather stations. So you need to either have a station of your own or have someone with a station grant you access to their data via the API. You aren't allowed to use the API to query stations you have not been given access to by the station owner. That's an Ambient Weather policy. To do this, the station owner would have to provide you with an API key to use.

Just for future reference and to maybe help others. A timeout like that in PG3 means that it's likely the UDX service on the box has failed. The UDX service is what's used to do reboots from the AC (along with a lot of other things). Thus, the only real solution to a failed UDX service is to power cycle the box. UDI may be interested to know why it failed, so if you have the time to work with them, submitting a ticket so they can look in to the reason for the failure may help prevent other failures in the future.

Somewhere in your account management section. I don't have access to check myself.

Nothing in the plug-in was changed, it was only an entry in the store record that tells PG3 to allow access to the IoX for this plug-in.

You have to wait for it to actually query before that will show up in the log. Once set to debug level, wait for at least the short poll time and then dlownload the log (download log button in PG3) and PM that file to me.

The error it's getting means that the weatherbit server is not returning any data based on the query that you are making. If you set the log level to debug, it will show the actual query being made and you can cut and paste that query into a browser and see what weatherbit is actually returning (likely some error). The most likely causes are either the location is not valid, or the api key is not valid or you've exceeded the number of queries you can make per your subscription plan.

What does the weatherbit log file show?