[RESOLVED] Fibaro FGS-223 second channel not working with Vera Edge

I bought a new Vera Edge system and some devices. Everything seem to work properly, I have only one issue left. I have a Fibaro FGS-223 device which should be able to switch two independent lights. I connected the device and added it to my Vera system. I see a device and gave it a name. I also see an “_Appliance module” and an “_Appliance module 1” device. The first has altid e1, the seconds altid e2. Using google, it seems the first device is the master, the e1 is the slave for the first channel and e2 is the slave for the second channel. Using the master device, I can operate the first channel. Operating the e1 or e2 device in Vera does not have any effect, only in the Vera UI it shows the devices are on.
When I use the hardware interface of the FGS-223 device, I can switch the first light (Q1) using the S1 connector and the second light (Q2) using the S2 connector.

So my question: how can I control the second channel using the Vera UI?

I have exactly the same problem. i have no idea how i can fix this
have you got any solutions yet?

It’s exactely the same to me. 2nd channel won’t be triggered by VERA Edge.

i send a message to Vera support
Maybe you can do the same
maybe they give it more priority when there ar more messages

I already dropped a message to Vera support, too.

By having a closer look to the log of the z-wave commnunication between the Vera and the FGS-223 I found out this so far:

The VERA uses the wrong command class to communication with the Fibaro. For the childs (2nd channel) it uses SWITCH_MULTILEVEL (0x26 / 38d) instead of SWITCH_BINARY (0x25 / 37d).

I conviced the VERA to use SWITCH_BINARY by removing the value 38 from the capabilities.
But then we have he next issue:

Per default VERA includes the Fibaro in secure mode. Which makes sense for 5th GEN / ZWAVE device, generally.
But it sends the command to swich the 2nd channel without encryption. The fibaro - of course - expects an encryption command and doesn’t move when getting commands the one-secure way.
In more detail:
To swich the 2nd channel the command class MULTI_CHANNEL and the command MULTI_CHANNEL_CMD_ENCAP (0x60 x0d) has to be used with a embedded SWITCH_BINARY. This in turn has to be encapsulated in a CLASS_SECURITY command to send it the encypted way.
But VERA transmits only a MULTI_CHANNEL / MULTI_CHANNEL_CMD_ENCAP with a SWITCH_BINARY without the neccessary encryption.

From from my point of view there are two bugs.
Until these bugs a fixed I could imagine as a work-around it works when the FGS-223 will be included the non-secure way.
Does anybody know how the set the VERA into the non-secure inclusion mode?

I got the feedback from support that this device will be supported in “near future”. The fixes will be included in one of the next firmware updated. But they don’t know in which ne.

The device is even not working on VeraLite/UI5/1.5.672.

I got my VERA already with UI7. So I’m not really familiar with UI5. Is UI5 able to handle ZWAVE+ (5th Gen) devices at all?

It’s not fully compatable with Zwave+, but I have some Zwave+ devices and they do their jobs quite well and as said in the manual, this device is “Compatible with any Z-Wave or Z-Wave+ Controller”.

Oh , that is great!

Just installed this relays , and now this problem. :-\

Hopefully it is quickly resolved

Cor

Hi guys,

has anybody got an answer from the support when the bug(s) that prevent the FGS-223 to work properly will be fixed?

That is the standard answer from vera. And that can add up to over a year.

Hi guys.

I just sent a message to support too.
Same problem for me… of course.
:-\

Just installed one of those and the next is on order. Ran into the same problem as everyone else and came here for help. :-[

[Edit] Sent a message to support as well [/Edit]

Most probably you will get this answer (as I did):

We are aware of this issue and actively working on this to reach a common ground on the specs of this device. And because we will have an intermediary firmware release which will contain some significant z-wave mesh mechanics, we can?t further work on FGS-223 until we have this firmware out first. Who knows, it might even work correctly after this intermediary firmware. But I can?t tell for sure.
If you are familiar with Luup code, PLEG and virtual switches. I have a temporary solution for you.
You can basically use these two Luup line codes, for turning the second child on/off . For ease of use you can include this code in a PLEG and to a virtual switch.

LUUP CODE Attached.

I asked when the new firmware will come out (since asking support will probablt not bash my karma :slight_smile: And the answer was in line with Vera’s strategy:
A whole team is working on the new firmware.
As far as I know the quality assurance department is testing it at the moment and after that we will release a beta firmware.
I can?t offer you a ETA, but I think it should be released soon because our testers are already working on it.

BTW also the second channel has the “can’t detect device” bug…

So tired of this all… A “team” usually is more than 1 person… but int this case I really doubt…

Well, I am no big coder, but that worked as a fix for me!

Thanks for posting this!

For the non-techies written down from A-Z:

Create 2 Virtual switches (via virtual switch app):
FGS-223-e2 VS
FGS-223-e1 VS

Lookup the altid of the master device created by vera for the real FGS-223 device (in my example 141)

Create 4 scene’s: select ON or OFF on Virtual switch device as a trigger, in step 1 (Whenever VirtualSwitch?A device is turned on or off), skip on step2 by pressing next, and on step 3, choose Also, execute the following Luup code: and put the code for ON.

Virtual Switch: FGS-223-e2 VS
Scene triggered with virtual switch “FGS-223-e2 VS” ON
luup.call_action(“urn:micasaverde-com:serviceId:ZWaveNetwork1”, “SendData”, {Node=141, Data=“0x60 0xd 0x2 0x2 0x25 0x1 0x63”}, 1)

Scene triggered with virtual switch “FGS-223-e2 VS” OFF
luup.call_action(“urn:micasaverde-com:serviceId:ZWaveNetwork1”, “SendData”, {Node=141, Data=“0x60 0xd 0x2 0x2 0x25 0x1 0x0”}, 1)

Virtual Switch: FGS-223-e1 VS
Scene triggered with virtual switch “FGS-223-e1 VS” ON
luup.call_action(“urn:micasaverde-com:serviceId:ZWaveNetwork1”, “SendData”, {Node=141, Data=“0x60 0xd 0x1 0x1 0x25 0x1 0x63”}, 1)

Scene triggered with virtual switch “FGS-223-e1 VS”
luup.call_action(“urn:micasaverde-com:serviceId:ZWaveNetwork1”, “SendData”, {Node=141, Data=“0x60 0xd 0x1 0x1 0x25 0x1 0x0”}, 1)

Optionally you can hide the orignal device.

And the power consumption is not given.

Thanks Sender, great job, great guide!
The switch works, but the display in UI7 don’t recognizes the state’s change of the switch when use the S1 or S2 manual switch.
E.g.
FGS-223-E1 VS is OFF, via manual switch S1 I switch to ON, on the display of UI7 the VS still shows OFF.
In brief, the state of the VS shown in UI7 is not relevant.

Hi, yes, I know… Vera also knows… and as always probably it will be fixed only if more than 50 people start complaining via support tickets.

Also having this issue, logging a ticket now ::slight_smile: