Fibaro FGS-223 EU v3.3 - "Getting Secure Class"

Other Devices & Integrations Lighting & Load Control
#1

Hi, after some interventions of Vera Support unfortunately it did not seem possible to remove the “Getting Secure Class” error message from the Fibaro FGS-223 EU v3.3 (and that is important because I have other v2.x device that work and do not display this)
I’ve paired the unit straight on the Veraplus, so distance cannot be a problem.

What kind of sorcery would it take for a Vera Plus to correctly recognize this ?
The good new is that the Q1/Q2 “channels” effectively work, only the top-level “Scenery Controller” device keeps indicating its getting “Secure Device Class” error. I found 1 topic on the forum but no real conclusive solution, even Vera Support does not seem to understand.

Vera support suggested to upgrade to the latest release (I’m on 1.7.4453) but reading here on these forum clearly is a no-no for me as it would break some things only make a bad situation worse…

4 04/15/20 8:03:39.152 <0x766de520>
04 04/15/20 8:03:39.153 <0x766de520>
01 04/15/20 8:03:39.153 ZWJob_SendData::Run job job#3 :secure node 31 dev:6505 (0x1069968) N:31 P:38 S:3 Id: 3 device 6505 node 31 Aborting without requee after 2 retries <0x766de520>
02 04/15/20 8:13:41.101 Device_Basic::m_eConfigured_set device 6505 was 0 now -2 zw configuring <0x76cde520>
01 04/15/20 8:13:52.181 ZWJob_SendData::Run done/fail job job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:7 Id: 17 took 11075 ms method 2 to node 31 command 152/2 failed 5 retries 0 of 2 <0x766de520>
01 04/15/20 8:14:03.262 ZWJob_SendData::Run done/fail job job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:7 Id: 17 took 11079 ms method 2 to node 31 command 152/2 failed 5 retries 1 of 2 <0x766de520>
01 04/15/20 8:14:14.341 ZWJob_SendData::Run done/fail job job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:7 Id: 17 took 11079 ms method 2 to node 31 command 152/2 failed 5 retries 2 of 2 <0x766de520>
01 04/15/20 8:14:14.342 ZWJob_SendData::Run job job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:7 Id: 17 to node 31 command 0x98/0x02 failed 2/2 or Quit 0 <0x766de520>
01 04/15/20 8:14:14.342 ZWJob_SendData::JobFailed job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:7 Id: 17 Priority 38 <0x766de520>
02 04/15/20 8:14:14.342 ZWJob_ConfigureNode::ChildChanged aborting job#16 :conf_jh#31 dev:6505 (0x1d1b098) P:39 S:5 Id: 16 for job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:7 Id: 17 <0x766de520>
02 04/15/20 8:14:14.343 Device_Basic::m_eConfigured_set device 6505 was -2 now 0 zw aborting <0x766de520>
04 04/15/20 8:14:14.344 <0x766de520>
04 04/15/20 8:14:14.345 <0x766de520>
01 04/15/20 8:14:14.346 ZWJob_SendData::Run job job#17 :secure node 31 dev:6505 (0x10fd530) N:31 P:38 S:3 Id: 17 device 6505 node 31 Aborting without requee after 2 retries <0x766de520>
#2

Stop your quest, sell the Fibaro and buy qubino. Then keep your fingers crossed it will include and keep working… ( 10 years experience here ).

#3

I always believed Fibaro was “top notch”. I’ve dozens of Fibaro devices (indoor, outdoor, under the soil in a box) that never failed me in many years, so IF they are supported fine on Vera, they are solid.

But I believe this is a VERA issue, they should purchase a FGS-223 EU v3.3 and let their dev’s have a go on it. I can’t be rocket-science if you are developing code in that area of expertise ?

Perhaps European devices are not on the “to-do” list with Vera anyway.

Perhaps I should for a another project try a Qubino module…
Thanks for the feedback anyway.

#4

I had the same for many years. But since the “supported but not list” was growing fast voor new fibaro devices (due to s2 secure classes) I ditched the brand and now qubino is the main one. All fibaro that work I leave untill so now and then they fall of the network (vera issue as well) I replace them with qubino.

#5

It’s a bit of a two sided blame:

Fibaro first for going too often off the beaten path in their zwave implementation and what you percieve as top notch can also be translated as “too customized”. These are devices I would ban from my setups for using odd implementations for very little added value.

Then there is the vera, which really in general does a pretty good job with generic devices, and this is one of its strengths but has gone down the rathole of customizing its device supports too much, falling behind on security class implementation, and not having been able to keep custom implementations isolated from polluting one another and the generic one.

So solution get rid of one or the other. The easiest is to dump the fibaro of course… and replace it with qubino.