"Input" on an "output"

I'll tell you why, because you flushed it down the drain on a bunch of oddb all landscaping that required too much water. Modern landscape architecture is getting away from that. People are learning that they have plenty of op tions using plants native to their climate zone and soil conditions. This m eans watering is only required during extreme drought conditions, *if that* . It also means the plants are immune to attack from the local pests and di seases (no pesticides, fungicides, microbicides, bactericides), and they su pply food to the local wildlife in one form or another. You will find that the native plants will do spectacularly well and with very little maintenan ce. There are exceptions with some of the chinensis and japonica imports th at have proved hardier than the natives, but you should check with your sta te agricultural department for things like invasiveness and legality first. Things like water intensive roses are out, and it sounds like the citrus a re too if they absolutely have to have three deep waterings weekly. Sounds like you have a bunch stuff that needs to pulled up and thrown on a compost heap.

"Lawns", golf courses, people using a garden hose to "wash" the cruft off their driveways instead of dragging out a *broom*, businesses watering lush lawns during daylight hours, hydraulic mining, fracking, leaving the water running while brushing teeth, legacy plumbing fixtures, swimming pools, spas, crops that use disproportionately high amounts of water, etc.

Our yard is xeriscaped with the exception of the citrus and roses. I (personally) removed/dug up the "lawn" that was here previously. We use no chemicals to control weeds, pests, etc. (because our domestic water comes from wells and we don't want to add more cruft to that water supply!)

But, you'll find truly "native" landscapes (here) are very boring, lack color, etc. And, you'll find things like blood oranges very expensive (and having to be *shipped* here) instead of growing them yourself (ignore the difference in the *quality*, lack of pesticides, freshness, etc.)

Oranges grown in California/Florida also require water. The difference is the amount available to them as a consequence of local environmental conditions. And, "subsidies" from other water sources. If each locality was required to survive with their own precipitation, lots of crops would just disappear. Or become vastly more expensive. E.g., trade diesel fuel (shipping products) for water.

We offset our "excessive" water needs with rainwater harvesting and general water conservation. Not letting water *leave* the property easily. E.g., using *all* of the precipitation that falls on the property instead of relying on "municipal water" to attend to those needs. Amending the soil to retain moisture instead of letting it seep through directly to the aquifer.

We *surely* aren't wasteful enough to fill a swimming pool/spa and watch hundreds of gallons evaporate *daily*. Or, have a *lawn* watered with "sprinklers". Or a "mister" that cools *outdoor* air (OUTSIDE!) around a patio by blindly pushing water into the air. Koi pond, "water feature", fountain, etc.

Correct. I limited my thinking to a way you can detect a switch state where the switch is installed near the solenoid location and connected using the 2 existing wires that go to the solenoid, _because that is what you asked about_ .

The rest of the functionality you want is up to *your* circuit.

Ed

You make a good point with that. The issue with the failure is not really such a big deal. His controller will be able to sense if the button is shorted and notify the operator. The button is very unlikely to fail shorted, but there are plenty of other failure mechanisms. If the system needs to be robust then these other failure mechanisms should be detected. Probably the most important thing would be to just plain detect if water is coming from the spigot or not rather than detect all the individual failures. Yes, a pressure switch *after* the valve could do that and the pressure switch could be connected to the power wires in a similar manner to provide a result back to the controller. The push button shorts the solenoid, the pressure switch has a resistor in series. So now you have three levels of voltage you need to sense to detect the button and the pressure switch.

I would do this with a current driver circuit. It would have a constant current drive allowing the voltage to float depending on the resistance. Sense the voltage out of the driver and you are done. 24 volts is solenoid operating normally, 16 volts is solenoid operating and pressure detected in the output line, 0 volts is button pressed or solenoid shorted. You could use a low level of current to sense the switch when the water if off, or you could pulse the full current briefly, too short to activate the solenoid.

Don is a tough cookie to discuss things with. You offer some help and he pulls more requirements out of thin air. But for the most part he is brainstorming and that can be part of what we are seeing. He likely didn't think about the failure detection as an initial requirement, it occurred to him after he started thinking about how to implement what he wanted. So it became a requirement because he thinks it will be easy to include whether it is very valuable or not.

I like your idea. But I'm not sure that it will do what he wants if you use a common resistor as a sensor. That would require that you periodically turn off all solenoids and poll each switch. In theory you could do this fast enough that active solenoids do not drop out, but you would then be sending some moderately fast pulses along long lines potentially generating a lot of RFI. I bet it would mess up AM radio pretty badly. Maybe there would be a way to shape the edges to prevent this. I guess sampling 4 times a second would be adequate, maybe even just once a second. That wouldn't be so bad, so maybe my concerns are not valid.

--

Rick

I've not claimed that I *couldn't* detect a "shorted" button. Rather, my objection to this approach is that the "short" implicitly propagates to render the solenoid unusable. As such, the "problem" has to be fixed *now* (or, "before the solenoid would likely need to be actuated").

This, IMO, is just a crappy design philosophy. Failures should have

*confined* consequences (Would it have been acceptable if that failure "took down" the ENTIRE irrigation system? If not, then why is it acceptable to take down that *valve's* functionality when the button's role is not inherently related to that?)

Imagine I can *telephone* the user AS SOON AS this condition is detected. What good does that do him if he's not "at home" to address the issue? If he *is* home, does he have to hire someone on "emergency" service to come right out and fix this problem? Or, can he wait a week/month? *Or*, even decide to live WITHOUT the ability to "signal for water" with that button -- all else continuing to work as intended?

There's a difference between "check engine" and OBD functionality. The latter has far more value than the former. The more information you can provide to a user, the more useful you can be (even if the user doesn't have the inclination/skillset to effect the repair, he can at least convey the information to a vendor/service provider who could then give a more detailed estimate of the cost of the repair ("Well, it'll cost you $100 for us to drive to your house. Then, whatever else we need to actually fix the problem -- time and materials")

Also, the more the system can discern about the consequences of a failure, the better it can adapt to that failure.

E.g., if the valve is shorted to another, then it can avoid "over/under-watering" at least one of those zones whereas acting as if both valves were still isolated (from each other) would result in both zones being overwatered. Or, possibly, *neither* getting watered properly -- depending on the consequences of trying to "open" those two hydraulic circuits simultaneously (you may not have enough pressure to cause water to flow as intended from each circuit)

I've approached this by watching water consumption "at the source". If I open a valve and there is no change in flow rate, then I know water isn't flowing. Because the valve is mechanically defective, because a pipe/filter is clogged, etc.

You actually need more than that to be able to detect all of the

*likely* failures you will encounter.

This is essentially the direction I've been pursuing. The problem is getting the "data" back across the isolation barrier "cheaply". I.e., you don't want to put much on the "exposed" side of the barrier as it represents increased propensity for failure.

My first approach was to use an iso-optilator in its linear region. That can provide lots of information -- more detail than you really need! But, coming up with a design that can reliably ensure you are using *only* the linear region of those devices seemed a bit dubious ("select/tweek at test" is not an option; esp if Joe Tinkerer opts to substitute some other device that he happens to have on hand -- not realizing the "special needs" that are imposed on the device in the circuit).

So, I'm now looking at relying solely on operating them as digital devices and conveying that information in the time/frequency domain. This should keep the actual interface robust, inexpensive and easy to build.

We *all* make assumptions. I don't even think twice about whether or not something like this would have to be electrically isolated. "It goes without saying". Similarly, the desire to keep the amount of stuff on that "exposed" side of the isolation barrier "robust" (surely nothing that is going to fry the first time there's an electrical storm, a large inductive kick in the cable, etc.)

