Electronics notes/Knobs and dials

 ⚠ This is for beginners and very much by a beginner / hobbyist It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book. Some basics and reference: Volts, amps, energy, power · batteries · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · skin effect And some more applied stuff: Audio and video notes: See avnotes Platform specific Arduino and AVR notes · (Ethernet) Microcontroller and computer platforms ··· ESP series notes · STM32 series notes Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer · See also Category:Electronics.

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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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)

In terms of electronics or code

Considerations when using switches as input

Button input isn't logic input (by itself)

💤 For context, consider that logic inputs tend to send and sense low voltage versus high voltage.

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 physically bounce, and this short-term variation in mechanical contact is mirrored in the electrical contact, so it amounts to very fast electrical switching (in particular when read out by something with high input impedance).

Clickier switches, often implies throwing a spring-loaded thing around, which tend to then settle.

In this case bounce is fairly literal: the contact area closing bounces a little before settling and making permanent contact.

Things like the cheapest doorbells, where you're grinding two plates together, 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 this, also keep in mind that corrosion from moisture, dirt, smoke, and such will change the exact contact behaviour over time.

We may also call that bounce, in part because we can resolve potential issues in a similar way.

Problems we're solving

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about 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

there are plenty of things that would get confused if they saw all those bounces as real input
more so if it's interrupt inputs, something's Vcc
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
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"

Transient noise

in EM-noisy environments, you can assume you will sometimes get some induced noise
sometimes also for safety reasons - you don't want an emergency off button to do that (and if 100ms of checking (and delay) solves that, great)

When controlling some power,

then fact that you're switching a bunch of current may introduce a mess of spikes (and inductors and capacitors can make that worse)
it could create transient noise for something else closeby
it could become a certification issue.

Problems we might introduce

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.

Small latching switches tend to settle within 10 or 20ms.

Most of the mess may happen within the first few one or two milliseconds.

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 disconnect versus bounce on making contacts

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 circuits

Debouncing in circuits usually comes down to a filter and a threshold.

...usually an RC circuit filter.

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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

Types

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

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.

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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

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
• EMRs are often derated for varying cases, SSRs somewhat less so(verify).

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: