I am an energy auditor in the US and use emonPi on a nearly weekly basis for monitoring client’s homes. I’ve also installed several systems for clients who have rentals with one meter and need to bill renters separately. In spite of the steep learning curve and occasional glitches, I absolutely love these systems.
Specifically, I’m looking for a way to strap a hall effect sensor to a motor and be able to record RPM at a specific interval (say every 5 seconds) to EmonCMS on the EmonPi. I can do this via hardwired cabling, or preferably, wirelessly.
Having this data is essential for me to know how often a motor turns on and what speed it spins, particularly useful when I need to monitor pumps that have variable speeds and/or when I am unable to place a CT around the hot leg of the circuit. Also, having the RPM data recorded can then let me overlay that with temperature data and assess efficiency. At its most simple use, I can know when a motor turned on/off. kWh can then be calculated via nameplate data.
I am not an electronics or programming geek! So I’m looking for detailed information as to how to go about this project. If I get the Hall Effect breakout board kit from the shop.OpenEnergyMonitor.com site (https://shop.openenergymonitor.com/acs7-hall-effect-breakout-board-kit/), how would I interface that hardware with EmonCMS and be able to graph that data from my EmonPi with EmonCMS? Or am I simply looking at the wrong product?
Upon further research, I’m not finding any sort of product that will do what I’m needing; to report RPM of a motor from outside the casing, which I find odd. But I do understand that most motors have multiple windings around rotor core. Therefore it seems that by simply detecting when any of the outer windings magnetizes, that should easily be detected by a hall effect sensor and we can then assume that one rotation has occurred, right?
Most of the monitoring of motors I need to do is with water circulators, like this Taco model, where the motor is a removable/replaceable cartridge. However, the outer windings are the same as most motors, so I should be able to put a hall effect sensor anywhere around the casing and get signal: https://www.tacocomfort.com/product/00-series-cartridge-circulators/
Am I way off base here in thinking that a sensor can simply be placed anywhere around the casing and simply sense any time the magnetic field is activated?
In short, yes to the first, but I don’t find the second at all odd. What you’ll pick up outside is the magnetic field in the stator. Generally speaking, the presence of a field will mean the motor is energised. It will tell you the frequency of the supply that energises the field. That will indirectly give you the speed if you have a variable speed synchronous motor that’s inverter-driven, but the likelihood is you won’t have that. And if not, it just tells you the stator is energised. The designer isn’t doing his job properly if there’s a big magnetic field outside the motor, because it’s going to waste. He wants to keep the field inside because that’s where it can do useful work. You really need access to the rotor, the shaft or even, in the case of a pump - the impeller if you need to know the shaft speed.
To know the shaft speed, I’d be looking at either a proximity or optical sensor mounted close to the shaft. In the first case, you’d need something like a key that you could sense going past, for an optical (I include IR) you’d need a reflective tape of a blob of paint.
We all know the sound of the motor indicates the speed, but analysing that signature would be an interesting problem - probably quite doable with a Raspberry Pi and some amplification, but unless you can find something, it would need a fair amount of development work.
Oh, and that Hall-effect sensor kit - that’s a means of detecting a.c. or d.c. current and providing isolation. The sensor isn’t good at detecting external fields - you’d need to consult the data sheets for the particulars.
I have one suggestion that might not be as flippant as it sounds - get a local university interested as it could make a good undergraduate project.
Robert, thank you very much for your response! It was very thorough and much appreciated. I love your idea about getting a local university interested. Seems like a very needed tool for many industries. I have suggested my nephew (a wiz kid) create this device. Maybe he will come up with something. Or maybe this is the perfect project where you can make your millions
This is a big disappointment in regards to my needs. Bummer! Perhaps I’ll just need to cut and remove some of the insulation around standard three-conductor wires and put a CT around the hot wire (when it’s hard wired). That sort of defeats a tenet of my industry though (do no harm). This doesn’t satisfy my need to monitor RPM though.
You might well be able to detect the motor is energised with a Hall effect sensor, but not that one, is what I was trying to convey. But then, there’s no standard interface to our gear - something else that needs development effort.
Me? I’m retired, well past those sorts of ambitions. I’m now passing on over half a century of experience in electrical engineering.
These things seem to use a split phase AC motor. So the speed will be roughly constant for a given load, and a little less than the synchronous speed of 3600RPM. The data sheet on one says 3250RPM
It looks as if it doesn’t meet your specification “Ways to monitor motor RPM” - according to its web page, it only senses on/off hence it can deduce total run time, but not speed.
It meets my needs however, simply telling me when the motor turns on/off.
Would sure love to see this sort of thing added to the openenergymonitor products in the future.
Is there a feature list request area anywhere on this website?
I’m still looking for a good solution…
It seems that the link I provided before is now broken, so here is a more recent URL:
In the user manual, it says it can log to their HOBO U-Shuttle (U-DT-1) to send data to, and that device has RS-232 output. I’m curious if that might be able to port into the Raspberry Pi board and be recorded to the database?
Almost two years later and I’m coming back around to this subject, after having taken an electronics course to get me up to speed with at least the basic nomenclature of this industry
Before I go and put effort into using this solution (Tachometer / RPM Measure – ForbiddenBit) would anyone caution me against it, in light of knowing what I’m trying to accomplish, getting RPM data from a motor, where I’m able to place a magnet on a pulley?
What did you say your motor speed was? And have you looked at the code? They are measuring the time for 1 revolution of the shaft using the millis( ) function, which nominally returns the time in milliseconds. So at 1500 rpm, I’ll count 25 ms - with a resolution of 4%. At 3000 rpm, I’ll count 12 or maybe 13 pulses, Your motor will run at 1800 or 3600 rpm (approx, less a bit of slip), so your resolution will be even worse. If all you need to know is you have a stream of pulses faster than (say) 10 per second - any slower and you call it ‘stopped’, then this should be workable. Note you can do the same with a reflective patch and an optical sensor.
If you want to go down this route and you really want the actual speed, you probably be much better to count the pulses over a longish time, the longer the better but depending on the accuracy you need.
If you’re going to use your own database, the HOBO data logger seems to be a duplication. The new emonTx V4 has an analogue input pin available (but no dedicated software as yet to read it), so if you had something - say a Hall effect sensor sensitive enough to pick up the magnetic field on the outside of the motor, which is presumably what the internal sensor of the Hobo device does, then with your own software you could arrange the emonTx to send whatever data you wanted to the database.
Yes, I think averaging makes perfect sense. Now that I’m a little bit more educated, I think I’ll try my luck at using a hall effect sensor and writing some code to capture that with the TX v4.
Thank you again, Robert!
You’ll need to scale the output so that it is always within the input range of the ADC (if you’re using an analogue output - likely as you don’t know what to expect) which is 0 - 1.024 V.