Likewise, that multiple valves could be active at the same time. Or, that "broken wires", "shorted solenoids", etc. are likely to be encountered in this sort of application (from knowledge of the types of mistakes DIYers make when doing these things).

And, the sorts of things that a "system" existing in this sort of environment is likely to encounter -- that you'd not consider if you approached it solely as a technical problem. E.g., a little kid standing there pushing the button, repeatedly or continuously, because he can *see* that each button press is causing the water to stop flowing from the hose -- a consequence of Ed's design (OTOH, if the button is an "independent function" that the controller must *interpret*, then the controller, after seeing several sporadic button presses, can opt to treat the button as "suspect" and disable that functionality -- wildlife? packrat chewing on wires?)

[*You* may, OTOH, assume only the left limit switch can possibly be engaged while "moving left" (see below).]

Folks frequently piss and moan that I'm too verbose. Yet, if I present a detailed specification, do you think that will be any

*shorter*? "Why do you need clause 3.8a?" "Can you eliminate clause 9.6b?" "Why does it have to work in 100% RH? Are you planning on using it UNDERWATER??"

Also, the more you specify, the more you close the door on other possibilities. Possibly incorrectly! I had a colleague go through a very detailed analysis to convince himself that a certain observed symptom could *not* possibly be caused by something I was suggesting. Not accepting his decision -- he was actually my boss/client -- I

