Fibaro "The Button" randomly not working, out of resolving options.

[dxfoxd]

Checklist

• I have read and followed the above instructions

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there or the fix did not work.

Describe the issue

I have a Fibaro "The Button" for almost 2 years. The last 3 months the button does randomly not responding to press events, although the log files shows that commands are received, but I cannot see if all commands are capturing all data. Also strange behaviour is happening after a press event. The driver requests the same battery level update from the device multiple times in a row (last event cyclus this was > 800 requests. I already reset and re-added the device and then it responds OK for the first hours or so, but after that randomly this strange behaviour starts again. What I also noticed is that the battery level of the device still reports 100% after 2 years of operation, which is kind of strange. I'm not sure how I can resolve this. Is it a defective device, controller or is there something else?
Sometimes other devices are not responding properly too, but this is a rare situation and it might be connected to the overflow of requests to the Fibaro device.

Your review is much appreciated!

Software versions

zwave-js-ui: 9.14.6.0443565
zwave-js: 12.12.4
Home Assistant Z-Wave Integration: Docker container
Home Assistant Z-Wave JS Addon: integrated
Controller: Aeotec Z‐Stick Gen5

Device information

Manufacturer: Fibaro
Model name: The Button
Node ID: 116

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

zwave-js-ui_log.zip

[zwave-js-bot]

👋 Hey @dxfoxd!

It looks like you attached a logfile, but its filename doesn't look like it a driver log that came from Z-Wave JS.

Please double-check that you uploaded the correct logfile. If you did, disregard this comment.

As a reminder, here's how to create one:

• Z-Wave JS UI
• Home Assistant Z-Wave Integration
• ioBroker.zwave2 Adapter

[AlCalzone]

It looks like you have the logs filtered to that specific node in the settings. Please disable the filter, as it hides other communication that could be interfering.

The driver requests the same battery level update from the device multiple times in a row

DRIVER « [Node 116] means the node is sending the battery reports, there are no previous requests for that information. This sometimes happens when there is bad connectivity between the controller and the node, but the fact that it never stops sending seems like a bug in the firmware.

Not sure what kind of troubleshooting you've done before, but there are a few pointers in the documentation:

1. Controller placement: https://zwave-js.github.io/node-zwave-js/#/troubleshooting/connectivity-issues?id=general-troubleshooting
2. Health checks: https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=testing-the-connection-strength (note that you will have to wake up the device to perform those)

[dxfoxd]

Thx for your feedback. I did:

1. Connected the controller to another USB extension cord and another USB slot.
2. I did a health check, which showed normal results.
   
3. Installed the newest version of zwave-js-ui (9.16.2.37dfcd3) and zwave-js (13.0.2)
4. Set a priority route (direct route) between the controller and the device (distance 1.5m)
5. Did a log count of all entries of this device. While the count of log entries of other devices are between 1-700, this device is at > 12000. However, as you pointed out that there was indeed a filter on it, I removed this from the log config so tomorrow I will have a better log file. I will run a script tomorrow counting the log entries of each node. Many log entries often mean that the device needs some additional configuration in its update frequency.
6. I also did some hardware maintenance. It may be a logical explanation that poor electrical contacts are the cause of the problems. Every time the contact with the battery s broken the device may start with sending the battery status upon reconnecting to the controller. I'll see if this improves the connection. Although it was an old message on the manufacturers forum, someone managed to get rid of the problems by spraying WD40 in the device, which may point to the contacts with the battery. The first results in the last 20 minutes are promising.

Art.

[AlCalzone]

I did a health check, which showed normal results.

Those are not normal results. All pings from the device to the controller are failing. The direction controller -> device looks okay though.

[dxfoxd]

Are these results better?

[AlCalzone]

Much better. What changed?

[dxfoxd]

I reinstalled the battery and made sure that the device was working (woken-up). However, after a few days of testing the random non-behavior repeated. After I trigger the device (press button) the command is captured, but the next one was not and the device also does not respond to ping requests, not even after wake up the device. So narrowing it down I'm now pretty sure the device is faulty and regularly is out of power due to a contact break. I checked the battery and this is ok. However, the constant battery update messages in the z-wave log are gone. So my conclusion is that it is now a more permanent circuit break. So it it not a z-wave issue any longer, but you increased my understanding of z-wave errors and logs (again). My next challenge is now to build an industrial emergency button with the z-wave board in this device.