Goose66

Exactly. Will the ISY act as a Matter hub for natively support devices (Insteon and ZWave) and expose them on the network as Matter-compliant devices. Similarly to how matter support for Philips Hue bulbs won't be in the devices, but implemented in the Hue Bridge, i.e., Matter Controller-(TCP/IP)->Hue Bridge-(Zigbee)->Hue bulb, instead of Matter Controller-(TCP/IP/Thread)->Hue bulb. That is how I interpreted the OP's question, and I suspect the answer is no.

One confusing thing is the use of "Matter" to refer to both the application layer protocol known as "Matter" and one of many link layers available to Matter known as Thread. Thread is a wireless mesh networking standard defined by IEEE 802.15.4. While it uses the same physical communication channels as Zigbee (same frequencies and antennas and such), the network protocol is TCP/IP instead of the proprietary Zigbee protocol (Matter relies on TCP/IP protocol for all supported link layers). Thus, from a purely practical standpoint, the ZMatter board from ISY is more of a Thread board than a Matter board. Given that, there are several functions UDI can implement via software that will utilize their ZMatter board: 1. It can give ISY/Polisy access to Matter-compliant devices over Thread. These devices would show up in the ISY as nodes right alongside Insteon, Zigbee, and ZWave devices. "Integration" between devices would be accomplished using the ISY ecosystem functions of Scenes and Programs. This is what I expect to see in the (at least initial) ZMatter support. 2. In addition to #1, the Polisy could act as a Thread "border router." This would allow it to take communications for Matter devices from Wifi/Ethernet and bridge them to the Thread mesh network. I don't know if UDI will implement this type of functionality, but I suspect there will be plenty of devices becoming available with Thread border router functionality (Home Internet routers, Amazon Echo devices, etc.) 3. The Polisy could act as Matter "hub." This functionality would allow natively supported devices (Insteon, ZWave, Zigbee(?)) to appear as Matter devices on the network, which would allow Matter controllers access to these devices for control and automation (along with the ISY control). I don't expect to see this functionality added. Also, independent of the ZMatter board, UDI could implement support for Matter devices over other transports, such as WiFi and Ethernet. This would allow the ISY to act as a Matter "controller" (a thing in Matter) and show Matter devices as nodes alongside nodes for native/node server supported devices, providing integration between these devices with Scenes and Programs as discussed above. This seems like a natural extension to implementing function #1 above, but it may not appear in the initial ZMatter support. Matter support could also be accomplished with a node server in Polyglot, but because Matter is already an application layer with all the standards, device types, and lower level support defined, it seems a node server would be an unnecessary intermediate layer.

The node server in the PG3 Node Server Store is called EnvisaLink-DSC. Both the EnvisaLink-DSC node server and IOGuy’s Nodelink require you have an EnvisaLink EVL4 or Duo connected to your DSC panel for access by the node server.

So you are saying adding the Matter/Zwave board to your ISY will allow the ISY to act as a Matter-> Insteon bridge so that Matter-compliant controllers and devices to integrate with Insteon devices controlled by the ISY? Can you point me to that information? Not trying to be argumentative - actually very interested in reading about that capability.

Which may leave us ISY/Insteon users out in the cold since the ISY bypasses the hub and goes straight to the device through the PLM. So either UDI implements bridge logic (which I don’t see happening) or IDI migrates away from “native” Insteon support in the ISY to support through the Insteon Hub (perhaps via a node server), and I don’t see the latter happening (nor do I want it to happen) until Smarthome offers a local, two-way API to the hub.

I assume you are asking whether the ISY will act as a bridge for Matter to Insteon devices. I suspect at least a first iteration will likely provide access from the ISY to Matter-compliant devices over Ethernet/Wi-fi and Thread (IEEE 802.15.4). Integration and interoperability between Insteon devices, ZWave devices, and Matter devices would be through ISY scenes and programs. A hub to bridge Insteon and ZWave devices to other Matter-compliant controllers and devices may be out-of-scope for UDI, since they aren’t really the keeper of these mesh standards. That said, at least for Insteon, if UDI doesn’t do it, I doubt it will ever be done.

This solution won't work, IMO, and reveals a weakness in the ISY programming model that has been debated for years now. The problem with this simple solution is if the Lamp is ever turned on by, e.g., a switch or another program, it will just turn off again. This is because the change in Lamp Status will cause the program to run, and the Else branch will be executed because there has been no motion. This problem needs the two program solution that has been discussed extensively, with numerous examples in this forum and in the wiki. Basically, the first program is ENABLED, checks for motion ("If MS control is switched On") and runs the second program in the Then branch. The second program is DISABLED and toggles the state of the Lamp ("If Lamp status is OFF Then Turn Lamp ON Else Turn Lamp Off.")

