Guy Lavoie

No reported Matter pairing yet (or if someone did, they're so excited that they forgot to come and tell us!) The mention of wifi settings change was within the eisy itself, to get it working with Matter. I'm theorizing here, but with a controller like the eisy having both hardwired and wifi connectivity, the vast majority of those using it hardwired will already have a wifi router in their setup (who doesn't have wifi at home now?). Remains the Thread support: Some (most?) will probably have a border router somewhere. If not, the ZMatter dongle should provide that capability, at least between the eisy and devices. Most of us will likely get the dongle anyways because it's the only way to get Zigbee. In theory, the eisy could also act as a border router, device to device. Matter is IPv6 whether it's wifi or Thread, so it's a simple packet forwarding function. Maybe there will be a configuration checkbox to turn on routing.

Oops, look like I got ahead of myself. The QR code isn't just an encoding of the PIN code. Other than including some additional information (Vendor ID and product ID) there is also Base38 encoding. Detailed information here: https://www.matteralpha.com/article/how-does-matter-qr-code-work

Join the club. If anyone has had success, they haven't said so here.

You can create a QR code here: https://qrfy.com/?utm_source=Google&utm_medium=CPC&utm_campaign=17317470455&utm_term=make a qr code free online&gad_source=1&gclid=CjwKCAiA5pq-BhBuEiwAvkzVZfy_UW8SDHl3_jj1ioTPcJ5J-vaRQYxDKxsh6VysN1mk_7Pd19OsphoCPfQQAvD_BwE Just choose "text" and enter the code as text, as I've done here:

Wikipedia has some links, and describes the evolution of the standard from it's beginnings. There is a link to github for developers https://github.com/project-chip/connectedhomeip There is a certification process, etc. Read up on Matter here: https://en.wikipedia.org/wiki/Matter_(standard) For most of us here (as UDI users), having Matter compatible node devices is almost secondary, as we'll already have our systems established around one or more existing technologies, whether it be Insteon, Zwave, etc. Matter isn't really introducing any new topologies. Again, the appeal of Matter is interoperability of existing systems. If you have both Google Home and Amazon Alexa devices, you'll be able to get them communicating more easily, without reverse engineering, plugins, etc. You'll also notice that UDI's announcement mentions "HomeKit plumbing". That must be linked to the addition of Matter support. Apple has always been the outlier. The fact that they're part of the group that got together to create Matter will only help in making home automation more consumer friendly and widespread.

Long press? In UD mobile? You should look for them in the Admin console.

You can find Matter command stuff here: https://community.silabs.com/s/article/Implementing-custom-commands-for-the-Matter-CLI?language=en_US And no, we don't necessarily need new hardware to send and receive commands. Matter is implemented using IPv6 over hardwired, wifi, or Zigbee physical layers. No new physical layer has been introduced along with Matter. Yes, it is a standardized way of interrogating a device to find out what it is, and what parameters it will accept. That's the whole attraction. Up until recently, each protocol had it's own, often proprietary way of doing things. Serial bytes to a PLM to send Insteon, various command implementations sending data over Zigbee and Zwave. Raw bytes to an IP port to send data to various hubs. Then things started to use more similar network layer implementations to save on costs, like HTTP for Venstar and Ecobee thermostats, Hue hubs, etc. Various forms of security too. The physical layers also become more common (like Zigbee and Zwave), but the commands sent across these physical layers were still proper to each device, and often undocumented. Then in 2019 (from the wikipedia article on Matter): In December 2019, Amazon, Apple, Google, Samsung SmartThings and the Zigbee Alliance announced the collaboration and formation of the working group of Project Connected Home over IP. The goal of the project is to simplify development for smart home product brands and manufacturers while increasing the compatibility of the products for consumers. Finally, lets get our stuff to talk to each other! The idea was to create a high level API that allowed common commands to be sent to each other's platforms. It might not implement every single feature, but each one could decide what to allow (expose) to be done by "foreign" controllers. That way they could still compete on finer exclusive features. For example allow lights to be turned on and off, dimmed, and set to a color. But things like animation, scenes etc could be restricted to the native platform. We often see that in product feature descriptions. Now with a controller like the eisy, UDI does the implementation of the commands needed for each protocol. They first did Insteon and X10, then added Zwave, then Zigbee, and now Matter. For us users, it always comes down to the same simple command, such as Turn <device node name> On That's what we pay them to do for us 😀

That's the whole reason why we (UDI controller users) are interested in Matter: because it's the first industry lead effort in interoperability. Go look at the dozens of smart bulb products available. They all boast "Works with Alexa" and "Works with Google Home". They all show a free phone app that you need to create an account for. But count how many of those have an open, local API? How many can you include into a scene command launched locally by your controller? Very few. Right now, Matter compatible products are rare. But give it a year or two and they should become as common as those Alexa compatible products. Many smart products are already IP compatible, so they just need new software. The Hue hub is a good example of acquired Matter compatibility. Having Matter compatibility in our favorite controller now gives us futureproofing.

That's the right approach. You've hit upon the one exception with true/false testing: a test for a state variable being greater than or less than a value will retrigger true every time that the variable itself changes value, along with the logic test itself being true. So you are doing the right thing by setting a second variable to one of two values, as a flag that your conditions are met.

You can't have a scene trigger another scene (though it can be done with a program and using the Virtual plugin). Instead, you should simply create a new 3rd scene, that involves all the lights that you want it to control. Individual lights can be responders to dozens of scenes if you wish.

To my knowledge (from what I've read on the forum since the release of 5.9.1) no one has successfully added a Matter device yet. We all get that kind of error when reading the QR code. I have these two test subjects on hand myself: the Cync bulb is Matter over wifi, the Nanoloeaf is Matter over thread. They both work with their phone apps (Nanoleaf over blutooth) For the Thread bulb, I don't have a border router yet (keeping an eye open for a deal on a used 4th gen. Amazon Echo) though I would think that eventually, the ZMatter dongle should be able to do that directly.

It's only there if you're using the ZMatter dongle. If you have the Zooz dongle, there is no backup option in the menu.

If a common cause was identified, it wasn't mentioned here... But it's interesting that only some Polisys got bricked, and no eisys as far as I know.

Instead of using "control" (is switched on) use the "status" for the If command. That way the Wait statement will execute for it's time interval. Test it with a short time initially, like 15 seconds.

https://bondhome.io/product/bond-bridge/?srsltid=AfmBOorgH_cOydFlDoW4OqUwL9_0NPRQfd2bycSXlSLF6FhhDMW0Jnqs Not sure if it can learn new devices, or if it can be controlled via a local API

That's neat, and I think we all learned a bit more in the process 😀

Interesting, thanks. So a keypadlinc toggle button sends dim commands if you hold it down. I'll experiment with that.

Well, could you explain how the keypad (a Keypadlinc?) button is configured. We might learn something here.

For Alexa, see here. Scroll down to Using Alexa Routines https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3#ISY_Can_Talk_To_You.21_.28Alexa_Routines.29

Well how are you doing it? Triggering scenes? That would work. But he wants real time control, manually.

It's the fact that you need to use a program at all that's the limiting factor. Dimming is usually a realtime thing that you do manually and intuitively, and doesn't lend itself well to translation. Take someone who speaks English fluently and someone else who speaks French fluently, and now add a translator between the two. The fluency is lost.

Well that's it, this is an early attempt at implementing it, and is even labeled as being beta. It's an opportunity for us to get up to speed early on as to how it will work. I bought that Cync bulb for the very purpose of familiarizing myself with Matter, because it looks like over time, this should become as common as "works with Alexa" and such on packaging. I've already managed to get that bulb working with a Google mini speaker, and the learning experience has been very productive. Because Matter is being presented as an interoperability standard (and not another communication protocol like Zwave or Zigbee), this is of particular interest to people like us, who like the UDI controller because it is already a unifying component for us. Insteon, Zwave, etc all brought to a common level (nodes) that we can program with. For the longest time, we've been patching together these independent ecosystems with solutions like the eisy. For the first time, the automation industry itself has finally recognized the interoperability problem and has actually done something to address it with Matter.

Since translating your intentions from an Insteon dimmer to a Hue bulb requires using programs, there is no easy solution. You could try creating a bunch of programs, each one for a range of desired dimming, but you're still stuck without real time control, because of the way Insteon sends the final dim level as previously mentioned.

Fading up and down in real time isn't very likely to work with programs because when you dim an Insteon switch manually, it only sends the new, final dim level when you let go of the paddle. This means you'll be limited to detecting a dim level (more like a range) with one or more programs, and/or detecting fast on/off commands, and then sending equivalent Hue commands. Things like that. You'd need to post your program(s), to see what it's trying to do.

Well that's better. It wasn't clear from your description. So you're using programs to detect the Insteon switch status, and then send Hue commands via the plugin?