Help please, multi purpose sensor trigger for lights after door closes the second time?

Let me start off by saying, I need your help to convince my partner that having a smart home is a great idea. Right now I only have lights really, but I need to convince her the opportunities and the worthwile investment :wink:

And this brings me onto my condundrum, bathroom light
 I have got a multipurpose sensor on the door (i know i should have got a motion sensor lol) and at the moment its on a timer, but sometimes you are in there longer and sometimes shorter


How do I go about having the light go off after the door closes the second time?

Scenario:

Open door light goes on
Close door light stays on indefinitely
Open door
Close door, light goes off instantly.

If I can work this out, I think it will go a long way in convincing her its better than “just having a light switch on the wall” :rofl::rofl:

I’ll also get brownie points if I can work out a way if the bath is run, the light dims so makes it a better atmosphere for a bath, and maybe change colour. Im thinking something like change of temperature as the sensor is on the inside of the door and has a thermometer. (This one may be trickier than I first suspect it is lol)


Anyway any help is greatly appreciated thank you :slight_smile:

In my opinion automatically turning off lights in bathrooms/toilets and the word ‘instantly’ are generally incompatible.

I’d also observe your scenario is based in a rigid alternate entry/exit pattern. Consider well known real life events such as:

  • Open from outside. Enter and exit the room without closing the door, or just change your mind and don’t go in. Close from outside.
  • Open from outside. ‘Sorry, I didn’t know anyone was in there.’ Close from outside.
  • Open from inside and exit as someone arrives. New occupant closes door from inside.
  • Open from outside. ‘Did you have a rat up there? I’ll give that five minutes.’ Close from outside. Wait. Open from outside. Close from inside.
  • Open from inside. ‘I forgot to do my teeth.’ Close from inside.

All those scenarios will get you out of sync and potentially leave the original, new or next occupant in the dark.

Unless an occupant occasionally lets rip with a world class effort that sets off the vibration sensor, triggering the need for a champagne celebration, you are probably limited to alerts about leaving the door open. You realistically need a bit more to determine occupancy reliably.

When it comes to running the bath allow for cleaning it, with or without comments about hair in the plug hole.

2 Likes

Yeh i suspected the bath thing is trickier.

And I understand your point on the different scenarios and bring up more potential solutions to problems!

I guess on the scenario that it leaves the person in there in the dark, a quick open and close would get the sequence back in sync?

I think I read somewhere you could put a counter on a webcore? Door closes, thats one count, door closes second time thats 2 and then fires light off.

I know its not a perfect fit, but maybe just leaving it on a delay might be a better option, but then we get to the arguement of “just use the wall switch” haha.

Really I should have bought motion sensors rather than contact sensors.

I was just wondering if there was a small work round until she has seen it in action for a month and then she can see the benefit. But right now I’m thinking she might be right


Sorry, I’ve been happily refining scenarios and missed your reply.

As you say, an open/close of the door would always get you back in sync (subject to being out of sync to start with) and if lights are turned off instantly the person who closed the door, either from the inside or outside should still be near enough to open and close it again. So it should be an easily recoverable problem, but it may still cost brownie points.

Yes webCoRE would let you set a counter, and more generally in automations you could exploit a virtual switch, or any other virtual devices with a binary active/inactive state, to act as a flag to signify the room is occupied.

You could also use a real light or switch to indicate the room is thought to be occupied.

In terms of app Routines you might consider things like:

  1. If contact open then turn room light on.
  2. If occupied switch is off (as a precondition) and contact is closed, then turn occupied switch on.
  3. If occupied switch is on (as a precondition) and contact is closed, then turn occupied switch off.
  4. If occupied switch is off (or alternatively if it remains off for a certain period) then turn room light off. Without the remains you could turn the light off in 3.

I haven’t though too closely about the above but there are certainly ways of getting out of sync.

Hopefully someone with more experience of this sort of thing will contribute. I only do a very limited form of lighting automation.

Thats ok thank you for your help! So it took me about 5 hours working this one out
 but it does what i think it should, and a brucy bonus, the light turns off when in theory leaving the bathroom, so a quick shout, a quick open close if it does get out of sync, but it will cost brownie points


Screenshot_20220715-133223_webCoRE

OK, just deleted my last post. I was struggling to see why the piston worked but I think I just have forgotten how globals work in pistons. I knew they were read into cache on startup and the cache was written on exit, but I think I must have forgotten that the updated values couldn’t be read within the piston.

I am not sure why the conditions using the globals aren’t flagged as triggers and I think only one of the two blocks incrementing the piston are needed.

Yeh I used a global, as I thought I may have needed another piston to run it in each mode (night time bulb comes on lower) but realised after I can use the same piston and its quite simple


No i think the incremental blocks need to be like that otherwise it doesnt know when the door goes from closed to open, back to closed, back to open


I have now also incorporated a simulation switch for when we are having a bath, and the piston doesnt fire at all, and tweaked the end and set it to 0 rather than -2 as that was causing me issues haha!

Now I just need to work out if I can set a piston that activates the simulation bath switch, when the temperature rises by X amount in Y amount of time, but only if the bulb is on :rofl::rofl:

But
 webcore isn’t as scary as it first looks! Lol

P.S that is my first ever webcore piston build
 I know its very clunky but it seems to work lol

Keep in mind that WebCoRE is a groovy smartapp. When ST ends support for groovy on the platform at some point in the future, then WebCoRE will cease. When it will occur is unknown.

2 Likes

Ahhh, well I won’t spend too much time learning it then.

Thats a bit annoying as thats a large selling point for ST isnt t
It?

Let’s see if how I think it works is how you think it works. I’ll use the previous version.

