(EDGE Driver-Mc): Z-Wave Edge Drivers and others with FIBARO devices:

is the stock DTH. Device pairing with It by defaut

Do you mean this one?

yes, it looks like this

Hello everyone.
Anyone with Fibaro Roller Shutter 2, using the “Z-Wave Window Treatment Mc” having problems ???
My shutter using this driver is not working today… It keeps saying “Network or server error. Try again later” for every attempt I try (open, close).

UPDATE: The only way to make it work was to turn off and on the hub.

Hi Mariano. Thank you for making the sources available. I needed the source of the zigbee-multi-switch-Zemismart-v3 driver because there was an error that did not allow it to work the automations with devices with different number of plugs. I also needed it to work with 1-plug devices as well.
If you want, tomorrow I’ll send you the changes I made.
I also inform you that for a couple of hours the Z-Wave Switch Mc driver has stopped working with the FGS-214 device

What do you mean it stopped working?
Could you please give me some details of what stopped working.
Have you tried rebooting the hub? sometimes driver updates are not done correctly

I don’t know what happened but it suddenly stopped working, and displays a network error. I replaced the driver and it works again. I tried to put your driver back after rebooting the hub and clearing cache but it is always the same “network error”.

As for the Zigbee Multi Switch Mc driver it has the same problems as Zigbee Multi Switch Zemismart Mc.
To make it work I changed these two functions:

----- config
local ep_ini = 1
local function component_to_endpoint (device, component_id)
ep_ini = device.fingerprinted_endpoint_id
if component_id == “main” then
ep_ini = device.fingerprinted_endpoint_id
return device.fingerprinted_endpoint_id
local ep_num = component_id: match (“switch (% d)”)
if ep_num == “2” then
ep_ini = ep_ini + 1
return ep_ini
–return ep_num and tonumber (ep_num) or device.fingerprinted_endpoint_id
elseif ep_num == “3” then
ep_ini = ep_ini + 2
return ep_ini
elseif ep_num == “4” then
ep_ini = ep_ini + 3
return ep_ini

local function endpoint_to_component (device, ep)
ep_ini = device.fingerprinted_endpoint_id
if ep == device.fingerprinted_endpoint_id then
ep_ini = ep
return “main”
if ep == ep_ini + 1 then
–return string.format (“switch% d”, ep)
epi_ini = ep
return “switch2”
elseif ep == ep_ini + 2 then
epi_ini = ep
return “switch3”
elseif ep == ep_ini + 3 then
epi_ini = ep
return “switch4”

In this way, the automations also work on devices with a different number of plugs

Excuse me, but I don’t know what doesn’t work in the automation of multicomponent devices

Please, could you explain a specific case to me, to see if I understand it?


ok. I have 4 switches 3 of 2 plugs and one of 3 plugs.
These 4 switches work together. If I press one, the other 3 are turned on. This does not happen with your driver.

I’m sorry, but I still don’t understand what you can’t do.

Do you want to press a switch on a strip and turn on all the switches of the 4 strips?

Now with the custom switch that turns on and off all the switches of each device, it is even easier

The code you modified only runs during device installation to permanently assign and save an endpoint to each component_id in the profile and each endpoint assign a component_id.

This assignment is permanent and is used for all multicomponent operation.
If it works badly for automations, it would also work badly to execute all manual commands or from the app

In fact, it doesn’t even work manually or in the app.
Without changes, if I press the switch button, the relays of the other switches do not close, only the relay of the switch that I pressed is closed despite the fact that there is an automation that should do so

I hope I have explained

I don’t know how you have the authorizations done, but I have automations that when I turn on main on the power strip, it turns on the other two switches and the network extender that is in another room.

I have tried to make others to turn on or off specific switches of the power strip and they all work well

It does not work if the switches have different number of relays.
I have to close all 4 relays of the 4 switches through an automation between a Main and 3 switch2

I’m sorry, I don’t doubt you have a problem, but I can’t understand what your problem is.

Once the devices are paired with the driver, each device works with its 2, 3 or 4 component profile independently since all variables, command and events are indexed by device_id.

But if that works well for you, I think it’s perfect.

I didn’t realize it, but we are talking about something that has nothing to do with this thread :man_facepalming:

1 Like


Not sure if this has anything to do with the issues that you have been seeing with the Fibaro device, but the symptoms would be the same as what you’ve described, so I did want to mention it.

Fibaro has always used many different association groups to create full functionality. One of the things that means is that you have to make sure that the hub is included in each of the association groups, for example, both the binary on/off group and the dimmer group, or the hub will not get the button presses. Which is one of the symptoms that you described.

Here, for example, is the association table for the dimmer two:


The hub’s device ID will have to appear in all five association groups. Which is weird, but it’s what’s required in this circumstance.

So that’s what I know, and I know that in the past I did help someone who had a similar symptom and the solution was that they did not have the hub ID in the dimmer group for the second switch. I also know that when working with zwave devices, particularly Fibaro devices, not having the associations set correctly is one of the most common reasons why two devices of the same model using the same DTH/edge driver might show different functionality.

What I don’t know is if there’s anything different about a device that is added with an edge driver as far as the creation of the associations goes. I just don’t know. I think @philh30 May have looked into this, but I’m not sure. It seems to me that more of the community developers have been working with Zigbee devices than with Zwave so far.

Anyway, like I said, this might not have anything to do with the issues you’ve been seeing, but I did just want to mention it in case it is relevant. :thinking:

I haven’t encountered anything different from how it behaved in Groovy or any functionality that’s lacking. The z-wave commands are all there, it’s just up to the author of the driver to implement a UI so the end user can edit association groups.

Speaking generally about z-wave (and zigbee, though I’m not as familiar with that standard), you’re still able to manually construct and send a command just like you did in Groovy. What’s new with Edge is an additional layer - the default handlers - that link z-wave commands to capabilities based on the most common behavior. We no longer have to write logic to link a z-wave BasicReport to turning on/off the Switch capability since the ST engineers have done that for us. You still can write your own handlers that have different behavior from the default handlers, but it isn’t necessary for most devices. So my overall view with z-wave and zigbee is that we haven’t lost functionality, but have some significant improvements in the ease of writing a driver for a typical device. All the flexibility is still there for complex devices that buck the standard though.

1 Like

From what I saw in the stock Groovy DTHs, SmartThings code authors generally did not expose association lists for zwave devices, or group assignments for zigbee devices. Some community members did in custom code. But if community members are building edge Drivers just based on what is in the stock groovy DTH, then my guess would be those don’t expose association lists, either. That will need to be added one driver at a time.

It would be great if the stock drivers did include all the parameter settings and association lists, of course.

Any sign of motion sensor capabilities in Edge beta yet? I see the latest beta firmware release notes don’t mention anything specific. Hoping to migrate my Fibaro motion sensors across soon. That’d pretty much complete my main daily devices being handled locally.

The ST beta driver zwave-sensor has a profile for Fibaro motion, but no fingerprints are using it yet. You could try adding your fingerprint to the driver if you want to try it out. Or, wait and it should be added in the coming months.

1 Like