bpwwer

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.

They're probably either using the same hardware/API or the API is different for each company that rebranded the hardware. I have no information on any of these, including the nuheat as I didn't write the node server. The only real way to know is to get the API from Schluter & Microline or to just try it.

The data for your location probably isn't providing that data, that's why it fails to parse it.