Vibration Sensor Filter Blueprint for Appliances (e.g. washing machines/dryers/dishwashers)

Home Assistant Vibration Sensor Filter Blueprint

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

This blueprint filters a vibration sensor’s state to robustly track the running status of appliances like a washing machine or dryer.

The running state can then be used for automations to send a notification once the appliance is done.

Tested sensor

This blueprint has been successfully tested with a binary vibration sensor (Tuya Zigbee TS0601 model). The sensor used for testing was purchased for around 5 EUR from AliExpress.

Limitations

The filter is optimized to reliably detect that a washing cycle has stopped, and prevent those conditions from being triggered more than once during a cycle (false positives).

Detection of both the starting time and stopping time is delayed, in particular the starting time.

In case of my washing machine, I receive a notification 5 minutes after the laundry is done.

Instructions

Start by mounting a vibration sensor on your appliance and keep it there for a few cycles to gather historical data for tuning.

The blueprint uses three helpers, all of which are explained on the blueprint configuration page, and can be created directly from there.

Tuning the filter

When configuring the blueprint, you will need to set two tuning variables

  • Started-to-Stopped transition threshold duration.

  • Stopped-to-Started transition threshold duration.

To tune these parameters, open a historic graph of the vibration sensor in Home Assistant and zoom into a cycle.

The actual lenght of the washing program is A + B, which lasted just under 1h 30m. However within A, not much happened that triggered vibrations so we cannot reliably detect the program within that phase. The goal is to identify the end of the program robustly and with as little delay as possible, not the start. For this purpose, we will only consider the B phase which lasted just over an hour.

Tune the Started-to-Stopped transition threshold

This threshold prevents the automation from mistakenly thinking a cycle is over during a temporary pause.

To select a value, identify the longest vibration-free gap within any running cycle. This would be E in the figure above, which is just under 3 minutes. The threshold needs to exceed that value, so let’s set it to 5 minutes. While you could set it higher, it would increase the delay between the actual end of the program and when you receive a notification.

Note: For this to be robust across multiple washing program, ensure this value is longer than the longest gap in any program.

Tune the Stopped-to-Started transition threshold

This threshold is a safety buffer that prevents the automation from starting a new cycle based on brief, non-cycle-related vibrations, such as events C and D.

To select a value, follow these steps:

  1. Find your shortest program: Identify the length of the cycle from the first to the last vibrations (e.g., B in the figure). The threshold cannot exceed the length of your shortest program, or the program will not be detected at all.

  2. Add a buffer: Identify the maximum length of any vibration-triggering conditions that do not mark a cycle (e.g., loading the machine). Add this buffer to your Started-to-Stopped transition threshold. In our example, adding a 5-minute buffer to the 5-minute threshold gives us 10 minutes.

  3. The final Stopped-to-Started transition threshold must be greater than this combined value. A higher value here means a longer delay from the actual start of the program until it’s detected. We will set it to 10 minutes to minimize this delay.

Usage

Once configured, the entity switch can be used to send a notification at the end of a program by creating a separate automation in the Home Assistant UI that triggers on the switch’s state change.

Homepage

5 Likes

perfect, work as intended with a Third Reality vibration sensor… thank you

2 Likes

Thanks. I’ll update the README file on the Github page with info on this sensor being tested.

Perhaps I am speaking too quickly… It appears that I am experiencing an issue with the ‘short vibration’… Currently, if I open the door of my tumble dryer and then close it again (vibration duration = 10 seconds), both timers (timer.start and timer.stop) are triggered (timer.start first, then timer.stop 10 seconds later). Both thresholds are set to 3 minutes.

The two timers do not stop until they reach 3 minutes (even if there is no more vibration). Then timer.start reaches zero and Started/Stopped Helper switches to ‘on’. 10 seconds later, timer.stop reaches 3 minutes and Started/Stopped Helper switches to ‘off’.

It seems that the timers do not stop or reset when the vibrations stop before reaching the start threshold.

For now, my second automation, which sends a notification based on the status (enabled/disabled) of the Started/Stopped Helper, is triggered every time I receive a brief vibration (instead of a complete cycle of the dryer). This is annoying.

Hi Vothar,

I assume the short vibration you’re talking about happens when you’re unloading the machine?

The issue is that the Started and Stopped thresholds cannot be the same. The Started timer needs to be long enough to give the Stopped timer a chance to cancel it after unloading the machine. For a 10-second vibration and a 3-minute Stopped threshold, the Started threshold should be at least over 3 minutes and 10 seconds.

I would try setting the Stopped-to-Started to 4 or 5 minutes to give it a good buffer.

If you’re still experiencing the issue, could you please share a single screenshot of the history of a complete drying cycle that includes the unloading phase? It would also be helpful to see the history of all the helpers in parallel on that same screenshot.

1 Like

HAAAAA, that’s it… my threshold settings were incorrect… I had set them exactly the opposite (in my test, the started timer was less than or equal to the stopped timer… :confused: ). I hadn’t read the requirements properly…

Everything is now working properly, without any false starts :slight_smile: Well done and thank you for your help!

1 Like

You’re welcome. I can probably clarify it a bit better in the instructions :slight_smile:

I am using this and it works well. An alternative approach wouldn’t require timers: For a lookback window W, the estimated state is On if the average state (On being 1) over W > some threshold, and Off if the average state over W < some same threshold.

Instead of a fixed window you could update the estimated average on every state change, and the time between state changes. Some sort of recursing running average, so if the state is X (1 or 0) for N seconds, A1=A*(W-N)/W + N*X/W. (if my math is correct). So you only have one thing to track the running average. If it is less than (say) 0.5 the state estimate is Off otherise it is On.

Might be interesting to try.