bpwwer

There are two node servers that support Onkyo control. You might want to try the OnkyoAVR node server instead.

You seem to be asking a couple of different things here so I'll try to answer as best I can. On your local network, there shouldn't be any problem accessing PG3 from an iPad. I just connected to mine using my iPhone and other than the small screen, it worked fine. That being said, you may have to use an unsecured connection (http vs. https) as the iPad probably won't allow you to use the self-signed certificate since it it can't verify it. Using the ISY Finder to connect may always try to use a secure connection. If so, you simply have to type the Polisy's IP address manually into the browser address field (http://<ip address:3000/). Then you mention trying to do it remotely. Right now, PG3 does not provide any method to access it remotely. That's not to say you can't, but you have to know how to configure your network to allow this. You can open port 3000 through your router, however, for security reasons it is never a good idea to open ports. Or you can access your home network via a VPN. Using a VPN is much more secure and once the VPN is configured and connected, you'd access PG3 remotely the same way as if you were on your home network.

This is what I get from the logs: At 9:36 you attempted to restart the ping node server. It failed to restart because it was unable to stop the currently running version. However, the restart attempt seems to have kick-started whatever was blocking it and it seems to start working. At least it sends a bunch of status updates to PG3. At 9:46 you attempt to start the ping node server. Again it fails because it is still running. So it appears that the network outage may have caused the node server to block in such a way that PG3 was unable to stop it. Restarting PG3 causes the OS to attempt to clean up hung node servers, so that is what likely resolved the issue. Yes, I ported the ping node server to PG3, but beyond that, I don't have any other involvement with the node server.

@johnnytYou can run to copies of the Airthings node server in different slots. Your current license allows you to run multiple copies. Weather or not the node server will allow each instance to control a subset of the devices on your account depends on the node server. You may need to create multiple accounts and have each instance use a different account.

Perhaps I can't. It was never part of the node server API to send commands from the ISY to control node servers.

Yes. When the Polisy is restarted, both the IoP and PG3 are started at approximately the same time. One of the first things PG3 does is try to contact the IoP and verify the installed node servers. Even though the IoP startup is fairly quick, it's still possible that it's not ready when PG3 makes this initial query. If that happens (and chances are good that it will), PG3 simply continues on and starts starting node servers. If those node server try to update status on the IoP and the IoP is still not ready, those status updates will also fail. PG3 does periodically verify the node servers installed on the IoP (every 5 minutes). So 5 minutes after all that above has happened, PG3 will again try to verify the node servers on IoP and probably succeed. At this point, everything should be running normally. The next version of PG3 will try to mitigate this. If it fails to connect to the IoP on startup, it will wait until it can connect before it starts the node servers.

It will only report anything if the node server is actually running at the time. Unfortunately, PG3 doesn't have any good way to notify about things like this. It doesn't have a email address nor any way to actually send email. Same for text. The ISY doesn't have any API's that would allow PG3 to route notifications like this through it. All it's left with is to send a notification to the UI, but that only happens if both the UI and the node server is running at the time. And it's possible that it's broken in 3.0.63. I've made hundreds of changes and fixes since then and don't recall if any of those fixes relate to the expiring of trial/subscriptions.

If you're running a trial version (and same applies to a subscription purchase). PG3 will notify you that it is about to expire. At 14 days before it expires it will put a message in the log At 10 days before it expires it will put a message in the log at 5 days before it expires it will put a message in the log and display a notice at 2 days before it expires it will put a message in the log and display a notice After it has expired it will log the fact and display a notice when you try to start the node server For a trial, if you purchase a non-trial license before the trial expires, it will use the purchased license and ignore the trial license and you won't get any notices because you are no longer using the trial license. Now this could be broken, it is very difficult for me to test since the purchasing system won't let me generate trial licenses for my own node servers and once you purchase one and it expires, you can't purchase it again.

I don't disagree with this but there are both pros and cons to each approach. The automatic update "feature" was already part of the PG3 design when I took over development. There has been some discussion with node server developers about this and what may be a better design. However, there are some concerns about how to handle and the priority hasn't been very high compared to all the other issues with PG3. In general, the automatic update of node servers has not been a problem. Certainly there are cases where a bad release happens, but that is typically resolved very quickly. @btreinderssince you don't specify the node server that broke, I don't know what happened.

Not yet. It seems like the packaging system doesn't like to downgrade stuff. I'm trying to get the production version back in the package repository. There is a know issue where you can't install some of the free node servers with 3.1.2, that's a problem with the node server entries in the store so not related to what you're experiencing. There are a couple of fixes in 3.1.2 but most of the changes effect developers only.

Pulling the ISY response times from the PG3 logs isn't that hard. Someone better at unix shell scripting than me could probably whip up a script that dumps just the timestamp and response time into a file that could then be imported into a spreadsheet to graph it. Just seeing how it changes over time may provide some insight like every day at 4pm the response gets slower, then you'd know to look at programs that start at 4pm. PG3 saves 2 weeks worth of daily logs so you do have some historical data available to correlate with other events/logs. You can just dump all the response time entries for the current day with the command line command: grep "ISY Reponse" /var/polyglot/pg3/logs/pg3-current.log Or to just get time and response time grep "ISY Response" /var/polyglot/pg3/logs/pg3-current.log | cut -d ' ' -f 1,2,13 This is from a ssh shell on the Polisy running PG3.

