Electronics notes/Knobs and dials
Potmeters
Variable resistors (see potmeters), many of the ones with a knob are single-turn, meaning they go though their resistance range in usually at most 300 degrees of rotation.
This makes them useful as absolute-position rotation sensors.
Not overly accurate ones, but cheap and fairly durable.
Rotary/linear encoders
Incremental encoders, a.k.a. Relative encoders (only) report/detect change in position, from which you can calculate direction and speed. ...assuming you're sampling fast enough to not miss transitions.
The idea behind incremental encoders is roughly that they're seeing two things 90 degrees out of phase
One way is to use a a quadrature encoding disc.
You read these out with two sensors at the same angle (e.g. the red bar in the image on the right is two sensors).
You can detect speed based on how the rate of state changes, and detect direction based on the sequence (which one leads the other).
There is a variant of that idea in how many mouse scrollwheels (and opto-mechanical ball mice before that) work: a wheel with a single set of slits, and sensors offset less than(verify) half the slit distance, which effectively has a response very similar to a quadrature disc.
This is effectively the same in terms of what you do with the output.
As-is, relative encoders are useful for things like menu navigation, where only movement matters in the first place, and when sensing speeds.
Absolute encoders report their actual position, from which you can then infer direction and speed.
You could intuit these as encoding their position as an integer, but they're actually Gray code, more useful in this context because it lets you detect and potentially correct successive values that don't make sense after the last.
Virtual absolute encoder (TODO)
Readout
In terms of electronics or code
Resolver
https://en.wikipedia.org/wiki/Resolver_(electrical)
Considerations when using switches as input
Button input isn't logic input (by itself)
Logic output to something else's logic input is potentially just wired output-to-input
- ...with some footnotes like
- the voltage level should be the same
- sharing ground must not cause issues).
- with some though to impedance and the currents that might set up
Switches themselves either short a circuit, or not (Low-impedance and high impedance, if you prefer).
That's not voltage, so a logic input won't sense that.
Even if you switch a voltage, if you do it in series, then one of the two states of the switch/button still leaves it essentially a floating input (meaning that in that state there is nothing to pull it to a stable state, and the tiniest electrostatic effect or EMI/RFI around might influence it (more so if the traces are longer because what we have made is a crude antenna)).
Given typical further constraints, the basic workaround is often a pullup/pulldown resistor. See also floating inputs for more context and footnotes.
Bouncing
The mechanics in almost all switches means when you change them to their other state, their contacts will have some time of moving, and some time of uncertain contact.
In clickier switches, that bounce is more literal: you throw a spring-loaded thing around, which tend to arrive with some force, bounce, then settle once that energy is lost in the physics.
That intermittent mechanical contact is mirrored in the electrical contact, so amounts to (sometimes very) fast electrical switching, in particular when read out by something with higher input impedance.
A different but related effect, seen e.g. in the cheapest doorbells where you're grinding two metal plates together,
is that they will continue to make intermittent contact as you move your fingers.
Also because they're more likely to be a little corroded.
...and once you include such not-quite-bounce effects, also consider dirt, smoke, corrosion from moisture, and other things like it will also affect contact behaviour over time.
We might call all of that bounce, in part because we can resolve potential issues in a similar way (often called debounce).
Problems we're solving
It turns out something as simple as buttons can be an engineering design question, for mostly stupidly practical reasons.
You can easily see dozens of bounces in a millisecond - which is moderately high frequency switching - can be kHz range.
Fast switching
- the individual changes can happen at nanosecond scale
- ...so there are plenty of things that would get confused if they saw all those bounces real changes in the input to react to
- more so if it's interrupts, a processor's power line, or such
- even if logic circuits can reliably react that fast, you may not want it to
- you e.g. may
- not want it to react thousands of times for what you want to think of as a single human/mechanical input
- not want it to re-trigger when a dirty contact moves a little
- you e.g. may
- as such, we effectively want to rate-limit the input (this is often already a side effect, of delayed reaction)
- and could add more limiting with a "once I decide trigger, I will not decide again for the next so-many milliseconds"
Receiving transient noise
- in EM-noisy environments, you can assume you will sometimes receive some induced noise
- You might want to ignore that with the same debouncing mechanism
- sometimes also for safety reasons - you don't want an emergency off button to trigger (and if 100ms of checking (and delay) solves that, great)
Causing transient noise
- when switching current on a wire, you make a little antenna, and will be the cause of EM noise
- also to other parts of the same device, because those parts are close
- it could become a certification issue.
- generally not so pronounced until you're switching more than a little current
Problems we might introduce
Delay
- most debounce methods come down to something "hang on, I'm checking repeatedly whether that looks consistently",
- which will almost necessarily introduce a delay.
- The code need not pause at all, but the decision will be later, and when spurious triggers are a worse problem than a delay, that is perfectly solid idea.
- Such a delay also usually rate-limits how fast that output can switch, which is usually a bonus.
Noise causing you to ignoring real triggers
This one depends a lot on how you implement it.
Say you implement "when I see an edge, I sample 50ms, and decide it's real if more than 75% of that is pressed sate; once that is done I start again".
- Say you see 40ms of pressing with a little bounce. It gets seen as a real press, just once. Great!
- Now say you see one transient, and 30ms later you see 40ms of pressing.
- That transient starts our sampling, so 20ms of that press fall into that sampling period, but is not enough.
- we start again and immediately see it pressed and start a sampling window, but only 20ms of the rest falls into this, and is also not enough.
- Congrats, we just completely ignored 40ms of pressing.
That particular problem is solved easily enough (e.g. continuous sampling in a ringbuffer of sorts, which you probably zero out on a press decision), but you do have to think about it.
And there are further edge cases we could think of.
So do we really need to debounce? If we want really low delay, can we just... not?
Why not react immediately, and somehow rate limit so this fast switching nonsense is also solved?
Because crosstalk, EMI, RFI and other noise exists. If
- you can avoid all noise, or
- you can get away with assuming it does not exist
then sure. Neither is very realistic, except maybe in some well controlled conditions.
Also, the impedance of how you measure also has an effect of how much of that you notice.
Assuming you figure out some that could you react to the first change in under 1ms? Absolutely.
Will that work on you desk in your lab? Sure.
Could you get away with it in DIY? Probably.
Would it practically hold up as a solid product and get no negative reviews ever? Maybe not.
Will that work shoved into, say, a nightclub (lots of devices leaking EM everywhere)? Probably not.
I have seen some hardware made for behavioural experiments (where initial latency matters) react to the first edge without debouncing.
- ...and still debounce the release, so it can sense "button was held" solidly (if letting go a little late)
- ...which also puts a serious rate limit on any presses
Will that hold up in a high-EMI environment?
- Maybe not, but for that particular case that's something you can usually control for.
May it need its buttons replaced earlier?
- Maybe, and if so, you'll probably have a technician around.
If I want to debounce, what can we assume?
Well, bounce images like the above look clean for lab-condition and cherry-picking reasons, but in the real world
- there are different kinds of buttons,
- there are different sizes of buttons,
- there are capacitive effects,
- there are sampling impedance details,
- temperature and humidity may change these properties a little
- the contacts will oxidize over time,
- the contacts will pit if arcs happen (when they control power),
- there are details to how e.g. logic-level interpretation sees this signal
Point being made:
Not all environments are created equal,
you rarely control all the details
and quantifying this is hard.
So even if you fix it very precisely for a specific switch, wire, and circuit today, exactly the same may fail to work in another device, relocated, or a year from now.
Different combinations of input impedances, and what you connect,
also work out as different amount of sensitivity to EM.
- microcontroller pins tend to have impedance somewhere between 100k and 1MΩ (verify)
- the pullup/pulldown impedance may be specced differently. E.g. AVRs seem to be between 20k and 50k, RPi between 50k and 60k (which can be more sensitive to EMI).
- so you might wish to use / add your own pullup/pulldown of 10k or less.
Not all switches's bounce is created equal
Mechanical differences
See also the debouncing-method plot below - already shows some different delays and contact patterns from different buttons under test
The mechanics of specific switch/button design ends up mattering.
Some types of switches bounce more than others.
For example, a classical doorbell maybe bounces less, but may also have imperfect contact while you hold it (looks like fast switching), which you would also call bounce. It may be faster than some alternative, but also less predictable - and this will change over time as the contacts corrode.
For the same design, smaller switches may bounce less.
On the other hand, something with a click, like a microswitch, will probably bounce a little longer but is effectively more stable in each state even though it is functionally as momentary as the doorbell-style pushbutton.
Bounce timespan
The mechanics of most switches depend on their size, and type.
Individual bounces may take e.g. 100 nsec.
Small latching switches tend to settle within 10 or 20ms,
and most of the mess may happen within the first few one or two milliseconds.
Larger switches may be messy for longer, and take longer to settle.
You may like to see what that looks like when sampled, like the image on the right, though again, the details will vary with mechanics and size.
Also keep in mind that capacitive effects will change the shape of that - traces like this are often lab-conditions with reasonable pullups/pulldowns, and high input impedance (because oscilloscope).
Bounce on disconnecting contacts versus bounce on newly made contacts
I had both cleaner and dirtier variants of that yellow-leaving part (and this is a fresh switch, it might be a little worse if corroded/arced with use).
The vertical offset between the traces is artificial, for visibility.
The horizontal offset is real, a ~1.5ms difference between the two contacts's actions.
In various switch designs, breaking a contact tends to be cleaner than making the same contact.
Intuitively, consider momentum-like reasons: if a contact gets flung by a spring-like thing, there's more energy to waste at the end of a movement/acceleration, and very little at the start. It may still have a scratchy start, though, so it's not perfect.
The oscilloscope traces on the right are from
a non-latching pushbutton (which is still fairly clicky, and stable on both sides),
that has both normally-open and normally-closed contacts (alternatively, seen as SPDT).
The first image is from when it is pushed in, the second when it is released. You can see that in both cases, the action of leaving is cleaner.
So if you can have a contact-breaking solution, it helps. ...but only so much.
For one, the actual physical contact of a switch still depends with the physical design of that switch. This happens to be a fairly clean case, others are not.
Also, these two images are absolutely cherry-picked. Even this fresh, never-saw-an-arc button also had dirtier traces for releasing contacts (though still not nearly as messy as arriving contacts).
So sure, debouncing a contact break may be simper and faster - but if you think you have to do little or no debouncing,
then you or your clients will be rather unhappy some time later.
(...and yes, there is delay between the two, which is mostly just physical travel between the contacts - think of it as a SPDT switch. It was roughly ~1.5ms for this switch and how I pressed it. )
Doing debouncing
Debouncing in hard ware - SR latch
Debouncing in hardware - RC circuits
Debouncing in circuits usually comes in one of two flavours.
One is down to a filter - usually RC filter - and a threshold.
You can think of it as a capacitor charging slowly towards the new levels
- If there are transients, they will contribute to charge but will not cause toggling themselves.
- If there is a lot of bouncing but it's still mostly connected, this slows that charging
Basically, find the button's bounce time, then figure out a filter where that is maybe 3RC
- In the image on the right, the circuit is slower than that, and might benefit from a smaller capacitor.
You may want to be a small factor more pessimistic to account for things like humidity and temperature. If you don't know what will get connected to your input, it can pay to choose be a few factors more pessimistic - slower but stabler).
If you have a comparator without hysteresis, its output may still switch moderately fast, if the output of that charging happened to still be changing directions while the output voltage is around the comparator's level.
Also, any input that wanted to react to a sharp edge to react to will not get one.
Two possible reasons (among possible others) that you might want to add a Schmitt trigger after this.
In the image above that mostly happened when it was still relatively high voltage,
but if you tweaked it to be faster, that would be a larger risk - even with a Schmitt trigger.
Debouncing in software
Software debouncing is mostly variations on the idea that when pressed, a button would be in actuated state most of some recent time before the debouncer actually considers it changed.
For example, the most basic arduino debounce code essentially just samples twice, typically 25ms or 50ms apart and effectively says "if the last two samples are high, output is high".
This feels a little cheaty but consider:
- two random samples in mostly-non-actuated are unlikely to both be high (unless there is a lot of EM interference around
- two samples during a actually-pressed bouncy transition are still only moderately like to agree
- if pressed, you often get either one sample within transition and one settled, or two settled, and both work decently (with some difference in delay)
Upsides
- the likeliness that both sample high when the button is pressed is nonzero, but usually are or can be made be made very low (and there are ways to lessen the EM noise issue)
- so works quite well for something so simple and CPU-cheap to implement (does not need to wait, sampling a GPIO takes order of microseconds(verify))
- the larger the time, the more that you limit fast oscillation (because you only change your decision slowly), and the less likely it is to oscillate overall (most switches will be stable after a while)
Limitations:
- fragile around significant EM noise (mostly because high impedence sensing is sensitive)
- regularly a somewhat lower-valued pullup/pulldown is a decent workaround, though this takes some consideration of the circuit
- the more stable you want it, the slower it needs to be, and the converse:
- becomes somewhat more fragile if you lower the interval too far (limitation determined by the mechanics of the switch)
- we don't know about the first edge, we just sample at a random time - so it's not the fastest or most consistent method anyway
Another method is to sample more frequently, count up when pressed, count down when not, and use a threshold
- can be made to react a little faster than the previous method, because you might notice a consistent on a little sooner
- has its own tradeoff between speed and robustness - but this is more gradual (how fast to sample, how high to count) and tweakable (e.g. counting up faster than down biases it a little faster).
- can still oscillate if the whole manages to float around that threshold. This is fixable with some intentional hysteresis
A rolling average (e.g. EWMA), much like the RC circuit below
- more computationally expensive, though, and particularly with a smaller alpha will amout to a slower implementation that is functionally the same as the the counting method
Notes:
- each method can be tuned somewhat for speed
- there are some implementations that you can bias to one way (e.g. a pushbutton is considered non-pressed until it's fairly consistently on) - but beware of variants of that code that will effectively debounce in one direction but not in the other, because that may have different implications
TODO: write up a fuller explanation, including common avoidable mistakes
Example of software-debounced results
A few different switches and buttons, sampled fairly quickly, and debounced.
The following also tries to illustrate that different kinds and sizes of switches may have different bouncing behaviour (though fails to show the effect of things like corrosion - the pushbuttons seem good now but are more likely to become worse over time):
Notes:
- colors:
- Blue lines and blue fill indicate the raw button state, which is boolean, because it's read with digitalRead (itself effectively a thresholded version of varied voltages).
- The yellow fill is debounced via the simple interval method, "it's high now and it was high X amount of milliseconds ago" (evaluated with that same amount of millisecond interval, which is part of why this is also fairly stable output-wise - but also comes at a random time after initial event at least in this implementation)
- The purple line is the counter method, showing the increasing counter with a line, and a purple fill once it's above the (somewhat low) threshold.
- Both methods would absolutely still flip-flop fairly quickly (or, on the other hand, act relatively slowly) if tuned wrong.
- In this example they are both a the tightest value they won't flip-flop at. This is cheating given this particular data - in general you usually want to trade away speed, for more more robustness (and methods may become of more comparable speed when you do that anyway).
Switches, buttons, toggles, and such
Encompasses combinations of:
- Multiple positions,
- a mechanical tendency to go to one position
- toggle/flip, or momentary
- multiple electronic states,
- and other electronic properties
Bistability refers to switches that will rest in both states.
It could be both a mechanical and electronic descriptor, though on the mechanical side it's often called latching, or some such term, whereas a monostable would refer to what most relays do (the term "monostable switch" would be rare because we have words like "momentary" and "pushbutton").
...so the terms monostable and bistability are usually about electronic switching, e.g. to pointing out e.g. that
- digital circuits can be made to sustain their current state.
- thyristors will stay in their current state, while transistors are not
- ...often then mentioning a simple bistable multivibrator circuit, a.k.a. flipflop), or contrasted with a monostable multivibrator
See also
Types
pushbutton tends to refer to any momentary thing, a switch frequently to something that stays in whatever state..
When shopping, it helps to know some names more specific than "small switch". A few more specific buttons/switches:
Toggle switch
- states: often two, sometimes three. Often toggled, rarely momentary
- toggle switch
Rocker switch
- states: often two, sometimes three. Often toggled, sometimes momentary
- rocker switch
Microswitch
- mainly a small momentary push-button
- states: Two. Momentary.
- with or without a metal leaf as a lever
- microswitch
Tactile switches, probably referring to their clicky nature
- momentary
DIP switches
- usually internal, for changeable device configuration that can't be acidentally changed
Reed switch
- states: Two.
- Mechanical, closed by nearby magnet
- reed switch
Mercury switch
- states: Two. Depends on orientation (because gravity).
- no contact bounce
- mercury switch
Knife switch
- The circuit breaker of old
- states: Two. toggled
- knife+switch
Footpedal switches (mostly seen around guitar pedals)
- the 9-pin are typically three separate latching switches (3PDT)
- these also exist in other variants, like single SPDT, momentary (SPST, for taps), and a few others
Uses:
- end switch
- a switch positioned at the end of a mechanical range, often to detect when actuation should go no further
- often a microswitch with some sort of lever, wheel, etc. for durability.\
- end+switch
Contact bounce (behaviour)
Contact bounce indicates the time in which an arriving contact mechanically settles and in which the connection is not yet stable. See some images. This bounce is often tiny, both in movement and time.
This bounce is rarely important when driving resistive loads, but in anything more complex there the reaction to the bounce itself can matter.
For example, a digital system observing/sampling it may see very fast switching back and forth.
Some components, such as ICs, also don't deal too well with bounce on their Vcc. A bypass capacitor helps here, and is nice for its power stability anyway.
Arcs (behaviour)
Default switch state (design)
Switches that are typically in one state are often can be referred to as Normally Open (NO) and Normally Closed (NC), roughly meaning they will return there unless actuated otherwise.
If it has contacts for more than one state (which, when one state is most natural, can be termed NO and NC contacts), the switch is termed Changeover (CO) (also Double-Throw, implying a typical two-state switch, Triple-Throw, etc.).
Changeover switches can be:
- break before make, meaning there is some time in which neither side makes contact. This may cause temporary high impedance long enough to cause some unpredictable behaviour
- make before break, meaning there is some time in which both sides make contact. This may easily cause temporary shorts.
Poles and throwing (design)
Depending on what exactly you want to do, poles and throws can matter when buying a switch.
Amount of poles matters to whether you want to do something with one state (e.g. powered or not) or with both.
Amount of throws matters when you want to control things independently from the same mechanical switch (without digital logic doing it for you). Consider that a car's emergency light switch turns on both turn signals without tying them together electrically.
In some constructions, both matter. Consider multiway switching.
- SPST (Single Pole, Single Throw), 1P1T
- open or closed
- SPDT (Single Pole, Double Throw), 1P2T
- a common lead switched between two other leads, resting either one one or the other.
- Used e.g. in multiway switching
- DPST (Double Pole, Single Throw), 2P1T
- two separate SPST-style switches controlled by the same mechanics
- DPDT (Double Pole, Double Throw), 2P2T
- two separate SPDT-style switches controlled by the same mechanics
Triple pole and similar also exist, for example
- three-phase mains knife switches are essentially 3PST (some are 3PDT)
- 9-pin guitar pedal switches are typically 3PDT
Relays
A relay is an electronically controlled switch - a switch you can flip remotely.
Relays switching an electronically separated circuit can be useful when they deal with different voltages and/or different orders of current.
Say, microcontrollers switching mains equipment.
Relays are also make sense around more modular systems, like process control,
because it's easier to separate control signals from drive currents,
e.g. via connectors following some convention.
Also to have them be plug-and-play replacable.
Electromechanical relays are the classical variant, specifically a solenoid that pushes/pulls a contact closed.
Being the main/only type for a while, just 'relay' often refers to electromechanical relays.
In contexts where you see both, people start using abbreviations like EMR and SSRs, where....
Solid state relays (SSR) are a relatively new development, and are becoming more common.
SSRs seem to often be either
- for switching AC or DC loads: a SCR or TRIAC with the appropiate control circuitry to make them work basically like relays (and may be isolated too)
- for switching only DC loads: a MOSFET
...plus heatsinking, optical coupling for isolation, and some other considerations.
There are also Reed relays, which can switch faster than EMRs, but can rarely switch more than half an amp of current. They are mostly associated with some oldschool analog electronics.
In general, your choice is between EMR and SSR. There is more comparison below, but in general, EMRs ar chunkier but wear over time, while SSRs take a bunch more design care but can then be more flexible.
Circuit considerations - control side
EMRs may need need on the order of 20mA-50mA to be held consistently. More when switched from lower voltages, less from higher voltages.
Because EMRs are coils, they are inductive elements that present flyback to the circuit that drives them, so you may want to sink that flyback spike elsewhere, particularly if controlled from ICs.
Circuits with ICs driving them
- typically something (probably a diode) for flyback protection of that transistor/optocoupler.
- regularly use a transistor (sometimes an optocoupler) to drive ~50mA even when the control
SSRs use less control current(verify), but run hotter overall due to their semiconductor nature, so
- you may need a heatsink or risk thermal runaway (read: smoky melty problems), particularly in already-warm conditions
- for safety's sake assume approx 1W of heat per 1A drawn, though usually it's noticably less
Circuit considerations - load side
Relay ratings
Not all relays are created equal.
The physical design will vary with the voltages they are intended to switch.
- Most are designed for at most mains voltage, because arcing is harder to design away at kilovolts.
- Relays designed for at most dozens of volts can switch faster because they barely have to think about arcing as an .
Relatedly, when switching significantly capacitive/inductive effects, you will briefly see larger currents and voltages (the inrush current of the load).
- This is one reason a relay's maximum rated inductive load is much lower, often well under half the rated maximum resistive load.
- For example, the one I'm holding right now is rated for 10A (at 125VAC and 240VAC) for resistive loads, and for 3A for inductive loads.
- This too depends somewhat on the voltage.
- Specifying these differences is called 'derating
There is also a difference between whether it's switching AC or DC.
- Because DC can sustain an arc longer, DC is derated more(verify).
- Check the datasheet, the ratings printed on the relay may be correct but less complete.
Hot switching refers to switching a relay while voltage is applied, which matters mostly to mechanical relays in that it produces arcing and wear.
Cold switching refers to applying voltage only after a relay switch.
Cold switching is possible to design into some test equipment, and sometimes useful to concentrate the wear in a predictable place, but in general many uses of relays will be hot switching.
Note that while it may seem that using a relay for much less current than it is designed for should avoid all wear issues (no arcing), it seems this actually can make them get dirty instead (?oxidation?(verify)), meaning they will fail to work reliably.
Comparison between SSRs and EMRs
- switching speed
- SSRs can switch at perhaps 20usec..10msec. That said, ones that have zero cross switching are by definition slower.
- EMRs at order of 50ms and wear faster in the process
- SSRs can switch much larger currents without much higher drive currents
- SSRs that do zero point switching means no sudden current change
- so they don't pollute the waveform as much(verify)
- EMRs have contact bounce
- and, when hot-switching, arcing, welding, and shortened contact lifespan
- this is worse on inductive loads
- EMRs are more susceptible to shock, and orientation matters
- SSRs are preferable around strong vibration (to avoid intermittent contacts, amplifying bounce)
- SSRs are preferable when they have to be close to magnetic sensors, temperature sensors
- SSRs can be preferable in humid and dusty environments (but you may want to protect the entire PCB with an enclosure, so this often matters less)
- current draw
- larger EMRs have to push larger contacts
- SSRs are higher resistance by nature, so use a few times more hold current
Safety-wise
- EMRs arc internally so unless they are entirely sealed (various are not), SSRs will be less risky around combustibles/explosives
- SSRs have different failure modes than EMRs, which can matter
- in particular, SSRs are more likely than EMRs to fail closed, which can matter
Protecting relays from capacitive/inductive effects
- if it's DC, you could use a chunky diode on the output end
- if it's AC,
Failure/Reliability-wise,
- Failure state
- EMRs can weld shut so fail in conductive state, but more usually have their coil fail so fail open
- SSRs usually fail in conductive state
- In some situations the latter is a much worse idea, both because they may melt or blow, and because the machine is probably not in a safe state before they break (and leaving e.g. a motor actuated might break it).
- In situations that require fast switching as well (e.g. industrial control), you can opt for SSR for everyday operation and an EMR as a safety interlock controlled from some sensing.
- EMRs can have intermittent connections due to poor contact surface (and spot welds over time)
- EMRs should probably not be switched overly quickly, and because they are physically slowish they often won't even manage
- SSRs have no clear primary wear-out mechanism so should last quite long in gentle conditions,
- yet there are conditions that kill SSRs faster than EMRs.
- SSRs are less resistant to heat (see thermal runaway), and at the same time are warmer than EMRs for the same current.
- so cooling them can matter
Voltage surges, momentary shorts, inrush, and (for some) the polarity of what it's switching matters.
Which means that EMRs can be preferable for components (motors, transformers) with high inrush current(verify).
Inductive can still create high enough voltage spikes to damage SSR's output transistors
You can generally assume EMRs have on the order of 100K switches in them, varying with quality, how near their current rating they are being used (you might get a spec that says 1M at negligible current, and 10K under significant load).
So assuming a few to a few dozen switches or so per day, they should last years to decades, though in some certain fast-switching uses (e.g. industrial machine control) that might reduce to months so you might want SSRs (with the exception that SSRs may fail on, so which you may want to back up with an EMR for safety and other such interesting implications)
Unsorted: