bpwwer

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.

PG3x doesn't know the internet connection was off-line so it can't detect that situation. It doesn't know why the nodes servers failed, just that they have. The problem is with specific node servers. Some don't handle the internet disconnect well others do.

Oops you must not have the updated firmware. 1.0.3 should handle that correctly now.

You should be able to restart the node servers without having to restart PG3x. However, PG3x won't try to restart them automatically. The "failed" state means that the node server failed and disconnected from PG3x unexpectedly. In your case, the node servers are likely crashing when they get disconnected from the internet. Most are not designed to recover gracefully when that happens. This is something that would have to be fixed in each of node servers.

Sorry about that, I didn't realize that the change I made would also effect the code. It should be fixed now in 1.0.2

@BamBamF16 Have you tried starting the node servers? If they don't start, download the PG3 log package and PM it to me.

I can't do anything about #1, that is a limitation of what the IoX will accept for node names. I can fix #2. I'll change it so that it looks like: This also changes the drop down so that the options are "Set Shade Position" and "Set Shade Speed" instead of both being just "Set Shade".

Run "Upgrade Packages" again. Once it completes, reboot. Once everything is back up, refresh the browser page.

@JKlinefelter That makes sense but I'm not sure how the node server can detect that from the incoming data. The incoming data has field names suffixed with 1, 2, 3, etc. The channel number I guess. So the node server lumps everything with a suffix of '1' under a single node. There's no indication in the data that it may be multiple sensors or a single sensor. The IoX considers it illegal to have two node values of the same type. So what's happening is that when there are 2 sensors with a suffix of '1', they both may be reporting battery status, but since the node can only have one battery status it the node server creates an illegal node definition and the IoX rejects it. Because there can be so many different combinations of stations/sensors and Ambient doesn't send anything but a list of field names/values, the node server has no way to know what sensors/values are going to be reported ahead of time, it has to process that in real-time and dynamically create nodes based on what it sees. I don't really have any ideas for a better way to handle this. It seems like trying to do any type of user configuration would be a real challenge given the limitations of the PG3 configuration screen. The right solution would be for Ambient to re-design their data structure format to provide the info needed actually parse it. I can try and improve the parsing logic in the node server, but it is already quite complex because the field naming conventions aren't all that consistent. Anything I do will end up making assumptions that may or may not hold in the future and may simply result in dropping data if it thinks it will create illegal nodes. Since I don't have any Ambient equipment and I haven't seen it documented anywhere, I had no idea the suffix numbers represented channels.

No difference between Polisy and eisy that I'm aware of. But that's not a PG3 issue as the IoX handles the upgrade process so you might want to ask this on the IoX firmware support thread.

I don't believe so. But you can install the node server in multiple slots with each using a different gateway.