Guy Lavoie

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! 😀

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

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.

This is an issue that's known to sometimes happen with the update, and is almost always recoverable. UDI strongly prefers that you open a ticket.

Well if Google Home is providing the credential information, but the eisy can't then get to the bulb itself (through the border router), then that could explain the problem. There seems to be no real set up or configuration information of the border router itself. I've been wondering about that. Nothing in the Echo device either. I know it's IPv6 to IPv6 so technically it's just a physical layer thing, wifi to Zigbee. It almost sounds too simple.

So you were you able to add the shared Cync bulb to your eisy ok. (I'm also experimenting with a Cync and Nanoloeaf bulb). Looks like it worked because Google Home is giving you a QR code for sharing, while Alexa and Hue only give an 11 digit pin code. But it's still strange that the shared Thread bulb isn't working, esp coming from the same Google home app that worked for sharing the wifi bulb. So each bulb gives you it's own sharing code? This is different from the Hue hub which seems to be giving you a single sharing pin code for everything on that hub. Then again, Hue is exposing the devices as Matter bulbs, even though the bulbs themselves aren't. If/when UD Mobile is updated to accept an 11 digit pin code for adding Matter devices, it will be a lot easier to try it with Alexa and Hue.

The REST functionality is alive and well. If you can get your text message to send a http GET request to your Polisy, that should work. the hard part will be getting the text message response to your local network and interpreted.

You would do that here: https://www.universal-devices.com/my-tickets/

Have you tried testing something like a lamplinc in that other building, to see if insteon signals can get there? If not, then IP based devices might be an option, since your network goes to it. What type of device are you looking to control?

Can you ssh into it? ssh admin@eisy.local If so then you should be able to recover without needing to restore from backups. Look at this thread, scroll down to tokenworkers post. Otherwise you can open a ticket. https://forum.universal-devices.com/topic/44914-brand-new-eisy-update-failure/

Good, great that you cleared that up for any other iOS users.