Dryer piston based on acceleration

#1

I’m trying to do a similar thing. I want

On initial Event from sensor:

  • set a Countdown timer to 180 seconds.
  • set @status variable to ‘Standby’

While that timer is counting down and @status = ‘Standby’….

  • increment @counter variable each time a new Event comes from the sensor.

If @counter reaches eight before Countdown timer reaches zero,

  • then set @status to ‘On’
  • else set status to ‘Off’

I want it to be event triggered because the sensor might not send anything for a week or more at a time. How do I create a countdown timer that is not telling the piston to wait? I guess I create a @timer variable, set it to 180, and decrement it by one every second?

Trigger Piston if an action is not repeated within a timeframe
#2

For your goal @Glen_King, I would use two pistons. One to monitor Sensor events, and one to run the 180 second timer. Maybe something like:

PistonA

IF Sensor "Event"                 <-- Trigger
Then
   IF {@timer} is not true        <-- Condition
   Then
      Set variable {@status} = "Standby"
      Set variable {@counter} = 1
      Execute PistonB
   ELSE
      Set variable {@counter} = {@counter} +1
   END IF
END IF

IF {@counter} is greater than 6  <-- Condition
   and
   {@status} equals "Standby"    <-- Condition
Then
   IF {@timer} is true           <-- Condition
   Then
      Set variable {@status} = "On"
   ELSE 
      Set variable {@status} = "Off"
   END IF
END IF

PistonB

With location  (TCP set to Never)
   Set variable {@timer} = true
   Wait 180 seconds
   Set variable {@timer} = false
   Set variable {@counter} = 0
END WITH

This method prevents your sensor from affecting the original timer, while still keeping accurate count within.

Note PistonA should have no WAITS at all. (we want those @globals to be written ASAP)
Likewise, PistonB has no triggers whatsoever. It only runs when PistonA tells it to.

Pro Tip:

I normally use LOCAL variables within the piston… and if need be, I copy the local to a @global afterwards. This gives more accurate data results, and a much quicker response time.

If you decide to keep your counter as a @global, you may need to set the conditional check one lower than normal since it would not report the +1 until after the entire piston has executed. (if your counter is local, it syncs instantly)

#3

@WCmore: Thanks for this!

I woke in the middle of last night with an idea. What I presented to you was only a quarter of what I’m doing. My piston is a Dryer piston based on acceleration from a ST multisensor. There are four states: off, warmup, standby, active. Off is default.

On acceleration event, piston goes to warmup status.
Warmup is when 7+ acceleration events occur within a short span (3 minutes). This represents the user opening the dryer, loading it, closing it, setting the dial, and finally turning it on. Each new Acceleration event resets the timer to three minutes. If the event counter never gets past 7 and three minutes pass since the last event, then it was a false alarm and status goes to Off.
(I’ve had lightning strikes set off that sensor, even though the thing is in the basement!)

If eight or more events occur, we move to Standby status. A 15 minute counter begins. Reasoning: a flurry of activity in the region of the dryer could have been non-dryer activity! It could have been loading the washing machine and using the dryer as a table. It could have been prepping beach gear, which we keep in that area. Etc. So we need to validate that indeed, the dryer is being used. (I’m hoping to eventually use various values from the accelerometer to determine whether it’s a person, or the dryer itself, causing the acceleration.)

If we get a confirmation event, we move to Active status and the timer gets reset to 15 minutes.

From here, each new accelerometer event resets the timer to 15 minutes while remaining in Active status. When the timer finally runs out, an announcement happens on my Echo devices and the status goes to Off.

My thought in the middle of the night was that really, the whole thing is a timer - and all the above after the initial activating event could be encompassed in a Do While (timer is ticking) loop, with events within the loop occasionally resetting the number of seconds til the loop reaches zero. In other words, I DO want events to affect the timer. But you’ve given me a new approach. I’m gonna play with this and see where it goes. I think I’d need two separate timers, a 3 minute and a 15 minute. Events would re-trigger the start of the timer.

#4

I have a piston that uses a while loop as a timer, its rather complex and is used to shut down different lights in a sequence at bedtime, with the counter reset if there is movement in the next area to be turned off.
Basically it works by setting a counter to 15, if there is movement, the counter is reset to 15. This code is not in the while loop. The while loop then just runs, with a 60 sec delay, then decrementing the counter. When the counter gets to 0 ( or less than 1) it turns the device off, and breaks out of the loop.

If you could connect a smart switch/power monitor, it may be simpler and more reliable to code by monitoring power usagge,

#5

Thanks… I already do that with the washing machine and dishwasher. Both of those are 120v, and work with smart plugs. The dryer is 240v, and I have the motion sensor to play with.

It will be fun getting it working. It’s sorta there already; the key now is to stop the false alerts.

#6

