Fibaro Button Crazyness

We have a bunch of Fibaro buttons.... $1000 worth in fact, for a new installation, so I'm very motivated to figure this all out.

We've been using the buttons for a while, and have usually had good success with them. Occasionally, one seems to need to "wake up" before any actions occur, but we've never had many problems.... until recently when we did a major 10 button installation at a new home.

The problem is this: Quite consistently with MOST of the buttons we've purchased, the "first click" does not work. Sometimes the second click doesn't. Usually the third does. But, with some buttons, the "first" does. So, I started debugging.

Here is the typical behavior. Note that the first two "battery status" messages were sent immediately after the first click. But the "press trigger" never happened, only the "battery status" messages. Then, if you press 2 seconds later, the press trigger occurs (and there are no battery status messages). This is very consistent though there are occasional exceptions.

Code: Select all

22 Dec 2018 at 4:29:02 pm
CLICK->   Z-Wave                          received "032 - Button: Black" status update battery level 100%
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 09 00 04 00 20 03 80 03 64 36
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 08 00 04 00 20 02 84 07 52
   Z-Wave Watcher Debug            Raw command sent (Node 32): 01 09 00 13 20 02 84 08 24 6D 02 (True)
CLICK->   Z-Wave                          received "Button: Black" button pressed
   Trigger                         Black: Test 1
   Action Collection               blackpush
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 0B 00 04 00 20 05 5B 03 01 80 01 0D
   Z-Wave                          received "Button: Black" button pressed
CLICK->   Trigger                         Black: Test 1
   Action Collection               blackpush
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 0B 00 04 00 20 05 5B 03 02 80 01 0E

Note however that it doesn't take long before the behavior repeats. Waiting just around a minute will cause the behavior to repeat, with the first click only sending the battery check messages, followed by the button starting to work normally. Note here that the FIRST and THIRD click did not work, only the second one did.

Code: Select all

22 Dec 2018 at 4:30:51 pm
CLICK->   Z-Wave                          received "032 - Button: Black" status update battery level 100%
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 09 00 04 00 20 03 80 03 64 36
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 08 00 04 00 20 02 84 07 52
   Z-Wave Watcher Debug            Raw command sent (Node 32): 01 09 00 13 20 02 84 08 24 70 1F (True)
CLICK->    Z-Wave                          received "Button: Black" button pressed
   Trigger                         Black: Test 1
   Action Collection               blackpush
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 0B 00 04 00 20 05 5B 03 01 80 01 0D
CLICK->   Z-Wave                          received "032 - Button: Black" status update battery level 100%
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 09 00 04 00 20 03 80 03 64 36
   Z-Wave Watcher Debug            Raw command received (Node 32): 01 08 00 04 00 20 02 84 07 52
   Z-Wave Watcher Debug            Raw command sent (Node 32): 01 09 00 13 20 02 84 08 24 71 1E (True)

Note that this appears inconsistent among many buttons. Some specific ones appear to work much better and there are no customer complaints. But some appear to exhibit the behavior consistently. The variation is quite remarkable. One button appears to work absolutely 100% of the time. One appears to work 0% of the time, sending battery status on every click. Others exhibit a mix of behaviors such as above.

This is a ZWave network consisting of about 20 devices plus a Phillips Hue plugin. Everything except the buttons works perfectly.... door sensors, Aeotec multisensors, Fibaro dimmers and RGBW controllers.... honestly not a single problem except for these darned buttons!

Is it an Indigo problem? I suspect not. But, considering that these are expensive devices, I'm trying to figure out if (a) they are completely useless and we need to stop using them and try to get refunds or (b) this is a solvable problem, perhaps requiring a discussion with Fibaro.

We actually really LOVE these things and have found pretty innovative uses for them that really have been received well by people... when they work!

Let me know what you think.

I don't think I can solve the problem, but have you checked the firmware version and correlated it with the issue? Last column on the indigo device table should show you which version. Mine is about 2 years old version 3.02

Take a look at this thread: Fibaro "The Button"

I had a lot of problems with my only one until I got it replaced. After my experience, I have avoided them.

I'm doing some research on this. I have a client who "absolutely loves" the button and so there are about 10 of them in the installation, and figuring out some way to "make them work" is a high priority for me. There really is no alternative to this device from a design perspective. I'm an advanced Python programmer so may need to dig into the API and see what's happening. I have two that work perfectly, six that don't, and can do a lot of side-by-side comparisons once I set up all the Zwave watchers and understand the meaning of the RAW packets I'm seeing.

It's notable that the button *always* sends a message when clicked, it is just not being recognised as the "right" message. As a (hack) fallback, I can probably even make them work for this client by doing a bit of script trickery to detect that first "false" message, but I'd rather understand more about why it's actually happening.

