Firmware version changing for hub. It gets restarted as well

Andreas_Roedl · May 14, 2026, 3:49pm

I received the firmware update a minute ago while I wasn’t at home. Usually I have to check manually whether the hub has been updated, but not this time. One of my IKEA KAJPLATS had turned on, triggering a notification that a device was activated while I was away. The camera in that room detected motion and sound, so I watched the recording and heard that the Zigbee siren (reminds me to check the init handler of my driver) had gone off.

On the plus side: all devices - even the IKEA BILRESA Scroll Wheels came back online in about two minutes.

★★★★☆ (4 out of 5)

Turns out that a pressed event was emitted by one of my IKEA BILRESA Scroll Wheels / Matter Switch driver:

Maybe something like this is missing in the Matter Switch driver?

github.com/SmartThingsCommunity/SmartThingsEdgeDrivers

drivers/SmartThings/zigbee-button/src/button_utils.lua

853b02b92


      
          button_utils.emit_event_if_latest_state_missing = function(device, component, capability, attribute_name, value)
            if device:get_latest_state(component, capability.ID, attribute_name) == nil then
              device:emit_event(value)
            end
          end

mocelet · May 14, 2026, 4:21pm

Yeah, I warned about the ghost presses by stock drivers here

When switching from another driver, Matter buttons may generate non-real presses Devices & Integrations

This is feedback in anticipation for future issues -unintended automations running- when custom drivers for buttons are shared by the community. Ideally custom drivers should not be needed for Matter, but there are features that can’t be realistically expected from stock drivers, like multi-tap emulation or held auto-repeat, and others that are expected but are not there, like the long press release event or being able to rename “Button7” to something useful. Let’s cut to the chase, when you add a button, the stock Matter driver initializes the button capability by sending a non-real pushed event with a misleading state_change = false: That’s presumably so the app doesn’t get nervous with an uninitialized state (can’t it just wait until you press an actual button?) and for a new devic…

then opened an issue in GitHub

github.com/SmartThingsCommunity/SmartThingsEdgeDrivers

Matter Switch driver generates artificial button presses when switching back to the driver

opened 09:55AM - 17 Dec 25 UTC

closed 03:19AM - 20 May 26 UTC

mocelet

After switching back from my custom driver to the stock Matter Switch driver, an… automation executed on its own when it should not. The issue was discussed some time ago in the SmartThings Community so it's probably already known: https://community.smartthings.com/t/when-switching-from-another-driver-matter-buttons-may-generate-non-real-presses/305587 Matter Switch driver has this line in the initial configuration code that, essentially, generates button presses without user interaction: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/4524087fb0501c8eaf01f10b8d0a37583ac37eb7/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua#L152 That's not a problem when a device is new and the user has not created any routine yet since nothing will happen. However, if the user came from another driver and already had automations in place (or, I believe, when using the Hub Replace feature), they will run if the last pressed event was different than the `pushed` the driver artificially emits. Mind `state_change = false` will not prevent that since it just means it will not generate a state change if the previous state was the same. Other non-Matter button drivers use a function like this to skip the event if the capability was already initialized: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/37691d50b13b618f7ce058743a5ce9c9972d873d/drivers/SmartThings/zwave-switch/src/switch_utils.lua#L6-L10 Another option is to just delete those false presses since they're probably not needed now and as soon as the user presses a button it's going to have a state anyway. Edit: In fact, in the previous example there's a bug since `emit_event` emits all the events to main instead of the component requested and should be `emit_component_event(component, value)`. Kind or proves those events are not really needed, if any only for the main component, not for all the others.

but it still generates false button presses and does not affect only changing from custom drivers since other situations could trigger that configuration code.

My opinion is that they are not needed, let alone for all the components, in fact I do not emit them in my custom driver.

Interestingly, in Zigbee wasn’t even a problem since main was kind of a catch-all that was not usually used in automations.

Andreas_Roedl · May 20, 2026, 7:37pm

This time it was only the siren and a reminder that I should really check the init lifecycle handler of my driver. On the other hand: without the siren I wouldn’t know that the firmware was updated to 61.3.

Andreas_Roedl · May 22, 2026, 9:45pm

What is going on here?

My sirene went off again (I really should have a look at the init lifecycle handler of my driver), devices went offline, checked the firmware version, see for yourself:

It was on 61.3 for about two days (see my comment above) and now it’s back on 61.2.

@Itati @nayelyz

nayelyz · May 22, 2026, 10:03pm

Hi, @Andreas_Roedl
Can you share a screenshot of the history as you did before to get the timestamps, please?
I already requested the hub logs since we have access to your account, so we can report this.

I just need to clarify the following:

So, you see a “ghost” event for the IKEA BILRESA Scroll Wheel device, right?
But, the driver for the siren has a command in the init handler that is making it trigger the sound, correct?

Andreas_Roedl · May 22, 2026, 10:09pm

This is not about

This is not about the ghost event issue, which is already being worked on (Edge Driver).

But, the driver for the siren has a command in the init handler that is making it trigger the sound, correct?

This is on me. I think I have to remove an emit in a lifecycle handler. It’s a bit of a running gag like the “Gotta fix that step” in Modern Family.

The firmware of my hub was downgraded to 61.2 20 minutes ago and as I’m typing this, it was updated to 61.3 again:

nayelyz · May 22, 2026, 10:14pm

