Issues with Bridged devices April 2026

Devices & Integrations
1

Hi everyone,

​I’m seeing a specific issue with bridged Matter devices (via Matterbridge) following the recent 0.60.12 firmware update on my V3 hub.

​The Issue:

My Smartthings door sensor(s), which (is) were previously working perfectly as Contact Sensor(s) with Temperature reporting, have been “dropped” or misidentified by SmartThings. Specifically:

​Devices that were stable for months now appear in the SmartThings app as Generic Switches.

​The Temperature capability is completely missing/dropped, even though the attribute is visible and updating in the Matterbridge UI.

​Other Matter controllers (Google Home/Alexa) are still displaying both the Contact state and Temperature correctly, suggesting this is a SmartThings-specific mapping/driver issue.

​Setup Details:

​Hub Firmware: 0.60.12

​Bridge: Matterbridge (running matterbridge-hass v1.1.0)

​Device Type: Zigbee/Tuya Door Sensor (Contact + Temperature)

​Matterbridge Strategy: Tried both Matter and Merge. Under Matter strategy, the device defaults to a Switch.

​Troubleshooting performed:

​Re-paired the device using a fresh pairing code.

​Power-cycled the SmartThings Hub and cleared the Android app cache.

​Verified IPv6 stability on my MikroTik network (mDNS/NDP are healthy).

​It seems the new hub firmware is failing to correctly interview multi-endpoint Matter devices, defaulting to the simplest profile (Switch) and ignoring secondary clusters like Temperature.

​Is anyone else seeing “Capability Dropping” on bridged Matter devices with the latest update? Is there a specific Edge driver I should be forcing, or is this a known regression in the 0.60.12 SDK?

2

tagging @Itati @nayelyz

3

Everything is working flawlessly here.

4

Although I don’t have any Tuya Zigbee contact + temperature sensors I do have contact sensors, T&H sensors and also motion+light intensity sensors by Tuya. They are bridged from an iHost hub and a Moes hub to ST and continue to be shown as Matter Sensors.

5

Yes, that’s the update icon. I get it whenever my devices are updating (ex: Ikea matter devices).

6
7

Hi, @Gruv_Shack
Can you help us provide the following info, please?

What model are these devices? I see you only used “Tuya Door Sensor”, but knowing more details about them can help us identify the issue.

Do you remember the date and time of when you repaired the devices? Did you submit the hub logs after that test, or when you detected the issue by any chance?
If you don’t, we need you to do it again so the logs of the configuration are saved for the team’s investigation. So, please follow the steps:

  1. Remove the bridged devices
  2. Install them as you normally do, but take note on the time of the attempt. When you share it with us, include the date and your timezone. For example: April 13th at 13:07 Hrs
  3. Then, submit the hub logs as follows:
Instructions
  1. In the Advanced Users app, enter the “Hubs” section
  2. Enter the corresponding Hub and click on “Dump Hub logs”
  3. Confirm the process by clicking on “Dump Hub logs” again in the pop-up.
  4. You’ll get a green box at the top confirming the Hub logs were requested.
  1. Open support access to your account
Instructions
  1. Confirm the email account registered in the forum is the same one you use for SmartThings. If not, please share it with me over DM
  2. Enable support access to your account:
  1. Go to the SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.

See more information about this access here: https://support.smartthings.com/hc/en-us/articles/36170233944852-Enabling-Account-Data-Access-for-Support

  1. Finally, share the name of the bridge device to find the others related to it and see their details.
8

All my Zigbee devices keep either randomly turning off or on. No new Wi-Fi devices added. No new Zigbee added. I’ve been unning Samsung SmartThings Station flawlessly for quite a long time, and as of 3 days ago, several devices started acting abnormal. I can see in the history of each one when they randomly are powering off/on and can’t really make sense of it.

One of the devices doesn’t even have an automation to power off, yet it powers off several times a day. According to this forum and several AI chats, it may be tied to a Samsung security update that was pushed several days ago that breaks zigbee paths and such. Anybody else dealing with this particular issue?

9

Check out this thread:

10

Hi, @TonyStark
After checking the post mentioned above. Let us know your results. We haven’t heard of other recent issues of devices changing status for no reason.

11

Have you tried the following.

  1. turn off all zigbee repeaters such as plugs/outlets/tv.
  2. turn off any and all ST hubs/stations for 30 minutes.
  3. turn zigbee repeaters back on.
  4. turn hubs back on.

What was the result?

12

I found a way to fix it, especially in my case where the temperature capability is no longer showing. I changed the device driver to a Matter sensor, and it worked.

13

Hi, @Gruv_Shack.
Thank you for letting us know. I checked some past cases, and the team has mentioned before that since Bridged devices are generally not certified, we cannot guarantee they will work.
The strange thing in this case was that when you installed the devices the first time, they displayed the correct capabilities.
So, if it happens again that they work and then the capabilities change all of a sudden, please send the following info:

  1. Submit the hub logs as instructed below
Instructions
  1. In the Advanced Users app, enter the “Hubs” section
  2. Enter the corresponding Hub and click on “Dump Hub logs”
  3. Confirm the process by clicking on “Dump Hub logs” again in the pop-up.
  4. You’ll get a green box at the top confirming the Hub logs were requested.
  1. Share an approximate timestamp on when this could have happened.
  2. Open support access as you did before. For now since the issue is solved, you can close it.
14

I have ruled out environmental interference and confirmed that the “Switch: Off” events are occurring despite a near-perfect signal.

Technical Environment:

