bpwwer

It's not the node server, but rather that the node server didn't get fully installed. Not that the difference means much to you, since the result is that it's not working. We've had other similar reports where a node server doesn't install properly using PG3. Typically what happens is that one or two of the files needed by the node server simply don't get installed and repeated attempts to installed them continue to fail. There has been a lot of investigation but it isn't possible to reproduce this on-demand and no root cause has been found. The only current solution is to migrate to PG3x as we have never had this issue with PG3x. PG3 development is currently on hold and it's has not been determined if any further development will take place on PG3.

In general, a system reboot and a system power cycle are the same. However, the Admin Console 'Reboot" button doesn't always cause a system reboot. I believe the button tells IoX to call UDX which then initiates the system reboot. So if UDX isn't working, the reboot button won't work. In this case, you either have to log into the box and issue the command directly or power cycle. That's why power cycle always works but reboot doesn't.

No, not at this time. the Polisy/eisy is set up to use self-signed certificates for most of the communication between components. This includes communication between node servers and PG3x so those certificates need to be created every time a node server is installed. We can't easily use something like let's encrypt to generate these because you need an public IP address/DNS resolvable system name to use let's encrypt and that's something user's would have to have set up for their network before it would work. For some, setting up things to work with let's encrypt isn't difficult but for others it can be a real challenge and making it a requirement to use the Polisy/eisy would be bad for business

Yes, there is the process on the Portal to migrate node server license to different hardware. I'm not real familiar with that process In general, the PG3x backup/restore operations are designed to be used on the same hardware. It simply restores the PG3x database which does contain hardware specific configuration info. Restoring on different hardware is not something we're testing or guaranteeing will work. It may be possible to restore a backup, and use the System->Re-install all node servers menu selection in PG3x to get all node server re-installed and working, but again, this process is not tested. Re-installing and re-configuring after migrating the license should always work. So it's not that it's impossible to migrate to different hardware, just that it's not an automated process. At some point we'll get the backup/restore process to handle the hardware changes automatically and thus, simplify the process.

When the query all runs at startup, one of things it does is clear the status values and then queries the node server to re-populate them. So the theory was that something like this might be happening: node server starts and starts adding/checking nodes. - gets the node values from IoX - It then starts comparing and updating as necessary. While this is happening, the query is called for this node and IoX clears all the status values, including the ones that were just updated. At startup, a lot is going on so the queries are slow/delayed so they align with the node servers starting time wise. Now that we have an idea about why this is happening, we should be able to come up with a way to fix it.

We've been discussing this and the latest thoughts are that IoX may be clear out fields while PG3 is trying to set them and if the timing is just right what you're seeing could happen. If/When you get a chance, can you turn off the query at restart in IoX (uncheck the checkbox on the AC configuration page) and reboot. And again, after everything is started, check http://eisy.local:8080/rest/nodes/n013_187658. We're looking to see if properties are still missing and/or if there are blank fields for that node.

Yes. The reasoning is that there shouldn't be too many people that need to replace a functioning Polisy with an eisy. A number of folks did that with the eisy was first release (and had no choice but to run PG3 on a Polisy) so the Polisy/PG3 to eisy/PG3x made sense to support. But now, chances are that if you're updating the Polisy to PG3x, you're probably going be using the Polisy for a while. And yes, there are exceptions.

Because it's not a high enough priority to expend resources on developing it at this time. Eventually there will be a way to migrate. Currently the PG3x backup can only be restored to the same machine that made the backup so the same problem exists if you have a hardware failure and get new hardware. In both cases, it's possible, just not automated. The main issue is the node server license. Once that is transferred to new hardware, restoring the backup from another machine and then re-installing all the node servers should be recovered.

That's not yet generically possible. The IoX is capable of having a value -> text lookup table, but it's a pre-defined table. The node server has to supply that table at startup to the IoX. So it's what's probably happening now is that the node server has a pre-defined table that maps lock state codes to text: 0 = locked by key 1 = locked by user 1 2 = locked by user 2 10 = unlocked by key and so forth. If the node server provided a way for you to define the user's, it could build that table with your user's names instead of just 1, 2, ... Right now, there is on-going work to provide a more dynamic way to associate the numeric values to a string. But again, this will require the node server author to update the node server so that you can configure it with your own strings. This may be something the notification node server takes advantage of in the future so that you can do pretty much what you describe.

There are only 2 currently available migration paths available: PG3 on Polisy -> PG3x on eisy PG3 on Polisy -> PG3x on Polisy the first does require a transfer of licenses but that is supposed to be part of the migration instructions. the second doesn't because the hardware stays the same so the node server licenses remain valid. ** It's should still be possible to migrate from PG2 on Polisy to PG3 on Polisy, but only if your system still has old versions of the software since current system updates will remove PG2 from the system.

When you got the results with just the 2 properties showing, was the AC showing those same values in the two fields? Or were all the fields still blank?

