I doubt it’s technically possible, because their drivers are in fact tightly coupled with the firmware.
I feel your pain.
I have good news, good news, and bad news.
The good news is Vera have got back to me and confirmed they are still confident they have identified the cause of this problem.
The other good news is they say they will gladly share a beta release with me of the “patch”.
The bad news… brace yourselves… they haven’t even started work on the fix.
Have to be honest and say my use of Vera is likely to come to an end when I consider this and how utterly fed up my wife was last night.
I also consider to finish Vera usage, I installed the system for my mom. She lives in different country, so I tried to simplify her life, but currently I have different situation.
PS: Please share the link of beta version when you will have it 
At the first sight these devices are “lagging” with Vera because Vera’s method of inclusion for GEN5 devices is only SECURE mode, per z-wave specs. Although gen5, apparently these devices are not implemented to work very well with secure mode.
Vera does not have the capability of including devices in “unsecured”.
Thank you for explanation! So I suppose it is not “fast” solution. It is not a week, or couple of weeks. Right?
PS: I tried to downgrade the firmware where FGS-223 was not included officially, and it works pretty fast
AFAIK other controllers don’t have this problem.
Sorin, have you reported it to Fibaro for cross checking?
Okay let’s entertain the thought for a minute that Vera has perfectly written code (bahahahaha, okay let’s really entertain it) and the Fibaro is indeed the one that is faulty when in secure mode (even though it works with other controllers?).
Also, let’s acknowledge it is a requirement for Z-Wave Plus certification that controllers MUST force secure mode - only allowing non-secure if that’s all the device is transmitting? Although again, it seems other controllers quite happily allow you to choose - but perhaps they are not certified?
Thankfully many DEVICES allow you to control whether they do a secure or non-secure inclusion. Although I totally rather it all be encrypted and have chosen the secure inclusion for all my devices that have two methods of inclusion.
There is still a VERY quick and VERY easy solution here. Add an unofficial setting that sets Vera to do non-secure inclusions. By default it is secure, NOTHING in the GUI, and thus out of the box Vera remains totally compliant as nothing has changed. But we set a special setting, say via a LUA command, and Vera now UNOFFICIALLY does non-secure inclusions. Again Vera remains a FULLY compliant devices and still retains certification, but give us a means to UNOFFICIALLY engage this mode.
The precedent for this is already set. The Z-UNO by default works by the standards and is a compliant and certified device - but the end-user is able to very easily reconfigure it to work in very, very, very non-compliant ways. Many other products and software across many industries also have hidden settings to engage unofficial modes of operation.
I would much rather have these things remain secure and encrypted, so Vera and Fibaro working together to fix the problem would to me be a much better solution. But I know this isn’t going to happen - Z’Wave’s “everything works with everything, no exceptions” is a load of crap, OTA firmware updates has actually been a crippling disaster so we won’t be getting a fix from Fibaro, the vendors are not the big happy family Z-Wave tries to claim so Vera ain’t going to work with Fibaro to identify the problems and then make Vera compensate for them, so Vera providing a quick and easy way to unofficially do non-secure inclusion is the best option here it would seem is the only solution…
On the other hand, working with the Z-Wave chip guys to “officially” provide this will mean a year or more… assuming it even happens…
Sorry quick question… didn’t investigation done by others reveal the Vera was accidentally expecting a non-encrypted response back from the Fibaro, when in fact it sends an encrypted one due to secure mode? Was this wrong?
Also, I’m curious why the Fibaro Single Switch 2 works perfectly… but the Fibaro Dimmer 2 and Fibaro Dual Switch 2 do not. Must be something Fibaro (or Vera) are doing differently between those three devices.
I have a vera secure at home, running fw 1.7.3535. I have a couple of FGS-223 (Double Switch 2) and some Dimmer 2:s, and they are all running fine.
I bought another vera secure to have at office, and once connected the first thing i did was to upgrade it to fw 1.7.3799 (7.0.26) . But when trying to add the some FGS-223:s and Dimmer 2’s things started to fail.
No variables can be sent to the devices to change the switch type (to momentary switch). The controller goes up and down, and the two FGS-223 I managed to connect reports that they are connected/disconnected with 2-3 hours interval. Pressing the physical switch connected to the devices causes a lag on roughly 8-10 seconds as described by others before anything happens.
When looking into the z-wave settings there is a big difference. The old firmware runs Z-wave version 4.5 L:1 while the new is 6.1 L:1. The old controller has “role” set to “Suc SIS: YES PRI: YES” while the new is “Master SIS: NO PRI: YES”.
Both of my setups are only using Z-wave plus devices so I guess (hope) that they are both running in a secured mode, so in my case i doubt it is the secure stuff that is the problem. Does anyone know what the role is, and if that could be what is causing the vera to behave like this? And more important, how do I change it?
Public service warning.
I have seen many discussions where people have pondered about a supposed fall-back to non-secure inclusion if out of the 1-2m range. because it’s too far for the secure signal to make the distance.
As I have not found any confirmation regarding this, I decided to be the guinea pig. First, to stop the potential for Network Wide Inclusion, I cut power to every single Z-Wave device throughout my home. Next, I wired up a long lead to a Fibaro Dual Switch 2. Finally, I took that into the backyard - so not only a long distance but two walls between the Vera and device.
The inclusion itself still occurs, as the core Z-Wave communications range is just fine, BUT it’s still a secure inclusion. Unfortunately, as it was well outside of the 1-2m range for doing the low power encrypted key exchange, the inclusion goes to crap. I stress again it was STILL a secure inclusion, it did not revert to a non-secure inclusion, but the device is broken as it is a secure device with no security keys exchanged.
In fact, Vera gets in one of its major moods where no matter how many times you unpair, or give up and try and delete, it claims to have done it but never does. You end up with a device that’s broken but can’t be removed because Vera has contact with the device and tries talking with it, but cannot do so properly so the unpairing and even outright delete (which you would think the point of is to simply purge it out) simply never works. The solution is to remove power from the Fibaro, THEN do the outright delete (actually twice, Vera is still in a bad mood the first time), and then power the Fibaro back up and do a factory reset on it.
So this often discussed theory that a long distance pairing might cause a non-secure inclusion is, I’m afraid, false. At least for Vera, maybe the theory came about because other controllers do fall-back?
Thank you for explanation! So I suppose it is not “fast” solution. It is not a week, or couple of weeks. Right?
PS: I tried to downgrade the firmware where FGS-223 was not included officially, and it works pretty fast :-)[/quote]
It’s being discussed at every level both with Fibaro and with Silicon labs and we’re hoping for a hasty solution.
[quote=“therealdb, post:26, topic:198800”]AFAIK other controllers don’t have this problem.
Sorin, have you reported it to Fibaro for cross checking?[/quote]
To my knowledge, Fibaro gateway has the option to include devices in non-secure mode.
Thanks for being transparent.
We hope for quick solution.
Thank you for good news! But I’m a little bit aware about upgrade firmware in the switch 
Is it possible with Vera?
Okay tickle me impressed - this is exactly the kind of cooperation one expects with the Z-Wave platform, but from a consumer perspective seems to rarely happen, so I’ll chat with the wife about persevering for a little longer.
I think he meant if you had contacted Fibaro about your claim their devices are at fault here. But sounds like you are indeed working with them on this as a high priority.
It’s not very constructive to blame another manufacturer Although sometimes the truth may be somewhere in the middle 8), we’d prefer to take it on us, especially because customers are expecting this to work ON VERA no matter what’s going on in the background.
1 Like
If Vera didn’t want to provide a behind the scenes way of triggering a non-secure inclusion, there is an alternative staring at us in the face.
If you Add a Device and select a Fibaro product from the list, then do a non-secure inclusion. For every single other case, do a secure inclusion. Even if a temporary solution until either the secure issue is sorted out, or a proper non-secure option is negotiated and added.
Did you try it and it actually solves the problem?
Vera doesn’t really do that, I was just suggesting it.
Does this lag only apply with controller/scene activation?
I only ask, because I have these modules behind every light switch and don’t encounter any physical switch lag. Controller/Scene varies from instant to some lag (sometimes a while…), but as the primary method is via physical switches it isn’t too much of an issue yet as I haven’t got the stage where I setup control of the lights via motion sensors.
Vera Plus firmware 1.7.3831
Version: 6.1 L:1
Locale: eu
Role: Suc SIS: YES PRI: YES
The lag is:
- Intermittently with Vera sending the instruction to turn on/off - whether via a scene or doing it within the interface
- Vera understanding the switch is now on or off
- Sometimes Vera gives up with the on or off and undoes it
So physically switching the light on and off is fine.
It gets more complicated than this though. Let’s say you go directly on to the light switch and turn it on and then straight off - over the next 10-20 seconds Vera will be go nuts deciding whether the light is on or not. Vera may then finally agree that it is and will now turn it on at the Vera end… but of course Vera will then realise that IT has just turned the light on, but the light isn’t actually on, so it will then try and turn it on… now that may fail because, again Vera, will be confused but it may also work. End result is that after turning that light on and off and walking away, 10-20 seconds later it might turn back on again.
You don’t have to quickly turn it on and straight off, this can happen simply by turning off the light and walking away - sometimes Vera will fail in its attempt to acknowledge it being off and will decide it is on… but the light is actually off so it will then try and correct that. It’s just that doing a quick change is a sure fire way to aggravate the problem.
Forget about scenes with more than one Fibaro device - they’ll seem to work and will then suffer immense problems with massive delays, some items working and some not, and heck in the immense time the scene takes to run Vera might do one of its wonderfully stupid LUUP restarts and that’ll kill things right there too.