Goose66

Look at the log files for the individual node servers. Are there entries at the bottom with timestamps corresponding to the last time your tried to start them? If not, look at the PG3 Log (via the "Log" menu item at the top right of the dashboard). Are their items in the PG3 Log with timestamps corresponding to the last time you tried to reboot or start a Node Server? If so, DM the log or a log package to @bpwwer.

There are several interwoven points here, so I will enumerate for the sake of clarity: 1. You point out a valid bug in the node server that also appears in the PG3 version: the hostname (often IP address) and token are stored in the node for the bridge, tied to a specific node address. Once the hostname and token for the bridge are stored for a particular node address, they can't be changed. If the actual hostname/IP address or token for a bridge changes, connectivity to that bridge will be lost. Adding the IP address and token in the configuration parameters won't help, because these are only used in device discovery to find Bond Bridges that won't or can't respond to the discovery broadcast messages. 2. Moreover, if you perform the Discovery process again (with or without configuration parameters), while it should find the bridge at its new hostname, it won't add the bridge node because a node already exists with the bridge address (the bridge address is derived from the bridge ID in a deterministic manner). I will add code to allow it to update the hostname and token in these situations in a future version (but read on). 3. A couple of notes (to be added to the Release Notes): a) you should add an IP address reservation in your router or DHCP server for your Bond Bridge (just as I recommend for all of your home network and automation devices) to prevent this from happening; and b) if this does happen, delete the bridge node from the Polyglot Dashboard (which should remove it from the ISY as well), restart the node server, and then perform the Discovery process again. This should be a low impact change since the bridge node and device nodes should all be added back with the same addresses, thus your programs and scenes should all work the same (but read on). 4. However, if the firmware of your Bond Bridge has been updated from the 2.X branch to the newer 3.X branch, it is possible that the bridge ID and device IDs have changed due to changes in the firmware, and thus re-performing Discovery will add them back with different node addresses. Accordingly, in this case, you will have to adjust all scenes and programs to utilize the new device nodes and bridge nodes (but read on). 5. If the firmware of your bridge is updated or has been updated from the 2.X branch to the 3.X branch, the PG2 version of the node server will stop working because a change that Olibra made in the API in the 3.X firmware branch. This has been fixed in the PG3 version, but I doubt I will ever add this fix (or any future fixes such as #2 above) in the PG2 version since Polyglot v2 has been deprecated by UDI. In summation, if you haven't updated the firmware in your Bond Bridge, then deleting the bridge node from the Polyglot v2 Dashboard, restarting the node server, and re-performing Discovery should work. If you have upgraded the firmware to the 3.X version, you will need to upgrade to Polyglot v3 to continue to use the node server. As far as not being able to delete the node server from Polyglot, this is likely a Polyglot v2 problem and not a problem with the specific node server, but you probably won't be able to get any support for this issue since Polyglot v2 has been deprecated.

This may be a quirk in Polyglot. Let me look into it deeper.

If you can, please add some screenshots of the Admin Console interface for building the program, including the pull-down with the available values.

Are you sure you have the new version (v3.0.10). It still seems to be reporting CLIHCS with the wrong UOM (66 instead of 25).

@bigDvette I may have found the issue, and I have uploaded a new version (v3.0.10) to the Polyglot Node Server Store. Unfortunately, cannot test it since I no longer have the thermostats. Let me know if this resolves the problem.

Can you attach some screenshots of what you are seeing in the programming interface?

The short answer is “not at this time.” The MyQ node sever utilizes a hack of the API the MyQ app utilizes. This is not public, undocumented, and changes every year or so, requiring updates to node server code, thus the annual “subscription” for the node server instead of one time $10.95 like my other node servers. The subscription for integration of MyQ with other home automation platforms is new. If this ends up being a public, documented API that we can use for integration with the node server, that would be a better solution, IMO, and we may want to convert the node server over to it. I would probably just change the pricing of the node server to perpetual, in that case. I also note that the subscription for third-party integrations appears to be $12 a year ($1 a month), not $10 a month. Looks like the more expensive subscription is for their cameras - mainly long term storage of video.

Excellent. @rwsani99 You can reinstall the node server to get the latest version and clear the error using the method above, or just let the current version run until Bob has v3.1.15 of PG3 ready for release. Hope that helps.