I'll keep this post up to date as I progress, and thanks for the other links.

I have the same issue - with first click often being reported as a ‘battery request’. To get to 2/3 clicks need to try multiple times before success.

Seem to recall was mentioned somewhere as an issue and fibaro replaced that users button which resolved the issue for the user. This lead me to believe rightly or wrongly probably a hardware/firmware issue.

If you make any progress please report back.

Although quick net search doesn’t seem promising:
https://forum.fibaro.com/topic/26679-so ... dy/?page=4


Glenn

I'm going to contact Fibaro directly and will let you know how this progresses. One thing seems clear is that the problem is consistent, and widespread. I've actually tried exactly the same button on three different Indigo Z-wave networks and the behavior is absolutely consistent. It's a bad sad. It's a pretty cool little gadget. And strangely, every other Fibaro product (including the keyfob) works flawlessly. I've come to expect quality from their products and this is pretty unusual.

I looked at these buttons a few months back but was put off because of the problems many were having with them, I did see someone had found an undocumented "fix" that was way above my grade 0 python knowledge.
I have looked up the code that was used by a ZWave.me user.

Code: Select all

// Code to include Fibaro The Button without proper support :-)
zway.devices[19].instances[0].commandClasses[91].data.keyAttribute.bind(function() {
  // action: status
   // --------------
   // 1x: 0
   // 2x: 3
   // 3x: 4
   // 4x: 5
   // 5x: 6
   // hold: 1
   // release: 2
   
  var translationTable = [1,"hold","release",2,3,4,5]
 
  debugPrint("Yoast: Fibaro The Button - Caught " + this.value);
   
  // Do stuff here. For instance, my setup does this:
  var options = {};
  options.url = "http://ACTIONURL/button.php?presses=" + translationTable[this.value];
  options.method = "GET";
  options.async = true;
  options.complete = function() { debugPrint("Yoast: Async request completed: " + this.value) };
  var res = http.request(options);
}


[url]
https://forum.z-wave.me/viewtopic.php?f ... 129#p67552[/url]

Not sure if that helps but I would love to see the button working reliably .

Ahh Clive, thank you! Now my entire Christmas day will be spent fiddling and figuring things out. I love fiddling and figuring things out. Better than the typical family crises on the holidays! Very helpful stuff, actually.

My apologies to your family for finding that but I hope it makes your Christmas wish come true , let us know how you get on!

Gary, if you want a hand with API, I’ve written most the 3rd party Zwave plugins on here.

Drop me a pm with questions.

Peter


Sent from my iPhone using Tapatalk Pro

Thanks, I'm a bit new to ZWave, but I think I can figure it all out at least enough to do some diagnostic work. My first plan is to describe the problem to Fibaro. I have at least a dozen units, one or two of which seem to work much better than the rest, though they all appear identical in terms of firmware. This problem seems quite widespread and they may have some instant advice. It may well be that they are defective, but it's the most bizarre kind of defect I've ever seen.

For example, buttons which "don't work well" also have the following characteristics:
1. They appear to report battery status every 1-2 minutes regardless of what "wake up" settings are sent to the unit. The wake up setting appears to be accepted, but totally ignored.
2. The battery level is always reported at 100% regardless of the state of the battery. (I have seen this with almost all the buttons).

Is there special programming information available for developers from Fibaro? Or, did your plugin merely use the documented parameters as well as the Silicon Labs public Z-Wave specifications? If you know of any shortcuts to deciphering RAW messages that would be great. My current approach is to download all the Silabs specifications and start digesting them. I've been using Zwave for years just not at this level!

Also, is it possible for me to temporarily replace the Fibaro Button plugin with my own so I can experiment with the protocol? Is there a template for starting out with something like this?

I'm a firmware developer so probably don't need much help with the basics of how to debug/analyze results, just the specifics of this implementation.

I'm writing to Fibaro now with some diagnostic details and let you know what they say.

[matt (support)]

We just have the info Fibaro has in their PDF manual.

Indigo's debug logging that you've used logs pretty much all incoming commands, so I don't think you'll get much additional information on what is being sent than that. There is a Z-Wave example plugin in the SDK download that let's you create a hook for the low level commands. But I don't believe you'll receive any additional data than what is shown in the Event Log when you have debug logging turned on.

I am interested to see if you find out any information from Fibaro. I don't see how this could be anything other than a firmware buglet, but I guess there is a small possibility it is somehow configuration related or related to the overall Z-Wave network (that is, the button being pressed command is being sent but never makes it to the Z-Wave controller). I don't think that is very likely the case though.