Is it finally time to embrace Matter? < Hint NOT!

Both my Echo Show 10 and AppleTV are at tv=v1.3.0. I never added my Matter devices to the Echo device, so I did that now. I guess it's "wait and see" if they negotiate to the same "nn".

EDIT: Ohwait... strike that. I just read the post above mentioning that amazon does not play nicely (or at all) with others at this time...

Not a concern. Ignore the fact that the nn= label references "nest" -- it doesn't really tell you which OTBR is in control (its just that the nest label was the one that stuck after the merge). The border routers dynamically select which one has the best connection and will adjust over time

3 Likes

Awesome - thank you again -- this is all very helpful info!

Just finished updating my three bulbs.

Other than the Nanoleaf app not indicating that the bulbs were already "Connected to Matter", it went smoothly.

Now just have to wait and see if my one bulb that is farthest from my TBR will behave better.

I believe TBR V1.3 is a necessary, but NOT entirely sufficient requirement for things to join the same Thread fabic - Even having all TBRs @ V1.3, doesn't resolve the credential sharing issues, as I understand it. - Specifically, see: Why Thread is Matter’s biggest problem right now - The Verge

From this article:

  1. To form this shared mesh, border routers have to be using the [Thread 1.3.0](Thread 1.3.0 makes Thread border routers Matter-ready - The Verge) specification. As of today, most are (Excluding Amazon).
  2. Next, these border routers have to share credentials with each other — similar to using a password to join a Wi-Fi network

The #2 is the problem part, and an CAN work, if you run the device inclusion from a IOS device, with both Google Home installed, as both TBR can (and do) access the same IOS keychain for the credentials, but I don't think this works from an Android device, as there is not Apple Home application that doesn't run on IOS - From the same article:

*Google’s tells me that “Apple and Google Thread border routers can share the same Thread network by leveraging the iOS Thread network APIs.” So, you could have a Google Nest Hub Max and an Apple TV join a single Thread network if you set them both up using an iOS device. *

However, the same is not true in reverse because an Android phone can’t access the iOS keychain, and there is no Android app that will set up a HomePod or Apple TV (and probably will never be).

My matter network (including HE) is all using the Apple _meshcop._udp nn= entry (the TBR is a HomePod mini - Seems to work fine from HomeKit and Hubitat) - I'm going to try and "force" my Google Nest Hub to join (which I've never really used with matter yet), by loading the Google Home app on an IOS device that's part of the matter network - I've just never tried to factor the Google Nest hub into this, and it's clearly off on it's on TBR fabic at this point (per the mDNS entries for the Google Hub and Apple HomePod mini - Both are showing up as TBRs under _meshcop._udp, but they have different nn= entries (and have both been active for months - So waiting a day, didn't solve this)

Bottom line, I think Thread V1.3 requirement is part of it, and Amazon is clearly totally out of this with V1.1 - But as I understand it, V1.3 doesn't completely resolve credential sharing, and it's still being worked on, given all the combination of different TBRs (SmartThings, NanoLeaf, etc.)

Again, @jvm33 thanks for the great mDNS pointers to "Discovery" and "Flame"

1 Like

And I know this has been referenced before, and it's somewhat HA focused, but see the sections on Multicast and Discovery for what some of the JSON elements of the DNS TXT record actually mean, and how to understand the various IP6 addressing that's going on:

image

Part three of his documents goes into mDNS and Ubiquity network tips and suggestions (along with lots of HA stuff which doesn't likely mean much to this audience)

All are updated and seem to be working well and stable. Thank you for the tip~ One thing I have noticed (and it is entirely possible it been happening since I'm not in the Nanoloeaf app often), is my devices seem to oscillate between thread and Bluetooth.

Do you know will using the app for scenes still tends to cause the bulb to drop out of HomeKit? We did like using the Blaze scene in our bedroom at night. I see the scene imported to HomeKit, but if you sect one, they all select and it doesnt actually do anything at the bulb.

Should I be able to connect to the eve energy (thread/matter) that is connected to Apple Home? All my HomePod minis (6) and the AppleTV 4k (2nd gen) are on the same network as all my Hubitat hubs. I've enabled matter on both my C8 Pro and the C8 it replaced (which was wiped/repurposed/all radios reset and turned off), and I never connect to the device when I put it into pairing mode via Apple Home. I just feel like I'm doing something wrong or it's not supported. I followed the "Apple" directions, but I've been unsuccessful after several attempts on two different hubs. I thought the minis and TV would act as thread border routers and make this available on the LAN.

Are you sure these Eve Energy devices are connected to Apple Home using ‘Matter over Thread’?

If they are instead using ‘HomeKit over Thread’, they will not be shareable from Apple Home to Hubitat.

1 Like

They are matter. And factory matter, not "upgraded" HomeKit ones. I can put them into matter pairing mode from the Apple Home app, get a pairing code, but it never works in Hubitat. (I tested one connecting to Alexa/echo and it was near instantaneous.)

1 Like

You might want to start a new thread (no pun intended :wink:) for this specific Eve Energy Matter issue. Hopefully, one of the Hubitat developers will investigate the issue.

Will do. Thanks. (And I actually do think the pun was intended. :smile: )

1 Like

@ogiewon must be drooling right now...

Admittedly, I am too...

2 Likes

I've been searching for this comment for a while to thank you! That March update did indeed dramatically improve these bulbs. No longer randomly dropping offline, etc. I had to replace one bulb that just dies the other day, and I noticed after I commissioned it, not only did it have the usual firmware update, but the other existing bulbs also picked up a new update. Seems there must have been something else released since the March update.

1 Like

All my Nanoleaf essential bulbs are on firmware 3.6.173 which I think is the latest (I'm also subscribed to the Beta channel for Nanoleaf and nothing more shows up). But agree - they do work much better under 3.6.173 / Matter 1.2.

I'll have to look when i get home. I had updated the older bulbs when you posted above, it made a world of difference. When i got the new bulb this week it had an update. When I did that update, then the other two triggered for a new update.
They sent me an email about joining the Beta program. I said I wanted to and filled out the questionnaire, but never heard anything else since.

I think there 2 different beta programs.

The first one is where they send you a survey is for completely new devices, and you may or may not be added to that after doing the survey (I completed it, but no further response).

The second "beta" is a simpler sign-up for beta firmware, not entirely new products. You access that through the Nanoleaf cloud portal: Nanoleaf Developers Forum , and go to your "My Account" -> "My Devices" section and you should see a list of devices, and can then enroll for beta firmware updates. But, again, 3.6.173 is the latest and that is already public.

1 Like

Getting another firmware update for the essentials bulbs this morning.

After more time has elapsed with zigbee devices hopping on and offline like popcorn every few weeks and my two matter devices (one thread, one wifi) being totally solid all this time I know what way I am tending to go!

I have lost all my hue subdevices (matter hub driver) for some change in my home network. So matter is unreliable.