bpwwer

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.

There isn't any limit on the number of local sensors that can be configured. set the node server log to debug level and restart the node server. Then PM me the log. I only have one sensor so I don't have any way to test/debug this locally.

It looks like they've completely changed the format of data returned by that query. It's no longer returning the XML data that it used to. It took some digging but I finally found this: https://www.weather.gov/media/notification/pdf_2023_24/scn23-122_atom_feed_transition.pdf Shouldn't be too hard to update the node server.

The plug-in is not getting a response from the robot. Are you sure it's in the charging station and you're able to connect/control from the app?

It's PG3x that sends the commands to the IoX to create the nodes. And the AC reads the info from the IoX. So if there's a problem when PG3x sends the commands to create the nodes, the error should show up in the PG3x log. You can try deleting and reinstalling (or even re-install the plug-in), but the problem doesn't appear to be the plug-in. You can also PM me the log package after restarting the plug-in and I'll take a look at it.

WIZ048 is a valid zone code WIC139 is a valid county code WIZ048/WIC139 is not valid

There should be a debug message before the "? invalid zone" message that shows the actual query request that is being sent. "? invalid zone" is what's is returned by the query which indicates that the zone is invalid. WIZ048 is a valid zone and I don't get that error when I query for that zone (but currently, as you said, there are no alerts for that zone). The query should look like: https://alerts.weather.gov/cap/wwaatmget.php?x=WIZ048&y=1

Please answer my question above. If you have restarted the AC, try restarting both the plug-in and then a minute or so later the AC. As I said, based on the logs and the fact that the nodes are showing up in PG3 means the plug-in is working properly.

That doesn't look like debug information. The errors indicate that whatever the plug-in got, it wasn't something it recognizes. I'd need the see the data from the query which it should show if the log level is set to debug.

Everything in the logs looks correct. The plug-in appears to be working fine based on what's in the log file. Did you restart the AC after the plug-in was fully running? The plug-in builds the nodes dynamically based on the data it sees from AWN. The AC must be restarted after the nodes have been defined since it only reads the node definitions when it starts.

The plug-in sends out broadcast that triggers the Roku devices to respond. When it gets a response, it attempts to query the device for it's specific configuration data (mainly what apps are installed). In this case, that query returned nothing. So if the device at IP address 192.168.2.195 is in fact a Roku device, it is not responding properly.

It queries the Climacell servers for the current conditions using the short poll interval and it queries for forecast data using the long poll interval.

It's already there "Dense Fog Advisory". If it's not working then possibly they've changed the wording so that the parsing is failing. With the log level at debug, what does the plug-in show when that alert comes in?

No, that "error" is just a debug message that I forgot to remove so it's not related to any issues you're seeing. Ideally would be to capture a log with the level set to debug for the time period when it's not updating. It's possible that you've exceeded some query limit and it's simply blocking the query requests. I'm not sure how this service handles it when you go over the limit, they may simply stop allowing queries until the next day or whatever the period that use for checking limits.