new command with .afterSec or cancel with .cancelQueuedCommands()  [Solved]

Easy to use, 100% Lua-based event scripting framework.

Moderator: leecollings

Post Reply
Gravityz
Posts: 652
Joined: Wednesday 16 December 2015 19:13
Target OS: NAS (Synology & others)
Domoticz version: 2025.1
Location: Netherlands
Contact:

new command with .afterSec or cancel with .cancelQueuedCommands()

Post by Gravityz »

i have a script which uses the afterSec(20) option.

at the moment when the script is called the timer is reset to 20 seconds again.

is this the way to do things or should i first cancel the previous command with .cancelQueuedCommands()

eg, is the .cancelQueuedCommands() neccesary because it works with this command as well but i do not know if this eats up memory by extending the timer instead of closing it and calling it again

i basically want the timer to be extended when movement is detected instead of switching the light off and on again

Code: Select all

return {
    active = true,
    on = {
        devices = {
            ['PIR sensor'] = {'between sunset and 00:00'}
        }
    },
    execute = function(domoticz, beweging)
        domoticz.devices('Veranda').cancelQueuedCommands()
            if beweging.state == 'On'  then
            domoticz.devices('Veranda').switchOn().checkFirst().afterSec(20)
            
            end
    end
}
User avatar
waaren
Posts: 6028
Joined: Tuesday 03 January 2017 14:18
Target OS: Linux
Domoticz version: Beta
Location: Netherlands
Contact:

Re: new command with .afterSec or cancel with .cancelQueuedCommands()  [Solved]

Post by waaren »

Gravityz wrote: Wednesday 27 May 2020 14:21 eg, is the .cancelQueuedCommands() neccesary because it works with this command as well but i do not know if this eats up memory by extending the timer instead of closing it and calling it again
The cancelQueuedCommand() is not needed here.

In this case it does not matter. In the deeper code of domoticz the same actions are done. The previous scheduled command is canceled and the new one is scheduled

My personal preference is to include it anyway because it makes the code-logic easier to follow. But that may well be different for you.
Debian buster, bullseye on RPI-4, Intel NUC.
dz Beta, Z-Wave, RFLink, RFXtrx433e, P1, Youless, Hue, Yeelight, Xiaomi, MQTT
==>> dzVents wiki
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest