Guy Lavoie

Also, you mention getting it in 2022 at the time when you got the Polisy. There is a thread in this forum section about an update from Zooz for that stick. Maybe that could make a difference.

And you're certain your Zooz stick is a 700 series?

Oops, I made a mistake in my post above. If you see an option button for "Migrate to ZMatter Z-wave" in the config screen like the one below, then you're set up to use the Zooz stick. If your config screen looks like the one in Techman's post, then you're set up to use the ZMatter dongle. If you are indeed set up for ZMatter and want to change it back for Zooz, then do this: From a browser, go to the following URL: http://<your_IP_address>:8080/rest/zmatter/zwave/deactivateZMatterZWave

I have the Zooz 700 stick on my eisy, running 5.9.1. Works fine. If your config screen is showing a check box to enable Zigbee, then you need to "roll back" the Zwave configuration from Zmatter in order to use the Zooz stick.

Well, this is an added functionality, so no real impact on existing systems. Add to that the fact that the eisy is very much a techie oriented device, and even more for forum participants. Several of us are more than happy to jump in and learn Matter at the same time.

That's a question that comes up now and then. I don't have an official answer but my theory on it is that yes, messages would be passed on. Contrary to Zwave and other networks where devices are "included" into the network, Insteon is based on direct links between devices that need to talk to each other. There are no required links to intermediate devices to create the mesh network. It is a well known practice to use lamplincs to help powerline only modules like the iolinc with reliability, even though you don't need to set up any links to the lamplinc itself. Even Insteon (the company) mentions doing that as a workaround in their recent webinar.

One little hiccup I've come across: yesterday the wifi bulb (Cync) stopped responding to commands from the Admin Console, but was still working ok from the Google Home app (from which I shared it). Same thing today. So I deleted it and redid the share from Google Home. Let's see if it lasts longer this time. The Matter sharing codes are only valid for a short period: 15 minutes with the Hue app, 15 minutes with Alexa app...and only 3 minutes with Google Home. Because I'm emailing myself a screenshot of the code to scan it, this is kind of tight. Google should loosen up a bit.

That problem comes up every now and then. It seems no one has created a zwave extender that could work over ethernet, or something similar. It would be handy as a distance bridge, with one module at each end that could convert zwave to ethernet and vice versa. Assuming you have wired ethernet across that gap, you'd need a eisy at each end, or even find an older isy994i that has a zwave board in it, that you could then control via REST commands from your in-house eisy.

You can't have two Zwave adapters or networks on a single eisy. What would be the advantage of having a separate Zwave network for the garage?

What type of phone are you using, Android or iOS? My tests have been with Android. Tried upgrading to 5.9.1_18?

Yup, updated to _18 and added the nanoleaf bulb. Only thing I did different is that I shared it from the Google Home app where it was already configured. Contrary to Alexa and Hue, The Home app offers both a QR code or pin for sharing. So I emailed myself a screenshot of the QR code and scanned it off my PC screen (I only have one phone).

It's normally port 8443

I'll certainly try that! I had the same thing with the Cync bulb: just on/off functionality even though it's a dimmable bulb with colors. One step at a time...

I have Weiser Zwave locks. You configure it as any other device (from the "My Device" list, and then select "Lock" as the Alexa Category. Alexa is then smart and secure enough to allow locking with voice command, and if you ask for unlocking, she tells you to use the app.

When you click on "Save" in the IoX Finder screen, it saves everything you see in the URL box. Ip address, port, directory. then if it ever comes up blank, I click on "Load" and it loads back the settings.

With what I've learned above (and with my limited Matter devices on hand) I dragged out my wifi Cync bulb again and added it to my Google Home mini with the Google Home app. Then I shared my nanoleaf bulb (still configured on the Amazon Echo as a Thread device) to my Google Home app using the pin code provided by the Alexa app. Worked like a charm, I can control both bulbs from Google Home. That also shows that the border router in the Echo is doing it's thing. 😀. Lets keep a good thing going...opened up the Philips Hue app and went into the Smart Home settings. There are 3 options for Matter sharing: With Amazon Alexa, Google Home, or "other". Tried selecting Google Home, which opens up the Google Home app...but nothing happens. Ok, stepped back and chose "other" instead. That gave me a sharing pin code and I used it to add the Hue bulbs (adds all 9 in one shot) to Google Home just like it did with the nanoleaf bulb. All bulbs can be controlled from Google Home. Matter works. I'm basically where @oberkc is at. I'll leave my test setup like that as I await the next update from UDI 🤩

The command format is well documented: https://wiki.universal-devices.com/ISY_Developers:API:REST_Interface The hard part is generating it with whatever you want to use to send it. The easiest is from a browser on a PC. Sending it from an app on a phone (which I haven't done myself) will be more work.

UDI would like you to open a ticket for that problem. They'll get your controller recovered.

I just read through the explanations of the various Matter components in the matter-smarthome above. It cleared up so many things and assumptions! It should be posted as some kind of sticky post at the top of the ZMatter forum section. So a "fabric" is essentially a group of devices that are initially commissioned to the same controller. The big feature of Matter is that any given device can belong to at least 5 such groups, so unless you have a huge number of devices and initially set them all up with a bunch of different controllers (that would be a nightmare) and then try to link the groups together, you can safely share them to a few previously created groups (or fabrics) without problem. I like that. A further constraint is that devices are shared on a single device basis, so lots of work if you're trying to link two groups of several devices. I wonder if some systems might allow some kind of one shot group share. It also clears up the purpose and usefulness of the nanoleaf app. Other than allowing direct bluetooth operation of the lights ("works without a hub!"), it's handy for viewing and upgrading the firmware in the bulbs (currently 4.1.3) and viewing the thread network that the bulb belongs to once commissioned by a controller, and plays no role in assigning or connecting to a network, because the app itself isn't used to commission a bulb to a controller. I have 6 of these bulbs, so I upgraded them all to the latest firmware, and the name I give them in the app is the last 4 digits of their matter pin code, shown under the QR code. Makes for quick identification. Now for UDI to complete their Matter implementation 😀

I just looked at the box of a 800 lumens LED bulb, and it draws 9 watts. So 50 actual watts certainly sounds plausible for 4000 lumens.

That's the better, more predictable way of doing it.

That should not be a problem. If you're willing to try the fix yourself, scroll down to tokenworker's post in the following thread. If you're not comfortable with that, open a ticket with UDI.

Nothing like getting it from the source!

Thanks, that link spells out exactly the kind of topology explanation I was looking for. I just bookmarked it, and will be reading through it at least once.

I agree. That's why I'm not overly concerned that Thread not working yet. It's a work in progress, openly identified as beta by UDI. I call it a learning experience (learning about how Matter works) and the sharing mechanism is certainly aimed at making interoperability easier. Do you have links that detail what you're saying in your third paragraph (about how credentials are shared)? It's the type of general information that I've been looking for. Thanks for that.