bpwwer

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.

I didn't look at yesterday's data, but so far today I've seen 3 instances. So I'm able to reproduce the issue.

I didn't think of this before, but I never really ran my system with your configuration for any length of time. For the development, I would start it, check if things started up properly or not, debug, restart until it was working. Since then I've left it off. So I never let it run for more than a couple of minutes at a time. If you don't mind, I can let mine run for a day or so and see if I get the same errors showing up. I'm not sure you can disable the station in the node server. Maybe by deleting the nodes while it's running. But a restart of the node server would re-create the nodes.

Yes, but mine is more text than graphical. I just use font sizing to make it "pretty". I display things like: inside temp/humidity/HVAC mode outside temp/humidity/rain solar production/use whole house audio settings weather forecasts Most of that comes from node servers with the exception of the HVAC info which is Insteon based.

I added the ability to set party mode to master so maybe that will help, but I'm at a lose as to why off wouldn't work. It matches what's in the documentation. The RNET documentation has a lot more detail than the RIO documentation. It says All that stuff with plus/minus is just for control from a keypad, the node server is using the discrete on/off/master commands. The RIO protocol uses events and it has this to say about party mode The only other information the documentation provides is this: You've verified that other events are working from the node server? Like volume up/down buttons, the all zone on/off events, and do not disturb.

Just released version 2.1.7 to the store. This has the all zones on/off, plus I added a number of keypad buttons to the zone nodes. Party Mode appears to be implemented, but for some things there are multiple ways to do things so if it still doesn't work, first set debug level and capture a log after setting party mode so I can take a look at what it does.

I just finished implementing the AllOn and AllOff. Have you, or can you also test PartyMode that way? I double checked and it mostly looks right although it was spelled 'partyMode' in one place which I corrected incase case is important. EVENT C[1].Z[1]!PartyMode ON \r

The Myq log won't really help When the node server starts, it gets the units from WeatherFlow. So first thing to try is to simply restart the node server. If that doesn't change anything, then check your settings on the Weatherflow app and make sure you have the right units selected for windspeed. If that looks right attach the log that includes where you restarted. Or better yet, set the log level to debug, restart the node server, then download the log and attach that.

The library that the Caseta node server uses does have support for RA3 but since I don't have any RA3 devices, I don't have any way to verify what works and what doesn't. I suspect that any RA3 devices that match the Caseta device classes will work with the generic device type support in the node server. For something like a dimmer, the only difference between the generic support and specific Caseta dimmer support is that it displays the Caseta model numbers instead of the word "generic". The node server will also report info about any devices it doesn't recognize and by sending me that info, I can usually add support for that device into the node server. So anyone with RA3 devices that wants to test that, just get a trial license for the node server and let me know what it does.

I don't know anything about how the node server works but this seems like the problem: Blink Start Exception: There is no current event loop in thread 'Thread-6'. Perhaps the author, @Panda88 can diagnose why that's happening.

That doesn't seem normal. I'd open a ticket.

party mode was implemented so I'll have to check to see if I can figure out what's wrong. I don't recall seeing an all zone on/off command, do you know if that exists or will the node server need to turn all zones on or off individually?

We would need to see the beginning of the log where the node server starts, queries for devices and tries to create nodes for those devices.