Guy Lavoie

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.

Have you tried manually adding it to the IoX finder with it's IP address? Click on "add" and enter the URL with the IP address (for example, 192.168.0.99): https://192.168.0.99:8443/desc

Hah no, I'm not necessarily ahead of anyone! Just doing some testing and theorizing, all in the aim of learning. Since the goal of Matter is interoperability, I'm also thinking that sharing is just one more way of achieving that goal, and that indeed control is being done by proxy through the sharing controller. This would be different from the border router, which is to provide connectivity across two physical communications methods. I'm still a bit puzzled at how Amazon describes their border router as being enabled if you configure a Matter device. It's like you need to configure at least one device in the Alexa app for it to activate. Then there's the nanoleaf app attempting to connect an added bulb to any thread network it sees (and fails). Not helping is the fact that when googling the nanoleaf bulbs, Lots of discussions comes up about unreliability and other problems. Many of those discussions are a year or more old, and nanoleaf has been issuing firmware updates. So some of these problems might be fixed, others not. Enjoy the skiing! 😀

That's awkward. Maybe there are communications issues (ie: noise) causing issues. Maybe it's caused by one of the other switches being turned on before it. Just for fun, try swapping the first and third items (the third being the problem one) and see if that changes anything. Or, since the routine is scheduled, try putting the problem switch in it's own program (and removing it from the original program), but schedule it one minute before the original program. Just trying to narrow down what the problem might be.

Ok I just went to my PC to try things out. I logged into unix via ssh, and the "who" command only shows me, as admin. Then I logged in the admin console (java), went back to my ssh session, and did "who" again, and I still only see my admin session. So the admin console isn't appearing as a unix user (which probably makes sense, and is a user within IoX instead). So the passwd command wouldn't help here. UDI might have a command line way of changing the password on a console user, but I don't know what it is.

sudo, not sudu It would probably be the admin password, so sudo passwd admin

Just off the top of my head, you might try accessing by ssh and then: sudo passwd <username> Not sure what username you need to change here.

Command to access your eisy (from a C:\ prompt) is: ssh admin@eisy.local

Well, sharing might not be the same as simply going across a router. If sharing implies a proxy relationship, where Alexa receives the request and then talks to the device itself, then it might not be passively routing it. I would have been curious to see what happens if you would have deleted the light in the Alexa app; if google home could have still controlled the light. I'd think that a true "routing" would be a direct communication between google home and the light. We still have a lot to learn. Let me know if you play around with the nanoleaf app.

Or look here (scroll down to tokenworker's post).

This started just randomly? Or after a version upgrade? Can you see your eisy in your router's device list?

The thing I forgot to elaborate on in my earlier post is that the bulb configuration process in the nanoleaf app says that it sees a Thread network but adding the bulb to the Thread network failed, but it still works with the Echo in the Alexa app. This sounds plausible because the Echo has both a Zibgee hub and a Thread border router. This seems to indicate that Alexa communicates directly with it's Zigbee hub, but that sharing the bulb would have less chances of working if accessing it means going through the border router. Are you certain that sharing it from Alexa worked? Did you notice any errors or mentions of a Thread network when adding the bulb with the nanoleaf app?

Not what he did but if he could ssh to it with the IP address, then https://<ip address>:8443/desc would certainly work. That's the way mine is set up.

Did you update the firmware in the bulbs? Should be 4.1.3

Ok, have you tried editing the program, by clicking on the line "Set 'Living Area / LR Lights' On Level 72%", and then selecting the exact same device from the list, and the other options for that line, and then clicking on "update" (this sounds irrelevant, but sometimes the actual link to the device can get lost and needs to be redone that way). then Save Changes and test "Run then" again. Creating a test program would also be a good test.

Well, I did find one thing about the border router in the Echo being created "automatically". From: https://www.amazon.ca/gp/help/customer/display.html?nodeId=TSWevY1sX8ADH2LC20 "Compatible Echo devices can act as Thread border routers. These Echo devices automatically create a Thread network and store Thread network credentials on your Amazon account. When you connect a Thread Matter device with your Echo, your Echo retrieves the Thread network credentials for easy setup." That seems to confirm my initial thought that routing across it should be transparent. I did run into another thing that I noticed with the Nanoleaf app. When it adds a bulb, it looks for a matter network. It finds one and says it will add the bulb to the network, but then says that fails, so it gets added as a bluetooth device. Yet adding the bulb directly in the Alex app (add, other, Matter) works fine. From various searches I've done, it looks like the Nanoleaf bulbs are very inconsistent with linking to various Matter controllers. They probably debugged the most common ones like Alexa and the rest remain flaky. I'd love to try and just share it from the Alexa app, but until either the Alexa app can provide a QR code for sharing, or the UDI app accepts a 11 digit pin code, that won't be possible.