Moving some logic from Homegate to SHAC I have simple event based script triggered on a lighting ga that looks like this Code: log(event.getvalue()) if event.getvalue() == 255 then -- do something SetTriggerLevel('general', 'breakfast') elseif (event.getvalue() == 0) then -- do something else end The question arises because the trigger lighting group is also set to ON by the breakfast scene (I know ...) If the breakfast scene sets the level instantaneously there is no confusion, but if the scene ramps to ON over 4s the script is triggered a second time with get.value() == 0 ? Is this intended behaviour? Or something in the tips/tricks/gotchas?
I believe this is intended behavior, event.getvalue() works the same as ifHasChanged in piced. it grates me that in an event script some commands relating to dimming don't happen the same as they do in toolkit/cgate eg if you watch the application log for a ramp command usually you see the group set to 255 or 0 (depending if its ramping up or down) then when the desired level is reached another command for the same GA is sent with its actual level, this doesn't seem to translate to an event script. my understanding is that an event script runs every time an object is updated on the SHAC, irrespective of an objects current level/state, so if say an obj is at 100% / 255 and it gets set to 100% again the script will run another thought, have you looked at the script settings there is a box that can be selected called "execute while ramping" not sure if its set to off or on by default but something to test/ toggle and see if it makes any difference. but it would seem your event script runs while ramping etc. you may need to put in some extra checking like check to see if an obj associated is on or off or check ramp rate with GetCBusRampRate(0, 56, 1) before setting trigger level this would stop the script running the command again. if event.getvalue() == 255 then -- do something if GetLightingLevel('some object') ~= 255 then SetTriggerLevel('general', 'breakfast') end elseif (event.getvalue() == 0) then -- do something else end
The issue here is the object is at 100% / 255 in order to set the trigger level for the scene, then gets set to 100% / 255 again by the scene but the event value == 0. No tick in the box for Execute during ramping. Easy enough for me to work around in this case by removing the ramp, but the behaviour doesn't feel right.
What firmware version are you running? Yeah on second thoughts doesn't seem right i was just testing on 5500NAC with 1.14.0 firmware, logging event it looks like the second command event.value() 0 is sent by a script, so you could filter with if event.sender ~= 'sc' then end have you got SHAC or AC2 controller? event.sender may vary between hardware AC2 and 5500NAC/SHAC firmwares
looks like the sender 'sc' is scenes, so event script is being generated again by the scene being executed. that obj that has the event script tied to it must be in the scene with value 0 which is why it runs twice.l and event.getvalue is 0.
new object lighting 'testobj' new scene testscene, one entry 'testobj' ->255(4s) new event-script testscript, trigger on testobj, with one line contents: log(event.dst, event.getvalue()) set the value of testobj to 255, log shows: * arg: 1 * string: 0/56/150 * arg: 2 * number: 255 run the scene testscene, log shows * arg: 1 * string: 0/56/150 * arg: 2 * number: 0
It seems to be a bug related to AC2 scene handling. If I tick the box to include the light in object logs it shows the object data 00FF0004, so starting at zero even though the light is already on. For comparison initiating the same sequence from a PICED scene the object data correctly shows FFFF0004.
I believe this was an issue that shows up when a group is ramped to a target level that it is already at over a timeframe greater than 0 seconds. If it has not gone public yet, keep an eye out for firmware version 1.15 and see if this fixes the issue.
FWIW, I raised a case with Schneider back for 1.10.0 about event scripts always executing during ramp, regardless of the check box setting. 1.6.0 worked perfectly, so for a while I was running two automation controllers. A secondary one on 1.6.0 for some event scripts, and the other on 1.13.0 for everything else. I ended up writing a work-around for my use case. Code: --[[ Event-based, execute during ramping, name: "HUE final work-around" Pushes HUE final level events to resident script via socket. Tag required objects with the "HUE" keyword and this script will run whenever one of those objects reaches its target level. This script is a work-around version of 'HUE final' that avounds a bug introduced after firmware 1.6.0, where scripts always execute during ramping, regardless of the setting of "Execute during ramping" for the script. Report filed for 1.10.0, but the bug remains up to 1.14.0... But for the bug, these 30 lines should be just 11, which would be far easier to understand what's going on. --]] logging = false huePort = 5435 hueServer = '127.0.0.1' -- Address of automation controller to send messages to val = event.getvalue() dest = event.dst parts = string.split(event.dst, '/') net = tonumber(parts[1]); app = tonumber(parts[2]); group = tonumber(parts[3]) rate = GetCBusRampRate(net, app, group) target = GetCBusTargetLevel(net, app, group) if rate > 0 then final = false -- Ramp almost always begins with zero level (but very occasionally not) if val == 0 or not storage.get('ramping'..dest, false) then -- Initial? if not storage.get('ramping'..dest, false) then storage.set('ramping'..dest, true) if logging then log('Ramp detected for '..dest) end elseif val == 0 and val == target then final = true end else if val == target then final = true end end if final then storage.delete('ramping'..dest) server = require('socket').udp() if logging then log('Sending final level for '..event.dst..' of '..val) end server:sendto(dest..">"..val, hueServer, huePort) end end
1.15.0 for the win. Thanks for the heads-up @Dasman. You little ripper! 16 October 2023 firmware after much... much... waiting since 1.6.0. I upgraded and just celebrated with a stogie and a long poured gin, watching in awe as event scripts execute as they should during ramp. Well done Schneider. A toast to you! It's the little things in life that make one a most happy man. Sadly which shouldn't have been a consternation in the first place. But per my life motto, "It is what it is", I have put up with it. But if it is not then I am most glad that it is no longer!!!
