bpwwer

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.

Please increase the log level to debug for the node server and try restarting it. It seems like it things some nodes were created but they no longer exist and that's why it reports all those errors. Deleting and re-installing should clear out any old configuration/data, but without seeing the log with debug enabled, it's impossible to tell what is really happening.

No idea what happened. The trial is simply a different license, you get the same plug-in for both the trial and the production version. I'd suggest deleting and then re-installing as it seems confused over what speakers have been discovered.

The last alert in the list is Winter Storm Warning. Winter Storm Watch and Winter Storm Advisory don't (or didn't at the time I last updated the list) exist in the list. I've updated the list in the plug-in based on the latest info from NOAA.

Fixed in version 2.0.5

I agree that it seems like a lot of variance, but I don't know what to do about it. You could play around with how you list your location, that may cause it to use a different station. You could also compare with another service using the other service's website for the data instead of getting another plug-in just to test with.

Have you restarted the admin console since installing the node server? The admin console only reads the node configuration information when it starts so must be restarted after every node server install to see the proper configuration.

Ok, that's different. You didn't have to go through all that before.

So there's a web interface that allows you to set up the listener. That's what I missing. Thanks! I was looking at the mobile app and it didn't seem to have any way to configure that. It's on my list of things to work on. Not sure when I'll get to it, but I'm intrigued so maybe sooner than later.

Update for what? The plug-in works fine with the existing API, I'm using it without any issues.

Looks like that's almost the same as the "local API 1.0", but one pushes data to a web server and the other pulls data from the internal web server. What's not clear from the document you have is how to configure the web server that the gateway will push to. It's not too hard to create a node server that runs a simple web server that would accept and parse the POST data from the gateway

Is this the API that you're using? https://rainforestautomation.com/wp-content/uploads/2017/02/EAGLE-200-Local-API-Manual-v1.0.pdf I've been looking at that and at https://rainforestautomation.com/wp-content/uploads/2015/03/EAGLE_REST_API-1.0.pdf which seems to be cloud based. I don't think either of these were available when I first wrote the plug-in. At least not publicly.

Sorry, I missed removing the offending line from that file. Fixed in 2.0.3