Set Level ignores ramp rate

[Hatallica]

Hubitat C7 running 2.3.4.153
webCoRE community app
Zooz Zen77 dimmer HW 1.0 running FW 10.30 (5 devices behaving the same)

Ramp rates operate as expected from the paddle and Hubitat device page (Set Level, On, Off). I converted to the community Advanced driver to ensure access to parameters (9, 27, 28, 29) and easily confirm their values.

Previously, I was using the native Zen77 driver, FW 10.10, and only setting parameter 9 to control all ramp rates. The update to FW 10.30 and change in drivers was an effort to unlock these ramp rates.

However, sending a Set Level command from a webCoRE piston results in an abrupt (<1 second) change. Behavior remains the same no matter what ramp rate is set on the device. Does Set Level behave differently when it is sent from the device page versus webCoRE? Do I need to include a transition time with each Set Level command?

Below is a green snapshot of an example piston, for reference. I happen to use device variables, but have also tried using the device name directly during troubleshooting. Any guidance is greatly appreciated.

[thebearmay]

Can you supply the command a second parameter, i.e. duration

[bcopeland]

setLevel command has level and duration (time to complete transition)

[Equis]

I also noticed my kitchen and bedroom lights no longer follow the transition time in the device settings. Kitchen lights are GE dimmers and bedroom is a Sengled dimmable bulb. If I change the level in the device settings, it transitions over 5 seconds. If I trigger piston (button press, etc), it changes in less than a second. I use the set level command in my webCoRE pistons.

[Equis]

Hm, I do see the duration as an optional setting in webCoRE now. That must be new. Since it's optional, if it's not set explicitly in the piston wouldn't/shouldn't it default to whatever is set in the device settings?

[Hatallica]

@thebearmay

Can you supply the command a second parameter, i.e. duration

@bcopeland

setLevel command has level and duration (time to complete transition)

Agreed. Duration does work. Thankfully @Equis recalls a similar change in behavior, so I feel slightly less crazy.

To recap:

• Device page Set Level (time blank) respects ramp parameters.
• webCoRE Set Level (time blank) now seems to force a duration value of zero.
• webCoRE seems to have behaved like the device page in the past.

Going back to tweak each piston with durations is not such a huge deal. I do rather like the idea of a ramp rate, though. Hopefully having it recorded here will save someone else some wasted time chasing drivers, parameters, or firmware.

[nh.schottfam]

It will help debug if folks mention

using built-in or user-install webcore

what the version is (seen from the main webcore application)

The latest webCoRE code should:

• if the parameter is specified, use it.
• if the parameter is not specified don't send anything (ie the driver gets setLevel(level) only. What the driver does with this is up to the driver

[jtp10181]

@nh.schottfam

if the parameter is not specified don't send anything (ie the driver gets setLevel(level) only. What the driver does with this is up to the driver

@Hatallica let me know if this seems to be a problem with my driver. Grab some debug logs and post. The driver should use the device defaults if setLevel is called with no duration, which I think is what you want.

[Hatallica]

@jtp10181

let me know if this seems to be a problem with my driver

Thanks. I don't have any reason to suspect the driver, since behavior is as you describe from the device page. Also, I initially observed the behavior using the native driver and various other devices.

[Hatallica]

@nh.schottfam

It will help debug if folks mention

using built-in or user-install webcore

what the version is (seen from the main webcore application)

@Hatallica

webCoRE community app

Thanks. I might have been sloppy with language, but this was meant to convey that it is the user-installed app.

Version is certainly important, so I will double check when I get back home. For expedience, is this the same as what shows on dashboard.webcore.co?

[Equis]

v0.3.114.20230130_HE - February 15, 2023. Community app installed through HPM.

It worked as you outlined until pretty recently. It changed sometime in the last couple updates. I can't pinpoint exactly when it changed, though.

[nh.schottfam]

Would need to see full logs for the piston.

The latest user-install should not send any parameter if nothing is sent.

If a 0 is being specified, then 0 is being sent.

[Hatallica]

I hope this helps. I am adding the Trace snippet of code below for reference.

