Making a cheap electrical energy meter

Great write-up. So there's no 'rate limit' on the number of records - the more power you draw the more records are created. Might that not get a bit heavy if you logged a big load? like 100 writes to boil a kettle?

All working now.  Well done.

 

I wish I understood one word of that, but well done Nick 👍

1 hour ago, Radian said:

100 writes to boil a kettle

I tried it in my kettle and it was fine. My CurrentCosts write up to 10 times a minute, large files are not really an issue these days.

There could be a secondary file that counts up from the first file every hour, then shows that.

It is those kind of details that others are better at.

It would be good if someone replicated my design and tested it, very easy to convince oneself that it is perfect otherwise.

1 hour ago, joe90 said:

wish I understood one word of that

Tis easy, even you can wire it up.

Wtf? 

 

You sketch it we'll CAD it / print it. I'm a 🐒 see 🐒 do kinda guy. 

54 minutes ago, SteamyTea said:

large files are not really an issue these days

No but the Rpi is writing to SD card if you're not using a RAM disk/network storage device/USB stick or HD. Most SD cards aren't really up to the repetitive write task but then again, they're dirt cheap.

1 hour ago, SteamyTea said:

Tis easy, even you can wire it up.

I could wire it up (with instructions) but does not mean I understand it 👀

Edited July 9, 2022 by joe90

16 minutes ago, Radian said:

Most SD cards aren't really up to the repetitive write task but then again, they're dirt cheap.

Got some that have lasted 10 years of logging.

And can easily change the file location to copy to a memory stick at the same time.

11 hours ago, Onoff said:

 

You sketch it we'll CAD it / print it

Thanks. Shall see what I can knock up.

11 hours ago, SteamyTea said:

Got some that have lasted 10 years of logging

Probably a genuine card then. The current market is peppered with fake SD but USB sticks generally fare better.

 

Thinking about how someone with no soldering skills could assemble this, some female to female 0.1" patch leads could be used to connect the photodetector to the 0.1" header on the Rpi so long as it was purchased with the ready assembled header pins. And to avoid the need for the USB to TTL serial adapter, with WiFi on the Pi, you can SSH into the command line by adding a couple of files to the SD card after writing the Operating System to it: Step by step Instructions here

10 minutes ago, Radian said:

Step by step Instructions here

I may give that a go as I have never managed to get it to SSH in with the 'create an empty file' method.

 

10 minutes ago, Radian said:

no soldering skills

Can you get small crimps to join very small wires.  Though that is more things to buy.

 

I am going to look around the shops and see if I can find anything that can be easily modified to make the LED holder.

I used a bit of rubber pipe and some epoxy. after super gluing the LED into place.

Picture to follow in a few minutes.

 

Edited July 10, 2022 by SteamyTea

44 minutes ago, SteamyTea said:

Can you get small crimps to join very small wires.  Though that is more things to buy.

The crimps and plastic shells themselves are inexpensive but the crimping tool you need is expensive. Not worth it if you're only doing this kind of thing on rare occasions. The patch leads are one way around it and You can also get male to female versions to make daisy chains in order to get a bit more length.

 

 

2 minutes ago, Radian said:

The patch leads are one way around it and You can also get male to female versions to make daisy chains in order to get a bit more length.

I suspect, anyone that fancies making one, will be a bit of a DIYer.

 

So you had any thoughts about adding a cheap display, but not one of those tacky LED matrix ones. Something like this.

https://www.ebay.co.uk/itm/165511794894

 

And the code to display useful stuff, i.e power, energy, time, price, temperatures.

It is that side of it that I have never done before and find frustrating.

10 minutes ago, SteamyTea said:

And the code to display useful stuff, i.e power, energy, time, price, temperatures.

It is that side of it that I have never done before and find frustrating.

OK, so there's a thousand different ways of going about this. But I recommend just one: Node Red.

 

Node Red can easily be installed in seconds and has a fully graphical interface that presents itself in any web browser. You can create dashboards and have it all show up on the sort of display you've found there, as a full screen. But as it runs on a webserver on the Pi you can also access it from any other PC, tablet or smartphone on your LAN. You can do anything with GPIOs and timestamps etc. like you've done in Python.

 

