simplextech

No the question was if you had a previous version of ST-Inventory running making this an upgrade to that pre-existing NS or if this was a new install. Is the Polisy new? Is it up to date? Do you have any other NS running, specifically any other Simplex Technology NS defined with ST in the beginning of the name. The error in the log is clear that the Polyglot API is not current which would cause the NS to fail on startup. What is unknown is why this would crash the entire ISY as you have stated it did.

I'm afraid I don't know how a NS is crashing the whole ISY. I recommend you opening a ticket with UD support about the ISY crashes. The log however does show that the Node.js Polyglot API is not a current version and needs to be updated. Were you running ST-Inventory before and then updated to the newer version? If so then it would seem that the Polyglot API is not being updated on NS updates or installs which is a problem outside of a single NS.

I'm not sure. I'll have to look.

This should be possible through programs.

That is interesting. Please do send me a private message and attach the log file to the message. Do you have any other Sonos players besides the Roam?

It is what it is. It's a inventory list of the nodes and devices within your ISY. Common use by many was to know how many nodes were in their ISY994i and whether they were close or over the node limit. If they were they knew what was now causing node add failures and they could upgrade to the ISY Pro. Knowing how many devices of different types is just a metric that many find useful or interesting. The error log entries was added from a request as it is good to know and then clear the log so it doesn't continue consuming system space.

Looks like the speaker was not available (likely after the firmware update/reboot) and at the same time (during the restart) a connection failed. I thought I had caught everything around the speaker restarts. Looks like something is not being caught.

They need to be placed on the file system on Polisy. Example: /var/polyglot/pg3/ns/00:0d:b9:4e:37:d0_4/node-sonos-http-api/static/clips Replace the Node Server 00:0d:b9:4e:37:d0_4 with the location that matches your installation.

Sounds good to me.

Interesting. This gives me a thought that perhaps there should be a forum for Node Server requests? @Geddy any thoughts on this?

Two of the errors (log level) are debugs that I left in and should remove. The other "error" related to the Node not found is because of the async nature of changes/things happening and the nodes not being created/existing just yet. Things have to "catch up". Initial "status" of the Nodes is set when they receive information related to them. So not all nodes will have any information if nothing has happened from that Node/Speaker yet.

I'm not aware of any native Sonos capability for 'fade to off'. Might be able to simulate one with a program or could be a simulated addition that could be done within the NS code and taking fade time as a configuration parameter and lower the volume at pre-defined increment until it hits 0....

Welcome. I went through and changed all nodes to report proper status (ST) for those that like looking at the overall system status from the primary ISY node in Admin Console

Do you have a Personal Weather Station or plan on getting one? If you do then use a NS based around your PWS. If not then use a NS based around a Weather service you prefer. @bpwwer is the defacto "Weather Man"

No... Pi Zero will not work. If you can't source a rPi 4 then go for a Odroid which is supported by easy installation. Another alternative (more work to install Home Assistant) would be a Rock64 board. When in doubt... read the docs: https://www.home-assistant.io/installation/

Lutron does not make any z-wave or wifi switches. Are you perhaps confused with Leviton?

Once a few things on my plate get stable then I'll definitely be reaching out as I port the node server to PG3 and determine the best route of doing so to support legacy and New devices.

Hmm... I've seen this type of behavior from another "hub" that's very popular... usually it was caused by some "bad" read really cheap devices which were not actually Zigbee ZHA but still had a label they printed..... In the world of Z-Wave/Zigbee a bad device can wreck a mesh network and a poorly implemented gateway stack (Z-Wave or Zigbee) on the "hub" can ruin the entire experience.

They are highly configurable indeed which can also be a problem for integration. I like the CoAP and the MQTT integrations. The problem with MQTT integration was the need to also have a MQTT broker also integrated with the node server and as such it would almost be like having 2 node servers to achieve one goal. This route posed somewhat cumbersome and problematic. Also NOTE that by using MQTT it disabled the "Cloud" access which disabled the Mobile App functionality which most people would prefer to also have available. So with these issues I went the route of using the HTTP interface and the Shelly "Actions" to provide instant feedback to the ISY. This has proven to work very well in practice. In order to overcome the large amount of options and configuration that is what is taking the most amount of time. Building those features in a way that works within the ISY Admin Console Interface and for each device. So yes this one is taking a long time to get right and be ready for people. Now with the porting to PG3 that has added some well... challenges and my attention is diverted to working with other developers to get PG3 ready before I put work into my own node servers.

The issue with standard consumer combo wifi/router issues still exist with any wifi devices. I think there are some innovations in this regard in the pipeline (can't discuss) so we'll have to wait and see. An interesting thing however is that URC has now included Shelly devices as standard supported devices. This was announced in CEPro a month or two back and was intriguing. I also have a RTI driver in the works along with the Polisy node server. My current attention lately is with the Polyglot node.js interface and once that's done I'll begin the porting and updates to my other node servers.

Whoa there... hold up just a second.... Shelly devices do NOT need to be flashed to be integrated. I have a node server in development (for a while) that works with Shelly devices out of the box with limited user input (basic config info) for each device. I do think you are thinking of other common Wifi devices that people flash with Tasmota firmware. This process is NOT needed for Shelly devices. Just wanted to clear that up before this goes too far off the rails.

I can confirm this as I do speak with Doug semi-regularly and I did ping him after I saw a post on here about issues with support and delays. Doug is a good guy and just getting his feet wet here in the forum so play nice guys!

It's great to see you here @Doug Roberson. I'm sure a presence from Shelly will go far within the community.

I worked with @Michel Kohanimthis afternoon and tried running a manual update but both failed in my case. He's sending me something in the mail. Not sure if it's a pin connected flasher for the chip or a new Polisy. It'll be a surprise ?

@larryllix yeah sounds familiar. Likely same old chip as I have one of the very early release Polisy boxes.