GE 14294 Operation

Other Devices & Integrations Lighting & Load Control
#21

[quote=“tbrock47, post:20, topic:197000”]Huh? lol
Like I said, I haven’t really played with it, and I have only ever had the 14294s. (zwave plus)
This is what Jasco states about the 12724 which appeared to also apply to my 14294s.[/quote]

This is the same documentation they had for the non-plus zwave. I think we all agree what parameter 8 does, the issue is that parameter 7 is never really explained, and in the past behaved counter-intuitively.

#22

My experience is that the parameter 8 is described inaccurately. It claims to be “steps or levels,” but it seems to change much faster if you set it to 99 vs. 1. This would imply 99 is the “percent change” per level rather than the number of levels.

I cannot seem to get manual dimming adjustment to behave independently of these settings. So if I want to be able to set the dim level manually, I need to set the values low. But the ramp down is very slow. How can the ramp up and down be fast while the adjustment goes slowly?

#23

Got around to playing with mine yesterday and found this.

I did a factory reset to the switch to restore settings.
Changed #7 to “99” and #8 to “1”.
I now get near instant ramping when the command is issued via zwave.

I also wanted to point out that Home Assistant has tool-tips for these parameters in the user interface, and this is what the tool-tips say for 7,8,9,10.

Param #7/#9
Indicates how many levels the dimmer will change for each dimming step.
Param #8/#10
This value indicates in 10 millisecond resolution, how often the dim level will change. For example, if you set this parameter to 1, then every 10ms the dim level will change. If you set it to 255, then every 2.55 seconds the dim level will change.

So essentially just setting #8 to 1 (10ms), you would still get 100x 10ms steps.
With #7 at 99 and #8 at 1, you get one giant step at 10ms.

#24

Instant ramp on AND off?

#25

Instant ramp on AND off?[/quote]

Yes sir. Definitely.

#26

Does anybody know what luua code you would need to use to address the parameters directly? I’ve been trying to implement a slow ramp up to turn on my lights to 50% using PLEG. The best I’ve come up with so far is pretty kludgy. What I’ve done thus far, is set the light level, do a 5 second delay, set the light level agin, do a 5 second delay, etc, until the light level gets up to where I want it.

The one thing I noticed from PLEG is that the parameters seem to be named differently than described in this post

I’ve attached a screenshot of what PLEG shows for the device.

I want to set Parameter 7 and 8 on the fly. I’m just not sure of the format.

luup.call_action(“urn:upnp-org:serviceId:Dimming1”, “SetLoadLevelTarget”, {newLoadlevelTarget = “50”}, 173)
luup.call_action(“urn:upnp-org:serviceId:Dimming1”, “?”, ? “?”}, 173) <------ For Parameter 7
luup.call_action(“urn:upnp-org:serviceId:Dimming1”, “?”, ? “?”}, 173) <------ For Parameter 8
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },173)

Or do I need to do something else?

#27

[quote=“wilme2, post:16, topic:197000”][quote=“tbrock47, post:15, topic:197000”]I have since moved off my Vera controller to Home Assistant on a Raspberry Pi, so I can’t really test in the way I could before.
But reading back on the history of this thread, I don’t think I can change my recommendation.

Remember 7,8 apply when you send the command to the switch via the network.
9,10 apply when you physically walk over and press the up or down rocker.

Param 6 - (0) Honestly not sure about this anymore since its been awhile. I would try both 0 and 1 and see what results you get.
Param 7 - (1)
Param 8 - (1)
Param 9 - (1)
Param 10 - (1)[/quote]

This doesn’t work - the switch refuses the configuration. I have tested every combination reasonable, and can not get rid of ramp down. My older ones did best with Parameter 7 at 99 and Parameter 8 at 1 - if you search here, that was the trick for the 10 millisecond ramp. Again, these new Z-Wave Plus refuse a 1 in parameter 8, despite the documentation, regardless of the setting of parameter 6 or 7…[/quote][quote=“JRH In Texas, post:7, topic:197000”]Tbrock47,
Thank you.

Unfortunately, when I change the #3 parameter, I get a message " Device Failed to Configure"[/quote]

