bpwwer

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.

Yes, PG3 does use MQTT for most of it's internal communication between components. But that is all secured and private, you won't be able to connect random MQTT clients to it's broker. The MQTT node server actually requires a MQTT broker to be installed somewhere on the network that it can use. I believe it is now possible to install a generic MQTT broker on the Polisy/eisy for this purpose. Installing the generic broker would give your Arduino client something to talk to, but that doesn't really help you much as you still need something to translate/redirect that into IoX (like a PG3 node server). I believe you have two choices: 1) modify xKing's node server to support the incoming messages from the Arduino. 2) create a custom node server just for your Arduino based pool controller. For either of those, you'll need to register as a UDI developer and become familiar with node server development. You may be able to hire an existing developer but since the solution will probably only be useful to you, it may be expensive to do that.

@photogeek54 You have version 1.1.02 as the version specified in the node server store entry but the node server is sending it's version as 1.1.0 You probably want them to match.

You don't need to use https when accessing PG3, you can use unsecured http. If you're accessing PG3 from your own network and you trust your network, then there's really no need for a secure connection.

Thanks for the details on your setup and what you did to test it. The node server to PG3 communication should not be effected by external network issues, but it clearly appears to be. I'll have to do some investigation to see if I can figure out why.

I looked at the files too and noticed that. This doesn't appear to be an internet outage but a local network outage which is a very different thing. There's a lot of local network communication between components and if that is disrupted for more than milliseconds, it may be unrecoverable. The MQTT connection between a node server and PG3x is happening on 127.0.0.1, that's not even external to the machine so for that to get a handshake error implies that something is actually blocking network activity on the local machine. I'll have to do some investigation but even unplugging the network connection should not effect that connection.

When the version reverts like that, it means the node server code is sending that version after it starts. PG3 access the node server store record for the node server and that record has version as 1.1.01 so PG3 assigns that version to it's internal record of the node server. Then with the node server starts it passes version 1.1.0 to PG3 and PG3 updates it's internal record to reflect what is actually running. There were versions of PG3x that had issues with permissions of node server files such that once installed, it wasn't able to update them. I believe that was fixed in 3.1.26 so make sure you are running a recent version. You could try installing in a different slot, doing that would guarantee that you have the most recent node server code installed. If you still see the issue, then the node server package that is out on the server isn't matching the version listed in the node server store.

Yes, I agree, they shouldn't crash. You can help by reporting the issues to the node server authors. And there's a good chance that some of them may be my node servers, I know many/most of mine don't handle lose of network connectivity well and it's on my list of things to fix eventually.

There were a log of things that changed with the eisy release. Probably too many. We're working to make it better and get things to be more stable. Many people have no issues at all and everything seem to work as intended. But for others (as shown by the posts here and other threads) it just doesn't. It seems like a lot of the issues occur during the update process and things are getting updated quite frequently. If nothing happens when clicking the login button for PG3x, it means that UDX is not sending back a response when PG3x tries to authenticate. PG3x is simply waiting for that response that never seems to come. The first thing to try is to simply reboot the box. If a reboot doesn't work, then you may need to run (or re-run) the upgrade process ("Upgrade Packages" from admin console, followed by reboot, followed by a refresh/reload of the PG3x browser page). If that still doesn't work, you'll need to submit a ticket.

@agoltz It sounds like you're using PG3x and not PG3. PG3x depends on IoX and on another UDI component called UDX. It queries UDX to get the IoX credentials for authentication. So if you're having issues accessing IoX, that will also impact your ability to log into PG3x. If nothing happens after clicking the login button, then it probably means that UDX is not responding to the request to authenticate. Sometimes a reboot will correct things. Other times it is because something didn't go right during an upgrade so you need to run "Upgrade Packages" from the Admin Console. Since it sounds like you can't access the Admin Console either, you may need to attempt one of the multi-button press commands to get it to try and upgrade again. There's also a way to ssh into the box and manually start an upgrade.