Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 1

Button Unreliable - strange ZWave Protocol responses


garywiz
 Share

Question

We have a client who loves the button.  In fact we do too.  It's very cool!  Except that out of 10 that we have purchased, only 2 actually work reliably.  About 5 of them work after a few clicks.  One doesn't work until you click it about 10 times.    7 of them are brand new.   One is still in the shrink wrap because so far, taking them directly out of the packaging consistently produces the flawed interchange on our ZWave network.   This is a VERY popular problem I see here in the forum, and although Fibaro comments here says "the button works fine", I am very skeptical (with all due respect).  I'm a firmware designer and have a lot of experience with this, so maybe I can lend a hand to debug these.  I have three ZWave networks, all configured differently.  The thing they have in common is "Indigo" as well as the AEOTEC USB Z-Stick.  The buttons exhibit the EXACT SAME behavior if I disassociate them with one network, move to another location, repair, and debug.   All networks are working flawlessly with the exception of the button.  Even the Fibaro keyfob (the cool one with + - and triangles etc) works flawlessly and each network contains many Fibaro devices that are also working perfectly.  So, I believe the problem purely has to do with the button. 

Because it is a very useful device (and an expensive one), I have been spending some time with the people at Indigo (the hub software we use), and have been doing some RAW packet debugging.   It's possible that there are flaws in the Indigo implementation of the protocol, and I'm spending some time learning what the RAW packets should be, and perhaps going to write my own driver specifically to debug what is happening.

I'm well aware of the internal microswitch and there is always a possibility that the button hasn't been fully pressed.   So, in my testing, I press the button down slowly until there is microswitch contact, then carefully assure that I hear the small "click" when the microswitch makes contact so I'm sure I'm making a closure.

I can break down the problems into two classes:
 

  1. "almost perfectly working" buttons.   These usually operate on the first click correctly, presses and multiple clicks work, and only rarely does a "wake up" or multiple click happen.  The original buttons we bought  over 3 years ago as an experiment are like this.  They have been working beautifully (two of them).
     
  2. Buttons with consistent flaws.  We have about 8 of these, 6 purchased in the last few months and all exhibiting the same problems.  
     

Category 2 buttons have a very interesting behavior:

  • When they are clicked, they send a "battery status" message ALWAYS.  The first click NEVER sends a click command.
  • The second click almost always works.  However some buttons continue to send a battery status message for several clicks.
  • Pressing the button always sends something, just not the right thing!   They are actually always communicating properly with the hub.  It is just the message being sent is wrong.
  • In addition to the above, these buttons update their battery status every 1-3 minutes always regardless of the setting of the wake-up time.  The wake-up time message is completely ignored even though it registers in our logs as being set.   The Category 1 (almost perfectly working) buttons do NOT exhibit this behavior.  They send a wake-up call ONLY when the wake-up time is reached.
  • The "non working" buttons report 100% battery at all times, even with a battery which is nearly dead.   We have tried swapping batteries during all tests and usually test with brand new batteries, not trusting the ones which were installed for freshness.  I think we have eliminated the possibility that the batteries are weak, unless all 20 of the brand new batteries we purchased from Element14 (same EVE brand as shipped) were also defective!

 

All of the buttons are labelled as FGPB-101-X (where X is the colour code) v3.2 AH.

 

However, some of them indicate, upon a status report, that security is supported, others (the original ones we purchased) indicate that security is not supported.  So, even though the version numbers appear to be all the same, it almost is hard to believe that there are not slightly different versions of firmware.

As we are under contract to deliver this home automation system, we want to please our client by assuring that we figure this out.    It is hard to believe that so many of them are "defective"!  Our local supplier is willing to swap them out, but the two we have returned were replaced with buttons which have the same, identical flaws!

I am willing to do quite a bit of technical work to solve this.  I have had nothing but wonderful experiences with Fibaro products, and they are the most reliable and incredible products we've used.   However, this particular item, despite it's promise, seems to have something haywire going on.

Can you please suggest any starting points?

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0

Its clear they are a massively flawed product as mine is brand new and is basically junk. Does not work reliabily at all and there are numerous forum posts to suggest the same.

 

The zwave vendors really need to step up their game and stop flogging this garabage to consumers. Im in Austarlia also and will be sending mine back for a replacement until the unit works as advertised.

 

Thats the good thing about consumer law in Australia - people like Fibaro can't flog off their BETA products to paying customers.

 

Pickup your game Fibaro , recall the units and fix them properly.

Link to comment
Share on other sites

  • 0

Thank you for this great analysis. I can confirm the behavior with one of my buttons. Between some button clicks the battery status is sent and not the click event. The battery event occurs at least after 10 clicks.

 

I attached the complete log file. The following is the shortened log:

 

#Successful button click (no battery status):

2019-04-09 13:14:23.576 Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-04-09 13:14:23.576 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 1.0
2019-04-09 13:14:23.576 Updating channel state zwave:device:1b8d26cf:node3:scene_number to 1.0 [DecimalType]
2019-04-09 13:14:23.639 Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-04-09 13:14:23.639 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 0
2019-04-09 13:14:23.653 Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-04-09 13:14:23.653 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 0
2019-04-09 13:14:23.781 Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-04-09 13:14:23.781 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2019-04-09 13:14:23.796 Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-04-09 13:14:23.796 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2019-04-09 13:14:23.927 Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
2019-04-09 13:14:23.927 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_ALARM, value = 255
2019-04-09 13:14:23.942 Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
2019-04-09 13:14:23.942 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_ALARM, value = 255

 

