bpwwer

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.

It looks like the admin console wasn't able to get the profile file (or at least the airlink node definition) from the IoX. The admin console needs that to define how the data gets displayed. Without it, it typically just displays whatever was last viewed. It took me a while to get the admin console working as this is the first time I've tried since doing a bunch of OS upgrades to my desktop. But now that it is, I still see the Airlink displayed fine. However you only provided me with access to your office weather station, not the equipment closet one you list above. When the node server starts, it first does a bunch of queries and parses all the data to determine what types of nodes to create. It then has to build the profile files and finally send them to the IoX. Depending on how many sensors it's having to parse, this can take a couple of minutes. Unless you're adding/deleting sensor devices, the files should be the same every time it starts so you should only need to restart the admin console once after the initial start up of the node server. It sounds like you've done this. From the log files, it looks like it's uploading the profile files to IoX without any issues. So that kind of implies that the node server isn't creating them correctly.

If the node server log file isn't being updated, then the node server is most likely not running. With PG3x, there's no quick/easy way to determine why since you don't have access to any output until it starts writing to the log file. My first guess would be that it doesn't list all the modules that it really requires in the requirements.txt file and thus fails at the import stage. What I would do is edit the rc.d file for that node server (/usr/local/etc/rc.d/<uuid>_<slot>) and add a -S to the command_args. That tells it to write output to the /var/log/messages file when starting. Then attempt to start the node server using sudo service <uuid_slot> onestart and check the /var/log/messages file to see what's failing. I believe that this is another of the node servers that I ported to PG3 for UDI.

The AirLink fields look like station fields, not sensor fields which makes me think that the admin console hasn't been restarted and doesn't know what the sensor node looks like. There's a lot of data in the various queries that I just ignore. For example most of the sensors have both sensor data and health data. I ignore the health data. You can see that with : Sensor Node Console Health/598950 has no properties we support and if you look above that in the log, it shows all the fields it found in the health data structure that aren't supported. When it parses the fields for a specific sensor/data block and doesn't find any supported fields, it doesn't create a node for that. When it later shows up in the query (the query returns everything, I can't pick and choose what to query). It reports the fact that there's no existing node as an error. I probably need to track which sensor/data blocks are valid (have nodes) and which aren't and not log an error those those that aren't supposed to be valid.

Yes, I use error's to log debug messages a lot while developing so a bunch of those will change to info/debug in the final version. The "Failed to find node address ..." message may or may not be meaningful. I'd have to see the full log with the level set to at least info, including the part where the node server starts to be sure. As it goes through the sensors, it will skip sensors that don't have any properties supported by the node server. Those will then show that error message during the poll. That could be what's happened or it could be a legitimate error and the nodes really didn't get created because something failed.