Z-Wave KFOB

[Jan-Piet Mens]

Hello,

I have a KFOB [1] in my Z-Wave network, and I'd like to use this to
'switch' things. So far, I've added the following item to openHAB

Switch Z_FOB "Key Fob" (Lights) {zwave="5:1:refresh_interval=60"}

but all I see in the logs is this:

2013-12-28 14:12:45 DEBUG o.o.b.z.i.c.ZWaveBasicConverter[:75]- Generating poll message for BASIC for node 5 endpoint 1
2013-12-28 14:12:45 DEBUG o.o.b.z.i.p.c.ZWaveBasicCommandClass[:114]- Creating new message for application command BASIC_GET for node 5
2013-12-28 14:12:45 DEBUG o.o.b.z.i.p.SerialMessage[:98]- Creating empty message of class = SendData (0x13), type = Request (0x00)
2013-12-28 14:12:45 DEBUG o.o.b.z.i.p.ZWaveController[:828]- Node 5 is dead, not sending message.

Can somebody tell me how I need to configure the item?

Thanks & regards,

-JP

[1] http://z-wave.me/index.php?id=31

[David]

Hi Jan-Piet,

Is your KFOB configured in your Z-Wave setup? For instance with: http://code.google.com/p/openzwave-control-panel/
Then you can also see what classes and commands are used for this device.

Regards,
David


Op zaterdag 28 december 2013 14:18:48 UTC+1 schreef Jan-Piet Mens:

[Ben Jones]

Can you send a full debug log (Z-Wave binding only)? This might show why that node failed to initialise properly. I am not sure if anyone has used a KFOB before with the binding, have you been able to find out what command classes it supports? It is possible it is not yet supported.

Also - you shouldn't need the refresh interval - that is only really needed for devices that don't 'send' their state when they are externally changed. I.e. an in-wall micro switch that doesn't send an update when someone manually flicks the switch. I would imagine the KFOB will always send a message when a button is clicked, otherwise it would be somewhat pointless! 

[Jan-Piet Mens]

Ben,

> Can you send a full debug log (Z-Wave binding only)?

I've put it at https://p.6core.net/p/Hr1rMVeVvWxEhqwtGAOgqCDA
It's based on a fresh restart of openHAB.

