Connecting to more than one sensor locally?

[vspete]

Hi @bpwwer, I recently updated to the PG3x version of this node server and observed that I can use my sensor's local IP addresses in lieu of API calls to Purple Air's servers.  I would like to do this for both of my sensors.

When i attempt to use local IP's for both, only one of the sensors is being updated. I can use a local for one and access PurpleAir for the other.  This seems strange, can you confirm that it is not possible to locally connect to more than one sensor?  Thanks in advance...

[bpwwer]

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.

[dbuss]

On 2/17/2024 at 12:36 PM, vspete said:

Hi @bpwwer, I recently updated to the PG3x version of this node server and observed that I can use my sensor's local IP addresses in lieu of API calls to Purple Air's servers.  I would like to do this for both of my sensors.

When i attempt to use local IP's for both, only one of the sensors is being updated. I can use a local for one and access PurpleAir for the other.  This seems strange, can you confirm that it is not possible to locally connect to more than one sensor?  Thanks in advance...

Mine do the same thing. Only one local will connect at a time.

[vspete]

2 hours ago, dbuss said:

Mine do the same thing. Only one local will connect at a time.

My issue with this is that I am unable to reduce the shortpoll time below 10 minutes (600 seconds) to remain compliant with PurpleAir API polling restrictions. I hope that this can be addressed.

I will also comment about node servers in general: It is my observation that they are not robust in reporting that they have stopped updating IoX.  They just stop and the only way to see if they are running is to look at the log and observe that IoX updates are actually happening. To do this requires monitoring the log in debug mode.  For the Purple Air node server that means opening the log and watching it for 10 minutes.  Or doing a restart just in case.  I am not saying there is a particular issue with the PurpleAir node server, it seems to be the case with generally.  The node server reports whether or not it is connected to the eISY, but not whether its program is updating its nodes.

[bpwwer]

3 hours ago, vspete said:

My issue with this is that I am unable to reduce the shortpoll time below 10 minutes (600 seconds) to remain compliant with PurpleAir API polling restrictions. I hope that this can be addressed.

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.

[bpwwer]

3 hours ago, vspete said:

I will also comment about node servers in general: It is my observation that they are not robust in reporting that they have stopped updating IoX.  They just stop and the only way to see if they are running is to look at the log and observe that IoX updates are actually happening. To do this requires monitoring the log in debug mode.  For the Purple Air node server that means opening the log and watching it for 10 minutes.  Or doing a restart just in case.  I am not saying there is a particular issue with the PurpleAir node server, it seems to be the case with generally.  The node server reports whether or not it is connected to the eISY, but not whether its program is updating its nodes.

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.

[vspete]

18 hours ago, bpwwer said:

I 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.

Attached is the node server's log file and my sensor information.  API key has been redacted. Initially both sensors were configured with their local addresses. To my knowledge only Local-60 would report information. When both were configured to use the API, they both reported.  The final log reports were with "outside" using Local-60 and "inside" using the API.  This configuration seems to report both sensors.

I appreciate your taking a look at the log.

PurpleAir_2-20-2024_124036_PM.zip

[vspete]

18 hours ago, bpwwer said:

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.

Thanks Bob, for providing this insight. I have not attempted to write a node server so I am not familiar with the messaging relationships between IoX and PG3x or what support might be available for error communication (outside of logging) for that matter. 

I have noticed that UDI does not wish to provide an ability to automatically restart node servers periodically due to a belief that it is the node server's responsibility to handle any errors. Thank goodness, UDI mobile does provide the ability to restart individual node servers without having to launch the admin console.

I am currently waiting for another node server to be fixed where the node server in question stops updating IoX when it receives a message that the node server wasn't anticipating and therefore believes it to be "malformed." When that occurs the node server stops updating IoX and no one knows there is a problem until something that worked suddenly stops working.  All automation using that node server is down until that node server is restarted. 

It would seem there are many reasons this situation might occur when a node server is attempting to interact with a third party device or service. API's can change even slightly or might be incomplete (contain undocumented messages). 