In the meantime would it help if I went out and just uploaded a dummy upgrade with a new version (e.g., v3.0.11) to the Node server Store?

@bpwwer Does the "Error: notices doesn't exist" tell you something?

Somebody else had this problem last month. It was resolved by upgrading Polyglot v3 from 3.0.X to 3.1.X. If you are running ISY on Polisy, in the Admin Console use the "Upgrade Packages" button under the "Configuration" tab to upgrade all of your software, then log into PG3 and select "Restart Polyglot 3" from the "System" dropdown menu.

The ZMatter board is just a ZWave and Zigbee (IEEE 802.15.4) radio. What it will provide in terms of Matter to the ISY on Polisy is the ability to communicate with devices that utilize Thread. Everything else for Matter support will involve software in the ISY. This means all of the Matter standard-defined device types, functions, and resources and the use of the TCP/IP stack to communicate with the Thread devices via the ZMatter board. Thus, as I said, I expect the first iteration to provide the ability for the ISY to show nodes for Matter/Thread devices alongside nodes for natively supported devices (i.e., Insteon and ZWave) as well as nodes provided by node servers for external devices. Once all the software for support of Matter/Thread devices is in place, however, it seems trivial to add support for Matter devices over other transports/links, such as WiFi and ethernet. That said, any support for non-Thread Matter devices won't be hardware-based - it will be all software in the ISY. And, if there was some unforeseen reason for UDI not to implement this (e.g., licensing, certification, etc.) then perhaps a node server could be developed to provide this support through a "hack," similar to how many other devices are supported. Of course, this is completely different from the question originally asked by the OP and speculated about herein by others which is the ISY acting as a Matter hub/bridge for Insteon devices (not going to happen, IMO). Also, it's worth pointing out that Thread is not a Matter-only thing. Devices already exist that use thread to communicate with HomeKit, BACNet, etc.

Except no one knows how it will work! 😆

Here: Matter was designed to make automation devices (switches, lights, thermostats, sensors, etc.) available to as broad a range of controllers and ecosystems as possible. That's its raison d'etre. Again, nobody is arguing that ISY won't support Matter devices or that ISY shouldn't support Matter devices. The question is whether ISY will act as a hub to provide Matter-compatibility to Insteon devices. As far as no one being able to answer questions on anything because no one knows, it's true that only Michel can speak with any authority as to what UDI will implement and when. However, when it comes to what Matter is and how it works, this is all pretty well publicly documented at this point. There's not a lot of speculation left to be had on what Matter is and what it does. If you want to understand what Matter is and work out use cases for yourself, there's lots of discussion, documents, videos etc. on CSA's website at https://csa-iot.org/all-solutions/matter/

I think you are missing the finer points of the discussion. This is not about the success or failure of Matter or whether manufacturers will do something to make it not work the way you want. It is a discussion of what Matter is defined as by the CSA. Will it be successful? Who knows, but it's not really germane to the present conversation. As far as the ISY exposing devices via it's REST and Webservices interfaces that you refer to above, the ISY must already have connectivity to those devices and have abstracted them as "nodes" in the ISY ecosystem for the devices to be exposed externally. I think certainly this will be the case for Matter devices that are connected via Thread through the ZMatter board. But that is very different than the ISY having access to all Matter devices in a site/location/home, or the ISY making Insteon or Zwave device nodes appear as Matter devices to other controller/ecosystems in the site/location/home, which was the original question posted.

The "controller" logic remains in whatever ecosystem is already in place. So if you already use Alexa, then Alexa works with your Matter devices the same way as it does with your current devices, e.g., Hue bulbs. And if you rely on HomeKit (which includes some local functionality albeit in your phone), then HomeKit controls the Matter devices. Etc. The primary goal of Matter is to create an interoperability standard for end-point devices (lights, switches, sensors, thermostats, etc.) so that the devices will work across ecosystems. Thus supporting companies can continue to develop their ecosystems and ecosystem-specific devices (e.g., Amazon Echo devices) and market them to more users, because those ecosystems will work with more endpoint devices. And those same users can move from one house to another (or, more appropriately from a Matter point of view, from one apartment to another) and take their ecosystem-specific devices with them and they will work with the endpoints in the new house/apartment. This also allows builders/developers to start adding home automation devices to their buildings as features while having some assurance that they will be supported by at least the big-3 home automation ecosystems out there (Amazon, Google, and Apple).

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.