I also found etc/zwave/1.4/node5.xml (#5 is the KFOB) which was created
when I pressed button 2 in 'management mode' of the KFOB, and I've
included its content above.

It looks as though the KFOB does emit something then, but not when I
simply press one of the four buttons. It may well be that I'm completely
misunderstanding the thing's use though.

-JP

[Ben Jones]

JP,

I had a look at your log and everything seems to be initialising ok. Because the KFOB is a 'sleeping' node it has to go through a couple of wake up cycles before openHAB can properly initialise. Which is what happens when you click the button the first time. However you have your item binding configured to 'refresh' every 60s which is probably not that wise for a sleeping device, since it will never react to these refresh requests unless it just happens to be awake.

I am not certain how these KFOB devices are supposed to work but I would imagine they stay dormant until you press a button, and then a BASIC report is sent for the endpoint associated with that button. The device will also wake up periodically on its own and send a battery report so you can keep track of that. Looking at the config XML it looks like the wake up interval is 604800s (or 7 days) which is probably sensible, since too often would drain the battery.

So what happens when you press the buttons on the KFOB, after the initial button press to wakeup? I would imagine you should start seeing BASIC reports coming in from the device, although I am unsure if each button is a unique end point, or if there is some other way of differentiating between the different buttons.

Ben

[Jan-Piet Mens]

Ben,

> So what happens when you press the buttons on the KFOB, after the initial
> button press to wakeup? I would imagine you should start seeing BASIC
> reports coming in from the device, although I am unsure if each button is a
> unique end point, or if there is some other way of differentiating between
> the different buttons.

when I press one of the four buttons, nothing happens -- nothing is
added to zwave.log; it's as though the KFOB isn't "sending" anything, at
least not something that openHAB can "see".

Thanks for your help; I'll see if I can get this going somehow by
studying the KFOB documentation once again.

-JP

[Ben Jones]

JP,

I have had a look in the openzwave control panel config for this device (https://code.google.com/p/open-zwave/source/browse/trunk/config/zwave.me/kfob.xml?spec=svn650&r=650) and it looks like there are 4 association groups - one for each button. 

You can configure how the buttons react, and by the looks of it by default buttons 1 + 3 switch group 1 on/off, and buttons 2 + 4 switch group 2 on/off. You can update parameters 1 & 2 to change these so that each button is associated with its own group. But you will need to run OZWCP to do this.

My guess is that your device has not associated each of the groups with the ZWave controller node. Usually this is done by default but it might not have happened for some unknown reason. This would possibly mean the device will not send any switch events to the controller node since there is no association.

Are you able to run OZWCP and see the KFOB device? If so you should be able to view/edit the group associations and ensure they are indeed set to the controller node (usually node 1).

Let me know if you have any luck with this...

[Ben Jones]

Also found this fairly thorough manual for the KFOB...http://www.slideshare.net/domoticadavinci/zme-kfob-manual-inen

NOTE: when it is talking about associations it is talking about associating your buttons with individual ZWave actuators. You may want to do this, but with openHAB as your controller it is probably better to associate with the controller node (using OZWCP) and write openHAB rules to perform any actions (at least this is how I do it).

The downside of this approach is if openHAB goes down your KFOB is useless, but who doesn't have openHAB running 24/7?!?!

[Jan-Piet Mens]

Ben,

I see the KFOB in OZWCP. I've tried putting the KFOB in 'management'
mode to create the associations, as per manual, sending a NIF (in OZWCP
it's called Send Node Information, I believe), but nothing much happens
(in other words, when I then click one of the buttons on the KFOB, I see
no 'traffic')

I've dropped the kfob.xml into OZWCP's config/ directory, but when I
select 'Configuration' or 'Information' in the panel, I see no
difference in the user interface. Can you give me a pointer on how to
view/edit group associations?

-JP

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openhab.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ben Jones]

Yep I would try OZWCP for now - I don't know much about those manual associations but it will probably be easier using OZWCP.

The kfob.xml file is probably already in you config - check under /openzwave-control-panel/config/zwave.me/?

The linkage from product/device id to that kfob.xml config file is in /config/manufacturer_specific.xml;

<Product type="0100" id="0001" name="ZME_KFOB 4 Button Key Fob" config="zwave.me/kfob.xml"/>

So you will need to check the type and id that is being shown in OZWCP against this file. If you have a different id for either of these just copy the line above and add to your manufacturerer_specific.xml with your ids.

You will then need to delete /openzwave-control-panel/zwcfg_0x12345678.xml as this is the cached version of your ZWave config. Deleting this will force OZWCP to re-query everything from scratch.

I am about to hit the hay, but if you don't have any luck with this send me a screen shot of what OZWCP looks like. 

Once you get the config being picked up correctly you should find it easy to update the group associations. It is the combo picker just above the list of devices. Selecting 'Groups' in that combo will show a second combo to the right with the list of groups for the selected device (this comes from the kfob.xml metadata). Then the list to the right of that will show all the node ids for your entire ZWave network. All you do is select the group and click on Node 1 (or whatever your controller node is) and hit Submit.  

You might need to 'wakeup' your KFOB before these changes are sent, otherwise OZWCP will wait for a WAKEUP event which could take a while. Not sure how to 'wakeup' the KFOB but some combination of button presses will do it no doubt.

Good luck and keep me posted.

[Jan-Piet Mens]

I've reset the KFOB to factory defaults, and have included it in the
network again. Twice. Unfortunately, I know see that node 3 times in
OZWCP.

I'm concentrating on the last inclusion (node #7) and I've updated group
associations, at least I don't get errors on pressing submit in OZWCP.

There's a bit of progres in that openHAB now at least receives a battery
report which it didn't before. As far as pressing a button, openHAB
doesn't 'see' anything. (For the record, OZWCP doesn't seem to receive
any data when I press a button on the KFOB either.)

Sleep well. :-) I'll carry on fumbling with this.

-JP

[Jan-Piet Mens]

Ben,

