Polling? Or not?

I have a Fibaro switch module that controls my Porch lights. In the way of these things Vera started reporting pretty much randomly that the device was no longer responding, oh yes it was, oh no it wasn’t.
Device responds every time it’s sent a command. This is consistent

So I disabled the polling which seemed lovely and stopped me having to clear a load of alerts every day

However, recently it’s started deciding to report that it’s not responding again, oh yes it is, oh no it isn’t

Far less frequently, but still annoying.

Checking the logs seems to show it’s something to do with a CommFailure but it looks like it’s only when the target status and the current status are the same (I need to verify this)

09/06/19 6:51:06.322 Device_Variable::m_szValue_set device: 18 service: urn:micasaverde-com:serviceId:HaDevice1 variable: CommFailure was: 0 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xbb2b20/NONE duplicate:0 <0x76694520>

Ant other pointers?


I am going to try to help here but because I do not have a any fibero devices and know that they are they use some non standard things in their firmware, I am not sure this will apply to you.

The “device cannot be detected” message is directly connected to the CommFailure variable. If it is set to 1, you will get the message.

What trips this variable?

  1. For battery devices which are setup to wakeup, this variable is tripped when the Wakeup interval has gone by twice without the node having actually sent a wakeup frame. The device is configured by the vera during the initial configuration process to have the same interval as the expected interval and when it has configured correctly you will see that interval under the variable ConfiguredWakeupInterval.
  2. Also one other thing which will trip this variable is if the zwave dongle has a node tagged as failed. In this case, the message and the commfailure will trip every few minutes, whenever the vera reads the device list from the zwave dongle. You need to configure the device again to get rid of that tag. (I have been asking to get the vera to remove the tag any time the node sends anything). I am suffering from one such problem with a sensor at the moment and I believe the tagging is caused by a single nightly heal failing to get a response from that node either because it took too long or because it is out of battery. Once it is tagged failed, the heal also ignores the sensor so it never comes back… I have also requested to disable the nightly heal for this reason.
  3. The last thing which trips the commfailure variable is… polling. If the device failed to respond has a LastPollsuccess variable which is older than the PollSettings or has ConsecutivePollFails >1. You can reset all of these variables but you may also want to make sure if you disabled polling on that device that your PollSettings is indeed 0.

After I disabled polling for all the wired Fibaro devices, I have nearly zero problems of “cannot device device”. Before, I had a lot of them. The strange thing is that it occurs on child device, not on the master, so it’s some vera strangeness at work here, because in theory the behavior described by rafale77 should be visible only on the master one.

Thanks both

An odd one then since

  1. It’s not battery operated
  2. It’s only flipping between responding and not responding about twice a day. Seems to be triggered by some scenes I have to shut the house down. The lights are off, the scene sets them to off and there’s a comms failure (or vice versa) which seems odd (still researching this. Trying to tie scenes that run with the time of the CommFailure) With some finessing of the Reactors I’m now using (yay!) I can probably kill some, but not all of these. Is there any way to read the failed device list?
  3. Polling is set to zero

I suspect this does have child devices, but it’s only stating for the master (as far as I can tell)



It seems this is happening only when a scene tries to set the Target to the value that it already was:

`09/13/19 7:02:01.114 JobHandler_LuaUPnP::HandleActionRequest device: 18 service: urn:upnp-org:serviceId:SwitchPower1 action: SetTarget <0x76c18520>

06 09/13/19 7:02:01.125 Device_Variable::m_szValue_set device: 18 service: urn:upnp-org:serviceId:SwitchPower1 variable: Target was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0xff2a90/NONE duplicate:1 <0x76c18520>

06 09/13/19 7:02:32.757 Device_Variable::m_szValue_set device: 18 service: urn:micasaverde-com:serviceId:HaDevice1 variable: CommFailure was: 0 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xfde6e8/NONE duplicate:0 <0x76c18520>

Smells a little like a bug to me but then why would it only impact one device of several



Is it the only one of that model you have?

It seems like the device just decided not to respond to the controller when it gets a command to set a variable to the same as what it already is. It seems to be more of a device firmware issue to me. You can see that it took 31s so the vera had been waiting for 30s before saying the dude is not talking back to me and flagged it as failed.

Fair call!

Wonder why the behaviour changed.

Trying to leverage(!) reactor to kill the scenes that I have that do this :smiley:

A brainfart of mine but I wrote a function in my startup code to prevent adding useless zwave communication to my network and use it to switch devices on and off. I then call this function to turn devices on and off. I have the equivalent for dimmers etc…

function updatestate(k,val)
    local stat = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", k)
    if tonumber(stat) ~= tonumber(val) then
    luup.variable_set("urn:upnp-org:serviceId:SwitchPower1", "Status", val, k)


I think it is an ex-Fibaro switch though. Just stopped altogether :frowning:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy