The star, of course, being the almost universally accepted sign for “entrance” in braille++. Or “exit” in certain dialects, conveniently.

I have done a similar thing in the past, but to flash firmware onto any device with a certain USB descriptor that gets plugged in. It was a mess of USB hubs and cables, but it worked.

What I did was write a udev rule that checks for the vendor and product id of a newly plugged in device and calls a script when there’s a match. The script then performs the flashing and logs the output.

In your case:

1. dd the source USB to a file (make sure the partition you’re dding is smalled than any target drive
2. Udev rule according to your needs (all the same product or different drives?)
3. Script that dds the file you created earlier back to the newly plugged in drive.

Edit. Did this on a rpi3

the password game irl

Good job troubleshooting.

5V or 4.68V input isn’t meaningful. The sensor has some input range and 4.68V most definitely falls into that. Could be a design choice that has no real implications.

On the other hand, if the device normally supplies 5V, just yours doesn’t, then that’s further evidence you have a faulty controller.

My money is on faulty controller at this point, but I think you’ll need to find someone with electronics chops if you want to avoid just buying parts until it works again.

For what it’s worth, I didn’t mean take the sensor out of the wall, but just electrically unplug it from the controller to see what it does on its own when you turn on the water.

A frequency counter won’t really help you here, I think. You already know to expect ~VCC/2 when water is running, and either VCC or 0V if it isn’t. The speed of the square wave isn’t very relevant.

Oh and be careful if you do end up trying it.

There’s no safety risk in what I described, but reversing the power supply might very well fry the device.

With better tools, it would be easier to troubleshoot more precisely. An oscilloscope would help you understand what’s going on, for example.

From what you describe, I’m actually starting to suspect the other end (the controller?) to be the problem.

One idea you could try before buying anything is to disconnect the sensor, supply it with 5V and ground (double check with data sheet!) and see what’s happening on the output when there is flow. If you don’t measure anything, as I would expect since the pin alternates between a floating state and ground, you then add a 10k or 50k ohms pullup resistor between 5v and output and measure again, and should get the levels you expected to see in the first place.

Don’t know if you’re comfortable doing this, but maybe you can find somebody to help you out?

Read your post again, and your readings are of course not in line with what I laid out. Are you measuring the sensor in-system?

If you are, the sensor might indeed be faulty. If you aren’t, you probably need a pullup resistor on the output pin.

These flow sensors are usually hall effect sensors, with two or four magnets attached to a rotor with a little water wheel. When water flows, the magnets turn and create something like a PWM signal at the output (actually it’s high level when magnet is there and low level when magnet is not there or vice versa). Measuring the pin with a slow multimeter, this would indeed give you approximately half the supply voltage when water is flowing, depending on a few other factors. So- readings sound sensible to me. To note that if the rotor stops with a magnet close to the hall effect sensor, you will read 5V (or VCC) at the output, but always VCC/2 when flowing.

Most of these sensors employ an open collector output stage, but that doesn’t need to bother you with the readings you’re getting, I think.

According to Varoufakis, Europe missed the bus on cloud capital (=big cloud platforms like amazon, meta, twitter,…) and the race is currently playing out between US and China.

Don’t forget a flyback diode at the inductive load or your transistor will bacon at midnight.

Highly recommend cupping your favourite coffee with different kinds of water (e.g. tap, mineral, DIY water see below). It’s pretty eye opening.

Here’s how to make your own, if you’re motivated to try: https://www.baristahustle.com/diy-water-recipes-the-world-in-two-bottles/

Haven’t seen your laptop, but if it’s anything like mine it’s a very lousy boat.

Read your reply now, and not sure about the requirements you have: must not leave the local devices or must not use the WiFi?

If it’s the latter, a 4g USB modem with a cheap iot data plan easily frees you of that.

I second Zigbee.

• There’s plenty of devices available.
• Battery life is amazing.
• zigbee2mqtt is an easy way to bring those messages into your regular IP network; they have a huge list of supported devices.
• Once translated to MQTT, you can hook any automation onto it you want: a python script, home assistant, or my recommendation in this case, NodeRED. NodeRED has a module for zigbee2mqtt that is very well integrated to just know all devices registered on your zigbee network and stringing flows together is actually fun once you get the hang of it. Plus, there is no upper bound to flow complexity.
• Gateway device can be a sonoff zigbee USB coordinator and the whole thing can comfortably run on a rpi3.

Hot sauces in YOUR area

Love it. Thanks for bringing it up.

Oh my bad. I’m no battery expert by a long shot; just meant to contribute a good source of information. But you’re way ahead of me anyway. Carry on! 😊

Take a look at Battery University, I think it’s a great resource.

On the topic of lithium polymer charging, it has this to say:

Charge and discharge characteristics of Li-polymer are identical to other Li-ion systems and do not require a dedicated charger. Safety issues are also similar in that protection circuits are needed. Gas buildup during charge can cause some prismatic and pouch cells to swell, and equipment manufacturers must make allowances for expansion. Li-polymer in a foil package may be less durable than Li-ion in the cylindrical package.