Let’s assume the global is 0 to start with and the door opens 


  • The piston is fired by the contact event and reads in the global to cache as 0.
  • The first condition is true because the contact has changed from closed to open and the global is 0. The light is turned on.
  • The second condition is also true because the contact has changed from closed to open. The global variable is set to 1 in the cache.
  • Ditto for the third condition as the piston still reads the global as 0.
  • The fourth condition is false because the global is 0 not 2.
  • The piston exits and the global is written from cache and is set to 1.

Next 


  • The piston is fired by a change in the global and reads it as 1.
  • None of the conditions evaluate as true.

Now the door closes 


  • The piston fires because of the contact event and reads the global as 1.
  • The contact has changed from open to closed so the first three conditions are false.
  • The global is 1 not 2 so the last is false.

The door opens again 


  • The piston is fired by the contact event and reads the global as 1.
  • The first condition group is false.
  • The next two conditions are both true as the contact has changed from closed to open. Both set the global to 2 in the cache because the piston reads the global as 1.
  • The last condition is false because the global is 1 within the piston.
  • The piston exits and writes out the global as 2.

Now here is where I struggle.

  • The piston is fired because the global has changed and reads it as 2.
  • The first three conditions are false as the contact hasn’t changed.
  • The last condition is true so the light turns off and the global is set to 0 in the cache.
  • The piston writes out the new value of the global as 0.

So I see the light closing shortly after the second open.

The piston will then fire again because the global is zero and then again when the contact closed, and do nothing both times.

So if that isn’t what happens I’d be mildly intrigued.

With regard to the modified piston. I recommend that you should swap the conditions on lines 18 and 20. The ‘changes’ condition works by checking that the current event involves the contact, and then compares the new value in the event data to a value remembered from the last time the condition was evaluated. By default, webCoRE only evaluates conditions when necessary and so the first condition might prevent the ‘changes’ working properly. I haven’t considered whether it matters in this case but as a general rule try to put the trigger condition where it will be evaluated.

There’s also the whole category of use cases where there’s more than one person in the bathroom.

Two people showering together, one leaves the room to start breakfast.

One person in the bathtub, calls to the other to bring them a towel.

One person on the toilet, calls to the other to bring more toilet paper.

I believe in All of these the suggested piston will result in one person being left in the bathroom in the dark. Not good for the xAF (acceptance factor by someone other than the person who designed the automation). :scream:

Also note that it may not be safe for the person left in the dark to get to the door to open and close it again, especially if they’re in the shower/tub.

When your goal is to convince someone else that home automation is useful, turning lights on is usually a good argument. Turning them off automatically Can all too easily convince the person the other way. Having a button or a voice option that lets you turn them off after you’re in bed is usually good, though. :sunglasses:

No, i think i may have wasted some of your time, it adds a +1 when the door opens, as when it closed it, it caused issues


I just havent renamed the variable my apologies for the confusion!

WebCoRE is an odd beast. Hanging around Facebook and the Community Forum you can quickly discover that the vast majority of the webCoRE users actually don’t have a scooby how many key elements of it behave. Yet this seems to in no way hinder their successful use of it. There is even a modest body of what I call ‘webCoRE lore’ that is utter cobblers. It still doesn’t seem to matter.

1 Like

For power users, yes, but less than 1/2% of SmartThings users use it. And the publicly stated intention is that there will eventually be similar functionality in the official Rules API and Routines, although maybe not full parity.

If you’re willing to pay a license fee, the thirdparty SharpTools has a nice rules engine and is already working in beta with the new architecture.

But the vast majority of SmartThings users now have a Samsung smart tv or appliance and no hub. Webcore isn’t a selling point for them.

1 Like

Yeh fair point i didnt of it that way that not many use the groovy API, let alone webcore


1 Like

Yeh you could well be right, but it was fun giving it a go!

I think having them on a 10 minute timer will probably be a better option until I can sneakily put motion sensors in without her realising haha!

1 Like

You can use the basis SharpTools rules engine for free. You only need to pay if you want to use advanced features like variables, and http calls.

3 Likes

Again you might see problems with a set timer. If the bathroom was used and the timer starts. If second user go into the bathroom, they could be without lights while in there when they turn off after 10 minutes.

If it was me, I would go ahead and get the motion sensor and you have better contol by using both sensors.

1 Like

Yes thats why I was thinking of other options. Yeh but shes doesnt want the sensors there, and explicitly told me not to buy anything else haha!

Oh well, they will become dumb bulbs i guess


Right an update, i tried to sneak a motion sensor in the bathroom and she noticed it straight away :rofl::rofl:, but she hasn’t left so thats a bonus


However I can now see trying to set automations for every/any permatation that is possible is pretty difficult and can definitely see the advantages of having 2/3 different sensors, even in a small room lol.

I have gone away from webCoRe as A, it’s going to stop working and B, I THINK I can do what I want it to do on the ST app.

Currently I have this:

Door opens, sets bulb to status of home (Day/Night).

Bulb goes off when no motion.

Bulb turns on when motion is detected. (I didn’t want to fire the first routine as I want the bulb to turn on to previous level if the door hadn’t been opened)

I then realsied that the light will become bright as I leave, so I then changed the first parameters “of no motion detected” as if I just pop out after changing the setting for a bath, then I don’t want to have to chane it again.

As it stands I think I have sussed it, and if someone is reading this hopefully it might give someone ideas.

A small caveat, our bathroom door is pretty much always closed, as it opens outwards on the to hallway, so very rarely will it be left open.

Thank you all again for your help and sorry I didn’t listen earlier, mainly due to GF not wanting me to spend money and found it poinless, hopefully now she will start to see the benefit!

The only small issue I can see is, if the bulb is chnaged to a colour, then that person leaves. If someone comes in when motion is still detected, then it will stay on the previous colour/setting. But thats not a huge issue, and not a deal breaker for the above automation.

1 Like