[ST Edge] Driver for Fibaro Switches and Smart Modules that creates a child device for second channel (double versions)

I’ve just released a new unique driver for managing both Fibaro Switches and Smart Modules.


  • Single Switch (FGS-213)
  • Double Switch (FGS-223)
  • Smart Module (FGS-214)
  • Double Smart Module (FGS-224)

The interesting thing of this driver is that for the “double” versions, it creates a child device for the second channel instead of an extra component in a single device (as the official driver does).

This way is far more convenient (eg. you can move your 2 devices across different rooms, you can see the status of the second channel from the room…).

Join my channel here:

Driver name: DR Fibaro Switches

Should you encounter any problem, please show me the logs taken with the following command:
smartthings edge:drivers:logcat 752dc324-02cd-46da-82e1-cf2709ba389a --hub-address=IP_HUB_SMARTTHINGS


Nice! Can you share how you did that because I just released a driver for Aqara’s double switch and I’d like to do the same thing.

1 Like

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.


Hi @Daniele_Ratti

But can you send events to devices with different id even if they are in the same driver?

What do you do?,
when you create the LAN device do you save the device{} table in another variable and use it to send the events to the LAN device?

Thanks for share It!!

@Mariano_Colmenarejo when I create a LAN Device and also within the init handler, I save this device inside a singleton class which has an object like:

singleton.devices = {}

I save it indexing the device_network_id, like:

singleton.devices[device.device_network_id] = device

and then I can get it from any other device (physical or virtual) within the driver.


Thank you @Daniele_Ratti

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”]

Have you tested to see if the automations still execute locally?

@krlaframboise yes, it executes locally

1 Like

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?

@krlaframboise exactly. I don’t think it is “uncertain” to create virtual LAN devices for the future (in terms they could stop working).

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…

1 Like

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.


Hi @Daniele_Ratti, will your driver work for the FGS-222? Thank you.

Hi @Daniele_Ratti I’m having difficulty with this driver now. Your “old” driver created a “switch 1” entity in the parent device, and this actually implemented switching of Q2. The two channel entities (labelled 1 1 and 2 1) both operate Q1 and this is the same in your new (switch) version. Writing a auto-off command to either channel does work, and this information (including the duration) are retained in the device so if the original SmartThings driver is reinstated, it works as auto-off on both channels. The auto-off also hangs the display in your driver if an attempt is made to turn off the device (as it permanently shows “on” after triggering). I wonder if something has changed in the environment?

The invitation says ‘Forbidden’ when I try it. I am trying to get my FGS-213 to work.

This is a system wide problem.