bpwwer

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">

I've looked over the log and this is what it looks like is happening. The outside sensor (local_60 right?) appears to be working correctly. It is getting the data from the sensor and publishing that data when it changes. The inside sensor, local_107, appears to be a different type of sensor and the data that comes back from a query is different. Well, not so much different as missing fields that the node server is expecting. It looks like it's publishing the AQI value for local_107 and that's all, the rest of the data is skipped because of the missing fields. Once the node server publishes the data to PG3x it's basically no longer under the control of the node server. At that point PG3x takes over and passes the data to IoX. If it's not showing up in the Admin Console, that's not something I can debug from the node server logs. You'll have to look at both the PG3x logs and the IoX logs and/or open a support ticket with UDI. You can open the event viewer in the admin console (tools -> diagnostics -> event view) and set the level to 3 and watch to see if it's getting the node updates from PG3x. It's best if you do this with just the one node server enabled and not much else happening otherwise you'd have to wade through a lot of events you don't care about. Configuring my sensor twice would be a good idea except that it uses the IP address as the address and IoX won't allow duplicate node addresses.

I only have one sensor, but when I add it to the node server, it displays information on the Admin Console and updates per the poll time. You can also force it to re-query and re-send the data from the sensor using the "Query" button. Without seeing the logs, I have no idea what is happening on your system.

I believe it is working as intended. IoX doesn't remember the status values when it is restarted and the node server was written to minimize unnecessary updates to IoX. This can result in the behavior you are seeing. The node server publishes a value, say gust speed set to 10mph. IoX sets the gust speed driver to 10. Then you restart IoX and IoX clears out all the previous values so they're all blank The node server makes a query for updated data, but not all the data has changed. If the gust speed is either not present or is still 10mph, the node server won't publish anything for gust speed, but will publish data for all fields that have changed. Until there's a change in the gust speed, the field will remain blank in IoX. Eventually, as the data changes, the blank fields will populate (except for node server on-line as that's only published when the node server is started, stopped, or fails)

From the log, it looks like it was working with both being local. However, it is throwing an error which stops it from processing most of the data fields. This is happening because the PM2.5 values are all zero. I wasn't expecting that. I fixed it and published version 2.1.1.

I wanted to address this separately because there's not a simple (or even a complex) solution to this. Node servers communicate with PG3 via a MQTT connection. The node server publishes updates and PG3 sees those and forwards them to IoX. PG3 does monitor that MQTT connection and if the connection between the node server and the MQTT server drops, PG3 can detect that and (if the node server has configured things properly) it can update IoX with that "connection status". The amount of time between updates from a node server is very node server dependent. One node server may send updates every second while another may send updates every other hour. It can even vary with a node server. Because of this, it's just not practical for PG3 to try and monitor node servers for updates. Also, if the node server encounters a bug and that causes to stop reporting updates, how is it going to send an update to notify PG3 that updates have stopped? I'm not saying this isn't a problem, as it is, but the solution really needs to come from UDI enhancing the node server API with a method to do this.

I'm not sure what you mean by this. The 10 minute poll time for accessing data using the Purple Air API is something Purple Air requires. The node server can't do anything to work around this. Or do you mean that when you're trying to use both the API and the local connection, you can't set the local connection poll time less that what's required for the API access? If so, that's a PG3 restriction, it only provides one short poll interval to the node server. II really need to see debug logs to debug why multiple local sensor configurations aren't working. I didn't not put any restrictions on the number of local sensors intentionally.