Having trouble getting fibaro keyfob working

Maybe so, but if there’s no SECURITY command class, I don’t think it matters what the manual says. :wink:

Maybe it’s just missing from the database. Can you post the node.xml file that was created in userdata/zwave.

network_dd419481__node_29.xml (24.4 KB)

Here it is … (thanks again for your help!)

Ok, the SECURITY command class is in the node.xml, but not in the database.

@chris Does the SECURITY command class need to be in the database in order to be able to securely include a device?

No - it will not make any difference as the information from the database doesn’t generate anything in the thing definition. So long as the device reports the SECURITY class, then it should try to perform the key exchange.

now that my battery device is included without security, what are the necessary steps to get it securely included? what can I do to “help” the device during this process?

I was so happy to get it included in the first place and now I have to undo and redo again???

Yes - it’s not possible to securely include a device after it is included. The secure key exchange must complete within 15 seconds of the inclusion, and I’m guessing that has passed :wink:

so … immediately after the inclusion is started, start waking up the device again and again?
when looking at the log trace during the last inclusion process, I realized that each wakeup only lasted a few seconds and then the device already went into sleep mode again.

@chris I really think you should take a look at the impact this change has had on the inclusion/initialization process for battery-powered devices.

This device, because of the large number of config parameters, associations, and command classes, will require many, many wake-ups in order to fully initialize.

I’m not saying it is impacting the secure inclusion issue, but it’s definitely making it difficult to complete initialization of the device.

The change was required - it is much worse bug without this as it means that the binding thinks the device is awake even when it went to sleep a long time ago. This then causes all sorts of timeouts and lost data. Fundamentally this is now the same as we had in the past.

I need to think about how to improve this, but I think it’s needed to avoid devices being marked as permanently awake, which is a much bigger problem.

It’s should not be related I think. We can speculate, but logs always provide a better picture of what’s happening. There are a lot of messages here, so maybe I’ve missed something, but I don’t think there are any logs?

I understand. And, I didn’t mean to suggest that you revert the change. But I think there needs to be some accommodation for devices that are being initialized for the first time. Otherwise, I expect there will be frustration with how long it takes to initialize battery devices.

Right. And I wasn’t trying to speculate. I would agree that if @ffr has trouble with securely including this device, then he should provide logs to help track down what’s happening.

1 Like

I do agree - this is why I added this in the first place, but it has a major flaw unfortunately. However, please also remember that 2.3 didn’t have any such feature, so the binding is now running the same way as it was before the development binding was merged (only a handful of months back).

Unless you were running the dev binding long before it was merged, in which case it’s hard to remember how the binding worked way back then. :smiley:

Sorry, I didn’t mean to be argumentative. I know you understand the issue, so I’ll stop bothering you about it. :zipper_mouth_face:

1 Like

No problem - I do agree that this could do with improving, but it’s unclear how to do that without getting into the mess where we think a device is permanently awake as there’s no definitive “truth” available. Ideally, a device would send a “gone to sleep” message, so we’d know…

@mhilbush I reset the device to factory setting, deleted it from the controller and then went through inclusion again. It included, but again not securely.
I had a trace log running throughout the process. Now, a newbee question: how can I get access to this log? At some point the file that is displayed in frontail “started over again” and the history of the whole inclusion process is nolonger visible.

By default, zwave debug information is written to openhab.log. Check that file to see if the debug messages are there. If so, post that file here. If the file is too big (which is likely), place the file on a sharing service (google drive, one drive, dropbix, etc.) and post the link here.

I’m not too familiar with the security protocol, so @chris will ned to take a look at it.

@mhilbush I think I found it, took a copy of it and had a look at it with Windows Notepad, obviously unformatted.
is there a tool in windows that I can use to view the log file. I am curious to have a look before I post it.

In Windows, I use Notepad++ for viewing large files.

If you want to view the zwave transactions in a more readable way, you can use the zwave log viewer here.


@mhilbush sent you a private message

with big help and support from @chris it is now clear that the Fibaro Key fob can not be included in secure mode at this point. A firmware issue was confirmed by Fibaro support. They are working on a fix.
Unfortunately, Fibaro is not able (or willing) to provide a way to get the firmware updated on my devices, because I am using Openhab and not their own controller solution, nor did they offer to replace the product.

My apologies for this inconvenience,
Unfortunately, in this case our device is third-party, because you’re using OpenHub as a main Z-wave controller, due to that fact we do not have solution for this particular problem for which I apologize,

(copied from an email I received from Fibaro support)

I returned the keyfobs in the meantime and will look for competitor product. Given the lack of support, I will most likely not buy a Fibaro product again.