Does dzVents have something like a semaphore to prevent multiple instances? [Solved]

[FearNaBoinne]

As per the subject, does dzVents have something like a semaphore to prevent multiple instances running simultaneously?

As an example, the Aeotec Quad has a touch and a long press option (it also supports swipes, but Domoticz doesn't, so I'm ignoring that!), but the long-press keeps repeating as long as you keep it pressed, which is fine, but I'd like to prevent a script that is designed to respond to that long press to have multiple copies running, and only respond again when the first one is done.

I've tried searching for similar topics, but most of my keywords do not return any results...

[waaren]

As an example, the Aeotec Quad has a touch and a long press option (it also supports swipes, but Domoticz doesn't, so I'm ignoring that!), but the long-press keeps repeating as long as you keep it pressed, which is fine, but I'd like to prevent a script that is designed to respond to that long press to have multiple copies running, and only respond again when the first one is done.

The domoticz event system is single threaded meaning that only one event script script can be active at any given moment. Exception could be if the script is active for more as 10 seconds. Domoticz will then close the connection between the eventSystem and the script and a new script can be activated.
I don't have the Aeotec Quad but I do have a Xiaomi button which also use longpress. This button only sends the longpress signal once and a longpress release signal when you stop pressing the button.

What do you see in the domoticz log when you longpress and longpress release the Aeotec Quad ?

[FearNaBoinne]

What do you see in the domoticz log when you longpress and longpress release the Aeotec Quad ?

As long as the touchbutton is being touched, it fires events in to the queue, and each one of them triggers a run of the dzVents script... This can cause a laggy response, if the script takes longer, and Domoticz executes it for every single cached event in the queue... Imagine using this to implement a dimmer effect by subtracting/adding a delta value to the dimmer value of a device to create an up/down dim effect depending on the last state and value... The result could be that the dim effect continues after you release the touchbutton, if there are enough long press events cached in the queue...

Code: Select all

2020-11-12 17:37:14.443 (Aeotec Zwave stick v5) Light/Switch (Quad TL Long)
2020-11-12 17:37:14.663 (Aeotec Zwave stick v5) Light/Switch (Quad TL Long)
2020-11-12 17:37:14.733 (Aeotec Zwave stick v5) Light/Switch (Quad TL Long)
2020-11-12 17:37:14.848 (Aeotec Zwave stick v5) Light/Switch (Quad TL Long)
2020-11-12 17:37:14.646 Status: dzVents: Info: Woonkamer Quad: ------ Start internal script: Woonkamer Quad: Device: "Quad TL Long (Aeotec Zwave stick v5)", Index: 1070
2020-11-12 17:37:14.646 Status: dzVents: Info: Woonkamer Quad: ------ Finished Woonkamer Quad
2020-11-12 17:37:14.668 Status: LUA: Device based event fired on 'Quad TL Long', value 'On'
2020-11-12 17:37:14.832 Status: dzVents: Info: Woonkamer Quad: ------ Start internal script: Woonkamer Quad: Device: "Quad TL Long (Aeotec Zwave stick v5)", Index: 1070
2020-11-12 17:37:14.832 Status: dzVents: Info: Woonkamer Quad: ------ Finished Woonkamer Quad
2020-11-12 17:37:14.853 Status: LUA: Device based event fired on 'Quad TL Long', value 'On'
2020-11-12 17:37:15.053 (Aeotec Zwave stick v5) Light/Switch (Quad TL Long)
2020-11-12 17:37:15.247 (Aeotec Zwave stick v5) Light/Switch (Quad TL Long)
2020-11-12 17:37:15.319 (RFLink) Temp (Xiron)
2020-11-12 17:37:15.012 Status: dzVents: Info: Woonkamer Quad: ------ Start internal script: Woonkamer Quad: Device: "Quad TL Long (Aeotec Zwave stick v5)", Index: 1070
2020-11-12 17:37:15.012 Status: dzVents: Info: Woonkamer Quad: ------ Finished Woonkamer Quad
2020-11-12 17:37:15.029 Status: LUA: Device based event fired on 'Quad TL Long', value 'On'
2020-11-12 17:37:15.185 Status: dzVents: Info: Woonkamer Quad: ------ Start internal script: Woonkamer Quad: Device: "Quad TL Long (Aeotec Zwave stick v5)", Index: 1070
2020-11-12 17:37:15.186 Status: dzVents: Info: Woonkamer Quad: ------ Finished Woonkamer Quad
2020-11-12 17:37:15.202 Status: LUA: Device based event fired on 'Quad TL Long', value 'On'
2020-11-12 17:37:15.413 Status: dzVents: Info: Woonkamer Quad: ------ Start internal script: Woonkamer Quad: Device: "Quad TL Long (Aeotec Zwave stick v5)", Index: 1070
2020-11-12 17:37:15.413 Status: dzVents: Info: Woonkamer Quad: ------ Finished Woonkamer Quad
2020-11-12 17:37:15.431 Status: LUA: Device based event fired on 'Quad TL Long', value 'On'
2020-11-12 17:37:15.596 Status: dzVents: Info: Woonkamer Quad: ------ Start internal script: Woonkamer Quad: Device: "Quad TL Long (Aeotec Zwave stick v5)", Index: 1070
2020-11-12 17:37:15.596 Status: dzVents: Info: Woonkamer Quad: ------ Finished Woonkamer Quad
2020-11-12 17:37:15.613 Status: LUA: Device based event fired on 'Quad TL Long', value 'On' 

