I’ve noticed this attribute in the zwave drivers set as true recently, but I cannot find any documentation about it.
@nayelyz what exactly is the purpose of shared_device_thread_enabled and do we need to enable it in custom drivers? Is it only for zwave?
It is mentioned in:
It has been applied to various Matter, Zigbee and Z-Wave drivers as an unhighlighted part of PRs to add version 2 of lazy loading of sub-drivers.
Took a screenshot from out of the lualibs when I first saw that. Can only post a screenshot, because I’m not at my computer.
Edit:
Use a shared thread rather than thread per device on the config in the hub augmented data. Drivers are able to override the hub augmented data by specifying the shared device thread enabled flag on the driver template.
Hi, @RBoy
I’m confirming with the engineering team, but the link shared by @orangebucket has a similar description to what @Andreas_Roedl shared, so I think it is updated.
Is there anything you wanted to achieve in particular?
Update:
The engineering team confirmed that the information in the documentation is accurate. It’s a memory optimization for drivers with many devices.
A boolean (nil by default) that allows a driver use a single Thread for all device events rather than one per device. The hub can enable this for a driver via hub augmented data, but setting this on the driver template will override the hubs setting. This is a memory saving optimization. Note the processing of one device message can block the processing of a different device messages when enabled (i.e. with socket.sleep() or calls to receive on a tcp or udp socket). In general, this should be fine to use with Zigbee, Z-Wave, and Matter drivers, but may cause problems with LAN drivers.
I’d ignore it for the time being and trust the defaults. Maybe in a few months we’ll know if it has any negative effects on the latency. Looks like something intended for drivers with large amounts of devices connected.
FWIW I’ve been running my Matter custom driver dev version with the shared device thread enabled for a few days now and didn’t notice anything at all but the logs.
Logs that would say something like “Desk Light device thread event” now say “_devices_thread device thread event”, like
2026-05-04T17:09:09.655127794Z DEBUG Matter Playground _devices_thread device thread event handled
My only worry was that a handler failing could affect others now that they share the coroutine but if it’s a crash it doesn’t matter since the dispatcher calls the handling function with pcall.
If the handler does not yield inside it’s fine to share the thread, that’s just less coroutines and overhead for the hub. But again, didn’t notice a thing, maybe people with 200 or 300 devices will see a difference.