have you finally woken up? ;-)

Nothing doing; first of all, I don't really understand what's going on
nor do I have a clue, and second of all, see first.

Using OZWCP I seem to be able to 'talk' to the KFOB. The instructions
you gave me where precise and work.

As soon as I start openHAB, there's nothing much to see.

1. openHAB sees the 'Send Node Information Frame' from the KFOB, when I
press the correct buttons, and this produces a node8.xml file in
etc/zwave/1.4

2. If I look at the supportedCommandClasses in that file
(https://p.6core.net/p/RqkRovPXGZ5HFxtgaQhvfrO7) there's nothing that
remotely sounds like 'SWITCH'.

3. I've configured an OH item as follows

Switch Z_FOB "Key Fob" (Lights) {zwave="8:1"}

and as

Switch Z_FOB "Key Fob" (Lights) {zwave="8:command=MANUFACTURER_SPECIFIC"}

4. Is 'Switch' actually the correct kind of item, do you think?

5. Using command=BASIC doesn't change anything.

6. Using command=MANUFACTURER_SPECIFIC results in OH reporting

2013-12-30 17:30:18 WARN
o.o.b.z.i.c.ZWaveConverterHandler[:193]- No converter found for
item = Z_FOB, ignoring execute refresh.

which sounds reasonable, as it cannot really know what to do with
that, right?

Regards,

-JP

[Jan-Piet Mens]

> 2. If I look at the supportedCommandClasses in that file
> (https://p.6core.net/p/RqkRovPXGZ5HFxtgaQhvfrO7) there's nothing that
> remotely sounds like 'SWITCH'.

Which is confirmed by http://www.pepper1.net/zwavedb/device/211

If I'm understanding this correctly, the device doesn't report those
commands in the NIF...

-JP

[Ben Jones]

Sorry mate - have been pretty busy the last few days with NYE celebrations etc. It is the middle of summer here and I am on holiday so away from my computer a bit at the moment!

I am not sure how this KFOB should work with the OH binding. It is designed to be 'associated' with ZWave devices directly. I.e. you might associate button 1 with a light switch in your hallway. That means when you hit button 1 it will switch the hallway lights on. This is a direct association between the KFOB and the switch and doesn't route through a controller of any sort.

Now most devices that have multiple actuators or sensors are represented with multiple end points. It doesn't look like the KFOB is modelled in this way however. It seems to have a single end point and simply relies on these group associations.

I would expect the KFOB to send MULTILEVEL_SWITCH commands, with the button id/number in the command class payload somewhere, but it is very difficult to tell what is happening without getting my hands on one of these devices myself.

Try something like this;

{ zwave="8:1:command=SWITCH_MULTILEVEL,respond_to_basic=TRUE" }

And see if that does anything. Another full debug log of OH starting up and you pressing some buttons might shed some light...

FYI - when you want to re-include a device with the ZWave network you must 'remove' it from the network first. Otherwise you will end up with multiple instances of that device, as you have found. I would read on the 'exclusion' procedure for your controller/device and try to remove any existing instances, before re-including. Not sure how the binding will react if there are multiple instances of the one device!

This stuff is a little confusing to start with (like most things I guess!) but you will get the hang of it! Once you have a stable mesh network configured it really does purr along with no problems.

[Jan-Piet Mens]

> I am not sure how this KFOB should work with the OH binding.

The answer is: it doesn't. Work with the OH binding, I mean. :)

OH doesn't 'see' the KFOB other than a short-lived success I had in OH
being able to read the battery level of the device. While the KFOB ought
to be able to send MULTILEVEL_SWITCH commands, OH doesn't show anything
in its logs when I click a button on the KFOB.

I've basically given up with the KFOB, due mainly to my not wanting to
invest more time fiddling with this particular device and OH.

I greatly appreciate all the trouble you went to to help me! Thanks a
lot, Ben!

-JP

[Chris Jackson]

I have one of these on order and I am pretty sure I should be able to get it working (he says hopefully!). Hopefully I'll have it this week - I've actually got this one, and the Aeon labs version coming - I hope to be able to use it to replace my garage door opener (which is crap!).

 

The KFOB supports associations, so I would have thought that you should be able to set up an association with a button to an item. I'm sure one way or another, it can be made to work...

 

Chris
 

[Jan-Piet Mens]

> The KFOB supports associations, so I would have thought that you
> should be able to set up an association with a button to an item. I'm
> sure one way or another, it can be made to work...

Associations set up directly on the KFOB work. I've set up e.g. button1
to switch on a lamp, and it switches that on/off correctly. OH then sees
the lamp item switch.

What I originally thought would be possible is for the KFOB to *tell* OH
to switch on the lamp instead of the KFOB talking to the lamp directly.
(This sounds very confusing ...)

-JP

[Chris Jackson]

Yes - this is also how I want it to work... I hope to be able to make this work - we'll see - maybe I'm being too hopeful :) 

 

Cheers

Chris

 

[Jan-Piet Mens]

Chris,

if you do get it to work, I for one would be most interested.

While associations are possible, as mentioned earlier, they can be a pita to set: imagine microswitches embedded in a wall: we'd have to tear stuff out to get the microswitch associated with the KFOB. That's not what I have in mind.

And while I'm at it: I wasn't able to set associations with openzwave-control-panel: I had to do it by pressing a bunch of key combinations on the KFOB and triggering a NIF (that's the name I think) on, say, a Fibaro switch via a tripple-click on the button there. Fine with standalone things, but see above regarding built-in stuff.

Hoping for your solution in 3, ... 2, ....

;-)

   -JP

--

[Chris Jackson]

Hi JP,
I’m not sure why you need to tear your wall apart to set up associations - you _should_ be able to configure them remotely…. I use HABmin to set up the associations on my switches etc, although setting associations on battery devices (i.e. the KFOB) can be problematic, I have done it with a battery operated IR sensor.

My thought is to associate the KFOB button with node 1 (the controller - at least on my system) and then when I press the button, my controller will (or should!) get the message. I should be able to configure an item so that it gets updated by this association (although I haven’t thought it through completely yet) and then apply a rule…

For sure though when (if!) I get it working I’ll post what I’ve done - hopefully next week…

Cheers
Chris

[Jan-Piet Mens]

> I use HABmin ...

holy moly! Why didn't anyone tell me about this before?! [*]

> ... to set up the associations on my switches etc,

Haven't found how to do that yet, but will look.

HABmin is gorgeous! It should be built-in to openHAB. I finally see
persistence data (graphs, tables), etc. Thanks for that, Chris!

-JP

* probably because I didn't ask...

[Chris Jackson]

This page has a description of setting up associations. Two points to note though -:
1) HABmin uses a product database (XML files) that describe the devices - this is needed to configure the associations. At the moment, it’s limited so depending on your devices, it may need some new files.
2) You need to use the HABmin zwave binding (and the HABmin binding) - you may have already sorted this out.

