bpwwer

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?

Version 2.1.3 is in the store now and it should fix the data for the indoor sensor.

I'll take a look at the log, but there's no reason to switch the nodes back and forth, you can separate nodes for the API configured sensors and for the local configured sensors such that you'd end up with 4 nods total. Trying to change the configuration of a node between API and local could lead to issues. The options like "Add All Nodes" on the IoX menu don't work with PG3 based node servers, in fact, I believe those options are completely ignored by PG3 so they shouldn't be doing anything.

I made some changes to the way it handled the data from the indoor sensor so it should work better now. These changes are in version 2.1.2

If the node server was sending values that were outside what's accepted by IoX/AC, it would be a bug in the node server, but the values being published all look correct. It's still possible that IoX is rejecting them for some reason but that should show up in either/or the PG3 log or the IoX error log. I can't debug issues with either of those, just issues with the node server itself. So yes, if you can't find the cause in the logs, then you'll have to submit a ticket to UDI.

You'd have to check the data available from AERIS for your location/station. It may not be providing that data. And like I said in your other thread, once the node server publishes it's data to PG3x, it's out of the node servers control. Looking at your log above I see: 2024-02-20 00:18:27,977 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV14', 'value': '87.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'SPEED', 'value': '6.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GUST', 'value': '11.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'PRECIP', 'value': '0.7', 'uom': 105, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV7', 'value': '9.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV8', 'value': '5.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'POP', 'value': '67.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'UV', 'value': '2.0', 'uom': 71, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV19', 'value': '3', 'uom': 25, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV1', 'value': '54.0', 'uom': 17, 'text': None}]} 2024-022024-02-20 00:18:27,977 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV14', 'value': '87.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'SPEED', 'value': '6.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GUST', 'value': '11.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'PRECIP', 'value': '0.7', 'uom': 105, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV7', 'value': '9.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,978 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV8', 'value': '5.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'POP', 'value': '67.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'UV', 'value': '2.0', 'uom': 71, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV19', 'value': '3', 'uom': 25, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV1', 'value': '54.0', 'uom': 17, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'CLIHUM', 'value': '93.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV14', 'value': '56.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GUST', 'value': '14.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'PRECIP', 'value': '0.2', 'uom': 105, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV7', 'value': '12.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'UV', 'value': '4.0', 'uom': 71, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'ETO', 'value': '0.06', 'uom': 120, 'text': None}]}-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'CLIHUM', 'value': '93.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,979 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV14', 'value': '56.0', 'uom': 22, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GUST', 'value': '14.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'PRECIP', 'value': '0.2', 'uom': 105, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'GV7', 'value': '12.0', 'uom': 48, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'UV', 'value': '4.0', 'uom': 71, 'text': None}]} 2024-02-20 00:18:27,980 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_1', 'driver': 'ETO', 'value': '0.06', 'uom': 120, 'text': None}]} So it appears to be publishing the data for at least some of those items you list.

No, it doesn't support those buttons. The list of buttons/commands it accepts will show up in the list when programming. <cmd id="VOLUME"> <cmd id="SOURCE"> <cmd id="TREBLE"> <cmd id="BASS"> <cmd id="BALANCE"> <cmd id="LOUDNESS"> <cmd id="DND"> <cmd id="PARTY"> <cmd id="MUTE">