bpwwer

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.

The node server author needs to fix that. The store entry says the latest version is 0.3.68 but the node servers says it's version 0.3.69. PG3 just knows that they are different and assumes you don't have the latest version installed.

I just posted this same thing on another topic. There are a number of node servers that UDI ported from PG2 to PG3 because the original author had abandoned them. I did most of this work for UDI. But there's no on-going support/maintenance for them as I don't have the time. All of these node servers are stored in https://github.com/UniversalDevicesInc-PG3 You can check if this is the case via the more info button. UDI doesn't really monitor the forum for issues with these so if you're not getting any response from the node server author here (via PM or github issue), then submit a ticket to UDI.

There are a number of node servers that were originally written for PG2 but then abandoned by the author. UDI ported those to PG3 (mostly done by me). For a couple, I've taken on the support/maintenance of them but I don't have the time to support all of them. When I ported them, I placed them in https://github.com/UniversalDevicesInc-PG3 area. So if that's where the more info button points and that's where it installs from, then it is likely a UDI ported node server. For help with these node servers, you should go directly to UDI. Submit a ticket and let them figure out what to do about it. In fact, for any node server where you don't get a response from the author, submit a ticket.

@sjpbailey This really should be a new thread on Discord or a ticket as there are only a couple of people that can answer your questions and/or actually help you. All node servers require a license to install and run. The cost of the node server doesn't matter. So yes, once a user obtains a license for a node server they can't delete it. Only UDI can delete a license once it's been granted. Perhaps the name of the page is a little confusing as it's not really "Purchases" but a list of node server licenses associated with the user's account. You'll need to provide more information/diagnostic information to the one person who can debug this. I don't know if this post will get his attention or not. For me, every time I've used those functions they have worked as intended. There is, it's the "Delete" button on your "List my Node Servers" list. I don't really understand what you're saying here. If you want to create your own purchasing/licensing system then you can control refunds. But the current system was developed by and is managed by UDI so they control how refunds are issued. By submitting node servers to the UDI node server store, you're agreeing to allow them to manage the licensing. Not an unreasonable request. You should submit a feature request to UDI for this. You can. When you submit a node server to the store you have a drop down menu that lets you select which store you are submitting it to. If you edit the beta node server entry and then change it to submit to the production store, it puts the same node server into the production store with all the same purchase options. Users that installed beta versions can then re-install the production version using the same license. It is also possible to create limited life time beta versions that can only be used by users for a specific length of time before they expire. Once expired, the user then needs to obtain a new license for the production version. You can pretty much do anything you want. However, you do have to pay close attention to what you are doing as it's just as easy to mess things up.

Creating a node server specifically for the mini-splits probably wouldn't be less expensive, depends on if there might e more demand than just you. A quick search led me to the following docs. https://openapi.ing.carrier.com/Content/pdf/getting-started.pdf It also looks like there may be an HA integration available which would help. If you can verify that there's a published API that's accessible to third parties then you may be able to work out a deal with one of the node server developers to create a node server.

There isn't any way to hard code device IP's in the node server. It was designed to only do the network device discovery.

I think I fixed it, try 2.1.6

Yes, I ported it from PG2 to PG3 but don't have any devices and can't really provide much in terms of support for this node server.

There is no automated way to "migrate" a PG3x installation to another hardware device. The current PG3x backup process backs up hardware specific information. If that is restored to different hardware, it won't work without updating all of the hardware specific settings. At this time, there's no documented process to update that hardware specific information. My recommendation is to document the configuration of your node servers before hand. Then do all the IoX/z-wave migrations and get the eisy working for those. Then do the portal PG3x license migration. Lastly, install all the node servers** to the same slots and configure them using the information you collected originally. ** You may have to use the re-install option to do the install as PG3x probably thinks there is already a node server installed (from the IoX restore).

Did you restart the Admin Console after installing the node servers? The Admin Console only reads the node definition information when it starts so after a node server is installed and sends it's node definition information to the IoX, the Admin Console needs to restart in order to read it. From the screen shot, it looks like the Admin Console doesn't know how to display the nodes so it's just displaying random stuff. (looks like a lock device node is being displayed)

I believe the original author of the node server has abandoned it. I converted it from PG2 to a PG3 node server but I don't have the hardware to test or debug issues. The fact that it created the zone nodes is a good sign, that means it was able to connect to your account and pull data about the system. I took a quick look at the code and it looks like it is supposed to update the zone status at the "shortPoll" interval (which is in seconds. The default seems to be 2 minutes. Maybe I'm missing something, but looking through the code, I don't see any status called "Locked". Zone status looks like it should be one of OK Bypassed Faulted Troubled Tampered Failed Alarm Unknown With all node servers, it's best to check the log if you're having issues. In this case, I'd recommend that you do the following: Restart the node server Click the Log button to display the log Switch the log level to "Debug" Once the node server starts it should query your TotalConnect account for panel information and then query for information about each zone. After that, every 2 minutes it should query again for the zone info. If what's in the log doesn't make any sense to you, use the button to download the log and then send it to me in a PM.