Guy Lavoie

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.

Well that's actually good: different tests with different devices. Up until my last test, I was thinking that a border router was strictly a networking device. Now it seems that it's also usually the initial commissioning device that the bulb or whatever will belong to, and be shared by. Mind you, this is a sample size of two users... So contrary to my Hue hub and Amazon Echo, your controller can generate a QR code for sharing. Now when you say that adding the shared Matter device with UD Mobile "never works", are you using the IoS version? That is known to not be working yet. We're both hampered by one thing missing in the chain. That's how we learn! Let's keep trying.

Welll you wouldn't see the incremental upgrade (to 5.9.1_13) that way. You really need to view the information in the sysconfig file to know. https://eisy.local:8443/WEB/sysconfig.txt that's how I saw my Polisy go from _7 to _13 when I did the pkg install. I estimate the the pkg install command is "safe" because it's not like messing around with individual files. It really is how packages get install and/or upgraded, albeit usually as part of scripts.

From my (very limited) experience so far, an already commissioned device isn't "found" by UD Mobile when you try to add it. It just keeps finding other bluetooth devices that aren't Matter devices, then tells you none were found. Factory resetting the bulb will allow it to be found again. You'll quickly learn the joys of factory resets (often by powering the bulb on and off 5 times or so) while experimenting with this. I finally got my Echo device set up this morning. The Alexa app quickly found my Nanoleaf bulb (Thread) and added it. Then I went into the device configuration and tried to share it, but just like the Hue app, it only gives me a numeric pairing code, while UD Mobile only accepts a QR code. So close... I'm still trying to find a way to convert a pairing code to a QR code, though that's not straightforward because a Matter QR code contains more then just a pairing code. There is vendor, version, etc information in it too.

Did you already have an earlier 5.9.1 when you did that?

Yes. It works with the android version of UD Mobile. You also need the latest iteration of 5.9.1 in your eisy or Polisy, which as of Monday was 5.9.1_13. From what I can tell, forcing an upgrade when you already have an earlier 5.9.1 requires going in by ssh and issuing a pkg install command. The first Matter device I was able to add was a wifi bulb. I just got (like an hour ago) a 4th gen. Amazon Echo, which has Zigbee and the needed border router functionality. I should have a chance to install it tomorrow and try out installing my Nanoleaf bulb, which is Matter over Thread. I'll report back on that when I get a chance.