bpwwer

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.

If you're talking about the Add Node menu option in the Admin Console, ignore that. It's not used for Polyglot based node servers and won't work. The node server should be detecting all 27 zones and if it's not, then it's probably a problem with the node server and is probably not something you can fix without help from the node server author ( @Goose66 I think). He'll likely need to see the node server log showing it starting. To prepare, you might want to switch the node server log level to debug, restart the node server then download the log package and have it ready. You can also look through the log and see if anything jumps out as a problem. I believe the node server queries the DSC panel for the zone information and then creates nodes for each zone it finds. So it may be throwing errors for zones it is not creating.

PG3 works properly with either HTTP or HTTPS, it automatically detects which protocol, no configuration needed.

I don't understand what you are trying to say. From the two screen shots it looks like the weekly and monthly values are the same on PG3 and ISY which is how it should be. Those values shouldn't be changing unless there is actual rain accumulating (which from the rain rate of 0, it appears it is not). And how are you determining that the data in the ISY is old? What are you comparing it with? Logs are always helpful and in most cases necessary. You can always download the log package and PM it to me and I'll take a look.

Yeah, that makes sense. The plug-in gets the alerts from NOAA and loops through them one-by-one. But since there's only one value for alert in the node, it sets it to each in turn until it gets to the last one on the list. That was just the simplest way to code it. The IoX doesn't support the ability to handle a varying number of alerts like that. If I dynamically created nodes, you wouldn't be able to create programs since you can't create a program for a node that may or may not exist. Nodes have a fixed definition and don't support the ability to have a varying number of values (which again, you wouldn't be able to write programs for).

There can only be one alert at at a time, it's a single value. It's probably something with the programs but I don't know what.

Sure, PM me the log. I might just be something simple that I need to change.

We had a winter storm watch and winter storm warning (for the lake Tahoe area) and those seemed to work fine. So now explain why for every other type of alert there is <alert> watch, <alert> warning, <alert> advisory but for this it is "winter storm watch" "winter storm warning" "winter weather advisory" I've updated the plug-in to use "winter weather advisory" instead of "winter storm advisory"

Thanks for letting me know it works, sorry it took so long to figure out the problem.

I accepted the pull request so it should be updated now. However, I don't own the node server so I can't update the store entry.

I just publish a new version with a change to do the npm install as part of the node server install. If you re-install version 1.0.11 it should work now.