#Next click only reports the battery status:

2019-04-09 13:14:25.624 Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-04-09 13:14:25.624 Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BATTERY, value = 100
2019-04-09 13:14:25.624 Updating channel state zwave:device:1b8d26cf:node3:battery-level to 100 [DecimalType]
2019-04-09 13:14:25.721 Got an event from Z-Wave network: ZWaveNodeStatusEvent
2019-04-09 13:14:26.751 Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

 

 

Please login or register to see this attachment.

Link to comment
Share on other sites

  • 0

I understand what you are saying.

 

Still, I would not rule out a "mechanical" problem. I say this, because a metal clip broke after one year and I removed the pcb and re-used it by adding a switch and soldering a LIon 18650 cell. That was end of 2018. I never have issues with this "frankenstein button".

 

My idea is that the spring(s) wear out, and this gives power supply issues, but that is speculation.

 

Anyway, interesting log and interesting theory. I recommend you send this info to [email protected], because this is mainly a user support forum.

Edited by petergebruers
  • Like 1
Link to comment
Share on other sites

  • 0
On 12/28/2018 at 5:09 PM, garywiz said:

 

  • When they are clicked, they send a "battery status" message ALWAYS.  The first click NEVER sends a click command.
  • The second click almost always works.  However some buttons continue to send a battery status message for several clicks.
  • Pressing the button always sends something, just not the right thing!   They are actually always communicating properly with the hub.  It is just the message being sent is wrong.
  • In addition to the above, these buttons update their battery status every 1-3 minutes always regardless of the setting of the wake-up time.  The wake-up time message is completely ignored even though it registers in our logs as being set.   The Category 1 (almost perfectly working) buttons do NOT exhibit this behavior.  They send a wake-up call ONLY when the wake-up time is reached.
  • The "non working" buttons report 100% battery at all times, even with a battery which is nearly dead.   We have tried swapping batteries during all tests and usually test with brand new batteries, not trusting the ones which were installed for freshness.  I think we have eliminated the possibility that the batteries are weak, unless all 20 of the brand new batteries we purchased from Element14 (same EVE brand as shipped) were also defective!

 

 

 

I wish I read the forums before buying this junk switch.

 

Lucky I only bought one to test before committing to a bigger volume purchase.

 

All 5 of your points above are EXACTLY!!! the issues I see. To top it off I cant even remove the switch from HASSIO any more, because the switch doesnt send the right message when pressing 6 times. All I ever get is this from the switch:

 

2020-06-12 20:03:55.688 Info, Node008, Received Battery report from node 8: level=100
2020-06-12 20:03:55.688 Detail, Node008, Refreshed Value: old value=100, new value=100, type=byte
2020-06-12 20:03:55.688 Detail, Node008, Changes to this value are not verified
2020-06-12 20:03:55.689 Detail, Node008, Notification: ValueChanged
2020-06-12 20:03:55.785 Detail, Node008,   Received: 0x01, 0x08, 0x00, 0x04, 0x00, 0x08, 0x02, 0x84, 0x07, 0x7a
2020-06-12 20:03:55.786 Detail,
2020-06-12 20:03:55.786 Info, Node008, Received Wakeup Notification from node 8
2020-06-12 20:03:55.786 Info, Node008,   Node 8 has been marked as awake
2020-06-12 20:03:55.787 Detail, Node008, Queuing (WakeUp) WakeUpCmd_NoMoreInformation (Node=8): 0x01, 0x09, 0x00, 0x13, 0x08, 0x02, 0x84, 0x08, 0x25, 0x0e, 0x48
2020-06-12 20:03:55.787 Detail, Node008, Notification: Notification - Node Awake
2020-06-12 20:03:55.793 Detail,
2020-06-12 20:03:55.793 Info, Node008, Sending (WakeUp) message (Callback ID=0x0e, Expected Reply=0x13) - WakeUpCmd_NoMoreInformation (Node=8): 0x01, 0x09, 0x00, 0x13, 0x08, 0x02, 0x84, 0x08, 0x25, 0x0e, 0x48
2020-06-12 20:03:55.802 Detail, Node008,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-06-12 20:03:55.802 Detail, Node008,   ZW_SEND_DATA delivered to Z-Wave stack
2020-06-12 20:03:55.818 Detail, Node008,   Received: 0x01, 0x07, 0x00, 0x13, 0x0e, 0x00, 0x00, 0x02, 0xe7
2020-06-12 20:03:55.819 Detail, Node008,   ZW_SEND_DATA Request with callback ID 0x0e received (expected 0x0e)
2020-06-12 20:03:55.819 Info, Node008, Request RTT 24 Average Request RTT 877
2020-06-12 20:03:55.819 Info, Node008,   Node 8 has been marked as asleep
2020-06-12 20:03:55.819 Detail,   Expected callbackId was received
2020-06-12 20:03:55.819 Detail,   Expected reply was received
2020-06-12 20:03:55.819 Detail,   Message transaction complete
2020-06-12 20:03:55.819 Detail,
2020-06-12 20:03:55.819 Detail, Node008, Removing current message
2020-06-12 20:03:55.819 Detail, Node008, Notification: Notification - Node Asleep

 

No matter how many times I press it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...