3/1/2023, 3:35:07 PM +196ms
+5ms 	╔Received event [PanoramaHE].time = 1677702907171 with a delay of 25ms, canQueue: true, calledMyself: false
+17ms 	║RunTime initialize > 16 LockT > 1ms > r9T > 3ms > pistonT > 2ms (first state access 7 m:12 6 10)
+20ms 	║Runtime (11497 bytes) initialized in 3ms (v0.3.114.20230130_HE)
+27ms 	║╔Execution stage started
+35ms 	║║Condition #17 evaluated true (1ms)
+37ms 	║║Condition group #15 evaluated true (condition changed) (3ms)
+42ms 	║║Executed virtual command setVariable (2ms)
+43ms 	║║Skipping task 20 because of mode restrictions
+53ms 	║║Calculating (decimal)50.0 - (decimal)25.0 >> (decimal)25.0
+56ms 	║║Calculating (integer)25 / (integer)10 >> (integer)2.5
+60ms 	║║Executed virtual command setVariable (1ms)
+64ms 	║║Calculating (string)Not active, dimmed to + (string)25 >> (string)Not active, dimmed to 25
+65ms 	║║Calculating (string)Not active, dimmed to 25 + (string) per mode - >> (string)Not active, dimmed to 25 per mode -
+67ms 	║║Calculating (string)Not active, dimmed to 25 per mode - + (string)Wed, Mar 1 2023 @ 3:35:07 PM EST >> (string)Not active, dimmed to 25 per mode - Wed, Mar 1 2023 @ 3:35:07 PM EST
+68ms 	║║Calculating (string)Not active, dimmed to 25 per mode - Wed, Mar 1 2023 @ 3:35:07 PM EST + (string) >> (string)Not active, dimmed to 25 per mode - Wed, Mar 1 2023 @ 3:35:07 PM EST
+70ms 	║║Piston state changed
+71ms 	║║Executed virtual command setState (1ms)
+99ms 	║║Executed device command [Hallway Dimmer].setLevel(25,0.0) (22ms)
+104ms 	║║Comparison (boolean) true is (boolean) true = true (1ms)
+105ms 	║║Condition #26 evaluated true (4ms)
+109ms 	║║Calculating (integer)4 + (integer)1 >> (integer)5
+112ms 	║║Comparison (enum) inactive stays (string) inactive = true (1ms)
+115ms 	║║Doing nothing found timed trigger schedule stays result true found timer for condition 27
+116ms 	║║Condition #27 evaluated false (10ms)
+117ms 	║║Condition group #25 evaluated false (condition did not change) (16ms)
+123ms 	║╚Execution stage complete. (96ms)
+182ms 	║Setting up scheduled job for Wed, Mar 1 2023 @ 3:36:07 PM EST (in 59887ms)
+184ms 	╚Event processed successfully (179ms)

[nh.schottfam]

I suggest you do an HPM repair, and then show logs.

[nh.schottfam]

The version in in the HE console -> apps -> webcore

I suggest you hpm repair to ensure you are on latest.

[Hatallica]

Repaired. Looks similar.

[Equis]

Repaired through HPM and ran a test of my piston.

3/1/2023, 6:04:55 PM +365ms
+3ms 	╔Received event [Bedroom Lamp Button 1].pushed = 4 with a delay of 24ms, canQueue: true, calledMyself: false
+11ms 	║RunTime initialize > 10 LockT > 1ms > r9T > 2ms > pistonT > 1ms (first state access 4 m:7 4 6)
+13ms 	║Runtime (6889 bytes) initialized in 2ms (v0.3.114.20230222_HE)
+14ms 	║╔Execution stage started
+23ms 	║║Evaluating switch with values [[i::09fb71634ac805277855872bd1950b71::pushed, v:[t:integer, v:4, d::09fb71634ac805277855872bd1950b71:, a:pushed, x:false, vt:string]]]
+25ms 	║║Comparison (integer) 4 is (integer) 1 = false (1ms)
+27ms 	║║Comparison (integer) 4 is (integer) 2 = false (1ms)
+29ms 	║║Comparison (integer) 4 is (integer) 3 = false (0ms)
+31ms 	║║Comparison (integer) 4 is (integer) 4 = true (0ms)
+56ms 	║║Executed device command [Bedroom Lamp].setLevel(100,0.0) (19ms)
+60ms 	║╚Execution stage complete. (45ms)
+65ms 	╚Event processed successfully (62ms)

Here's the piston I'm using to test...

[jake9]

There were some recent changes to WebCoRE to allow duration of zero (Set Level - Duration of 0 - #22 by jtp10181) that seems to have broken the default and I had to go back and add a level command to all of my Set Level commands. That said, having the option to use zero is great for a few of my scenarios.

[nh.schottfam]

So when editing the piston for the setLevel command, can you show what is set for the arguments?

[Hatallica]

This is what I see: