Hi there, I have a bunch of matter devices configured on my Flic hub. They've been working well for the two months I've had them set up. Then one of my buttons stopped controlling one Matter device (a Leviton plug) but worked fine with another Leviton plug it was configured to control. Checked another button with a similar config and...same thing. The plug seemed to be fine (control via tha Leviton app and Alexa worked just fine). Digging in to it, I noticed about half of the 8 Matter devices on my Flic hub were showing "Offline". But like the first device mentioned, all were working fine through other channels.
Came back a few hours later to do some more troubleshooting, and lo and behold, all but one of the Matter devices are back online. I did nothing in the interim, but the hub is now finding them again. Prior to resetting the hub or removing and re-adding the one device that is still MIA, is there anything I can look at to help troubleshoot this?
@buckyswider Hi @Emil ! So I installed that beta Matter code on my Leviton plugs and switches...and VIOLA! They are now all advertising the proper tcp service all the time. (At least for the first 24 hours or so). So it seems like we are good. Presumably now the FLIC hub will never show these as "offline" again. Thanks for your counseling!
I do have another Matter related question that came up dealing with Leviton support. But I don't want to be guilty of "thread drift", so I'll start a new thread.
Thanks again!
@Emil Thanks for that awesome engagement Emil! I should've ran my query through perplexity, since that gives source links. Gotta learn to take chatgpt with healthy skepticism!
Anyhow, Leviton has said that their devices are coded to advertise the protocol, so they feel there is some sort of bug. They have offered me their latest matter beta code, which I will load onto my devices next week (out of town right now) and see if there is any difference. I'll keep you posted.
Thanks again!
@buckyswider Yeah you shouldn't really trust all the generated nonsense text AI bots spit out, especially if there are no cited sources that can validate the stated facts. In this case, you can ignore everything it says as everything it says is just misleading.
During the commissioning phase, the device does not advertise _matter._tcp but _matterc._udp.
The _matter._tcp service is advertised in the operational state, i.e. after it has joined a fabric. If it has joined multiple fabrics, it will advertise one service per fabric. It will continue to advertise this service (forever) as long as it wants to accept Matter commands and stays on the network.
When I say "advertise", I use the same terminology as in RFC 6762 (the mDNS standard specification), i.e. when a service is "advertised", it means the service is registered on the local network according to the rules in the mDNS standard. On a low level, according to the mDNS specification, this means that unsolicited udp packets containing the dns record can be sent from the device, e.g. when it boots up so that clients performing service browsing can quickly be notified about its presence, as well as that it will respond to explicit queries requesting that service. It seems ChatGPT means "send a udp packet" when it says advertise, which is not really the same thing. It is of course true that a device does not blast mDNS packets all the time as long as it is "advertising" a service.
DNS-SD with mDNS is more or less standard nowadays for devices on the local network that need to be able to be discovered by other devices. Chromecast, Spotify Connect, Airplay, printers etc. all use this protocol.
@Emil said in Matter devices showing offline:
@buckyswider _matterc._udp is for commissioning, so that one is only present while the device is "pairable", typically 15 minutes after boot when the device is factory reset (i.e. no Matter pairings yet).
_matter._tcp shall be advertised after the device has been commissioned (paired), one service per "fabric" (i.e. per "hub" it has been commissioned to), as long as it is powered on and connected to the network. If it does not advertise this service, it will not be possible to reach it by Matter controllers. If you don't see this service when you expect to, it seems like a bug in that device.
Maybe you have devices from other Matter brands you can test with?
Hi again @Emil. The Tapo device seems to be advertising _matter.tcp most of the time now. Surfing the web leaves me confused about expected behaviour of Matter Wifi devices...so I did what any techie would do...I asked chatgpt! Now I know it's not perfect, but that answer seems to be a "No". Really curious is the statement about mDNS query. Again, I'm just spitballin' here, but is it possible that a hub is supposed to issue an mDNS query in normal operation to try to recover an offline device? I did email Leviton support as well to get their take on this. Here is the complete ChatGPT answer. Thanks!
No, a Matter-over-Wi-Fi device does not need to advertise the _matter._tcp service at all times, but it must do so when it is available for commissioning or reachable on the IP network for control or communication.
Commissioning Phase:
_matter._tcp service via mDNS (Multicast DNS) during commissioning to allow controllers (e.g., smart home apps) to discover it.Operational Phase:
_matter._tcp to reduce network chatter.Dormant/Low Power Devices:
A Matter-over-Wi-Fi device does not need to continuously advertise _matter._tcp, but must do so when it's discoverable (e.g., commissioning) or active on the network.
@Emil said in Matter devices showing offline:
@buckyswider _matterc._udp is for commissioning, so that one is only present while the device is "pairable", typically 15 minutes after boot when the device is factory reset (i.e. no Matter pairings yet).
_matter._tcp shall be advertised after the device has been commissioned (paired), one service per "fabric" (i.e. per "hub" it has been commissioned to), as long as it is powered on and connected to the network. If it does not advertise this service, it will not be possible to reach it by Matter controllers. If you don't see this service when you expect to, it seems like a bug in that device.
Maybe you have devices from other Matter brands you can test with?
Thanks @Emil ! I think we posted about the same time, but in case you haven't seen mine I rigged up a Tapo (TPLINK) switch to test. When it powered on, it advertised both TCP and UDP matter protocols. When I connected it to the FLIC hub, neither was showing anymore. I now saw this note, so I powered up the switch again, and it it showing both _tcp and _udp. Now an hour later...it is not showing either. I wonder if this is some anomaly of the scanner app? Oddly, I do now see another device showing _matter._tcp- but that appears to be an Amazon Echo. (IP matches that, but it looks like the scanner is showing a MAC, which doesn't match...aye karumba).
I will keep looking at the services scanner occasionally to see if anything else show up. Maybe I'll pick up a third manufacturer's matter wifi device to see how that behaves.
@buckyswider _matterc._udp is for commissioning, so that one is only present while the device is "pairable", typically 15 minutes after boot when the device is factory reset (i.e. no Matter pairings yet).
_matter._tcp shall be advertised after the device has been commissioned (paired), one service per "fabric" (i.e. per "hub" it has been commissioned to), as long as it is powered on and connected to the network. If it does not advertise this service, it will not be possible to reach it by Matter controllers. If you don't see this service when you expect to, it seems like a bug in that device.
Maybe you have devices from other Matter brands you can test with?
@Emil So I wired up a TAPO (TP Link) switch to see if it is advertising _matter. After connecting to WiFi (and before connecting to a Matter hub) I do see _matter._tcp and _matterc._udp. Now let me add it to Flic and see if keeps advertising...
So I added it to my Flic hub, and now it is NOT advertising either _matter protocol. Looks like the proper operation (based on devices from two different manufacturers) is to only advertise when you are not paired with a hub (or maybe in setup mode?). So my speculation here is that it is something with the matter hub- the hub thinks the device is still configured (but shows offline), and the device isn't advertising _matter because it is already owned by a hub...
Let me know if there's anything I can do to continue troubleshooting. I've kept the one device as showing "offline" for the time being...
@Emil said in Matter devices showing offline:
@buckyswider yes, assuming your phone/tablet you run the app on is connected to the same network as the flic hub and the Matter device, all Matter devices that are currently paired shall advertise that service, regardless of if it's connected or not.
Hmmm, that is weird then. I see many, many other services on my local network (who knew that TiVo had so many services!). But nothing that seems to be matter related, and DEFINITELY nothing with "Matter" in the name... I assume that since you need to know the service name to code your listener, it can't just be something that Leviton is doing differently...
@Emil said in Matter devices showing offline:
@buckyswider We have planned to add network packing logging to the hub in order to be able to debug situations like this, but have not yet had time to do that. The Flic Hub runs a DNS-SD listener in the background, waiting for its paired Matter devices to come available, and then connects to these. So the first step you can do is to use any DNS-SD app (like this https://play.google.com/store/apps/details?id=com.druk.servicebrowser) and verify that your device is there. Matter devices advertise themselves under the _matter._tcp service.
So to see if I could see anything advertising _matter._tcp, I put one of the "offline" devices into setup mode. When I opened the listener app, there still was no sign of anything matter. But when I went into the Flic app, VIOLA! The device was back online...
@buckyswider yes, assuming your phone/tablet you run the app on is connected to the same network as the flic hub and the Matter device, all Matter devices that are currently paired shall advertise that service, regardless of if it's connected or not.
@Emil thanks. I don't see anything advertising that protocol at all- including my currently functioning devices. Once a device is connected to the hub, should it still be broadcasting that service?
@buckyswider We have planned to add network packing logging to the hub in order to be able to debug situations like this, but have not yet had time to do that. The Flic Hub runs a DNS-SD listener in the background, waiting for its paired Matter devices to come available, and then connects to these. So the first step you can do is to use any DNS-SD app (like this https://play.google.com/store/apps/details?id=com.druk.servicebrowser) and verify that your device is there. Matter devices advertise themselves under the _matter._tcp service.
@buckyswider said in Matter devices showing offline:
Hi @Emil, this has reared its ugly head again. This AM I have two matter devices that are showing "Offline" but can be controlled fine via other means. This time, it's two Leviton dimmable smart plugs. 5 other Matter devices (including another Leviton Smart Plug) are fine. I power cycled the hub with no difference. Is there anything I can do to troubleshoot this? Looking at this thread, the last time it happened it just self-cured. There has to be a reason this is happening...
Hi @Emil , can you advise any troubleshooting I can do? I don't want to have to occasionally just be forced to re-configure these devices.....both of these have been offline for a week now and aren't coming back themselves like the last time...
Hi @Emil, this has reared its ugly head again. This AM I have two matter devices that are showing "Offline" but can be controlled fine via other means. This time, it's two Leviton dimmable smart plugs. 5 other Matter devices (including another Leviton Smart Plug) are fine. I power cycled the hub with no difference. Is there anything I can do to troubleshoot this? Looking at this thread, the last time it happened it just self-cured. There has to be a reason this is happening...
@buckyswider did you finish the pair device again or didn't you have to since you noticed it became online again?
@Emil said in Matter devices showing offline:
@buckyswider The only thing I can think of is if any other app (Alexa or Leviton app) has thrown out the Flic Matter connection (Fabric) to the Flic Hub. In that case you would need to add it again to the Flic hub.
Figured I'd try to add it back to the Flic hub without deleting it. Put the device into setup mode and...it was no longer "offline" in the Flic app. Oh well.
@buckyswider The only thing I can think of is if any other app (Alexa or Leviton app) has thrown out the Flic Matter connection (Fabric) to the Flic Hub. In that case you would need to add it again to the Flic hub.
@Emil said in Matter devices showing offline:
@buckyswider what devices do you have? Only Leviton? Are they Thread or wifi?
Hi @Emil , so before I go delete and attempt to re-add the device showing Offline (a Leviton wall switch), is there anything I can do to provide troubleshooting data?
@Emil Yes, all of my matter devices are Leviton. All WiFi.
@Emil said in Matter devices showing offline:
@buckyswider what devices do you have? Only Leviton? Are they Thread or wifi?
Hi @Emil , so before I go delete and attempt to re-add the device showing Offline (a Leviton wall switch), is there anything I can do to provide troubleshooting data?