bpwwer

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

Yes, it says the API key is invalid. I can't do anything about that as that's OpenWeatherMap reporting that error when that specific key is used. I'm not affiliated with OpenWeatherMap other than having my own account with my own API keys. As the response says, you can check https://openweathermap.org/faq#error401 Which just says: You can get the error 401 in the following cases: You did not specify your API key in API request. Your API key is not activated yet. Within the next couple of hours, it will be activated and ready to use. You are using wrong API key in API request. Please, check your right API key in personal account. You are using a Free subscription and try requesting data available in other subscriptions . For example, 16 days/daily forecast API, any historical weather data, Weather maps 2.0, etc). Please, check your subscription in your personal account. I believe the plug-in is using the "Professional Collections" API, but they've changed the API name/subscriptions since I developed the plug-in.

The "Connected" means that the plug-in is running and is connected to PG3. The most common reason why no data is displayed is because OpenWeatherMap is rejecting the connection attempt from the plug-in. The reason for that will be logged in the plug-in's log if the log is set to debug level logging. OpenWeatherMap has supported a couple of different API's over the past few years and the API keys for them are not interchangeable. It's also possible that the API key's they are now assigning don't work with the API that the plug-in is using. Again, the log on debug may help determine this. Also, the query interval is set to 10 minutes, so make sure you're waiting at least that long for data to populate.

Should be fixed in version 2.0.2. Refresh the store to see the new version. Thanks for reporting the issue.

Maybe now fixed in version 3.1.8

I see the problem. Should be fixed in version 3.1.7. If you refresh the store listing it should show the new version and allow you to reinstall/update. Thanks for reporting the problem.

Are there any warnings or errors in the log? I think the only reason it would be displaying 0 is if something failed in the parsing.

That list is really a list of licenses you've obtained for this instance of Polyglot. For the Notification node server you probably have a license for the free version and a license for the paid version. Because you have a license for the free version, you could install that version too, but there's probably not any good reason to do that. This really should be updated to make things more clear to the user, but the priority has been fairly low.

The number of nodes for a Pico varies depending on the Pico model. For a 3BRL, that's a 3 button with raise/lower and it should have 2 nodes. The main node has the on, off, raise, lower operations associated with it as those are fixed in the Pico design. The second node is for the favorite button and its operation is configurable. For 2B there is only one node that has the on and off operations associated with it. In general, the Pico devices have no status, they are control only devices. The Pico nodes can be used in programs as it can detect the button presses, but there's no "state" saved. I.E. a pico button can not be on or off. There's no ability to query a Pico to see what button was last pressed. The nodes that do have a status, only use that to show how a configurable button is configured in the node, it's not related to any status in the Pico itself.

There are plugins for various personal weather stations and plugins for various weather data services. Since you don't have a personal weather station you're going to want one of the services based plugins. There's AERISWeather, Climacell, NOAA, OpenWeatherMap, and WeatherBit They're all basically the same with slight differences. Your best bet is to first determine what specific weather data you need then go to each service's site and look at what they provide. That information should also be available in the plugin's description. I believe AERISWeather is the only one that doesn't have a free subscription plan. One of the main differences between the various services is how often they allow you to query for the weather data with the free subscriptions and how often they actually update their data.

Does the existing node server not work with the Eagle 3? Does the log show anything useful if it doesn't? I've found two API documents for Rainforest Automation, one specifically for the Eagle-200 and the other is a more generic Eagle API. The current library that I used for the node server is no longer being maintained and appears to use yet another API (not what's documented either of the two documents above). So I think I'd have to write a new node server using the generic API docs. If that API works with the 200, then it might not be too hard, but if it doesn't, it gets a lot harder as I don't have the Eagle 3 hardware to test and debug with. I'll do some testing later, but at this time, I can't really promise anything.

@bigDvette It didn't work. I'm not sure what you did but the first commit in the changes looks like they were applied to the PG2 version of the code and you ended up checking in a lot of the conflicts. The second commit looks like it tried to clean some of that up. I pulled what you had in git and manually applied it along with a small fix to the README changes. I did notice a couple things I think you need to check/verify. Some of the issues seem to be related to my initial port to PG3. 1) I think the readme needs some additional changes to be correct. For example, without a controller node, the only discover button will be in the PG3 node details (which currently isn't enabled). So I don't think there's any way to call discover manually. If you want the ability to call discover manually we'll need to make other changes. 2) There might be a race condition in the new parameter handling. It's possible that the CUSTOMPARAM event will happen after the discover() function has run. At startup, it's probably unlikely, but it is possible. I typically have the CUSTOMPARAM handler call the discover() function so that I first verify that I have the parameters. Also, since the user can edit/add/delete custom parameters at any time, the node server needs to update when those changes are made. The master branch of UniversalDevicesInc-PG3/udi-sonos-poly has your changes so you can pull that again and make changes on top of that. Also, now that it has parameters, there should be a POLYGLOT_CONFIG.md file that provides info on what those parameters are and how they should be set (similar to what's the README file).

From the admin console go to the Node Severs menu -> Configure -> slot 1-20 -> [pick a slot with an unmanaged node server] You'll get a dialog box with a delete button. Use that. Do that for all of the unmanaged node servers and after about 5 minutes they should all be gone from the PG3x dashboard. "Unmanaged" means that PG3x doesn't have those installed and can't control them in any way. They were installed by a different instance of polyglot.

In the plug-in configuration there are two settings - short poll and long poll. Most likely it is the short poll that is too small of a value and causing the plug-in to make more calls to the API than Govee allows. The short poll interval is in seconds. So if set to 300 the API is queried every 5 minute.