Enjoy.

Cheers
Chris

[Jan-Piet Mens]

> This page has a description of setting up associations.

Invisible URL; white font on white background? ;-)

-JP

[Chris Jackson]

Oops - probably forgot to paste it in :)

https://github.com/cdjackson/HABmin/wiki/Z-Wave-Configuration

[Ben Jones]

Can't believe I didn't mention HABMin to you JP - I have been championing it to anyone who will listen!

[Jan-Piet Mens]

> Can't believe I didn't mention HABMin to you JP - I have been championing
> it to anyone who will listen!

Just checked: you did actually mention it in passing, I just wasn't
listening properly (which seems to happen more and more -- I suspect
it's an 'age' thing). ;-)

-JP

[Chris Jackson]

Ok, Here's what I've done. I've only spent an hour or so on it and it no doubt needs more time to get it fully working (or more fully - I'm not 100% sure it's "fully" possible).

I have managed to set up an association with 1 button. Unfortunately all buttons send the same message when using associations since they are designed to directly talk to devices. So, currently this means I can only use 1 button...

I used HABmin to simply set up an association in one of the association groups to the controller (group 1). I then set up the following item -:

Switch KFob_Chris_Button1 "KFOB Chris Button 1" <light> { zwave="14:1" }

Now, then I press the (1) button, I change the item to ON, and when I press the (3) button, it goes to OFF. I haven't (yet) set up a rule on this, but it should work fine :)

As I say, the problem now is to get the other button set working since the same message is sent for that as well.

Chris

[Chris Jackson]

I've just implemented the SCENE_ACTIVATION command class. This now fully supports the keyfob (and presumably other scene controllers) for all buttons...

To use it with the zwave.me kfob, you need to set the configuration for the buttons to "Send Scenes".

The following binding strings will work for buttons 1 and 3.

Switch KFob_Button1 "KFOB Button 1" { zwave="14:1:command=SCENE_ACTIVATION,scene=11,state=1"  }

Switch KFob_Button3 "KFOB Button 3" { zwave="14:1:command=SCENE_ACTIVATION,scene=12,state=0"  }

The scene=11 or 12 part means button 1, ON or OFF (so it maps actually to buttons 1 and 3 on the keyfob) - this is described in the keyfob doc section on scenes.

The state= part is a bit irrelevant since you can only set one state. The update needs to then be detected with a rule and the relevant scene/command sent.

I've created a PR for this so hopefully it will be integrated into the repo in the coming days...

Cheers

Chris

[Ben Jones]

Nice one Chris. These little devices look like a very useful addition!

[hans.jo...@gmail.com]

To use it with the zwave.me kfob, you need to set the configuration for the buttons to "Send Scenes".

The following binding strings will work for buttons 1 and 3.

Switch KFob_Button1 "KFOB Button 1" { zwave="14:1:command=SCENE_ACTIVATION,scene=11,state=1"  }

Switch KFob_Button3 "KFOB Button 3" { zwave="14:1:command=SCENE_ACTIVATION,scene=12,state=0"  }

Hey Chris,

Sorry for bringing back an old topic..

I've been trying to make some ZME_WCD1 wall controllers work, and according to the documentation they have similar configuration as the KFOB and has to be used with Scene Activation to do any good with openhab.
I have been configuring them with openzwave control panel for the parameters using the kfob config from openzwave and they do seem to pick up the parameters correctly...

With the controllers configured for Scene Activation I get no SCENE_ACTIVATION in etc/zwave/1.4/nodeid.xml .. I only get these classes; MANUFACTURER_SPECIFIC, WAKE_UP, BATTERY, VERSION, BASIC, ASSOCIATION, NO_OPERATION, CONFIGURATION.

I guess I should see SCENE_ACTIVATION somewhere there..

I'm wondering if the controllers are stupid, or if it can be the zwave binding getting it wrong? I don't know...

Any suggestions on how to proceed?

[Chris Jackson]

Hi,

That’s strange - from what I can tell from a quick look online, it should support the scene activation class. What’s also strange though is it looks like it should also support a few more classes that haven’t shown up in your list. Are you using the released version of openHAB 1.4?

Chris

[hans.jo...@gmail.com]

Den tirsdag den 18. februar 2014 22.09.20 UTC+1 skrev Chris Jackson:

Hi,

That’s strange - from what I can tell from a quick look online, it should support the scene activation class. What’s also strange though is it looks like it should also support a few more classes that haven’t shown up in your list. Are you using the released version of openHAB 1.4?

Chris

I'm currently using a git snapshot from yesterday.. still doesn't work for me..

However I noticed the following in the documentation;
"Simple Scene Activation using configurable scene control commands.. Associated devices in an
association group are controlled by individual commands defined by Z-Wave command class 'Scene
Controller Configuration'. One scene number can be configured per association group. On default, the
scene number equals the association group number as shown in the figure below. This mode implements
communication patterns 6 and 7. This mode is typically used to activate scenes in IP gateways but can also
be used to activate predefined scenes in other scene-capable devices."

So it seems that I'll need support for SCENE_CONTROLLER_CONF, 0x2D ... Does that sound right?

[Chris Jackson]

Hi,
I don’t think you need support for the SCENE_CONFIGURATION. The documentation states “On default, the scene number equals the association group number”, so it should do something by default without configuration (at least that’s my understanding). This is also how the KFOB works - it defaults to certain numbers which are fine - but you can change them if you really wanted (and were able).

Can you send the XML file that the binding creates for this node?

Cheers
Chris

[hans.jo...@gmail.com]

Attached..

I get this with debug logging if its any useful.. :)

