bpwwer

@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.

I did update some of the UOM's now that UDI added them to more recent IoX firmware. I sent a message back to PurpleAir too. I was kind of annoyed that they implemented the points system, then after a few months say oh, by the way, we're going to start charging for points now that you've used half of the "free" points we gave you to start. Oh and did we forget to tell you about how optimize you're queries? It feels like this points system is overly complex and I can't really see it generating much income if sensor owners really won't have pay for points.

zone 127 is some special zone that the node server doesn't care about. The error message is triggered when the node server sees a zone number that isn't an actual zone (1-6 or 1-8 depending on the controller). But the controller uses these virtual or fake zones to send messages for keypads, etc. So, yes, the node server simply ignore those messages instead of logging an error, but i'm lazy and didn't bother to add a condition to check for that.

Yes, it wasn't persistent by design. The logging levels for PG3 were never meant to match the levels being used by plug-ins (node servers). The default (info) level is meant to provide a reasonable detail of what PG3 is doing. This level typically provides enough detail to allow us to understand what's happening when a user submits the log as part of a ticket. In many cases, having that level of detail for the entire day is very helpful. Having the log level set to warnings/errors will not, in most cases, provide enough detail to resolve issues and is not really useful from a support perspective. These levels are available mostly because the logging library being used has them by default. The debug level and db operations level generate too much log info to be generally useful. There are some specific cases where seeing that can help and in those cases, the user would only need to set it to levels when told to by a support person. Also, leaving it set to db operations level could end up filling up the available disk space fairly quickly. In my opinion, having it be persistent is a bad idea.

Version 2.1.0 of the PurpleAir plug-in is now in the plug-in store. This version adds the ability to configure the plug-in to query the sensor directly instead of using the API to query the cloud servers. I also optimized the API call to just request the fields being used.

They've been using the points system for quite a while now. Seems like a good way to annoy customers to me. There's a way to access the sensors locally without using their API and cloud services, it's on my list to change the plug-in to use local access instead of the API access. Not sure yet when I'll get to it though.

Looks like a network issue of some kind. The node server was disconnected from PG3 but it recovered. So it probably also lost the connection to the Russound but that didn't recover.

What is the plug-in that I highlighted in bold? That plug-in seems to be what is causing all the CPU usage. Also, it's username seems wrong. The username should be the Polisy's uuid_slot for the plug-in. Top only displays part of the username, but all plug-ins should have the same uuid with just the slot part different. For the two you show, the uuid portion is very different.

Someday I'll purchase a RA3 processes and some devices so that I can make sure the plug-in works with it. But I don't know when yet.

The node server is not responsible for updating the status in the AC. When you stop the node server it is no longer running and is no longer able to send status updates. PG3 is what sends the status update to the AC

Thanks! I'm glad that it's useful.

The PG3 Caseta plug-in for eisy/Polisy may work with RA3. As I said before the library that it uses does have support for RA3, but I don't have a processor or any RA3 specific devices to test with. The plug-in does try to provide generic support for devices it doesn't have identified support for so most non-caseta devices should fall into that category. It also tries to provide enough information about those devices so that I can then add specific support for them. There is a trial period where you can try the plug-in. If it seems like it might work for you, I'm willing to work with you to add the RA2/RA3 devices. You would need to migrate from the ISY to a Polisy or eisy so that may not be something you want to do if you're not sure you want to stick with the UDI ecosystem.

I agree with what @xlurkr says about Home Assistant so it's worth checking into. While it may be possible to convert the PG2 RA2 node server to PG3, it's hard to support without an RA2 setup. I only have a Caseta bridge and Caseta devices, no RA2 or RA3 stuff.