bpwwer

@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.

It should not start on boot/restart of PG3 if it was previously stopped by you. Once you "stop" a node server, the only way to get it running again is if you specifically "start" it manually.

Not something I can change/add. You'd have to submit a ticket to UDI to have some type of apparent power/reactive power status value define in their firmware. Then the node server could be modified to make use of it.

If the values aren't populating, then the most likely cause is because the query to the weather service(s) fails. The most likely reason the query fails (assuming it has never worked) is that the configuration is wrong. For both node servers, the next step is to view the log files. From the dashboard, select the node server and then click the Log button. Change the log level to "debug" and then restart the node server. If what shows up in the log doesn't make sense or help, download the log package and either attach it here or PM it to me.