bpwwer

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.

The log doesn't help. They are rotated every day so the current log just shows the current day's messages. Whatever happened 'yesterday' isn't in the log. I can't really diagnose anything without the seeing the log for that time period. So if possible, try to download the log for during the same day when the issues happens.

The eisy is using an Intel Celeron N5105 with integrated graphics. Here's the specs https://www.intel.com/content/www/us/en/products/sku/212328/intel-celeron-processor-n5105-4m-cache-up-to-2-90-ghz/specifications.html All the KVM switches I've used don't work like that. They allow you to to use one monitor, keyboard, and mouse to control multiple computers by switching between which computer is connected to the monitor/keyboard/mouse. There are boxes that can take an HDMI signal and split it between multiple monitors. Say you run the HDMI at it's max resolution of 4096x2160 and have two display panels that are 2048x2160. Using special hardware it is possible to display the left half of the signal on one panel and the right half on the other. I've seen this used in automotive displays (one display for dashboard and the other for the infotainment center console display). The integrated graphics can use the two HDMI ports for various display modes, including what Windows calls extended mode when running the Xorg Xserver. However, I don't believe it can run both HDMI ports at the max (4096x2160) resolution at the same time (I may be wrong though since I never worked on JasperLake). The HDMI ports are are capable of HDMI 2.0b @ 5.94 Gbps but there's also a dependency on the platform configuration and that could have some limitations. Yes, you can run VNC on the eisy. I don't know if it is pre-installed/configured or not, @Michel Kohanim would need to answer that.

I just uploaded version 3.0.1 to the beta store. Try re-installing and see if this works better.

I didn't have the node server renaming the node when the station name changes so it was still showing as office but the incoming data does have the new name. I only see one airlink in the data I'm getting when I query the current conditions for the station, not 2 like you are. Any reason you can think of that would cause that? I think it might be because of the two airlink sensors. When I create the node definitions and NLS entries, I do so for each sensor so with 2 airlink's it's going to create duplicate entries in the profile files. It's possible that the IoX doesn't like seeing the duplicate entries and that's why it's not showing them properly. I'm looking into fixing that now.