Hub: SmartThings Station (Firmware 0.60.12)

Device: Gledopto Zigbee Controllers

Driver: Zigbee Light Multifunctional MC (Mariano Colmenarejo)

Network Optimization: 2.4GHz WiFi is locked to Channel 1 (20MHz width). Zigbee is on an isolated channel.

Evidence of Software/Driver Bug:

High Signal Quality (LQI): During the most recent uncommanded “Off” event at 3:21 AM, the LQI was 208-210. This confirms the physical mesh is robust and the “Off” status is not due to a dropped signal or interference.

Blank Data Field in Logs: The SmartThings Advanced Web App events list shows Attribute: Switch, Value: Off, but the “Data” field is completely blank. This indicates the command is not originating from a user routine, Alexa, or a SmartApp, but is being initiated at the Hub/Driver level (likely a Supervision or Health Check timeout).

Specific Timing: Devices are turning off at specific times (e.g., 3:21 AM) and occasionally back on (e.g., 7:05 AM) without any active routines set for those windows.

Baseline: This setup was 100% stable from March 1st until the recent 0.60.12 update.

Since the signal is verified at 208 LQI and the “Data” source is blank, this appears to be a regression in how the Hub handles “Supervision” or “Reporting” for Gledopto hardware under the new firmware. I have already performed a Hub log dump.

Has there been a change in the Zigbee timeout or reporting requirements in 0.60.12 that would cause a “Switch: Off” default when a health check is performed?

15

Hi Andrew,

I’ve done all this several times to try to force remapping. I just responded to another individual with my setup and things that I’ve checked. It’s definitely not signal interference. I have a relatively healthy blend of wi-fi, zigbee, and Z-Wave devices. The lqi from the SmartThings Hub to the controllers is excellent

16

Hi, @TonyStark
So, is this happening every single day at the same time?

Please, provide support access to your account and the device names to see their details:

  1. Confirm the email account registered in the forum is the same one you use for SmartThings. If not, please share it with me over DM
  2. Enable support access to your account:
  1. Go to the SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.

See more information about this access here: https://support.smartthings.com/hc/en-us/articles/36170233944852-Enabling-Account-Data-Access-for-Support

Also, it would be convenient if you collected the driver logs at the time of the event to see if there’s something exposed there.

17

That’s quite a bold statement and it doesn’t tie in with what I see. Events are generated by the hub/driver for hub connected devices and usually in response to status reports from the devices. Acceptable event data is defined by the capabilities and offhand I can only think of it being used with locks though there may be others.

I’m not suggesting the hub/driver isn’t screwing something up, only that the (lack of) event data isn’t evidence for it.

18

Hi orangebucket,

Sorry, not trying to be bold, I’m just trying to get to the bottom of this.

My setup was fine until this update. Now I have two Gledopto zigbee controllers that randomly turn off and sometimes back on and a Third Reality zigbee plug that randomly turns on by itself. I haven’t added anything else after these devices to any of my networks.

Where else could these ghost commands be coming from?

19

Can we clarify exactly what we do know? The driver logs captured via the CLI are useful for this.

For example:

2026-05-01T10:15:42.981207924Z INFO Zigbee Switch  hub handled command: {Redacted ID}:main:switch:on []

Here you can see that my hub has handled an incoming capability command. In this case I pressed a button, a Rule was executed, and the switch capability on command was activated. As the Edge driver didn’t need to do any bespoke handling of the on command it wasn’t passed up to the driver.

By contrast, this is the sort of fuss you get in the logs when the on command reaches the driver (this is a driver for a virtual device rather than the Zigbee Switch driver shown above):

2026-05-01T10:26:42.735292878Z TRACE Anidea LV Devices  Received event with handler capability
2026-05-01T10:26:42.736480795Z INFO Anidea LV Devices  <Device: {Redacted ID} (0xXXXX)> received command: {"args":{},"capability":"switch","command":"on","component":"main","named_args":{},"positional_args":{}}
2026-05-01T10:26:42.739788295Z TRACE Anidea LV Devices  Found CapabilityCommandDispatcher handler in Anidea LV Devices

Again the key point is that it is handling a capability command.

If you are getting a capability command then it is being sent via the API so it is the mobile app, a Rule (or Routine, Scene or SmartLighting), some other app making an API call, or something along those lines that I can’t think of offhand. What it isn’t going to be is something coming from the device or happening internally to the hub or firmware.

Going back to the Zigbee Switch driver, here is the hub doing something for itself.

2026-05-01T10:41:24.411448345Z INFO Zigbee Switch  hub handled attribute 0x0000
2026-05-01T10:41:24.413578178Z INFO Zigbee Switch  hub emitting event {Redacted ID}: {"component_id":"main","capability_id":"switch","attribute_id":"switch","state":{"value":"off"}}
2026-05-01T10:41:24.424934303Z TRACE Zigbee Switch  Received event with handler device_lifecycle
2026-05-01T10:41:24.425709762Z INFO Zigbee Switch  <ZigbeeDevice: {Redacted ID}  [0xXXXX] (Light)> received lifecycle event: update

I don’t know exactly what is going on there, other than that my Zigbee switches contact the hub every three minutes with something trivial to assist with detecting loss of connectivity and that is probably what happened. I didn’t even know there was an ‘update’ lifecycle event. Anyway the point is that there isn’t anything sign of a capability command, so this is very much between the hub and the device.

20

Hi there,

Just witnessed the lights turn off so I have the dumped the logs, enabled access, and will be sending you the email my Hub is registered under