bpwwer

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.

If you don't mind, what was the fix?

I really thought most of those steps would be obvious which I guess explains why I suck at creating documentation. I do tend to assume that stuff that is obvious to me is also going to be obvious to others and that's a bad assumption to make when creating documentation. @DennisC I think that having a zoom session (or sessions) is a great idea. @bmercier is this something you would be able to do?

I have the same problem with my Fedora Linux system after a recent system update. Same behavior where it launches but something fails and I get no admin console. My work-a-round at this point is to download the admin.jnlp directly from the eisy and launch it from within the web browser (I'm using Opera). To download it from the eisy use http://<your eisy ip address>:8080/admin.jnlp You can also get to it by going to http://<your eisy ip address>:8080/WEB/had.htm clicking on the admin tab and then selecting "Admin Console"

This looks like it happened during device discovery. If device discovery fails, the node server will simply give up. The most common reason it would fail there is because the username/password isn't working and it doesn't really make any sense to keep re-trying. So in the case where the service is down and the node server tries to start, you will need to restart the node server after the service is back available. That's pretty much by design. All of the actual authentication is handled within the third party library that the node server uses. I'm not sure if that can handle the service going down or not.

And that's not really a question for me. The networking setup on UDI controllers is outside my area of expertise. You're not the only one that has experienced issues that appear to be network related. There is an effort to try and track down what's causing some of these types of issues. For example, there's an issue that can show up if you've ever had wi-fi configured on the eisy but use wired ethernet and for some reason the ethernet cable is disconnected. It will cause the whole networking subsystem on the eisy to reset which forces all network connections to close. That's probably not what's happening here. But even brief Internet interruptions can have effects on the other, seemingly unrelated operations.

@DennisC It's not really clear to me what you think is missing which is probably why I've never created what you need. To me, creating a node server is basically the same process as creating a Linux kernel driver or creating a phone app or creating any type of software. There's nothing really special about node server development which is why I don't really know how to answer what steps need to be completed. For me, it starts with wanting a node server for some device/service so I start with what I want. Step 2 is to come up with the design, how do I want the node server to work and interact with the user and the device/service. (this is mostly done in my head). Step 3 is copy most of the files from another node server as many of the required files are common. I think modify the ones that need modifying (README.md, POLYGLOT_CONFIG.md, etc.). Step 4 is to create a git repository and check in these basic files. Step 5 is to do all the coding to get the basic node server working. Step 6 is to create a local store entry for the node server Step 7 is to install the node server and start testing. Step 8 is to debug/test/enhance the node server, going back to step 7 and repeating this until it is fully working. Step 9 is to determine how I want to release it (packaged in a .zip file or via github) Step 10 is to create the production store entry and publish that posting anything that needs posting in the forum about it. Is that helpful? To me it doesn't seem like it would be but I could be wrong. And this is just how I generally proceed, it sometimes varies. Others probably have a different set of steps. Details on what's actually needed for some of the steps are in the developer's documentation which does tend to focus on creating the store entries and what's needed code wise. If you're asking more about how to set up a development environment on the Polisy, that goes back to what I was trying to explain above, it's really a personal choice so there's no one answer. You'll likely get very different answers from the different developers. I know the way I set up my environment is very different from the way @Jimbo.Automates sets up his. I keep everything on the Polisy and I use command line tools like git/vim pretty much exclusively while others will use a Windows machine running some IDE like pycharm and allowing the Polisy to access the files via SAMBA. Some HA systems use a specific development environment. HomeSeer for example mostly requires that you use Visual Studio as the plug-ins are developed using .NET. But even there, that's about as much info as you'll find for getting started creating HomeSeer plug-ins. @sjpbailey's videos can be very helpful, but keep in mind that that's only showing the processes he's using, not what everyone uses so it can be hard for anyone else to help if you have questions about things that are being done in the videos.

Thanks @sjpbailey for creating and posting the videos. Creating content like that takes a lot of work. For software developers, developing plug-ins (node servers) should be fairly straight forward. And like most software development, there isn't one way to go about it and not even one "best" way to go about it. A software developer figures out what type of environment works best for them and adapts it to work for PG3 plug-in development. However, when a non software developer (someone who doesn't have any real world experience developing software) wants to create a PG3 plug-in, it can get confusing very quickly. They'll get conflicting information because all the existing developers do things differently. They not only have to figure how to create a plug-in, but they may have to learn a new programming language. They may have to learn what a source control repository is and how it works. They may have to learn how to use an IDE. It's a lot all at once. I've been doing professional software development for about 40 years now. I've worked on drivers for the Linux kernel for a number of years. So I have processes, tools, development environments that I've tweaked for many years and lot of the stuff is just second nature to me. When I explain how I work to someone just starting out, it will typically just confuse them as it's hard for me to articulate all the steps I go through without really having to think about them. I've tried to create documentation and even a tutorial for plug-in development, but it seems like nobody reads any of that because I keep seeing questions in the developer discord that are answered in the documentation. I haven't created a step by step guide because, as I said, I don't think anyone would find it that helpful. For example, @sjpbailey's step one video above is usually my last step in creating a plugin. For me, github isn't really part of the development process, it's an off-site backup solution.

It seemed to be some type of network issue. At the time it locked up, the node server was also disconnected from PG3. It was able to re-establish the connection to PG3, but the network connection to the Russound was never reported as disconnected so as far as the node server was concerned, it was still connected.