i am working on a driver for a random device in my house that seems to be less popular. is there a driver available that has one or multiple child devices so that i can see how that looks in the new LUA format?
You can make child “components” with LUA driver, but you cannot make child “devices” with this.
Information about sending events in multi component devices are in the documentation below.
Practically speaking this could be achieved only with LAN drivers, since these have on-demand access to the
driver:try_create_device resource (see reference here), this way you could iterate over the supported profiles and create individual device instances.
I believe this can be useful to avoid overwhelming local networks by connecting LAN devices to custom access points (parent nodes) and granting control through the driver.
my device is zigbee.
it is curious to see the baked in LAN support now for smartthings. all previous iterations seemed to be totally against the use of LAN devices integrated directly into the smartthings network.
Many Zigbee devices have multiple end points. This includes but is not limited to:
- Multisensors, such as temperature and humidity in the same device, or motion and temperature
- 2 or 3 gang lightswitches
- Multi button handheld remotes
- Power strips with independently controlled sockets
Being able to handle multi endpoint devices should be base functionality for any Zigbee home automation system. You should be able to receive messages from different end points and know which one sent it; you should be able to actuate different endpoints when appropriate, including from voice assistants, and you should be able to get logging for different endpoints. This has been true since the Zigbee specification was first introduced.
This has nothing to do with network traffic. It’s just basic functionality. If I have a two gang light switch, both switches should work independently and I should be able to give each switch a different name. And I should be able to tell Alexa which one to turn on.
Indeed, that functionality has been addressed. However, my response was focused on the representation of devices at the SmartThings App, i.e. Multi-Child vs. Multi-Component devices.
And the network conflict use case I proposed was mainly for WiFi networks that do not support a large number of devices, which sometimes ends up in simply getting disconnected from the router, or having connection issues while having a meeting because a bulb was having a firmware update.
Good point for WiFi, but that has nothing to do with zigbee, which does not use the Wi-Fi network.
no but WiFi and zigbee often interfere with each other. it is a good thought to have in the back of the mind, even if it does not directly apply here.