Hi @TJF1960 If you get a chance to do test, I'd like to try the following. 1. reboot the eisy 2. after everything starts and the AC is showing blank fields for the Vue nodes try the following from a browser window http://<eisy ip>:8080/rest/nodes/n013_187658 You may be able to use "eisy.local' instead of the <eisy.ip> It should prompt you for your Iox username and password. Copy the results to post here. Then restart the node server and do the same thing. Thanks.

Using the AC, select Node Servers from the menu then select Configure, then goto the slot range and select the slot that has the node server you want to remove. You'll get a box with the node server configuration and at the bottom is a "Delete" button. Click the Delete button and a few minutes later it will disappear from the PG3x dashboard.

That's not really possible. Node servers and the associated installation are tied to the hardware. With PG3x, PG3x and the IoX are essentially tied together as one entity. If you try to move the configuration from the Polisy to the eisy, it will get very confused because it will still attempt communicate with the IoX on the Polisy, for some things and will be communicating with the IoX on the eisy for others. In addition, none of the node server will work because the license for the Polisy is invalid for the eisy. The only way to "migrate" would be to first get all the node server licenses transferred (by contacting UDI and telling them you want to transfer licenses from the Polisy UUID to the eisy UUID). Then start the eisy (and make sure it's updated), and install and configure each of the node servers. Any node server's with a free license don't need to be transferred as you can just get a new free license that works with the eisy for those.

If I remember correctly you need to install the development tools for eisy. One of the python packages that it uses is only available in source form, so when the node server is installed and attempts to install the python package, it tries to build it from source (using a 'c' compiler). The build fails because the 'c' compiler is not installed on the eisy. Use the admin console and click the "Install Dev. Packages" button on the configuration tab. After those are installed, try installing the node server again.

Just checking the query at reboot box should be enough. So that I'm clear. After the reboot, you have device nodes with blank fields. (you had screen shots attached to the ticket, right?). If you either right click -> query or press the query button on the node, it does not populate those blank fields, correct? Then if you restart the node server, all those blank fields are populated without you having to do anything else. If the above is accurate, then I don't think the problem is the node server. As I mentioned, we have other reports of the same behavior but for other node servers. The node server would have to not send data for the fields to remain blank, and based on the node server logs, that's not true. The node server is sending the data but IoX is either not accepting or not seeing it. The fact that it doesn't seem to accept data even later (when you force a query), is what's really strange. I think we're going to have to figure out how to reproduce on one of our (UDI developer's) systems to be able to debug it. I'm not giving up yet.

To close out the discussion on NC rain, the latest WeatherFlow release now creates a node for nearcast rain values. I made this a separate node for a couple of reasons; there is a limit to how many values a node can have and the main tempest node is approaching that limit and also, NC rain data is only available from the server so currently the station has to be configured for REMOTE data and not LOCAL to get NC rain data. So anyone wanting to use the local data that hub provides won't have access to NC rain data. And to provide some info on the business aspect of doing this. It took about 20 hours to add this feature. The average hourly rate for this type of work (where I live) is $60, so the business cost to add this was $1200. This means I'd have to get 120 new sales because of this feature just to break even. Sales of the WeatherFlow node server run about 4 per month (or $40). So it will take about 30 months just to recover the expense of adding this feature.

@mbking you should be fine. Now that I think about it, it's possible that some addresses won't change with the new method.

It would also be good if node servers had access to the "Preferred Measurement System" from IoX. That way the node server could send data using the user's preferred UOM.

I just finished up the changes to the WeatherFlow node server and I need to test and release that. Adding RIO support to the Russound node server is what I'll work on next, but I don't really know how much effort it is to take the RIO support from the PG2 node server and incorporate it into the PG3 Russound node server so it's hard to estimate the time. I want to say a couple of weeks, but that's not guaranteed.

I'm not able to reproduce the issue you're seeing. When I reboot my eisy, the node server starts and data is shown and updating. Did you try a query this time? If so, did it help now or not? We have other reports of this same issue but with different node servers. I made a change that I think will help. When you have a chance, try version 1.0.25

Fixed in 2.0.10 Yes, just delete the old node.

@TJF1960 I don't know if you saw the update in the ticket, but I made a small change to the node server and released it as version 1.0.24. I've been testing with that version and I'm not seeing any issues when restarting the eisy. The Emporia devices that I have do populate values on restart and appear to be updating properly. If you're still seeing the issue with nodes not populating with this version, then more investigation will be required.

This version fixes an issue where the node server would fail if the number of sensors exceeded 9. While trying to create a sensor node for the 10th sensor, it would generate a node address that was invalid causing the IoX to reject the node. The node server would then get stuck waiting for the node to be created. Version 2.0.9 of the node server uses a different method to generate the node address so that it will no longer generate invalid address, however this also means that it breaks any programs that used the old sensor nodes. After upgrading to this version you will have to update any programs to use the new nodes and manually delete the old nodes from the admin console

I reviewed the logs and responded in the ticket. Basically, I don't see anything wrong in the log.