bpwwer

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.

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.

@bigDvette If you can send me a pull request via github, I can merge your changes and release a new version of the pug-in. As an alternative, you can PM the file.

Version 3.1.6 adds the icon url

UOM 25 allows us to have number -> text mappings. The node server sends that mapping to IoX when it starts, but IoX will only read the mapping when it starts. So initially the order needs to be: 1. node server send mapping to IoX 2. IoX reads all mappings (for all node servers) into memory This only needs to happen once for each node server that sends mappings. Once the node server has sent the mappings (at least once), IoX will be able to read the mapping every time IoX is restarted (or the system is restarted). Note that the Admin Console is the same in that it needs to be restarted to read the same mappings.

The short answers are no but that's not very helpful. The formatted values are set by the IoX and this is one of the quirks of it. After installing the node server, you have to restart IoX before it will send out the formatted values that are text based. It's not something the node server can control, but at least the solution is fairly simple. For the second question. First, that's a great idea but not currently possible. The poll values are really PG3(x) configuration values for the node server in that slot. That's why they're separated out from the other configuration parameters. So again, the node server doesn't control the poll intervals, PG3(x) does. Having a polling schedule vs. just the two values is a great idea, but that's something UDI would have to add to PG3(x).

Download the log package and send it to me in a PM.