Can anyone tell me what this actually does? Cant find any reference to it.
When you ramp a cbus group address the initiating unit just sends out a ramp giving a end value and ramp rate. It is up to receiving devices to do the physical ramping (e.g. an output device like a dimmer). By default the SHAC doesn't track ramps for events so it will only trigger a single event at the end of the ramp. If you select track ramps it will call the event at regular intervals during the ramp. For 4 second ramps it's every second, 8 second ramps every 2 seconds, 12 second ramps every 3 seconds and then gradually less often as the ramp rate increases. I'm sure there's some logic to it, but that's not documented anywhere.
Might be a silly question, but I see no functional change when this option is ticked or not. So in what situation would you use it? Scripts are always periodically triggered during ramps for me, whether the ramp is initiated by the NAC or elsewhere like a PIR, and regardless of this option. That would indicate that the dimmers are reporting status periodically on the network and that the NAC is acting upon those messages.
No they don't. They issue a start ramp command and a final set level command at the end of the ramp. The 'execute while ramping' works fine for me. If it's unticked you just get an event at the end of the ramp. If ticked you get regular events during the ramp.
Hmmm. Then not a silly question. It would appear broken for my NAC on v1.11.0 as it makes absolutely no difference.
I'm still running 1.6. (They didn't fix any of the important issues to make it worth upgrading for me). Maybe someone else can test it on 1.11 and see if it's general or isolated to yours.
Righto. I have another device on 1.11.0. I might try flashing it with 1.6 / reset and give that a go. Cheers Ashley.
Sooo... Downgraded a SHAC to 1.6.0 ... works perfectly with execute during ramping, or not. Upgraded it to 1.10.0 ... busted. Triggers the script during ramp with that option set on or off. Stay on 1.6 Ash. I'll log something with Schneider. Edit. Logged: Case 93590350
This feature has been confirmed broken by Schneider support in later firmware versions, and has been escalated to engineering to hopefully be resolved in an upcoming release. I would appear to be the only person to have noticed and reported this issue, so hopefully that doesn't affect priority on the fix list.