So, this is only because you saw a change in the firmware versions? I can ask the engineering team if there was some work in this regard but I want to confirm what the issue is

Andreas_Roedl · May 22, 2026, 10:21pm

It was like a typical firmware update: devices went offline, firmware version changed (double checked it in the AWA). On 61.2 some devices needed a kick to come back, like the last time. On 61.3 all of the devices came back online.

Maybe the team is doing an A/B test on my hub.

Andreas_Roedl · May 23, 2026, 2:18am

it’s 4 o’clock in the morning. Woke up because of the usual signs and symptoms of a firmware update: siren went off, devices temporarily offline and this time again with a ghost event from a Matter button that turned on the bedroom light.

Hub:

Ghost event:

Edit: this is maybe the most interesting screenshot:

This started with the beta release of 61.3:

Are you guys switching the firmware of my hub back and forth between 61.2 and 61.3? And also find out why it was back on 61.2 for about half an hour.

Going back to sleep now!

@nayelyz @Itati @Zach_Varberg

Edit2: despite being half asleep I was able to dump the hub logs right after the incident - about 5 minutes after the hub rebooted. Check the cloud logs to see if this hub is fetching firmware files.

Edit3: can’t get back to sleep now. The siren only ever goes off after a hub firmware update. I can power cycle the hub and the siren stays quiet. So it’s a good indicator for a firmware update. The hub - and some more critical devices - is connected to a uninterruptible power supply. I never ever had issues like that anyway.

Andreas_Roedl · May 24, 2026, 11:08am

This isn’t funny anymore.

Back from 61.3 to 61.2:

Logs dumped:

mocelet · May 24, 2026, 12:12pm

My V3 aeotec seems to have reverted from .3 to .2 too. It’s so weird.

Andreas_Roedl · May 24, 2026, 12:18pm

Check the history.

This is what’s happening here the last 7 days:

This started with the release of 61.3:

mocelet · May 24, 2026, 12:24pm

I never found anything Hub related in the history, maybe the history only appears for V4 hub?

Only knew something happened to SmartThings hub or cloud because Google Home told me the Eve Energy was offline and that one is shared using SmartThings cloud integration.

Andreas_Roedl · May 24, 2026, 12:49pm

It would be nice if SmartThings Hubs exposed their existing capability-based model more visibly and consistently. The v4 hub profile already includes the firmwareUpdate capability, but it does not seem to be surfaced in a way that is easy to inspect or use.

It would be helpful if the existing firmwareUpdate attributes - such as the current firmware version, available version, update availability, update state, progress, last update result, and failure reason - were made more accessible, just like attributes on other SmartThings devices.

It would also be nice if the related firmware commands, such as checking for an update or triggering an update, were discoverable and usable where appropriate. Similarly, hub-level actions like rebooting the hub could be represented as explicit commands instead of being available only through the AWA.

Relevant hub status, diagnostic, firmware, and lifecycle changes could then be emitted as events. This would make SmartThings Hubs more transparent, easier to monitor, and more consistent with the rest of the SmartThings capability model.

mocelet · May 24, 2026, 1:21pm

And now again from beta .2 to .3, definitely not funny.

Andreas_Roedl · May 24, 2026, 1:30pm

Same here:

Turning off automatic updates for now until we’ll receive an answer from @nayelyz .

By the way: thanks for confirming that I’m not crazy and not the only one with this issue, @mocelet .

mocelet · May 24, 2026, 1:36pm

That’s only for the updates of devices, the hub always updates automatically.

Andreas_Roedl · May 24, 2026, 1:42pm

Just grasping at straws here, hoping that the V4 is handled differently with its firmwareUpdate capability.

nayelyz · May 25, 2026, 4:50pm

Hi, @Andreas_Roedl
Just following up. The engineering team mentioned this should have stopped 2 hours ago.
Please confirm.
Linking this here:

Beta - 61.X Hub Firmware and Edge Driver Release Notes Hub Firmware Beta

While I fully understand that this is a beta test and that we, as participants, accept a certain degree of risk and responsibility for joining, there’s still a serious issue several of us are experiencing with the current beta version. It keeps flipping back and forth between two versions, which is causing repeated and disruptive downtime for our hubs. [Screenshot_20260525_113211_SmartThings] It’s disappointing that no one at SmartThings appears to be monitoring or supporting the platform over the weekend. For a beta release of something as central and critical as the device hub, this level of oversight really feels essential. These kinds of problems shouldn’t be left unaddressed for days at a time. To help prevent similar issues in the future, I’d like to suggest a few improvements: …

Andreas_Roedl · May 25, 2026, 4:55pm

It did. Would be nice to know what happened and the cause.

By the way: I’m not the only one with this issue. @mocelet is another victim.

Topic		Replies	Views
57.X Hub V2/V3 Customer Beta Release Notes Hub Firmware Beta	42	2143	June 20, 2025
Hub Firmware Beta 45.6 Hub Firmware Beta	153	7351	October 29, 2022
Beta - 61.X Hub Firmware and Edge Driver Release Notes Hub Firmware Beta	53	1676	June 10, 2026
Hub Firmware Beta 0.42.6 Hub Firmware Beta	22	2423	May 25, 2023
Hub Firmware Beta 47.3 Hub Firmware Beta	39	3761	April 17, 2023

Firmware version changing for hub. It gets restarted as well

Related topics