There hasn’t been any development on this driver, so I’m guessing that ST updated their firmware and it stopped working. I’ll see if I have time to set my ST hub back up. I have stopped using ST, so my responsiveness will be slower.
I’m also guessing it has something to do with the recent ST update. I greatly appreciate you looking at this issue. Please let me know if I can help.
Below is an error from ST CLI while trying to add a consumable device.
smartthings edge:drivers:logcat
…
FATAL Virtual Hub Kit runtime error: [string “init.lua”]:30: [string “drivers/consumable.lua”]:31: attempt to index a nil value (field ‘setConsumableStatus’)
stack traceback:
[C]: in function ‘error’
[string “env builder”]:97: in global ‘require’
[string “init.lua”]:30: in main chunk
I can confirm that SmartThings dropped support for updating “consumables” which prevents setting the status in automatons. I assume this was a mistake on their part. This is causing a crash in the driver since they removed that command. I will need to remove support for setting this directly.
Virtual Hub Kit 2024-11-15.20.22.20.93
- Updates driver to remove support for setConsumableStatus after it was removed from ST
Thanks for coming back and fixing this.
Seems to be working as expected. The only thing I noticed that looked off was that the virtual “DOOR” only has a generic icon.
Thanks! I can confirm it is working like a champ again.
My virtual garage doors look normal.
Glad it is working. I have seen this with the ST app before. Sometimes it has trouble downloading the icons for devices. The only way I have found to fix it is to clear the app data, but that may be more trouble than it’s worth. Before doing that, I would check a second device first.
Updated Invite Link. Also updated above. SmartThings. Add a little smartness to your things.
There is no network component to this driver. It is purely virtual. It is probably due to the ST app itself.
Thank you for the quick reply. I’ll keep trying!!
It’s still not working for me. I’ve created a new virtual garage door along with all the routines to go with it. I press the button and it just spins and nothing happens. I may be the only one, but I’m no longer getting a network/server error. It may be something on the ST end, so I just wanted to follow up.
I’m also running into issues running my virtual garage door. It must be related to some software update/enhancement on the ST end.
Below is a log from my hub:
2025-12-22T16:53:53.556704933Z TRACE Virtual Hub Kit Received event with handler capability
2025-12-22T16:53:53.557960433Z INFO Virtual Hub Kit <Device: DEVICE-ID> received command: {“args”:{},“capability”:“doorControl”,“command”:“open”,“component”:“main”,“named_args”:{},“positional_args”:{}}
2025-12-22T16:53:53.559186183Z TRACE Virtual Hub Kit Found CapabilityCommandDispatcher handler in virtual → door
2025-12-22T16:53:53.561366767Z ERROR Virtual Hub Kit Single thread encountered error: [string “st/dispatcher.lua”]:270: Error encountered while processing event for <Device: DEVICE-ID>:
arg1: {args={}, capability=“doorControl”, command=“open”, component=“main”, named_args={}, positional_args={}}
“[string “st/dispatcher.lua”]:270: Error encountered while processing event for <Device: DEVICE-ID>:
arg1: {args={}, capability=“doorControl”, command=“open”, component=“main”, named_args={}, positional_args={}}
“[string “drivers/door.lua”]:33: attempt to index a nil value (field ‘main’)””
Thank you for the trace log. It appears that ST removed an attribute from their state cache and the driver crashes when looking for it. I’ll need to contact ST to see what the replacement is. This will impact the virtual garage door and the virtual consumable types. The others should not be impacted
I looked a this further and it may not be a new ST issue. This probably has to do with a known ST issue when adding knew devices. They don’t always setup their initial state.
You may be able to simply remove and re-add the device causing it to setup its state correctly. If that isn’t an option, you can try to use the contact sensor functionality of the door and set it to open or closed. That might force the state to sync, after which point you can avoid the bug as well.
The device shows a sync’d status between the virtual garage door and contact sensor. The issue is when I press the virtual garage door “button” the button spins and nothing happens. This started happening when I originally posted.
When I created a new virtual garage door and sync’d the devices after creation that had the same no response issue.
I tried finding out how to get logs but I can’t seem to view them, only send them to Samsung when I report an issue.
I’ve been using the Consumable device for a long time and it has worked flawlessly until now. The count increase function has stopped working entirely, I’m not sure if I’m the only person here presenting this problem. Any idea why this functionality is broken?
I am seeing the same issue with the garage door type. Added a new device, rebooted the hub, same issue. Circle just spins.
As noted here, the garage door and consumable types will be impacted. It looks like ST changed the way the state cache is handled in their most recent firmware and the driver will have this issue with those two device types until it updated. I plan to fix it as other development is finished up.
I am having this same issue and will continue to check back. I hope this is fixed soon.

