It’s amazing how “the UI accepted values that the back end didn’t support” can get paraphrased into something that sounds like “user error.”
1 Like
This is one of the inconsistencies of the vera design unfortunately. I can sense an attempt to simplify to make things much more user friendly like it is the case here when arbitrarily setting up the wakeup interval to a default value and not let the user worry about it.
At the same time this value is so absurd that it needs to be changed and should not be the same for all devices and therefore requires some advanced knowledge to set it up properly so… instead of leaving that value alone during inclusion or at least have a pop up screen to ask the user to set that value to a “guardrailed” value which can be accepted by the device, which would make it really user friendly, mios took the approach of using the hammer of a bad arbitrary value, which actually may not even work for all devices…
Personally I would make decisions like this only for code I would use for myself knowing that I could change any time but would never release a product that way for others to use… By trying to make it more user friendly, the opposite result was actually obtained. It’s just not a very good design and hopefully will change in the upcoming Ezlo designs.
1 Like
Rafale, since the zwave tweaks I have several devices not updating vera (status updates) anymore when operated locally. E.g. I have a Fibaro FGS211 switch which does by my knowledge is able to update instant status but is not doing anymore… any tips or suggestion on where to look or where to start?
@slelieveld, I would reenable polling in the zwave menu and then change the polling interval for all my AC powered devices. It is known that some of the instant status patent workaround were relying on polling so disabling it altogether may disable instant status as well. I myself re-enabled polling on my network for the sake of a handful of devices but then disabled polling on a device individual basis by setting the PollSetting variable to “0”.
Rafale, how does this link to thefact it “should” send instant status? Polling is not instant…
This is what the manual says:
FIBARO is a bi-directional wireless system. It means that the signal is not only sent to the receivers but also the receivers send the confirmation of its reception. This operation confirms their status so to check whether they are active. Safety of the FIBARO system transmission is comparable to the safety of transmission in data bus wired systems.
The “FIBARO is a bi-directional…” is what makes me avoid FIBARO like the pest… I have no idea how much of it is standard zwave and how much is their own creative/non interoperative implementation. If they are able to update status on their own, then none of the settings change I posted in this thread should affect it. I verified this with a number of my instant status devices. If they used a creative workaround for instant status relying on a triggered polling, I have devices like these too, then polling will need to be enabled at the controller. What is described here is ressembles any standard stack protocol with an ACK frame returned when the device receives a frame. It could be all marketing or I could be completely wrong and this could be some very creative communication stack mods. Either way… I am not touching it.
I have a lot of fibaro dimmers ,double switches and universlsensors…and I haven’t had any status update problem… 7:31 with all your scripts 
I’m on 7.30 special and also have some Fibaro kit (thinking they were brand leaders) with no obvious issues apart from what I think is a flakey dimmer in the kitchen. I should update it but it’s going to be a royal PITA
C
Agreed.
This sounded like something my developers used to say when they were in CYA mode and I would have to call them on it. It was much easier dealing with the lawyers and auditors when we called a bug a bug instead of making it seem we were denying the problem. Weaseling makes it seem like you are hiding something.
2 Likes
Well I live in the US so I have the advantage of having choices ranging from the zooz, monoprice, vision ,Leviton, GE, Cooper, Hank, neo coolcam etc and for more specific devices, Aeotec, Yale and sensative. They are all cheaper and more standard than what I see from fibaro.
I am commenting on FIBARO based on the sheer amount of issues across all platforms forum all requiring very specific implementations to make them work with varying level of success. Just google it and you will see that all zwave hubs struggle with these. I think I mentioned this before, they are trying in their material to get you to buy their hub and allow themselves some very creative and specific things because it is supported by their own hub. I am not saying they for sure won’t work on vera. Just that if I am given a choice, I would avoid them because they have the potential to add a lot of complication to your setup. Now back to @slelieveld and his instant status… hard for me to diagnose as I don’t know how they implemented instant status. I can only say that my Leviton models which implemented with the Lutron patent work fine with or without polling enabled and that the ones which use a workaround, work only with polling enabled and even when the pollsettings is 0 (meaning that specific device never gets polled from a time basis but likely gets a poll call from the vera when status changes)
I have a lot of fos 223 and 222 and they’re all working with 0 polling. But no single channel so I can’t help with that.
Thanks. Looks like I’ll have to stick with the more limited UK options. Aeotec, Fibaro and TKB pretty much it
C
Have looked at AliExpress to get direct ships from the OEM in China? I have seen a lot of European frequency devices there. I myself purchased some devices which offered multiple frequencies.
Oh there’s an idea…
Cheers
Gahh, bloody idiots have screwed their email validation and it won’t accept my email as valid 
C
@rafale77 7.31 is in beta and we hope will be officially released in not a long time and will solve all the 7.30 problems.
My question is: Will we have to run again your scripts of the first posts of this thread once the 7.31 will be installed in our controllers ?
Thanks.
No you won’t have to if you are already on 7.30 and have already run the scripts.
Thanks Rafale. Yes, we (I and my daughters) are in 7.30, Vera Edge and run your scripts weeks ago… So, less work to be done .
Thanks again
@rafale77
I understand that in the new 7.0.31 version your code for the polling and wakeup should also be executed, but another question I do have.
Once I have added or changed several devices, I understand a network heal is adviced to be done. I don’t find any command for manual and safe doing it, so, one way I feel it can be done is reversing the code to stop the nightly heal: "luup.attr_set(“EnableNightlyHeal”,0,0) My question then is: Which parameters should be used? “1,0” “0,1” “1,1”?
Thanks for all your help.