Please fix battery report for devices after battery changes

Other Devices & Integrations General Device Discussions
#1

Here we are again. This time the battery of my Remotec ZRC-90 was dead (Vera reported 80% for months, and by looking at the report date, it seems to have never reported BatteryLevel correctly). So I changed batteries and woke up the device, with no effect.

So, I tried with a “Replace failed” and in fact it paired again. But battery is not reported and in the logs I have a lot of

ZWaveNode::HandlePollUpdate_BatteryReport stray node 17 device 53

I know from the past that by excluding and including again, I will probably fix this - unless the next battery change - but this is insane and should not happen with supported devices.
Now trying to have half an hour to go thru this absurd procedure just because I swapped batteries…

#2

Yes please. Have this with several of my devices, both ZRC 90s and a thermostat

C

#3

Ok, I was able to fix it (I just remembered I had to do it previously for a NeoCoolCam door sensor). If you look at the device’s capabilities, it’s empty. I suspect this will not route the messages, hence the errors. I just set it to:

19,150,1,1,1,6,B,|33,89,90,91,94,114,115,128,132:2,133,134,

Be sure to se the device to “automatically” configure and check for Associations. Be sure to set it to group 1 (lifeline) for device ID 1 (zwave controller). After that, run a “configure device now” and the device should report the battery again. YMMV, but it helped me to solve this problem.

I still think something it’s really broken regarding this particular area and I hope things will improve in the future.

EUROtronic SPIRIT Z-Wave Plus working with Vera (Plus)?
#4

The fundamental issue here is two fold and related to what I have been requesting to disable:

  1. Luup engine to remove a device from the zwave chip’s failed device list as soon as any signal issued from the device.
  2. Disable all luup engine triggered luup reload. They are completely abusive and utterly useless 90% of the time. They cause more damage than they fix. They cause some devices to lose their configurations in the user-data.json file requiring a reconfiguration. It is for example the reason for the child devices of the Aeon HEM stopping updates. It is completely idiotic as the device keeps reporting but the vera having corrupted itself is not linking it to the object layer device anymore. Also splitting out the configuration file from the device state file and preventing the vera from writing in the configuration file without user input would help.
    While disabling the luup engine triggered reload is a trivial fix, the latter may require a bit more work to implement.

In your case, I think doing a “configure the device now” and waking up the device should have fixed the problem too but why you would need to even do this is beyond me. If the vera would stop updating configuration data of devices on its own, without user inputs, we would not be having these issues.

#5

I tried, but it was not enough. In particular, it started to reconfigure it after I put the capabilities back again. I inserted a fake value to start (well, the part before |, the part after was reflecting the device capabilities) and then a reconfigure did the trick. I agree, this is insane and should stop.

#6

One trick I forgot to mention: You could have also tried restoring from a backup dating from before the device went out of battery… since it is really a problem with configuration database self destruction…

#7

Yeah, I restored one in the past by manually editing the user_data.json, but this is a very old device and I’m not sure when it stopped reporting. As you said, this is all linked to the absurd auto-configuration saga.