bpwwer

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.

Hi Russ, The WeatherBit node server collects and displays two types of data 1) current conditions. You are polling the service every 30 minutes for the current conditions. 2) daily forecasts. You are polling twice a day (every 12 hours) for the daily forecasts. The polling starts when the node server starts. So if the node server was started at 10am it would be updating the daily forecasts data (which day of the week is part of) at 10am and at 10pm. So yes, it wouldn't update until 10am. Also, I believe it may be using UTC time and not local time for the data reports, thus WeatheBit will change the day of week at midnight UTC time which will likely be offset from your local midnight. If day of week is important to your programming, you may need to adjust the polling intervals to poll for forecasts more often and current conditions less often. If I recall correctly, WeatherBit limits the number of calls to 50 per day for the free plan. As for logging, there are two different types of logs available to you. 1) the PG3x log (from the UI main menu -> log). When set to it's default of info, it provides quite a bit of info on what PG3x is doing. If you don't see updates, try refreshing the browser window/tab. Setting it to error will result in no log information as it should not be logging any errors under normal operation. 2) each node server has it's own log that you get to by clicking the log button on the specific node server details page. Depending on the node server, this log may only update infrequently at whatever the default log level is for the node server, so you might not see any log entries appear for a long time. Setting this log to debug should start showing log entries fairly quick and it is at this level that node server authors would prefer you use when asking for help on the node server.

It does set a flag so that the next time "upgrade packages" is run from the admin console it installs PG3x, replacing PG3. However, one of the recent IoX firmware updates removes PG2 from the system so if you really need PG2, you'll have to hold off performing any updates.

@Jimbo.Automates Your node server controls when configuration help is available. When the configuration button is pressed, the UI checks to see if the customParamsDoc key is set in the database. Only if it is set will it display the button to show/collapse the configuration help text. Looking at your node server code, it seems to set that key quite late in the nodes/Controller.py somewhere in write_profile()? So it's possible that after the initial install it won't get set until after the user has clicked the configuration button. Or, it's also possible that the browser cache needs to be updated. In both those cases, refreshing the page will probably allow it to show the configuration help.