bpwwer

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.

Probably, since that's the error that was being returned by their API.

That says that you've exceeded the number of calls you can make to the API. You'll probably have to adjust the poll intervals so that you don't exceed the limits. You can read about the limits here: https://govee-public.s3.amazonaws.com/developer-docs/GoveeDeveloperAPIReference.pdf If you enabled debug logging, it might provide more information about the limits in the log, I'm not sure.

It looks like the username or password is wrong: 401 Client Error: Unauthorized for url: https://api.emporiaenergy.com/AppAPI

I believe you can integrate RA3 with an existing RA2 system but you may have issues integrating with anything else. RA2 uses telnet and not LEAP to integrate with third party controllers. RA3 uses LEAP and not telnet. There was a an ISY plug-in (node server) for RA2 but that's no longer supported. There is a eisy plug-in for Caseta which may work with some RA3 devices. But that's about it for eisy integration with Lutron. The Home Assistant and the eisy plug-in both use the same reverse engineered library for integration with Caseta/RA3. So it's possible that could break but not very likely as Lutron has always tried to maintain compatibility and breaking the reverse engineered library would also likely break a lot of systems in the field.

Those errors occur when the communication between the plug-in and the MQTT broker are disrupted. We did identify an issue where a plug-in could cause this internally. The fix for that issue was released a few days ago. However, there are many other ways that the communication can be disrupted that are not internal to the plug-in and cannot be resolved by plug-in authors or the interface library. That being said, I've been running this plug-in for about 4 weeks now with the fix and I've not seen a single issue. When something happens at the same time every day, it is usually something external to the plug-in that's causing that disruption. I.E. router reboot, dhcp server restart, etc. The reality is that those types of events effect your entire network, but it may just be the UDI system that notices them and reports it as an issue. The plug-in's are working correctly. They log the network error and then re-establish the connection and continue working as if nothing had happened. The only reason you even know that this happened is because we make use of the MQTT broker's built in facility to notify PG3 when a client (plug-in) connects and disconnects. We do that so that PG3 can send out notifications and set the plug-in status appropriately.

I'm the author of the Vue plug-in and it works fine for me. The connection status in the AC mirrors the status of the plug-in and I get notifications when it is stopped or started. Since a re-install does the same thing as manually stopping and starting, it appears as the node server is working correctly for you also.

Based on the behavior you're reporting, I'd guess that it's crashing or getting an unexpected error from the API. What shows up in the log?

No, it's using the PM 2.5 10 minute average which is GV3. This is probably changing less often that GV0 which may explain what your seeing for AQI values.

1. Your assumption is correct in that it only updates values that have changed. The goal was to reduce the load on the ISY by only sending changed values instead of them all. The "loading stats" message should be a debug message, not an error message. Thanks for pointing that out. 2. No, I'm only looking at the "stats" info which I believe is an average of the the stats_a and stats_b data. 3. Yes, it is calculated. I use the pm2.5_10minute value. I'm using the EPA https://www.airnow.gov/sites/default/files/2020-05/aqi-technical-assistance-document-sept2018.pdf

It should show up. The fact that it's not indicates something may be wrong with the node server. The author @Panda88 I think, would need to take a look at it.

GV5 is short for General purpose Value #5. Not real descriptive. So node servers will typically provide a human meaningful name that gets displayed instead. If everything is done right in the node server, it's that alternate name that should show up in the programming interface. Depending on how that value is being used in the node server, it may show up when selecting 'Status' or 'Control' in the programming interface. Looking at the Blink node server code, it looks like it's a status value called "Motion Detected" with 3 possible values. So in the programming interface, you should be able to do something like: if status frontwalk Motion Detected is Motion Detected I don't have the node server installed so can't provide a real example. But the programming interface will use the "names" vs the internal variable. The internal variable is only used in the various types of notifications. Recent versions of node servers can now display the mapping between the variable and the name in PG3 under the node servers details "Nodes" tab. I don't know if Blink takes advantage of this feature or not.