The other thing I'd highly recommend is to install a MQTT broker This gives you simple messaging between things and is fully integrated with Node Red, Python etc. Say, for example, you had other energy meters connected to Pi zeros. You could publish MQTT messages containing the power info and collect and display them all in Node Red. You could even communicate between the Python script your written and Node Red for display.

 

Thus you have one central server Pi running Node red and the MQTT broker (and have it also taking some measurements) and have as many satellite devices as you like. MQTT is a great way to communicate with ESP8266 modules as well, so you could slim down your measuring devices for temperature, power etc. with a £3 device!

19 minutes ago, Radian said:

ESP8266 modules as well, so you could slim down your measuring devices for temperature, power etc. with a £3 device!

 Could they be made to run reliably for a couple of years on a couple of D batteries like the CurrentCost does. My old clamp ones lasted 5 years transmitting away. The Optisence uses just one D cell and lasts at least 2 years, as long as I don't put my metal frame collapsible chair in the way. It is better that a tinfoil helmet at blocking a signal, and you can sit in it.

Edited July 10, 2022 by SteamyTea

1 hour ago, SteamyTea said:

 Could they be made to run reliably for a couple of years on a couple of D batteries like the CurrentCost does

Possibly. CurrentCost sends a radio packet every 10 seconds which is not possible over WiFi, on batteries. But WiFi can be brought up, say every 10 minutes, and the last 10 minutes of data could be transmitted including a temperature reading. The ESP can also sleep between pulses so minimising power consumption. Alternatively ESP32 has more in the way of power saving including Bluetooth LE. At the end of the day they're equally easy to work with. Anything you can think of doing has very likely been done and put on Github for inclusion in your code.

Great work!  Could do with 2 of them to the same cpu - we have a main meter and a PV meter.  I think we might need another meter again really, in series with the main one but backwards, to measure power flow both ways.  Then we have V2G....Why is it so complicated?!

 

Some elec meters have isolated outputs, as well as an led, that pulse.  This one that I've used does, pulsing at 1 pulse per Wh - prob worth getting that sort if you're buying one.

I used a 10k pullup resistor to 3.3V, connected -ve to cpu 0V, and fed the pulse signal into a cpu input:

 

https://www.amazon.co.uk/Electric-Electricity-Backlight-Certified-Calibrated/dp/B096YBRRYK/ref=sr_1_7?crid=3VCCVWXIONQEG&keywords=electricity+meter+din+pulse&qid=1657462762&sprefix=electricity+meter+din+puls%2Caps%2C106&sr=8-7

 

11 minutes ago, RobLe said:

Could do with 2 of them to the same cpu

Should not be a problem as the RPi has loads of GPIO pins, 

Just add

 

button1 = Button(23)

 

and

 

            button1.when_pressed

            button1.when_released = sort_time1

 

Also add

 

 

def sort_time1():

            dt = datetime.datetime.utcnow()

            runday = dt.day

            dt.day == runday

            ts = time.time()

            UTC = datetime.datetime.utcfromtimestamp(ts)

            logfile = '/home/pi/monitoring/data/PV-%s-%s-%s.csv' % (dt.day, dt.month, dt.year)

            tfile = open(logfile, "a")

            tfile.write("%s"%UTC + '\n')

            tfile.close

 

Though there is probably a more elegant way to do the above.

Edited July 10, 2022 by SteamyTea

This is a great little device, and I will build one but using a WEMOS D1 Mini device,  however I guess there must be a rate limit somewhere in this version and if you add in additional meters it will arrive much sooner, if its coming at all. Several concepts could, but don't think they will, indicate that although a terribly simple and reliable idea it may fail in exremis. I am not saying any of this is a problem for this system as implemented but it may be if you extend it without getting to grips with the nature of real time systems.

 

Firstly the RPi OS is not really a real time system so although the quickness of the hand deceives the eye it can only do so much in a given time and probably cannot do things at a given time! You can programme it to give priority to aspects of the code but when everything is competing this become a real art - games programmers will tell you this is their biggest headache - my fraction of the CPU is this and spread over....  Real Time OS's do guarantee timings, it is the definition of a real time system that time critical events are handled. This all means that although the RPi will probably do this reliably it may miss a pulse here and there while it is busy housekeeping - a headless system will take less time doing this naturally and this system is not being asked to operate at very high speeds (See below)

 