I know this is old but I found the problem and it might help someone. z-wavealliance incorrectly identifies all parameters as size 1 but the manufacturer clearly identifies 8, 10 and 12 as 2 byte. I followed the manufacturer and it worked great. Note the mfg still doesn’t identify paramter 6 (which works).

#28

[quote=“tamorgen, post:26, topic:197000”]Does anybody know what luua code you would need to use to address the parameters directly? I’ve been trying to implement a slow ramp up to turn on my lights to 50% using PLEG. The best I’ve come up with so far is pretty kludgy. What I’ve done thus far, is set the light level, do a 5 second delay, set the light level agin, do a 5 second delay, etc, until the light level gets up to where I want it.

The one thing I noticed from PLEG is that the parameters seem to be named differently than described in this post

I’ve attached a screenshot of what PLEG shows for the device.

I want to set Parameter 7 and 8 on the fly. I’m just not sure of the format.

luup.call_action(“urn:upnp-org:serviceId:Dimming1”, “SetLoadLevelTarget”, {newLoadlevelTarget = “50”}, 173)
luup.call_action(“urn:upnp-org:serviceId:Dimming1”, “?”, ? “?”}, 173) <------ For Parameter 7
luup.call_action(“urn:upnp-org:serviceId:Dimming1”, “?”, ? “?”}, 173) <------ For Parameter 8
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },173)

Or do I need to do something else?[/quote]

So, I figured out the problem.

First off, unless variable 6 is changed back to default, it doesn’t need to be changed once set. In reality, the same goes for variables 7 and 8 for setting the ramp rate, but in my case I want to set different ramp rates for different conditions. I discovered the problem was in the wording for variable 7. It says you can have from 1 to 99 steps. It turns out, the larger the number the fewer steps it takes to get to your desired target. So, if you choose 99, thinking that that is the maximum number of steps to use, it’s backwards. 99 steps will get you to your target the fastest. Choosing 1 step will get you there the slowest. In the example below, I choose 15 for fairly slow, but fast enough that it doesn’t take forever to get there. The 255 entry is as expected, as it’s 255 (x 10) ms between steps, so 2.5s

To ramp up:

luup.variable_set( "urn:micasaverde-com:serviceId:ZWaveDevice1", "VariablesSet", "7,1d,15", 173 ) luup.variable_set( "urn:micasaverde-com:serviceId:ZWaveDevice1", "VariablesSet", "8,1d,255", 173 ) luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },173 ) return true

To turn off the lights, I set a faster ramp rate of 25. It’s still fairly slow, but not quite as slow.

To ramp down:

luup.variable_set( "urn:micasaverde-com:serviceId:ZWaveDevice1", "VariablesSet", "7,1d,25", 173 ) luup.variable_set( "urn:micasaverde-com:serviceId:ZWaveDevice1", "VariablesSet", "8,1d,255", 173 ) luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },173 ) return true

The nice thing in all this is even with my recessed LED bulbs, I really don’t notice the ramping up or down of the lights. It’s not as jarring as before when I had just set delays and set the light a specific level.

Regarding the format after VariablesSet, the first is the variable, the second is the number of decimals, and the third is the value you want to set. The last value, after the quotes, is the device number.

According to both Z-wave Alliaance and Jasco, the length for both 7 and 8 is 1 BYTE. 1 Byte is from 0 to 255, or 00000000 to 11111111 in binary, or 2[sup]8[/sup]. Where I think there is some confusion, is the parameters can be 1d, 2d or 4d in luup. If you look at Device Options and the pull down (see attached screenshot), it says 1 byte dec, 1 byte hex, 2 byte dec, 2 byte hex, etc. The abbrevited parameter of luup makes one believe that it’s 1 dec, meaning singles, tens, hundreds, etc, when in fact it’s looking for X bytes dec or X bytes hex.

2d would actually be 16 bits, or 0000000000000000 to 1111111111111111,or 2[sup]16[/sup], (0 to 65535), which is way beyond the accepted value.

So, bottom line, you need to use 1d for these parameters, which is 1 byte dec, which covers 0 to 255.