simplextech

Thanks for the log packages and the first log. I took a quick look at them and I have no freaking idea what is going on. The node.js install is throwing errors for node modules that are not directly even in use by the Node Server. What version of PG3 are you running? What version of Node.js is installed on your Polisy? (From the command line ssh session) run "node -v" this will output the node.js version. Top of my head says that something with Node.js is wonky. Could be Node.js version installed and module compatibility or worst case the jishi node-sonos-http-api used by the node server has some serious compatibility issues with the node.js version. Dunno yet.

There's no limit to the number of copies you can run. No reason to run multiples but no limit. Based on the error log something is broken with the xml2js module which parses the ISY data. This could be a module problem or something broken with the node.js install on the polisy. What's interesting is that you mentioned installing in one slot and it works but in another it does not work. This is very odd as node.js is installed system wide but the node_modules are per node server so I think something is not being cleaned up completely when a node server is removed.

Sorry but life and work has been very busy. I only get notified via e-mail from direct messages so I do not see everything in the forum all of the time.

I'll look and see if the Jishi API supports it. If is does then yes I can add it. If not then no.

The say function generates the mp3 file via a cloud based service that takes the values in the Say configuration to create the MP3. The file being generated may be of low quality or volume. I'll have to run a test and look into it. The Clip function may use a local mp3 file which is provided as part of the underlying API being used. This I don't know about but can look into it. Neither Say nor Clip change/adjust volume on their own (or should not) which leads me to think it's the mp3 quality.

What type of file are you playing? This is odd as the clip/say function does not touch volume before or after in the NS.

I'm not running 3.1.2 yet but I did a clean install on my dev box and I did not have this error/problem.

What version of PG3 are you running? I'm running 3.0.63 I just deleted ST-Nuheat and re-installed. It installed and started as expected. Then I went into the configuration page added my auth information and saved the changes. After the save it auto discovered the thermostats. It does take a minute for the node modules to download and install. Are you trying to manually start the NS before the installation is completed maybe?

Since the NS is not starting there's likely a problem with the install. Have you tried deleting it and re-installing it?

Can you provide the log?

It's not about if/how they are related. The existence of Net resources is all that matters. As with the existence of anything in the ISY. Inventory just counts them. Some request for info is returning 'undefined' which is likely a timeout of the request since your ISY is very busy. I'll just need to verify each of the query handlers and make sure they all account for this timeout failure.

I'll take a look through the log and see what I find. The error in the post was at Network Resources. How many of those do you have (if any)?

It's possible. Are you running the latest version that was published after your first round of issues? Code was updated to handle more error circumstances of calls returning empty like this 'undefined'.

Given the amount of programs and activity that could happen at any time on your poor ISY994i I understand. I have made some updates to ST-Inventory adding a 2 second delay between each of the calls and processing to try and reduce load on the ISY994i.

I don't think the trial has anything to do with it. Or I would hope not. There nothing in the code that defines the trial or difference in functionality that's all part of the PG3 Store. There are instances where a NS does not stop correctly and then will not start up again but this is resolved by killing the old process or by rebooting which you did. So this isn't the issue. Before I pushed the update to the store I removed and re-installed my local version and I did not have any problems. If the update process is not working for you then please try a delete of the NS and then fresh install of the NS. If this works I'll have to go back and install an older version and try the update and if there's a problem with the update I'll work with UD.

The nodedefs file for the NS has been updated which should correct the UD Mobile error. A new package has been released to the NS Store and should show and update available. Please keep me informed.

No... that's one of the places. I moved the website and e-mail to a new provider to reduce costs so I'm sure something is broken. I'll have to look into it.

Contact form where?

You rang? I can take a look but I don't use UD mobile nor even aware if it's available for iOS so it will be difficult to test. I'm also not sure what piece is missing so I'll have to investigate.

I can look into timeout handling which is essentially just quieting the log message as it will retry on the next short poll interval. Currently there's a short/long poll. The short poll is the only thing that does anything which is query the ISY. Default should be set to 5 minutes but in your case I recommend increasing that. You'll have to change the long poll which must be greater than the short poll. I have thought about swapping the short/long poll where only the long poll is used. In most cases nobody needs 5 minutes updates to changes within their ISY (Unless they are testing something which they can then use the discover button). So yes in your case I highly recommend you set the long poll to something like 24 hours and short poll to 1 hour or longer. 24 Hours = 86400 seconds 1 Hour = 3600 seconds

I've setup my isy994i and have had ST-Inventory (fresh install) running for the last hour without any problems. I did go back and review the log that you sent and it is interesting 2022-07-16 00:47:18 error: POLY: getInv() Error: http://192.168.200.251:80/rest/programs?subfolders=true 2022-07-16 00:47:20 error: NS: Parsing Error: TypeError: Cannot read properties of undefined (reading 'toString') at exports.Parser.Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:312:19) at Parser.parseString (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/node_modules/xml2js/lib/parser.js:5:59) at _0x242b12.processPrograms (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:5651) at _0x242b12.onDiscover (/var/polyglot/pg3/ns/00:21:b9:02:55:cd_7/Nodes/ControllerNode.js:1:3227) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) This error repeats numerous times. This is not the NS crashing as the log shows the NS continues running and works "most" of the time but then these errors again return. This error is caused because the data received from the ISY is not valid. Most of the time the ISY is returning valid XML data for the inventory calls. However many times the ISY is not returning valid data that is causing parsing errors. This could be resource contention on the ISY and processing of the network calls being made to it or it could be something else. I will make note of this and clean up the error message to make it more friendly about what is happening.

I'll clean up my Polisy and setup an ISY994i and test against it to see if I can replicate the problems.

Now this log is much more interesting. Are you running ISY on Polisy or a ISY994i? This log is showing intermittent success/failures for various inventory aspects.

It does not matter how many times you remove and install at this point as the Polyglot Node.js Interface is not the correct version on your Polisy. At this moment I do not know why the interface was not updated with the NS install. I'll see if I can find some time this weekend to investigate and see if I can replicate the problem.

No they are not related. However your previous problems tell me there's some other problem as I've not heard/seen this type of behavior from anyone else.