So, secondly, how fast does it need reliably to be. Most people have a 100A connection so if one was running that flat out (Approx 17Kw {240 x .707rms x 100A} of resistive stuff running) those pulses are going to be coming reasonably quickly, perhaps 5 pulses per second, and you might worry that your Rpi, usually running with Raspberry Pi OS, is busy doing some housekeeping while a pulse comes and goes without being spotted. This is assuming that the GPIO library does not implement any interrupt based process - if so all this is tosh - someone will tell me (See link below)! The sampling is not really a problem of the frequency of the pulses but rather their length, how long are the pulses anyway? If I can find a photodiode around here I will have a look at my meter and find out! Do they change length depending upon frequency one also wonders? For now I am going to work on 30ms pulses as a guestimate. So you need to guarantee your sample rate at least meets the Nyquist criteria (I was always taught that simplistically you need to sample at least twice the highest expected frequency / period to be reasonably sure you spot everything). So this means you need to sample at least every 15ms to be sure of catching a pulse of light. Rpi can sample at MHz so sounds like no problem but with an non RTS OS you might find that the writing of that CSV file actually takes a period of a of 15ms and you may have missed your pulse.

 

The good news is that even if the libraries don't implement the interrupt driven GPIO functions you can still do it and there is a very good explanation of all this here: https://roboticsbackend.com/raspberry-pi-gpio-interrupts-tutorial/ 

 

This world we are living is getting increasingly demanding of the union between mechanical, electronic and software systems. So if you can get the electronics to do some of the work the RPi does not have to be so real time. I think the Rpi has a PIO that can be set up as a pulse counter which you can just read anytime, count the difference - measure the time between and it recycles at the top but I may be wrong on that one. 

 

 

@MikeSharp01

 

As a test, I have set up an LED to flash for 0.01s then wait for 0.03s.

Left it logging, expecting a large file when I get back.

 

I think that will work out at 25 Wh per second.

90kW draw.

Few houses will go above 20 kW.

Dropping the odd Wh is not really a problem, and I think my CurrentCost does this anyway.

 

I did initially try to append to a list, then when the list got to length 10, timestamp it.

Was not very successful.

 

Be interesting if it works in the WEMOS D Mini.  I have some ESP 8266s, but not that good at micropython, not that good at python.

I did wonder about the file write time, if I deleted the tfile.close line, what are the consequences?

I actually don't think you have a problem. I need to find out if the python libraries implement the interrupt driven features but either way as you have the pi doing only a couple of things it will be fine. The problems come down the track if you get the pi doing more jobs and loose track of what is happening where and when in the system.

1 minute ago, MikeSharp01 said:

I actually don't think you have a problem

It was still logging when I got home a few minutes ago. File was almost 7 meg.

Just left it going and shall see what is happening in the morning.

I should be able to calculate how many pulses have been missed. Would be happy if it was less than 1%.

Ok so I have been working up a ESP8266 based equivalent of the Steamy counter. Although it broadly works I am having a real struggle getting the RTC to work reliably. Technically I don't need it as the receiver end could do all that, I could use the millis() functions to create quite good timing and I need that anyway to measure the interval and get a rough idea of instantaneous KWh. Could do this better with the 32KHz pulse train from the RTC if it was enabled on the boards I have - same as Steamy's. I have tried a slew of libraries but I still regularly get a bus conflict error on all three of my RTC chips and they all behave perfectly on an Arduino nano. As the RTC is currently managing the sensor timings - I put a DHT22 on the board as well for fun, I guess I need to fish out my logic analyser and look at the timing on the I2C to see whats going on although the scope would show me if the edges are fuzzy / noisy. I decided to echo the flashing LED on my sensor and made a bracket I can just tighten on the meter so nothing is actually fixed to it. So work still in progress I guess. 

20 minutes ago, MikeSharp01 said:

Ok so I have been working up a ESP8266 based equivalent of the Steamy counter

Going to be interesting to see your code. Never thought of adding an RTC to one.

Have fitted a DHT22 to them before.