Having trouble getting fibaro keyfob working

fibaro
openhab2
zwave
Tags: #<Tag:0x00007fe058a31840> #<Tag:0x00007fe058a31700> #<Tag:0x00007fe058a31318>

(Andy Bryant) #1

I’m having trouble getting the fibaro keyfob working. I’ve got it setup in the initial basic mode. The controller is getting the button press, but it isn’t processing it fully. Any suggestions?

keyfob.rules
rule “KeyFob2”
when
Item KeyFob1 received update
then
var swState = KeyFob1.state
var name = “KeyFob2Rule”
logInfo(name, "Update: " + swState)

switch swState {
    case 1: {logInfo(name, "Square1xClick") 
      Light_LivingRoom_Oval.sendCommand(ON)
    }
    case 2: {logInfo(name, "Square2xClick") 
      Light_LivingRoom_Oval.sendCommand(OFF)
    }
}

end

keyfob.items
Number KeyFob1 (div, remotes) { channel = “zwave:device:9901e9f5:node11:scene_number” }

Number KeyFobBatt1 (div, remotes) { channel = “zwave:device:9901e9f5:node11:battery-level” }

errors
22:03:22.164 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 04 00 0C 05 5B 03 46 80 01 C1 00 A1
22:03:22.178 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
22:03:22.187 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0D 00 04 00 0C 05 5B 03 46 80 01 C1 00 A1
22:03:22.199 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 0D 00 04 00 0C 05 5B 03 46 80 01 C1 00 A1
22:03:22.217 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0C 05 5B 03 46 80 01 C1 00
22:03:22.244 [DEBUG] [essage.ApplicationCommandMessageClass] - NODE 12: Application Command Request (ALIVE:DONE)
22:03:22.270 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 12: Starting initialisation from DONE
22:03:22.311 [DEBUG] [ave.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@7fe5c52a already registered
22:03:22.361 [DEBUG] [essage.ApplicationCommandMessageClass] - NODE 12: Incoming command class CENTRAL_SCENE
22:03:22.395 [DEBUG] [ndclass.ZWaveCentralSceneCommandClass] - NODE 12: Received CENTRAL_SCENE command V3
22:03:22.410 [DEBUG] [ndclass.ZWaveCentralSceneCommandClass] - NODE 12: Received scene 1 at key 0 [Single Press]
22:03:22.435 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
22:03:22.455 [DEBUG] [essage.ApplicationCommandMessageClass] - NODE 2: Transaction not completed: node address inconsistent. lastSent=2, incoming=255


(Vincent Regaud) #2

After a received Update the item’s state doesn’t change immediately. It takes time (5-40ms) depending on your system for the event bus to process the event.
Try changing the rule trigger to changed

rule “KeyFob2”
when
    Item KeyFob1 changed
then
    var swState = KeyFob1.state
    var name = “KeyFob2Rule”
    logInfo(name, "Update: " + swState)

    switch swState {
        case 1: {
            logInfo(name, "Square1xClick") 
            Light_LivingRoom_Oval.sendCommand(ON)
        }
        case 2: {
            logInfo(name, "Square2xClick") 
            Light_LivingRoom_Oval.sendCommand(OFF)
        }
    }

(Scott Rushworth) #3

Since this keyfob, or something like an Aeon Minimote, using a ‘changed’ trigger doesn’t work, since you can send the same button press more than once. This is one of the rare occasions, using DSL rules, where separate rules work better.

This is also one of the areas where the new rule engine with scripted automation (JSR223) shines, since you have access to the update that was received when using a ‘received update’ trigger.


(Vincent Regaud) #4

So you would do:

rule “KeyFob2 Scene 1”
when
    Item KeyFob1 received update 1
then
    ....

rule “KeyFob2 Scene 2”
when
    Item KeyFob1 received update 2
then
    ....

??


(Scott Rushworth) #5

You got it… one for each button.


(Mark) #6

CentralScene gets formatted by the binding as scene.key, which from the following debug statement would be 1.0. I’m not sure if your case 1: will match.

22:03:22.410 [DEBUG] [ndclass.ZWaveCentralSceneCommandClass] - NODE 12: Received scene 1 at key 0 [Single Press]

But, possibly more fundamental, are you seeing any of the LogInfo statements logged in your log file. I’d be especially interested to know if the first log statement (i.e. logInfo(name, "Update: " + swState)) is being logged, as that will indicate whether the rule is being executed.


(Rich Koshak) #7

That’s definitely true for received command but is it for received update? I’ve never encountered a timing problem with that. If it is a problem then we need a receivedUpdate implicit variable too. I routinely code just like OP and haven’t had a problem. It has always behaved such that the Item processes the update before the Rule triggers.

For the minimote which worked the same way, I created a Rule that sets the Items back to OFF automatically and trigger the Rule using changed to ON. Aeon Minimote Configuration OH 1.8.2?


(Scott Rushworth) #8

OMG, I did it again… no more late night posts! I think Mark has the root cause… the device uses CENTRAL_SCENE, so the OP needs to modify the states in the switch/case, similar to…


(Rich Koshak) #9

If I had a nickle for every time I’ve done that I could buy a boat. :wink:


(Frank) #10

this keyfob drives me absolutely nuts.
I have tried for days now to get it properly included, but it stills stays as an unknown device. the openhab log seems to indicate that it does never wake up …

2019-02-11 17:56:51.496 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:56:51.497 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:56:51.499 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:57:22.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: MANUFACTURER not set

2019-02-11 17:57:22.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Controller status changed to ONLINE.

2019-02-11 17:57:22.140 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Controller is ONLINE. Starting device initialisation.

2019-02-11 17:57:22.191 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Updating node properties.

2019-02-11 17:57:22.245 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Updating node properties. MAN=2147483647

2019-02-11 17:57:22.247 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: App version requested but version is unknown

2019-02-11 17:57:22.248 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Properties synchronised

2019-02-11 17:57:22.279 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Configuration synchronised

2019-02-11 17:57:22.311 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Initialising Thing Node...

2019-02-11 17:57:22.312 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Polling intialised at 1800 seconds - start in 1503000 milliseconds.

2019-02-11 17:57:22.314 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Device initialisation complete.

2019-02-11 17:58:12.071 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:58:12.073 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:58:12.075 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:58:12.077 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:58:12.079 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:58:12.080 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:58:26.171 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:58:26.173 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:58:26.175 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:58:26.177 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

2019-02-11 17:58:26.180 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: listening == false, frequentlyListening == false, awake == false

2019-02-11 17:58:26.183 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 27: Node not awake!

Now after I do not know how many times of pushing the wake-up buttons, the damn thing always blinks red when I push a button … with one exception … the inclusion mode (3 klicks on any button) still works.

Any suggestions aboutt what to do?


(Rich Koshak) #11

I remember having the same problem with the minimotes. All I can suggest is keep on trying and try different distances from the controller.


(Mark) #12

Are you sure it’s actually waking up?

Tail the openhab.log file and watch what happens when you press the button(s) to wake it up. Is there a flurry of log activity, or is it silent? If the latter, then it’s not waking up.

Hell, yeah. I hate those Minimotes. I hope this device doesn’t follow in those same footsteps… LOL


(Frank) #13

no activity visible in the logs at all when trying to wake it up.


(Mark) #14

Hmm. It’ll never initialize if it can’t be woken up.

According to the manual… Have you tried both methods to wake it up?

Waking up the device:
The KeyFob needs to be woken up to receive information about the
new configuration from the Z-Wave controller, like parameters and
associations. Use 1st menu position (white) or click o and + simultaneously to wake up the device.

If so, it might be time to exclude, factory reset, and re-include.


(Andy Bryant) #15

OK… This seems to be working in single click mode.

rule “KeyFob2”
when
Item KeyFob1 received update
then
var swState = KeyFob1.state as Number
var name = “KeyFob2Rule”
logInfo(name, "Update: " + swState.toString)

switch swState {
    case 1: {logInfo(name, "Square1xClick") 
      Light_LivingRoom_Oval.sendCommand(ON)
    }
    case 2: {logInfo(name, "Square2xClick") 
      Light_LivingRoom_Oval.sendCommand(OFF)
    }
}

end

Now to try to reconfigure the keyfob for multiple clicks.

A.


(Andy Bryant) #16

Hmm. Ok - I reconfigure to add single click, double click and click/hold, in paper UI then ‘wake up’ the keyfob. I see the log entries for this happening.

Once done I then don’t get any lights when I press buttons, and I don’t get anything triggered in the log.

I’m going to try the reset cycle to get it back to single press mode.


(Andy Bryant) #17

I think blinking red when you press a button means it’s not paired to the controller.

If you press a button 3 times it should start blinking white, then you can discover and add it back to OpenHAB.


(Frank) #18

I can report some progress … but still not where I want to be.
After numerous wake-ups, I got the device recognized by the controller with correct name etc. … but … the inclusion did not use security successfully. the device is marked as not using security.
I have “Security on” for all devices on the controller, and have had successful secure inclusion with switches and the likes already.
What do I need to do, to get the Fibaro Keyfob recognized as a secure device?
And specifically, what exactly do I need to do, now that the device is already included in non-secure mode?


(Mark) #19

Is this the device?

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/542

If so, I don’t see any SECURITY command classes. Are you sure the device supports secure inclusion?


(Frank) #20

this is an extract from the manual … and the same text is actually on the very first page, when I click on your link