Of course @johnconstantelo. Basically I’ve created a virtual LAN device with driver:try_create_device and any time I receive an action event (capability handler), I check if that device is the main or the virtual one to determine the channel.
Vice versa, when I receive a device event, I determine to which device emit that event based on the cmd.src_channel.
I was doing something similar, but I am indexing it by another more stable variable in zigbee (device.id), since for zigbee the device.device_network_id can change if the device does an automatic rejoint and a different dni is assigned
That’s probably not a problem. Here’s what you can do:
(1) you can index virtual devices (LAN) as I described
(2) you can index the physical device (the one with device.type ~= “LAN”) in singleton.devices[“physical”]
and of course update the (2) everytime the zigbee device changes (I think it does the init anyway)
In this way, you can alway refer to the physical device with singleton.devices[“physical”]
Is this a workaround for multicomponent children not being accessible to Alexa/Google Home? if so, that’s awesome…
@nayelyz , is it safe to implement a driver like this or is creating a LAN device from within a hub connected driver something that shouldn’t be possible and could stop working at some point in the future?
You’re probably right and I really hope you are, but ST is constantly breaking features that are documented so I figured it’s probably a good idea to get the opinion of a ST employee in case this is a known exploit they plan on patching at some point…
Sorry for the delay, I was checking some details with the engineering team.
The implementation of creating separate LAN devices as part of a Zigbee/Z-Wave driver isn’t suggested as the ability to perform this particular action may be removed in the future, so, please, use it at your own risk.
The team is aware of the requirement of supporting the “parent/child” model for Zigbee/Z-Wave and will be analyzed later on.