vspete

I am pleased to report that so far everything is working perfectly with "SmartZonetracking" enabled. Clearly, based on the offending message, "malformed" is the correct term for this message. What I find interesting is that while the malformed messages are frequent and identical, they do not occur every time a particular set of sensors are triggered or opened individually. What I have observed below seems always to be true: The panel is in a disarmed state An Exit Zone is Open A perimeter zone is open (or opened) AND one (or two) motion detectors are open (simultaneously). What I am not sure of (in addition to the ambiguity described in #3) is whether the malformed message is created during, after, or concurrent with the expiration of the entry delay initiated by opening the Exit Zone. In a disarmed state, the entry delay doesn't mean anything, but I don't know whether it might affect EnvisaLink messaging. I am going to mark this issue as solved. Thanks so much Randy for the effort you have put into addressing this issue.

Thanks for releasing the update. I will install and advise after a few days. Whether the offending data message is "malformed" or "undocumented", ignoring it would seem to be the appropriate solution. I was able to suppress these messages by changing zone #10's type to "interior type". Zone #10 is a perimeter (interior house to garage door) zone physically located between two interior motion zones. This change negatively affects my "stay" security but doesn't adversely affect "away." I will revert #10's zone type to a "perimeter," test the plugin and let you know.

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

I did take a look at the logs, but couldn't discern why certain values were not populating. I decided the best thing to do was do a complete re-install. I removed the node server completely from PG3x and then reinstalled. After restarting the node server and restarting IoX, all fields are now populated for both measurements and forecasts. Only "Climate Coverage" is "blank" in IoX for both Aeris Weather and Forecasts. The GV 11 (Weather) and GV11 (Forecasts) node values are "16" which matches to "blank" in the en_us.txt profile lookup table. It looks like it may be working as expected now. Now that all the fields are populated, I expect they will be updated when changes occur. Thanks for your assistance getting this resolved.

Good advice, thanks Bob. I will review those logs for errors and go from there. As stated previously, I never experienced this issue using the PG2 version of your node server running in a Debian Polyglot v2 VM communicating with a ISY994. This issue has to be an IoX/PG3x thing. I appreciate the time you have taken to answer my questions and confirm that it isn't a node server issue.

Bob, I can see that it is "publishing." However, IoX is not displaying what is "published." Perhaps this is not a node server issue per se. But it is definitely an issue. Aeris Weather is clearly displaying all the data on their site: https://www.pwsweather.com/station/pws/DW3801 The screenshots are what my eISY (IoX) screens looks like. If it isn't a node server issue, it must be an IoX or PG3x issue. Should I raise a trouble ticket with UDI? Thanks again Bob!

Bob, I appreciate that only changes are written. However, after several days certain fields have yet to be populated despite the numerous condition changes that have occurred. Those that are being populated are accurate. Here is the list of non-populating fields: Current weather: Gust Speed; Climate Coverage; Windchill; Precipitation Forecasts: Gust Speed; Precipitation; Chance of Rain; Evapotranspiration During that past few days we have had storms pass through with considerable wind and precipitation. One would expect these values to change. I am also running the Davis Node Server and it is populating all fields without issue. A can also report that this issue was not present when I was running the pg2 versiton of this node server on a different platform. Thanks...

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

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

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

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.

Migrated this node server from PG2 (running in a Debian VM interfaced to isy994i). Never had this issue. Now running the PG3x version on an eISY v5.80 I am experiencing incomplete population of IoX. Looking at the node server logs, the values are being set and appear to be published. See attached screenshot of the admin panel and associated node server log. The node server hasn't been running for very long and IoX was restarted just prior to taking the console screenshot. Also, certain fields in forecast_0 and forecast_1 are not being populated on the IoX screens as well. Thanks for looking into this issue. AERISWeather_2-20-2024_21316_PM.zip

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

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

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.