bpwwer

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.

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.

The units it uses are based on the query results from the WeathFlow server. The defaults are based on the WeatherFlow defaults and I believe the windspeed default is m/s. The log would report an error if it wasn't able to query the units from WeatherFlow.

Yes, the MQTT broker is running on the Polisy. So in theory, external network issues shouldn't effect anything between node server and PG3, but there's nothing that I can do at the node server level (or even the PG3 level to change that behavior. All I can do is make sure it attempts to recover when it happens.

@Michel Kohanim spent some time on my system and I believe he identified what had failed, but not why. I don't think he was ever able to reproduce it on his end and I think it was something like 3 or 4 total out of thousands that failed.

Do you see the same errors in the Yolink node server or any other node server for that time frame? When the errors happen in the Davis log, there's also a pause of about 40-60 seconds in PG3x where nothing is received from any node server. Typically, PG3x is seeing something every second. The error is happening when the node server is trying to send messages to the MQTT broker and it fails. This indicates some type of communication failure on the network. It's not something in the node server code.

No, everything is normal on the box now. The Polisy that had the upgrade fail is my development box so it has PG3 and all my node server development stuff running on it and I didn't lose anything. My production Polisy upgraded just fine. When the upgrade fails, it basically fails to install all the required files so things like the ssh daemon fail to start, that's why you can't ssh into it. But it does still have network access so once you have access to the box, you can run the update script and do whatever package management is needed to get everything properly installed. I don't remember the exact steps but if you get a serial console working on it, submit a ticket and I'm sure @Michel Kohanim can walk you through the steps needed to bring it back to life.

That happened to me as well. Apparently whatever it was that caused the update to fail only effected a small number of Polisys. Lucky us. I was able to recover by opening the box, connecting a serial cable and logging in over the serial console. From there I was able to manual do the update and get things working again. Instructions for connecting a serial cable are somewhere in the forum (I just searched and it popped right up). I think the only other option is to send the box back to UDI and they'll either use a serial cable to recover or just replace the image.