*demonstrated* that this was, indeed, the source of the problem! ("Where is the error in my analysis? Let me check my math, again..." "Why bother? Do you doubt what you are *seeing* in my 'proof'?")

I think folks don't think "twice" before responding. I.e., this isn't a place where folks come to ask "simple" questions. And, for the most part, it's not "high school kids" with no background trying to get answers to homework problems. Or, equally clueless homeowners tying to fix their own furnace, etc.

When I respond to a post, I assume the querant has already thought about the problem. So, any *obvious* solution that I see gets double or triple scrutiny: "Surely he would have thought of this, already. Dig deeper for a solution." (e.g., my comment to Joerg, recently, about using a lawnmower engine as an "air pulser")

Note my original post explicitly stated "shorting the coil". So, it should be rather obvious that I'd already considered that as a potential solution -- and moved *past* it (I didn't ask "how do I detect when I deliberately short a coil").

Finally, I consider engineering to be the art of finding the LEAST WRONG solution to a given problem (i.e., there are no "ideal" solutions in the real world). So, I find *my* best and then hope someone else will have a *cleverer* approach. Or, see some issue that will eat my lunch that I've neglected.

Actually, it's the other way around. I *assumed* everyone would have considered that as it's been an integral part of my design process (and the folks I've worked with) for decades.

My favorite example: driving a motorized mechanism. Often, "limit switches" (of some sort) exist to signal the controls when the mechanism has reached end-of-travel in a particular direction. Most folks tasked with driving such a mechanism would write:

case (command) { "left" => while (!left_limit) { drive(LEFT); }; "right" => while (!right_limit) { drive(RIGHT); } * => # can't happen }

I, OTOH, would build a little state machine that modeled the mechanism: "at left limit", "at right limit", "traveling left", "traveling right". Then, monitor *all* inputs in each context.

So, if I think I am "traveling left" and I see the left limit switch activated, I know I have arrived in the "at left limit" state. OTOH, if I see the *right* limit switch activated, I know something is VERY WRONG! I was not *in* the "at right limit" state (so, the right limit switch could not have been active). And, I am driving to the *left*. So, how could the RIGHT limit switch become engaged?

Clearly, the software's model of reality no longer corresponds with "reality". Because we are actually *moving* things, there is a real risk that physical damage/injury can occur when the software is out of sync with the real world. So, go immediately to a "safe" condition -- without relying on any of these models!

I.e., "CAN'T HAPPEN" *has* happened (because someone miswired the drive signals to the motor, it's drive circuit, or the limit switch sensors, etc.). The failure isn't allowed to propagate (cascade, get worse, etc.). And, the "cost" for this protection is just NOT "assuming" that only the left switch is significant when moving left!

[This sort of approach has served me well -- VERY well -- over the years. IME, bugs hide in the "CAN'T HAPPEN" parts of designs.]

Similarly, the idea of relying on "dead plants" as an indication of a failure wouldn't even enter into my calculations. "Doctor, the patient in room 205 is dead".

And, do that fast enough to catch a "quick" button push (or, do you burden the user by telling him he has to hold the button pressed for

15 seconds to ensure it is "seen" by an ULF polling event?)

And this saves, what -- a few resistors? :>

Make the "pin driver" circuit effective; then efficient. As with software, don't "prematurely optimize".

Don, you seem to get very emotional about this stuff. Relax a little and lets just discuss a few things.

My point is that the failure you are describing is *very* unlikely. Push buttons most often fail open or intermittent rather than shorted, especially a quality outdoor button as you would surely be using.

That is my point. You are making a big deal out of one failure mode while there are many others, much more likely, which result in the same problem that you can do nothing about. There is little utility to focusing on this one failure mode rather than looking at the system and considering what are the mostly likely failures and dealing with those.

Yeah, like someone is going to give you any sort of quote over the phone based on the diagnostic of a home built controller. That's not the way service people work normally.

Still, I don't get your point. Why can't you detect details of the failure? I'm talking about what is ultimately useful to the user, knowing that he plants are getting water. In fact, he wouldn't know that unless you also included a flow meter of some sort in case someone shuts off the faucet handle, etc. So if you aren't doing that, you really are just pretending to include a useful self diagnostic capability.

You can try to make the "at risk" side as dumb as possible, but that may be difficult to make flexible so it will work with different resistance coils, etc. A single smart controller watching all the solenoids could be made very simple and cheap so that it would be inexpensive to replace if damaged. Of course you can add protection circuitry which will increase the cost somewhat.

I don't know so much about using linear optos, but why bother? You still have a failure mode, the opto. Why not just put a small, inexpensive controller on the "live" side and live with the small added cost? We are talking less than $5 for an MCU and the circuitry. BTW, remember you need to power this circuit no matter what it is. I suppose you can power this from the 24 V which I assume is AC.

Much easier to just put an MCU on the "live" side and be done with it.

*Any* circuit you put on the "live" side will be susceptible to the transients from lightning, even passives, even relays! It just depends on the strength of the jolt. A simple MCU circuit can have some protection added for the smaller jolts. Keep it inexpensive and consider it an expendable for the few times you have high voltages coming in.

Yes, actually. Much of the info you give is not directly relevant. Such as much of what I just snipped.

That is great if you are really trying for the ultimate solution. But most of us want a practical solution without spending an excessive amount of time "optimizing" it. In fact, I once read a paper on how optimization is a *bad* idea most of the time. Things should be optimized when optimization is required, but otherwise it is best to avoid. Your coil concerns is a perfect example. The design could be optimized to provide lots of noise immunity by assuming some reasonable range of the expected coil resistance. But if you use a different coil, that optimization gets in the way of the circuit working.

Likewise, if you want to optimize the design to have no active components on the "live" side of the isolation barrier, then you will have a design with little flexibility for design issues you find a month, six months or some longer time down the road.

There is no real need to catch a "quick" button. I would expect to press such a button for a "long" time, possibly until the water started to flow. This is an easy issue to deal with by directions to the user. Where did you pull 15 seconds from... no, wait, I don't want to know!

BTW, I have found that gas pumps do exactly this. If you press the octane select button quickly, it is not seen by the pump. You have to press it like you are working a mechanical device, not a quick jab. This is not unusual on ruggedized equipment.

If you think this just saves a few resistors, you don't understand your own design. Each of those resistors have to be sensed and the sensing circuitry has to be protected from spikes. Having just *one* sense element may be the biggest cost saving you can come up with here.

--

Rick

Sorry, I'm actually *not* "emotional" about it. Rather, trying to infuse my sense of priority and commitment to various aspects of the discussion, goals, etc. Old-school, "New England" personality.

(Workplace debates have always been "passionate" -- for want of a better word. But, never "emotional". They are *ideas* fighting, not *people*. "If two of us agree, then one of us is UNNECESSARY!")

Again, you're making assumptions. What *I* would use isn't the issue. What would *you* use if you were a DIYer building something like this (from published schematics)? What would a manufacturer intent on trimming pennies from teh design try to smuggle into the process?

E.g., I'm currently looking at using a pneumatic switch, here with the intent of "burying" the mechanism safely and having only a "tube" to expose to the user. I doubt a manufacturer would go to those extremes.

Buttons can also fail because of the environment they are in. Getting "gummed up" because tree sap dripped on them. Or, ice formed inside the switch or along the path that the mechanical actuator follows.

If *I* am supplying the switch, then *I* can make an assessment as to the likely failure modes of *that* switch. And, play the "expected value" game of offsetting the cost of the "more reliable" switch against the cost of detecting a failure.

If I *don't* have control over the parts used, means by which they are assembled, etc. then I have to expect that "CAN'T HAPPEN"

*will*, in fact, happen!

How do you decide which failures are "most likely" when you can't control what components are actually used and how well they are assembled? I've never had a solenoid fail. Neither the actual solenoid(s) nor the wiring to them. But, I take great effort when making connections, waterproofing them, routing the cables, *digging* in the yard (to avoid hitting any buried cables), etc.

OTOH, I've been called on by friends and neighbors to service varous bits of kit around their homes and found multiple splices in a single cable ("cut out the old component, tie in the new -- but don't bother to remove the old *splice*... just treat it as part of the *wire*!").

I've found 110V electric outlets wired with 220V across them (i.e., the neutral connector wired to the other "hot leg"). Earth grounds tied to live "travelers". 110V devices on 220V services. None of which are *expected* to "happen" -- yet, do!

It's not intended to be "home built". As I've said (here and in other recent threads), I have no desire to be in the manufacturing business. Yet, would enjoy if these designs found a home *with* some manufacturer. So that folks who can't or don't want to recreate these designs can still avail themselves of them -- for a price. If the development has been done for you (as a manufacturer), all you have to do is decide if you can make money at some particular price point *with* that design.

[OTOH, if you enjoy playing with electronics, know how to solder, would like to tinker with the code *in* such a device, then you shouldn't be BLOCKED from doing so because a vendor won't expose the device's innards to you!]

My garage door opener didn't come with an inbuilt ability to "talk" to anything. It could *listen* to *it's* remote. But, the only way to tell if the door was open, closed, jammed, etc. was to walk out to the garage and *look*.

If you, as a manufacturer, could implement a similar opener design replacing the ~900MHz remote with, for example, a BT remote (possibly paired with your cell phone so the cost of the actual transmitter was eliminated) *AND* add the capability of allowing that remote to *query* the state of the door & opener, would you do so if all you had to do was deal with tooling charges?

I.e., now the designs are no longer "home built".

You can monitor flow *out* of the valve and still not know that the plants are actually getting water! A pipe downstream from the valve can fail (as happened to next door neighbor). The emitters for a plant can clog and restrict the flow of water (esp true for drip systems -- you might not be able to detect this until *all* the emitters for a particular plant have clogged)

I.e., a high resolution flow meter is your best bet (assuming you know -- or can learn -- what the nominal water consumption rates are for your zones). This is the approach I have been pursuing as it also gives you other useful information (e.g., "I am not calling for any water, anywhere. Why do I detect water flowing? Has some pipe broken somewhere??")

[It's still possible for certain types of failures to escape detection -- if they resemble nominal usage patterns -- like a broken pipe on a nominally high flow zone]

Actually, it isn't hard if you can "measure" current consumption (or, resistance, etc. -- duality). And, you don't have to *know* what the nominal coil's characteristics are. Just that they are in a certain range. You then *learn* what each condition "looks like" (to your electronics/software). (you don't even care if your "measurement units" correspond to any of the SI units!)

So, if you replace a solenoid (or valve -- and fail to "rescue" the old solenoid from the old valve) with an identical/similar one, the system sees little or no change. As long as the change isn't enough to make the bare solenoid look like some other detectable condition, all is well.

The first time someone presses the button, the results that the controller sees may be slightly different than previous -- due to the different solenoid. So, you now learn that "new normal".

If you make a significant change to a solenoid (e.g., a valve from a different manufacturer; replacing a 3/4" valve with a

1" valve; moving the control signal to another "circuit", etc.) then you need to *tell* the system to notice the changes. Otherwise, risk it misinterpretting what it sees.

In reality, you would publish a "how to replace a solenoid/valve" guide. It would enumerate the steps to perform -- one of which would be to tell the controller "relearn" (relearn *everything*, not just a specific valve -- that would be requiring more information from the user than the system would need. It can figure out which solenoids have been replaced -- *if* they are "different enough").

This capability also lets you notice more failure conditions. And, adjust how you report those as well as how you continue to operate while they persist.

When was the last time you heard of someone replacing their $39 irrigation controller because it "broke"? Or, $139 controller? So, you're advocating a *feature* whereby YOUR controller can be readily replaced? :>

Repeat that with: "You still have a failure mode: the drive transistor; the field wire connector; the forward-going opto; the voltage/current sensor; the PSU; etc." :> The goal isn't to make things that *can't* fail but, rather, that are *resistant* to casual failures. And, are able to report as many conditions as possible that affect the performance of the device in question.

We had a lightning strike in the back yard at a place I lived many years ago. *Toasted* the "electronic" telephone and "magnetized" the TV. But, nothing (aside from the phone) in the house "broke".

Because that sort of device is more fragile than some discretes, etc. And, you don't *need* that, there. OTOH, you *do* need the hammer drivers over there!

Why expose it if you don't have to? Protect things that are less flimsy and that *must* exist on that exposed side. Even if you can price a product so taht you can afford to replace a fair number of them "under warranty", you don't leave your customers with a good feeling about your product if they have to be INCONVENIENCED to replace it!

Ah, silly boy. :> Here's just a *short* bulleted list.

As you suggest, I should *omit* putting all this in context. So, try hard to forget EVERYTHING about that which has been discussed in this thread. Ask yourself *honestly* how many items for which you *crave* justification (it's a spec, I shouldn't have to justify anything, right? :> ) And, how willing you would be to even *think* about a problem presented in such a way?

- wired connection(s)

- drive a load of < ~20VA, < 36V, < 1A

- detect an input signal presented via "volt free" contacts

- both simultaneously

- tolerate deployment in temps of -40F - 140F, RH 0-100% (though the "sense" and "drive" end can exist in RH 0-80, 0-100F)

- not "break" if subjected to conditions beyond these

- operate as a two wire circuit

- operate alongside other (31?), similar circuits with a "common"

- detect a missing load

- detect a shorted load

- detect a short to any "alongside" circuit

- detect an open in any "alongside" circuit

- detect inputs as short as 0.2 sec (i.e., < 5Hz)

- detect indefinite inputs (i.e., > DC)

- survive "nearby" lightning strikes

- "minimize" RFI

- "immune" to RFI/EMI

- 20 yr product life

- low cost (e.g., $2-3 per pin)

- minimize attack surface presented to a potential adversary

- use components and technologies available to tinkerers (cost, low qty)

- use components and technologies available to vendors (not "by hand")

- use components that will be available for product lifetime (or equiv)

- electrically efficient (e.g., 80-90+%)

Of course, you can improve on these -- they are just minimums) If written as a *real* spec, this would occupy many pages further clarifying each issue (to answer the questions that the reader would invariably have and to put each requirement into context -- so he understood *why* each was necessary)

I'm looking for the *right* solution -- for *today*. Someone can revisit this in the future when MCUs with 100V pin drivers are available. Or, when mixed mode customs are available at the corner grocery store.

"Right" doesn't mean "expedient". I've already *got* something that works -- it just doesn't deal with everything I want to do (as well as the other applications to which I would like to apply it)

E.g., I use speech as a primary modality for interacting with the system. I'm not going to waste my time trying to design the best speech synthesizer. I don't have expertise, there. So, I'll make a box into which that component fits. And, put a nominal implementation in place that works -- the *right* solution for today. Someone can replace this, later, with better technology (perhaps even proprietary technology -- in the case of a vendor opting to commercialize it!)

Because you figure you can revisit it, later. I don't know how old you are or what your opinions of your "future life" include.

*I* don't want to revisit things, anymore. I want to make my *best* stab at these things (there are a *lot* of them on my list) and move on. Omitting something that is fairly obvious is just plain embarassing...

I have *21* designs that I need to complete. I would much prefer leveraging work done on one to eliminate some *other*. And, to increase the quantity of individual designs that I will have to fabricate. I'd love to prune this number down to 4-6. But, will be happy if I can hit 6-8. By the time I'm done, I figure I will have dropped ~10K of recurring dollars into this. It's unlikely I'm going to save another $100 beating it with a stick!

[If someone wants to commercialize any of these, they can always elide the components that are not required for a particular *instance* of a design -- instead of relying on differential stuffing as I will]

I want to move past "building infrastructure" to developing better algorithms to *use* that infrastructure. Where, by far, the majority of the effort and challenge will lie! It might be fun to *build* a race car; but FAR MORE exciting to actually RACE it! :>

I've already quantified those "issues". As I said, I don't plan to revisit this. I want to come up with a design that I can produce "a few of", publish and then move onto other aspects of the project. If someone else figures out how to use some technique or device that comes on the market next year to do this better, then *he* can undertake that task -- with my blessing! :>

Our clothes dryer requires the power button to be depressed for a full second. The washer (same manufacturer -- "sister" product) responds instantaneously. It annoys the hell out of *both* of us!

Why should we have to hold the button IN for so long? It's already recessed so it's not like someone is going to bump into it! And, if such a time is required, then why doesn't the same argument apply to the *other* product sitting beside it?? Same manufacturer. Possibly same developers, code base, etc.

You're also thinking only about it "as a button" (because I only described a "button" application). I can use the same hardware interface to talk to the anemometer and/or rain sensor on the roof. Both emit very *brief* pulses. Should I design, layout and fabricate *another* circuit that is largely similar -- but with different constraints?

{Again, I didn't mention this in my post as it just would complicate the discussion. It is, however, reflected in the bulleted list I presented above -- as a simple, unqualified "requirement")

If you have to drop the solenoid to examine the button, then you would want to keep the polling interval relatively long -- so the water isn't "pulsing" through the pipes (which can become audible).

[Having been involved with gas pumps in the past... :> ]

This is often a consequence of a slow polling loop -- the button is just not *examined* very frequently. Some implementations treat the "pump" (what the user interacts with) as a "terminal" of sorts. The switch closure is *reported* to a control algorithm elsewhere. Which, in turn, responds with commands to turn on lamps, engage the pump, etc.

And, some switch debounce algorithms are sloppy -- they report the switch only *after* it has been "seen" for some number of observations (instead of reporting it on the *first* observation and just absorbing any bounce thereafter). If this happens before the event is reported to the "controller", then the response is even more slugish!

[I've got a paper I wrote on hardware and software debouncing techniques here, somewhere]

I was being facetious. But, in fact, it doesn't save much. Recall, you have to be able to drive multiple solenoids at the same time. You don't want a failure in one to cause the others to be unusable. So, you want to treat each output/input as a separate circuit. With its own current limiter, isolated *control*, etc.

Once you put a current limiter/source in the equation, you've already got a handle on the "sense resistor" -- *in* the current limiter!

As I've said, give me credit for having thought about these things *before* posting my question!