bpwwer

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.

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.

Is this something new that happening or something that has always happened? Can you clarify a couple of things for me. First, when you say reboot eisy, what specifically are you doing; rebooting the hardware (Reboot button under eisy System Settings) or restarting the IoX (Restart IoX button)? what data is populating? Most useful would be to set the node server log level to debug and then reboot the eisy. After things have stabilized, the restart the node server manually. Download and send me the log package.

When you do the submit it sends the request to the AWS servers to add it to the node server store and it adds it to your local cache. So what you are seeing is your local cached version of the store. When the status is 'new", it is in the store, but waiting for approval before it is visible to anyone else. If it's waiting for approval, it will sit like that until I see the notice in slack and approve (which could be 24 hours or more. The approval process isn't really necessary as we have so few node server developers and they're all trusted at this point to "approve" their own node servers. Just submit with the status set to 'active' and it should show up for everyone.

Version 2.0.4 is now in the store with the additional rain values. After you update/re-install this version you will have to restart the Admin Console to see the new values.

Ok, easy enough. Solar radiation should already be reported, is it not?

You'd have to set the node server log to debug level and check the query response message. If the rain_storm value is listed there, then I can add it to the node server. The 709 represents how many bucket tips happened during the store. There's another value in the list that specifies how much rain is in a single bucket tip (.1 inches or ...). The node server knows how to translate that to inches/mm of rain.

What shows up in the node server log file if you set the log level to debug and restart the node server?

@TriLife Here are the fields I see in the data that aren't reported by the node server. 'thw_index': 63.2, 'thsw_index': 61.2, 'wind_speed_avg_last_1_min': 1.37, 'wind_dir_scalar_avg_last_1_min': 32, 'wind_speed_avg_last_2_min': 1.56, 'wind_dir_scalar_avg_last_2_min': 31, 'wind_dir_at_hi_speed_last_2_min': 22, 'wind_speed_avg_last_10_min': 0.62, 'wind_dir_scalar_avg_last_10_min': 23, 'wind_speed_hi_last_10_min': 3.0, 'wind_dir_at_hi_speed_last_10_min': 36, 'rain_rate_hi': 0, 'rainfall_last_15_min': 0, 'rain_rate_hi_last_15_min': 0, 'rainfall_last_60_min': 0, 'rainfall_last_24_hr': 125, 'rain_storm': 709, 'rainfall_monthly': 1048, 'rain_storm_last': 232, Are there specific ones you are interested in? One of the reasons that I didn't just add them all is that the ISY/IoX doesn't handle multiple values of the same type in a node. I.E. a node can only have one value for rain rate or wind speed or wind direction. There are ways around that somewhat, but there are then other limitations that come into play so it's not possible to include all of the above values without re-designing the node server to split the current conditions in to multiple nodes.

Yes, it does send the 'magic packet'. However, the network stack on FreeBSD (Polisy/eisy) is different from most other systems, including a Google Pixel so sending WOL packets from it may not behave the same as other operating systems. The node server uses a python library called wakeonlan (https://github.com/remcohaszing/pywakeonlan) to generate and send the magic packet'.

I'm pretty sure it's 3.0 as I believe the 2.5 api was supposed to have gone away years ago. However, when I go into my account, I can only generate a key, no choice for a 2.5 or 3.0 key

You can copy the URL from the log and paste it into a browser window to double check but there isn't anything the node server can do to make the API key be valid if the OpenWeatherMap server's say it isn't.

Did you look at the FAQ and verify the checks they list there?

It looks like not all the files got installed when you updated WeatherBit. You can try re-installing it. There's been a random issue with PG3 where it will fail to install node server files. We have not been able to track down why this happens, but once it starts happening, it seems to consistently fail to install the same specific files. The only known work-a-round that this time is to migrate to PG3x

That I would believe! It probably isn't even crashing PG3x, as it is probably working correctly just unable to connect to UDX which means you can't log into the WebUI. If it's having trouble with UDX then it also can't start/stop/install/remove node servers. The communication issue with UDX is something that a number of people have experienced (I've seen it before too) but it hasn't been consistent enough for someone to be able to debug it. Rebooting the Polisy/eisy makes sure everything is starting in the right order and should be a safe/clean method to get everything working.

"sudo service pg3 onerestart" is the correct way. And I do this sometimes dozens of times in a short period of time when debugging and doing feature development on PG3x, never once has it caused my eisy to crash. If the Polisy is crashing, then something else is probably wrong. PG3x should not have enough privilege to crash the Polisy/eisy.

The node server will only send updates to the ISY (IoX) if the value is different from the previous value. So if the day changed just after midnight, it likely won't send another day update until just after midnight tomorrow when it changes again. The node server log doesn't show historical entries, it's only displaying new entries that occur after you open it. Under normal conditions, that should be very infrequently unless debug level is selected.