# Should a flow check if a device is currently on before turning it off?

**URL:** https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421
**Category:** Flows
**Created:** [January 14, 2022, 12:01pm UTC](https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421 "2022-01-14T12:01:46Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![K\_S](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/k_s/32/11635_2.png) [@K\_S](https://community.homey.app/u/K_S)
#### Post date: [January 14, 2022, 12:01pm UTC](https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421/1 "2022-01-14T12:01:46Z")

</div>

If I have a a flow that says:

When…  
_Something happens_

Then…  
_Turn off this device_

…and the device is already off, my experience has been that the device remains off, but is there actually any merit in checking if the device is on first? i.e.

When…  
_Something happens_

And…  
_This device is on_

Then…  
_Turn off this device_

Does Homey get confused / use more resources if the device is already in a state that it’s being asked to change?

Or does it make no differece?

---

<div class="post-metadata">

### Author: ![FKey](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/fkey/32/14793_2.png) [@FKey](https://community.homey.app/u/FKey)
#### Post date: [January 14, 2022, 3:40pm UTC](https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421/2 "2022-01-14T15:40:06Z")

</div>

There is an advantage is checking first: less wireless traffic.  
Will you notice?? Not sure…

Personally

- I like to check before sending, to keep trafic low
- I prefer to disable flows that can be triggered often (lux motion) instead of checking with an AND. To keep,homeys activity low

---

<div class="post-metadata">

### Author: ![JPe4619](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/jpe4619/32/9017_2.png) [@JPe4619](https://community.homey.app/u/JPe4619)
#### Post date: [January 14, 2022, 5:31pm UTC](https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421/3 "2022-01-14T17:31:17Z")

</div>

Some devices don’t update their status to Homey when they are switched manually, in that case, a check is not handy, so if you want to be sure the device is switched, then don’t check. The use of extra resources is minimal.

---

<div class="post-metadata">

### Author: ![Martijn\_Hoogenbosch](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/martijn_hoogenbosch/32/10647_2.png) [@Martijn\_Hoogenbosch](https://community.homey.app/u/Martijn_Hoogenbosch)
#### Post date: [January 14, 2022, 7:06pm UTC](https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421/4 "2022-01-14T19:06:44Z")

</div>

What do you mean by disabling? You disable a flow when the light is on?

---

<div class="post-metadata">

### Author: ![FKey](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/fkey/32/14793_2.png) [@FKey](https://community.homey.app/u/FKey)
#### Post date: [January 14, 2022, 7:18pm UTC](https://community.homey.app/t/should-a-flow-check-if-a-device-is-currently-on-before-turning-it-off/58421/5 "2022-01-14T19:18:07Z")

</div>

Its in case I have flows that start with a IF card with  
If motion is detected  
If lux is changed  
If temp is changed

When The flow shoul not be used I disable it  
 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/d/5dc053e7a588fe47406ce6d6d5fd63a7d08594e2.png)  
Instead of using an AND card to verify.

For example:  
A flow that switches off the lights in my livingroom when its light.  
I disable the flow until the sun has risen.  
And not use the AND “its after sunrise”

Dont have the impression homey is running low on resources.  
But no trigger is better then trigger but no action even if its not limiting…  
(So many ways to program flows 😀)