Yes. I do something like this in most of my node servers. The idea is that if you have power failure, waiting until the first short poll gives other devices and network components a chance to settle before attempting connection. Also makes for automatic reconnect when a connection drops for some reason without the user having to restart the node server. Like you said, restarting the node server is an exception condition. It’s design just to run undisturbed for weeks.

Right. This a product of the connection to the EnvisaLink being checked in each shortpoll and being reestablished if the connection has been lost. From the Release Notes: The node server relies on this for the initial connection as well. So when the node server restarts, the connection to the EnvisaLink and the processing of status messages won't start until the first shortpoll.

The JSON file error is OK (always been there for this node server. Hope to see a a fix in an upcoming version of PG3. If you can DM me a log package, I can take a look and see what’s happening.

@macjeffIs the node server functioning?

What are you seeing to suggest that? Because those log entries don’t seem to point to anything to me.

The OnQ boxes on Amazon were exactly what I was looking at. I was just wondering if anyone had put the Polisy, PLM, and maybe a UPS or transformer all in a box like that and what the performance was. It would certainly be nice just to mount it on the wall open like @Geddy's picture, but I don't think that would fly with the wife - especially if it is in the hallway. I particularly like the built-in bubble level. Can't have the whole thing tilting and all the electrons pooling on one side! 😁

My new townhome has sufficient living space, but significantly less utility closets and unused/dead spaces than my house did. I need to install my Polisy Pro (destined to include ZMatter board) in a central location in the home - perhaps a laundry room or hallway. It needs to be installed with an Insteon PLM and a small Li+ UPS (like the TalentCell unit). WAF probably requires that it be installed inside a box, either one flush mounted in the wall or perhaps surface mounted (if in the laundry room). Has anybody had experience with mounting a Polisy with Wi-fi and/or Zwave radios inside an enclosure and/or wall mounting such in a visible location, and what solutions have you found?

Note that the TalentCell comes with a 2A power supply. It’s fine for ISY (and probably Polisy) and keeping the battery charged. However, if you’re going to run more things off it, you will need to up the amperage of your 12v PS accordingly.

So the initially reported version in the Dashboard on startup comes from the local database entry in PG3 database. But a few moments after startup, the Dashboard shows the version indicated by the running node server code itself. I had one that was doing what you described, and it was because the code package specified with the new version either wasn't being found or failing on unzip/install, and what ended up being started was the older version, despite the fact that PG3 thought the new version was installed (in my case it wasn't finding the specified zip file on the Node Server Store servers). Choose one of them and work with the node server developer to go through the log package and see if you can troubleshoot what is (may be) failing on the installation of the update. WRK

Update PG3 using the Admin Console in IoP - specifically "Configuration"->"System"->"Upgrade Packages."

@Panda88, if you are running the Python interface for your node servers, you can drop the server.json file and just pass a version string on the poly.start() call. That way, there are only two places (Node Server Store purchase option(s) and version string passed to poly.start()) that have to be kept in sync.

This is a question for @bpwwer.

I recommend the TalentCell Mini UPS: https://www.amazon.com/dp/B07WLD32RP?ref=ppx_pop_mob_ap_share

I have released the PG3 version of the iAquaLink Node Server (v3.0.9). The iAquaLink node server interfaces with the iAquaLink™ cloud service to allow the ISY to control Jandy® AquaLink® pool controllers and accessories. See https://www.iaqualink.com for more information on iAquaLink™. Installation instructions, release notes, and version history can be found here: https://github.com/Goose66/NSDocs/blob/main/iaqualink-pg3.md There is a 1-month trial period and an annual subscription price of $10.95. Similar to MyQ, the subscription price is for keeping up with the occasional breaking API changes that Zodiac makes.

It was a team effort!

@Chris McKean Please try upgrading your version of PG3, then reinstalling the node server. Send the new log file if it still fails.

@Chris McKean Also, please send a new log package with the attempt to reinstall the Bond node server.

Yes, the error is caused by the fact that the 3.X firmware on the Bond Bridge introduced something in the API that breaks the 3.0.9 version of the node server. So the problem here is that you can't upgrade to the 3.0.10 version, but I don't understand what the problem could be. Others were able to successfully upgrade to version 3.0.10 without problems. What version of PG3 are you running?