I’ve just released a new unique driver for managing both Fibaro Switches and Smart Modules.
Specifically:
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…).
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
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.
@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:
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.
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?