Ok, try version 1.0.4.

@simplextechThe log shows this when trying to install: 8/16/2022, 11:37:50 [pg3] info: [00:0d:b9:59:41:84_1] 'ST-Nuheat' installed into ISY successfully... 8/16/2022, 11:37:50 [pg3] error: NSChild: ST-Nuheat(1) /bin/sh ./install.sh: /bin/sh: cannot open ./install.sh: No such file or directory 8/16/2022, 11:37:50 [pg3] debug: NSChild: ST-Nuheat(1) /bin/sh ./install.sh: exited with cause code: 127 8/16/2022, 11:37:50 [pg3] error: installNs: Error: Non-zero exit code: 127 at ChildProcess.<anonymous> (/var/polyglot/node_modules/@universaldevices/pg3/lib/services/node servers.js:47:30) at ChildProcess.emit (node:events:537:28) at maybeClose (node:internal/child_process:1091:16) at Socket.<anonymous> (node:internal/child_process:449:11) at Socket.emit (node:events:537:28) at Pipe.<anonymous> (node:net:747:14) Then when it tries to start if fails with: ReferenceError: Cannot access 'logger' before initialization at process.<anonymous> (/var/polyglot/pg3/ns/000db9594184_1/st-nuheat.js:1:6746) at process.emit (node:events:537:28) at process._fatalException (node:internal/process/execution:167:25) Node.js v18.5.0 I don't think running version 3.1.2 would cause this, but I've also never tried any node.js node servers on it yet.

Nope, I don't know anything about that node server. Have you tried uninstalling and reinstalling since you did the update?

I understand that you have a very large system and it's possible that no one else has built one out to that same level. Unfortunately, folks won't normally be monitoring threads like this if they aren't having issues so we may never know. My point is, that the current assumption is that the box is just overloaded and something with more "horsepower" will work better. But what if that assumption is false? What if you have one program out of those 900+ that's doing something that is taking 90% of the CPU resources and causing everything else to wait and changing that one program makes everything better? What if there's a bug in the ISY firmware that you just happen to trigger with one of your programs that causes the ISY to sit in a busy loop for 30 seconds over and over? I like to know the root cause before trying to come up with solutions. It may be that you've simply overloaded the box, but Insteon, Z-wave, and node server devices typically are very low resource drains on the system because of the communication delays. In the time it takes an Insteon device to receive a command and return a status response, the ISY can likely process 100's of TCP network requests. But we're seeing the ISY take 100-200x the normal time to respond to TCP requests. What is it doing for all that time?

The PG3 log may be too big to display. Try downloading it and PM it to me.

What version of PG3 are you running? What's in the node server logs that aren't starting (if there is any log) What in the PG3 log?

While anything is possible, it's just not real practical to try and reduce the data sent by the node server. WeatherFlow may be one of your more prolific, but it is far from the most prolific of node servers. I've created stress test node servers that send far more data to the ISY than the WeatherFlow node server, probably at least 100x more data without problems. I don't believe your issues are solvable by changes to PG3 or the node servers. Perhaps there's a way to profile what the ISY is doing to isolate what's really causing it to be so busy and re-work that so that. I don't know. Without data to determine what the ISY is really doing that causes it to be so slow in responding, there's not much we can do about it. Maybe @Michel Kohanimhas a way to debug issues like this or extended log info that would help.

It would still be good to see the PG3 log file that includes an attempt at installing the node server. That's the only way for us to determine what's not working right. The one you attached above says "unavailable" so we can't look at it. Also, since you're running the test version, any feedback? The main changes are in how node servers are presented for installation from the store. It looks like the production version got overwritten with the test version. I'm working to get that corrected. Once the correct version is there, an update should revert it back to the production version.

hmm, that's not good. That version should only be installed manually. What did you last do to update the Polisy? Click the "Upgrade Packages" button in the Admin Console?

Try version 1.0.3

@johnnytI guess you missed it or I wasn't clear. The WeatherFlow hub sends the data every minute, that's not configurable in the hub or in the node server, it just the way it works. You can configure how often the WeatherFlow node server queries for forecast data and that's it. Since I don't have any PG3 node servers running on a i994, I don't have any way to directly compare, but those times seem very long for a response. On my IoP, I will occasionally see requests take 200-300ms but most of the time it's 4 or 5ms. From the log snippet, it seems like the ISY is always busy and responding slowly. There's not really anything the node servers or PG3 can do to make the ISY respond faster. Slowing down node servers or having them send less data won't really help, it doesn't appear that they are the cause.

3.1.2 is a test version of PG3 for developers to test their node servers and provide feedback on the current direction of PG3. As such, there's no expectation that all current node servers will install and run on it. Is there some reason you are running the test version?

Maybe I forgot to upload the new package. I just uploaded it so try again. If you can, test to verify which buttons on the remote correspond to the A-E buttons created for it. You'll probably have to create program(s) with the button press as the trigger as that's the only way they can be used (or maybe as scene controllers, but testing with programs is a bit easier). My guess is that A = open, B = up, C = down, D = close, and E = preset as I think that would match the 3 Button R/L Pico.

You can always go to the PG3 Log menu and select download log there. That will download the PG3 logfile only and if a node server isn't starting, the error will be in the PG3 log, not the node server log.