16:39:47.920 DEBUG o.o.b.z.i.p.ZWaveController[:147]- Message type = REQUEST
16:39:47.920 DEBUG o.o.b.z.i.p.ZWaveController[:341]- NODE 30: Application update request, node information received.
16:39:47.920 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x80 to the list of supported command classes.
16:39:47.920 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x80
16:39:47.920 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x70 to the list of supported command classes.
16:39:47.921 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x70
16:39:47.921 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x75 to the list of supported command classes.
16:39:47.921 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x75
16:39:47.921 WARN  o.o.b.z.i.p.c.ZWaveCommandClass[:204]- Unsupported command class PROTECTION (0x75)
16:39:47.921 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x86 to the list of supported command classes.
16:39:47.921 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x86
16:39:47.921 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x72 to the list of supported command classes.
16:39:47.922 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x72
16:39:47.922 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x85 to the list of supported command classes.
16:39:47.922 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x85
16:39:47.922 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x8E to the list of supported command classes.
16:39:47.922 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x8E
16:39:47.922 WARN  o.o.b.z.i.p.c.ZWaveCommandClass[:204]- Unsupported command class MULTI_INSTANCE_ASSOCIATION (0x8e)
16:39:47.922 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x2D to the list of supported command classes.
16:39:47.923 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x2D
16:39:47.923 WARN  o.o.b.z.i.p.c.ZWaveCommandClass[:204]- Unsupported command class SCENE_CONTROLLER_CONF (0x2d)
16:39:47.923 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x77 to the list of supported command classes.
16:39:47.923 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x77
16:39:47.923 WARN  o.o.b.z.i.p.c.ZWaveCommandClass[:204]- Unsupported command class NODE_NAMING (0x77)
16:39:47.923 DEBUG o.o.b.z.i.p.ZWaveController[:350]- NODE 30: Adding command class 0x84 to the list of supported command classes.
16:39:47.923 DEBUG o.o.b.z.i.p.c.ZWaveCommandClass[:194]- Creating new instance of command class 0x84
16:39:47.924 DEBUG o.o.b.z.i.p.SerialMessage[:98]- NODE 30: Creating empty message of class = RequestNodeInfo (0x60), type = Request (0x00)