@Glen_King, I moved this to a new thread so as not to clutter up the original topic. Feel free to modify the title or your earlier posts to help with continuity.

#7

I just got an idea. Why have this thing guess, when it can query the person who is in the laundry room? I have a spare Echo Dot….

Dryer variable in OFF status. On event from accelerometer,

  • if not between 10pm and 6am (don’t want laundry announcements in the middle of the night!) then
  • close ST virtual switch.
  • Alexa, upon seeing that virtual switch close, asks “are you starting or continuing a dryer load?”
  • upon receiving any of the following three words, alexa opens the virtual switch: yes, starting, continuing
  • this starts the now simplified timer piston.
  • if no new accelerometer input arrives within 15 minutes, the “laundry done” announcement plays throughout the house.

My two pistons are coming along. One is nothing but acceleration actions and the results based on applying them to present conditions, and the other is timer functions and the results based on timers winding down. But I’m now intrigued by creating a more conversational interaction experience. So I’ll put those pistons aside for the moment, and explore this new idea.

#8

I like it!! :+1:

For reference, here is my piston that incorporates that logic.

#9

I was in that thread. Great work…. Thanks for the reminder!

#10

I also have a convoluted acceleration-based piston that does some counting. I also added a contact sensor on the dryer door and asked the family to keep it slightly open when there’s no load so the piston does not run.

Hmm, maybe put a simple button by the dryer also that I can ask them to push, indicating there’s a load. hmm

#11

FINALLY! A reliable dryer alert!

BC98E36F-A4D9-4261-A732-32363E16DEB0
BC98E36F-A4D9-4261-A732-32363E16DEB0.jpeg694×1455 128 KB
FA3C298A-4D7C-42E1-9D16-A895F2916001
FA3C298A-4D7C-42E1-9D16-A895F2916001.jpeg1639×1190 184 KB
9F1221A6-16E5-4797-9043-4B88CD990189
9F1221A6-16E5-4797-9043-4B88CD990189.jpeg2527×1809 676 KB

#12

Passing the question off to another ‘handler’ is an option if you do not have text to speech set up. Alternatively, if you already have TTS capability, then the question section can be inserted into this piston… Thereby bypassing any logic in Alexa whatsoever… and preventing the need for all the extra switches.

I can assist with this if you want to go this route.

Regardless of your decision above, I suspect that your line 27 should be changed to a condition. IE:
IF AlexaYes IS on

For reliability, we don’t want a trigger inside of another trigger.
(and we NEVER want AlexaAnswerYes to be a trigger in ANY piston… Conditions only!)

<snippet>

</snippet>

#13

You were correct about line 27. I had multiple images as I progressed, and posted the wrong one.

The “yes is on” handler is already in there. :slight_smile:

The thing I’m happy with here is the time restriction. It is being handled by the Alexa routine, so the piston is simpler.

#14

I have a stackable washer/dryer, but after much experimentation I was able to come up with a very reliable setup which notifies me when a washer cycle and/or dryer cycle completes.

The dryer was easy. Mine has a knob you turn which slowly ticks down to the end of the drying cycle you selected. I was able to attach one of those small slim Visonic open close sensors to the knob, and then strategically placed small magnets around the knob where they dial reaches the cycle completion. With very fine adjustment of magnet placement, I get notified exactly when the dryer cycle ends (or during cooldown if I want to hang dry warm clothes :wink: ) I also placed an O/C sensor on the dryer door. This allows the piston to know if a cycle has completed but the clothes haven’t been removed. Great for when you forget to unload the dryer in a timely fashion.

As for the washer, two sensors. One water-tight, sealed securely adhered to the top of the inside bin, and one on the washing machine hatch. Getting the vibration pattern down was tricky, especially during those fill points when no motion is detected for a period. After a lot of trial and error, I discovered simplicity was the best performer. “If the washer bin sensor stays active for 3 minutes and the hatch is closed, set @washer_running to true”. I’ve found it doesn’t matter what you’re doing on or near a washing machine, nothing records 3 minutes of constant acceleration then an active washer bin. Running the attached dryer doesn’t effect it either.

As for determining the end of the wash cycle, “If @waser_running is true and washer bin sensor remains inactive for 9 minutes, set @washer_running to false, @washer_cycle_complete to true, and @washer_full to true.”. The 9 minutes was derived from testing all cycles to find the longest duration of inactivity the washer bin records during an active cycle. Again, the washer hatch door sensor allows the piston to know when a wash is complete, but the clothes haven’t yet been removed.

It seems you may have have found your solution, but this has worked GREAT for me. Hopefully this may help someone else trying to tackle this daunting project.

#15

I do this in two steps.

“Dryer” is an ST Multi-contact sensor.

image

Then:

image

The second piston only runs if the @DryerCyle is “YES”.