In my case, by studying the logs, I can find a unique sequence of events that causes the error and could write some IoX code to restart the node server when that sequence occurs, if a node server restart command was available.

That would certainly help take the pressure off node server developers to respond quickly to this type of issue.  Just a thought...  Thanks again for creating many useful node servers..

[bpwwer]

5 hours ago, vspete said:

Attached is the node server's log file and my sensor information.  API key has been redacted. Initially both sensors were configured with their local addresses. To my knowledge only Local-60 would report information. When both were configured to use the API, they both reported.  The final log reports were with "outside" using Local-60 and "inside" using the API.  This configuration seems to report both sensors.

I appreciate your taking a look at the log.

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.

[vspete]

15 hours ago, bpwwer said:

I fixed it and published version 2.1.1.

I just updated to 2.1.1 and set both sensors to their local ips.  I restarted the node server and restarted IoX. When looking at the admin console there were no values being received by IoX (all fields blank for both sensors).  I looked at the node server log in realtime and didn't see any errors being thrown. I replaced the local Ips with their sensor numbers and the admin console immediately began showing values in all fields for both sensors.  Hope this helps some.

[bpwwer]

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.

[vspete]

1 hour ago, bpwwer said:

Without seeing the logs, I have no idea what is happening on your system.

I will pull logs and send tomorrow.  I currently set both sensors back to use the API. All is now working.  I did try a couple of other things before giving up. 1) I set both sensors to use local addresses; 2) I removed the APIKey field; 3) I rebooted the entire platform.

When I fired up the admin console all fields were blank for both sensors. I looked at the log and it showed that local_60 was setting values, but there was no sign that local_107 was doing anything.  I next looked at the nodes themselves they were populated but they showed the sensor numbers as the node addresses (this shouldn't be). They were not updated when the configuration was changed.  I thought that they might have been held in cache, but given the entire system, including PG3x was rebooted, that shouldn't (couldn't?) have been the case.  My guess is these addresses didn't get changed when the configuration was changed to use local IPs. I cannot tell if the data being set in the logs is fresh or not.

I understand you not being able to replicate the two local sensor configuration.  If you wish, please propose configuration variants you would like me to try and I will annotate the log file where the configurations were changed.  Will get that done in the morning.  Thanks again...

[vspete]

Attached is today's file.  There were numerous configuration changes in an attempt to isolate the issue. These are not annotated, so I will start clean tomorrow and annotate when any changes are implemented.

PurpleAir_2-21-2024_14557_PM.zip

[vspete]

Good morning @bpwwer, attached is the log file from this morning.  I have observed that despite restarting IoX and the node server, configuration values are not completely reset to new values.  The node server and IoX retain the old API node addresses even though these have been replaced by local addresses. If IoX is restarted AND the configuration includes only local addresses AND the APIKey has been removed; all fields are blank in the administrative console.  I have never seen an administrative console screen or node server node listing that shows local_60 and local_107 has the node names.

Given you have only one local sensor, you might try using the same local IP address for both sensors in your configuration and see what happens.  Just a thought.  Thanks again..

PurpleAir_2-22-2024_94007_AM.zip

[bpwwer]

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.

[bpwwer]

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

[vspete]

I re-installed the node server to update to 2.1.2.  The node server added two additional nodes named inside and outside linked to local_107 and local_60 respectively.  I performed and "add all nodes" in IoX and the two new nodes were created in IoX.  These new nodes were not populating correctly and I decided things were not updating correctly, so I decided it was getting too difficult to troubleshoot.  The best path forward seemed to be to start with a clean install.

I deleted the node server from PG3x and installed the node server into a different slot (just to be safe). I only specified the local IP addresses and restarted both the node server and IoX.  The Local_60 sensor populated its screen, however, Local_107 did not populate correctly (many fields were blank and others were just wrong). I had started the ISY event monitor and have included the slot 5 results in the archive.  The included debug log is for the clean re-install.

After collecting the attached log information, I added the API key and returned the sensors to their API addresses and the node server is now reporting complete and accurate information.

PurpleAir_2-24-2024_101913_AM.zip

[bpwwer]

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.

 

[bpwwer]

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