simplextech

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.

Yes in time. Along with a lot of overhaul to the PG2 version.

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.

Just ran an update as I do whenever a new PG3 is released. The follow packages were included: Installed packages to be UPGRADED: isy: 5.4.0_5 -> 5.4.1_1 [udi] npm: 8.4.0 -> 8.5.2 [udi] pciids: 20220128 -> 20220225 [udi] pg3: 3.0.44 -> 3.0.45 [udi] py38-distro: 1.6.0 -> 1.7.0 [udi] py38-typing-extensions: 4.0.1 -> 4.1.1 [udi] udx: 2.6.0_2 -> 2.6.0_7 [udi] After the install Polisy went into a reboot loop. It would startup, I could login...few minutes and it would just reboot and give the lovely beep during boot.... annoying BEEP. Powered off from console. So far the only resolution I've seen is open a ticket and a remote session?

In-Line relays are plentiful with Z-Wave https://www.thesmartesthouse.com/collections/z-wave-relays

I have 6 First Alert ZCOMBO Smoke/CO Detectors for sale. Reference information link: https://www.amazon.com/Z-Wave-Detector-Carbon-Monoxide-Generation/dp/B08FFB233Y/ref=sr_1_2?crid=2WKIFPQND0CZ&keywords=first+alert+zcombo&qid=1646597325&sprefix=first+alert+zcombo%2Caps%2C184&sr=8-2 All 6 for $120 with free shipping within the US. PM me if interested.

I'm aware that the NS is not installing or updating. The update has no functionality just a version change trying to work out problems with the NS store. There is a store problem with production vs beta packages in the store. Before it was delivering the beta package even for production installs and now it's not delivering any package. The UD developer working on this was informed last night.

I don't know if they will release the API info to UDI. I do know that UDI has been in communication with Lutron as well as I have been.

Again not a valid statement. Read what I posted. Lutron will not provide the API to open source projects or source based integrations aka those derived using interpreted programming languages where one can simply open the program in a text editor and read everything. Nodeservers are NOT limited to source based languages. In fact I pushed my first binary Nodeserver to the beta store last night. Ra 3 integration could also be possible as a ISY integrated module much like the older modules were for ISY where source is not available.

The Ra 3 API is not public. I don't know if it ever will be made public. I do know they have only granted access for integration to the big players (RTI, Control4, Crestron, Savant) at this point. I also know they are not giving this information out to any small players for use in any source based integration or open source usage. With that said I have seen where some people are actively reverse engineering the integration based on knowledge of the Caseta authentication method which is somewhat working but it's still a blind undocumented implementation. I've repeated this multiple times over and over... I get the impression people don't read forums they just post.

As with anything assumptions are bad. I've looked at porting it directly to PG3 however the Nodejs interface is lagging behind in development. Not unexpected as the current PG3 development and all interfaces is a one-man show who has way to much on his plate. I've started investigating going back to the Python interface and working on porting one of my simpler nodeservers back to Python on PG3. As this work continues I'll have a better idea of how much time it will take to move the larger more complex nodeservers like the Lutron.

RA2 devices (most of them) are supported on the RA3 main repeater. The PG2 Nodeserver only works with the RA2 Main repeater. At this point in time if someone is on the fence I would buy Radio Ra 2 having the option to upgrade the main repeater to RA3 in the future. That is unless you really must have the Sunnata devices which only work with RA3. Yet if you really must have RA3 and this is a completely new setup and you have the budget then I'm going to say go with RTI Control but that's just me and likely frowned upon here.

There is a big...huge...major change in how integration works from RR2 and the new RR3. It's not going to be simple or easy and Lutron isn't going to just give anyone the keys to be able to integrate. I know RTI has a driver now, and I think the other major players do as well. I know Lutron is not going to hand out keys or allow any kind of "Open Source" integration. That's not happening and they have said so.

And this is all I have to say on that "Matter"....

This is dependent on which system. Some Pro systems are strict about how has access and who doesn't. This is to reduce support on the company. No company wants thousands of customers calling their support about problems THEY created. However not all platforms are this strict. Example with RTI. I sell/install the system and all customer interaction is between me and the client. How much access I provide to my customers is determined between ME and THEM and nobody else. So depending on the customer I may provide a way for them to tinker and do whatever they want. With a contract fee of 4X support cost when they call me to fix what they broke.

No formal announcement because there's been nothing formal. Every vendor has been going through shortages and delays. You think others are any better? I just placed a Lutron order and my supplier told me it was a 5-6 week back order. I tried to place a RTI order and the supplier is out of stock with no ETA on what I ordered.

There is no end-user web interface or any access to the system beyond what the Installer developed for the user. Can it have a web interface? Yes if one was developed by the installer. Typical interfaces are through hardware controllers which are table top or wall mount. Hand held remote controls or via the Mobile apps for iOS/Android or the PC based Virtual Panel interface. RTI is custom to each and every installation. There is no "cookie-cutter" interface.

I'm an RTI Control and Lutron certified dealer/installer/developer among other vendors I work with and Z-Wave certified installer. So a little experience. @lilyoyo1is the resident Control4 guy if you have questions on that.