bpwwer

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.

Yeah, the helper node-sonos-http-api program isn't running. My guess would be that it didn't get installed properly but there's nothing I can do to check that. Someone from UDI would have to remotely access your system and check the install logs.

Only in that it does show there was an error parsing the alert. The logging needs to be at debug level to show what the alert looked like so I can figure out why it got the error parsing it.

Looks like that worked. I've changed the node server to use that instead. Version 2.0.2 has been pushed to the store.

It looks like they're using the NOAA weather alert system (same as the NOAA node server). However, it doesn't look like WeatherFlow is making that data available via their API.

Looks like they've changed what's allowed with the free plan. That did work at one time. If you can, do a quick test for me. Use the same URL, but change the "timesteps=5m" to "timesteps=current" and see if that works.

That log shows this: 'Connection aborted.', RemoteDisconnected('Remote end closed connection without response') Which is saying the NOAA server simply dropped the network connection without sending any data. However, it still doesn't look like you debug log level enabled as there's no debug log entries.

Alerts are difficult to test and where I'm at, we rarely get any at all. Since the node server has to parse the alert info that comes from NOAA, it's possible that I'm not parsing out that specific event correctly. I based the parsing on the info I got from the NOAA site but I'd have to see the debug output of the node server for that event in order to check it.

Looking back at the changes, I don't see anything that would have made the nodes created by the PG3 version different from those created by the PG2 version. I suspect that something happened during the migration and it marked the programs that way. I don't know if there's a way to fix that or not, I'd suggest opening a support ticket with UDI.

You'll have to be more specific about what you mean. When I look at my station(s) I don't see anything I would consider a weather alert. There doesn't appear to be anything referencing any type of alert in the API documentation.

I have "ownership" of the Sonos NS as well. The original author abandoned it and I converted it to work with PG3. But, since I don't have any Sonos devices, I'm only able to provide limited support and can't really make enhancements. If someone else does want to take over updating and supporting it, they can contact me about doing so.

There's one more thing you can try. I posted an update to your ticket and I'll copy the same here. When the node server is installed, it should download the node-sonos-http-api package and install it in the node server's home directory. Then when the node server starts, the first thing it does is spawn a process to run node-sonos-http-api. If that process isn't running, the node server will not be able to discover any speakers and will not create any nodes. You can verify that the node-sonos-http-api process is running with a web browser or from the Polisy command line. From a web browser http://<polisy_ip_address>:5005 On my system I get the following response: Which seem correct given that I don't have Sonos devices. From the Polisy command line, running "ps auxww | grep sonos" should show node-sonos-http-api is running. If the helper is not starting/running, I would suggest deleting the node server and then do a fresh install of the node server. If that doesn't work, UDI will have to review the installation logs and investigate why the helper isn't starting.

Set the log level to debug and see what shows up. The above log doesn't show any errors.

Yes, I own the repository. And I can grant permissions to it, but because of the way PG3 works, I either have to update the store entry or hand that off to someone else as only one person can "own" the store entry. There are a number of node servers, like this one where the original author simply abandoned them. I did the conversions to make them work on PG3 but beyond that, I can't really update/improve or even really debug them. You should be able to make pull requests, there's nothing in the repository that would prevent that. You should be able to fork the repository, make changes to your fork and start a pull request for those changes.

No, you can't create the nodes manually. It's strange that it does seem to get updates from the speakers but can't seem to discover them to create the nodes. I don't have any Sonos devices and took over the node server so that it wouldn't get removed but I don't really have any way to test things. It should be starting another process that handles the communication and discovery and maybe it's not running? I see the same type of behavior but since I don't have anything that can be discovered, I expect that. In the log it shows: 2023-12-30 14:33:35 info: NS: Discovering 2023-12-30 14:33:35 error: NS: undefined 2023-12-30 14:33:35 info: NS: No Zones Discovered And the second line "NS: undefined" seems to be saying it's not getting a proper response from the helper program that discovers the speakers. There are quite a few other folks that run this node server but I don't have access to the names of those that have purchased it.

After reviewing the log, the code and running various experiments. It appears that it is unable to discover any speakers on the network. There doesn't appear to be anything wrong with the plug-in. Based on the nodes not found messages, it looks like it did discover speakers at one time but that it can no longer see them.