Automating kitchen lights on and off using a zibgee light level sensor and a zigbee PIR sensor combination to detect motion with a 5 minute timeout to turn off lights

OK so this is my current favourite use case. It’s been discussed extensively on the forum but I’ve just implemented it with Apilio and Tuya only so no need for IFTTT! It works much quicker and slicker with the Tuya kit - I really recommend the zigbee devices as they are super quick (see my rather too proud video here).

Hardware being used:

  1. a TUYA Wifi PIR sensor which does NOT send any message at the end of a movement detection timeout period but has an inbuilt hardware timeout of 2mins
  2. a separate Tuya Zigbee light level sensor
  3. All running through a Tuya Zigbee hub

I have set up one trigger condition called kitchen-movement, which triggers everytime the PIR sensor fires. CRITICALLY, I have added a 5 minute Timeout to the condition - thanks @Anna :star_struck: - which will set it back to false after 5 minutes. This is important for the continued detection of motion to avoid the lights going off when someone is in the kitchen.

I have set up a second condition (not a trigger condition) called kitchen-light-level which determines if the light level in the kitchen is below 60 Lux. This is important to me as it’s often dark in our kitchen during the day.

I then add two logicblocks, one to turn on lights and one to turn off lights if there is no motion detected within the 5 minute condition timeout window.

The first Logicblock is straightforward, using the positive action chain to switch on two Tuya light routines. The kitchen-movement condition triggers the logicblock evaluation which AND checks the light level is below 60 Lux. If the AND is true then the Tuya Kitchen Table Group:ON and Kitchen Work Group:ON are switched on.


The second logicblock is even more straightforward but perhaps more complicated to understand (for me at least). If the same trigger condition kitchen-movement fires then this logicblock is evaluated but nothing will normally happen as the result of the evaluation will normally be true because the trigger has just fired. If however there has been no movement for 5 minutes then the timeout in the trigger condition makes the condition false, meaning this logicblock is evaluated (because the trigger condition changed) and the result of the logicblock evaluation is therefore negative, so the negative action chain runs, switching off the lights using the Tuya routine Kitchen lights OFF

So the principle is that a change in the trigger condition causes an evaluation of two logicblocks at the same time.

If the trigger condition turns true then both the lights-on logiblock and the lights-off logicblock will evaluate positive. The lights will turn on but there’s no positive action on the lights-off logicblock so nothing happens.

If the trigger condition turns false then both the lights-on logiblock and the lights-off logicblock will evaluate negative. There’s no negative action chain in the lights-on logicblock so nothing happens but the negative action in the lights-off logicblock will turn off the lights.

The timeout function is so important as it is the mechanism that turns the trigger condition to false, thereby starting the negative action chains.

All clear? Let me know if you have any questions!

2 Likes

I just added a second PIR sensor, at the opposite end of the kitchen, with identical conditions to the first and am using the following complex (:wink:) logic statements:

In the lights-on logicblock: AND(kitchen-light-level,OR(kitchen-fridge-motion,kitchen-radio-motion))
In the lights-off logicblock: OR(kitchen-fridge-motion,kitchen-radio-motion)

Nice.

Sorry if it’s confusing but I changed some label names around to help me out…

1 Like

OK @pebneter :mage: so now I have found out I really need to make the timeout configurable. At mealtimes, socialtimes, sometimes it needs to be 20mins whereeas other times the timeout only needs to be 2mins. Would be great to be able to use a numeric variable as the input to timeout (and delays probably) which could be updated either using time conditions or say a webhooks button to get the timeout boost when required for an hour or so (also depending on time of day) or until the boost button is switched off. What do you think?

1 Like

Bit sad I can’t like and promote my own post :pensive:

1 Like

With the current feature set, you can setup multiple conditions for the delay levels and then multiple logicblocks with timeframe settings. That way you’d have a changing behaviour throughout the day.

1 Like