It would be better - in this specific case - if it ignored the events that came in after the first one until the script is done...

[waaren]

As long as the touchbutton is being touched, it fires events in to the queue, and each one of them triggers a run of the dzVents script.

The domoticz EventSystem parse every event to Blockly, Python, classic Lua and dzVents except the ones that use the NOTRIGGER option. So if you device does not use that NOTRIGGER option, the event will be parsed.
A kind of semaphore can be implemented at script level using persistent data but the script will be triggered if the device is named in the on = section and a device update is send from the device to domoticz.

[FearNaBoinne]

The domoticz EventSystem parse every event to Blockly, Python, classic Lua and dzVents except the ones that use the NOTRIGGER option. So if you device does not use that NOTRIGGER option, the event will be parsed.
A kind of semaphore can be implemented at script level using persistent data but the script will be triggered if the device is named in the on = section and a device update is send from the device to domoticz.

Yeah, I've been thinking about it... I could probably do some throttling by storing the event timestamp in a variable, and then not allow the script to run for X msec after the last one, by putting a time-check function in the active=() section... With a bit of experimenting I should be able to find an interval that'd allow the system to absorb events that triggered during the last event's run time.

Are there any concerns or obvious pitfalls with that idea that I am missing?

[waaren]

Yeah, I've been thinking about it... I could probably do some throttling by storing the event timestamp in a variable, and then not allow the script to run for X msec after the last one, by putting a time-check function in the active=() section...

I am not a big fan of putting any functions in the active = or on = sections because the functions will be executed on every device change in the system and at every minute.
My preference would be to just put it in the execute function. There it will only be executed when the script is triggered by an update of the device at hand.

Could look like below.

Code: Select all

return
{
    on =
    {
        devices =
        {
            'Quad TL Long (Aeotec Zwave stick v5)' ,
        },
    },

    data =
    {
        lastState =
        {
            history = true,
            maxItems = 1,
            maxMinutes = 1,
        },
    },

    logging =
    {
        level = domoticz.LOG_DEBUG,
        marker = 'longPress',
    },

    execute = function(dz, item)

        if dz.data.lastState.getLatest() == nil or  dz.data.lastState.getLatest().data ~= item.state or dz.data.lastState.getLatest().time.millisecondsAgo > 2000  then
            dz.log('Your actions here',dz.LOG_DEBUG)
        else
            dz.log('No actions to be done because ' .. item.name .. ' has not changed state and time is too soon after last script trigger' ,dz.LOG_DEBUG)
        end

        dz.data.lastState.add(item.state)
    end
}

[FearNaBoinne]

That seems to be working as needed... I'll experiment further, but thanks for the help and code-snippet!