[Chris Jackson]

Thanks

Looking at the pepper1 database for this device (http://www.pepper1.net/zwavedb/device/501), there are some config options that might be required -:

Paramter No.	11	Size	1	Default	1
Name	Action on group 1
Description	In Switch On/Off only mode On command is sent on Dim Up, Off on Dim Down. In Scenes mode the scene ID sent is (10 * group + ActionID), where ActionID is: 1 = On, 2 = Off, 3 = Dim Up Start, 4 = Dim Down Start, 5 = Dim Up Stop, 6 = Dim Down Stop
Type	rangemapped
Values	0   ->   Disabled 1   ->   Switch On/Off and Dim (send Basic Set and Switch Multilevel) 2   ->   Switch On/Off only (send Basic Set) 3   ->   Switch All 4   ->   Send Scenes 5   ->   Send Preconfigured Scenes

This is of course replicated for all groups, but the interesting thing is the default value is 1, which makes it act like a switch. If you want it to act like a scene controller, I think you need to set these to 4. I just checked the key fob config, and it is set to "Send Scenes”.  See if that helps.

Are you able to make a config file for this device? If not, let me know and I’ll make one as it’s nearly the same (I think) as the key fob one.

Cheers

Chris

[hans.jo...@gmail.com]

Hey,

Funny thing is that I'm pretty sure they are set to 4 on parameters 11-14, I am using openzwave control panel and modified the manufacturer_specific.xml to detect it as a Zwave>me KFOB..

When I press one of the buttons the WCD1 lights red shortly and then lights green... I've tried to set 11-14 to 5, then I only get the red light, and when I set it back to 4 I get the short red and long green light, which I think is supposed to be a confirmation?

// Hans