NodeRed Control - Add Delay option

I am using NodeRed to automate lights based on many PIR sensors, across several ecosystems.

Ideally I would like to extend the delay to switch off if another PIR triggers. In TuYa you can do that by sending an update “countdown” command to the device. That is effectively the same as the “delay” on an IHost device control panel.

Can the delay value be exposed to the NodeRed control node, and enacted in such a way that any calls made when a delay is already active just cancel the active request and invoke the new one?

In Node-red you have the ability using the Q-gate node (search for it in the pallete) to send one message, which is held until another message triggers it. Not exactly sure if that is what you need but playing around with this I’m sure you can get it to work.

BTW what systems are you using?

You can do this with the built on trigger node too. It’s probably just harder to set up. You need to select “send: nothing” “then wait for” and then tick the box “extend delay of new message arrives”. Suspect the Q gate node adds something special or just makes it more straightforward.

sorry, I should have been clearer

Ideally I want to simplify the logic and where processing is undertaken, getitng as much native on the IHost as possible hence having the ability to just programiatically invoke the native delay finction which you can invoke manually

I also aim to move many of my devices away from the other eco systems into my IHost. As compatability becomes better thats is becoming more feasible. If they are all in the same space then I could potentially just use scenes to do this although they dont allow delays to be invokes and multiple activations result in parallel instances of a scene so they have many issues too

I am already using the solution @eerke suggests to achieve the desired outcome but that is that relies on a more complex solution

I use triggers from each ecosystem to invoke a nodered flow with active / delay / deactivate

Tuya (Wifi) via cloud
TuYa (Zigbee) via local control
Tasmota via tasmota nodes but conversting to IHost control
Hue local control via HueMagic node
SonOff via IHost
IHost native zigbee

My question was only to see if, maybe using the same system as me, I could share some Node-red automation with you.
But that’s not the case as I’m bridging all Sonoff wifi, Tuya and Sonoff Zigbee, in the iHost to Smartthings with Matter, where I run the majority of my routines. Node-red handles the more complex automations and as it allows me to create virtual devices that are also bridged to Smartthings, integration is good.
The possible alternatives for designing a ‘smart’ home are many!

The Zigbee2MQTT Palette I use on the iHost Node Red isn’t bad. I forget which one I use. Then you can control all Zigbee devices on Zigbee2MQTT and then register a device and synchronise them on the iHost so they can be controlled from the dashboard in the iHost. The one time Zigbee2MQTT didn’t know a sensor device it still had ongoing MQTT messages that the data was in. I just can’t set it. And the iHost NR has MQTT in nodes. You just need something to run the Zigbee2MQTT on. I’d bet it even runs on the external USB on the iHost as there is a V6 docker image. You’d just need a Zigbee dongle. That’s all Zigbee. Anything with a chip you can put Tasmota on you can control as it can be controlled by MQTT and I’ve checked the MQTT broker can be put on the iHost. Apart from Google Nest stuff and two Tuya Blinds I think I can control everything from the iHost.