Economy seven metering

Getting Started
1

Looking at getting an eon setup, but I have an economy seven meter - which has two pulse outputs.
The Economy 7 meter has a bit of a wonky clock (not nearly enough that that the energy company cares), so the different pulse outputs are the things that tell me when I am on cheap rate power.

Looks like the emonpi only supports one pulse sensor - is that a hardware limitation on the Arduino side, or on the Pi side?

Whilst I am fairly happy to pay for the overall system (case and all) to help cover dev costs paying another 80 quid for a second pulse sensor seems a little OTT - so is there another way?
I presume an arduino nano every would have sufficient counting capacity, it’s just getting that data back to the Pi that’s the question…

As far as I am aware there is never a case when the two pulses would be active at the same time - so I might be able to combine them and have something else spot which one is firing to see which power rate I am getting?

Cheers,

2

Emon?

It’s a limitation of the Atmel '328P processor, it has two interrupt inputs, and one is committed to the radio.

However, it is possible to have a pulse input (or two) on a Raspberry Pi, the details are here:
Directly connecting to Optical Pulse Counter with RPi? - #2 by pb66 but it doesn’t appear to be physically possible to add those connections to an emonPi without modifying the case.

So I think the question becomes: do you need the analogue current and voltage inputs of the emonPi as well as the pulse inputs? You will if you have your own generation, because pulse outputs tend not to work (or worse, work wrongly) when exporting. But as you don’t mention that, you might get all the information you need from the pulses.

3

Yes, eMon… Stupid drunken elf…

Adding them to the pi directly is well within my current capability… The desire for the current clamps was to measure the EV charger directly as much as anything else.

I might start off with just the two pulse sensors then, since I have a Pi on my desk already.
Once I have this done here I’ll package up a much bigger system for my parents house, they have PV generation, and a power wall…

Thanks for the link.

4

Thanks Robert…

Two pulse counters… and I now have evidence that my meter is borked.
This is going to be fun conversation with my supplier.

5

It won’t be the first time that OEM has provided evidence to challenge a supplier - that time, it ended in our user’s favour. I hope the evidence is strong enough to convince them.

6

Getting somewhere with the supplier, but putting together an evidence package for them and I’m now rather confused.

I still think my meter is broken, it doesn’t pulse the rate2 led overnight, continuing to pulse rate1, but rate2 does get the occasional pulse throughout the day.

Where I am concerned that I have something amiss - I took a short term look at daytime base load:
The monitoring through emon indicates ~ 1.3kW
Measurements using a clamp multimeter (3.1A, 240V) indicate ~750W (max resistive load)

However based on short (30 seconds or so) visual observations the daytime base load is about 1 pulse every 5-6 seconds (~700 pulses/hour → 700W) which looks about right. Adding the 3kW kettle I get to ~1pps (3.6kW) which again looks about right.

My input is set up:
1 - Log to feed
2 - Wh Accululator
3 - x 0.001
4 - kWh to Power

And that is fed from a pulse counter script which is mostly the same as that linked in the thread above (though I also fire off another packet on each pulse - that isn’t received anywhere, but it’s a useful debugging tool)…
That script is picking up pulses most of the time, but it seems to miss a pulse every so often, the gaps end up at 5,5,5,6,5,12,5,6,5,6 with a basic packet capture being used to spot the detection events.

The data on 50012 shows:

  • Timestamp (to the hundredth of a second
  • Node ID (18)
  • Counter 1
  • Counter 2

And for every UDP packet I see the counter is incremented by two, not one - that would put my actual power at half what is being shown by emon…

One difference to the above script… I have the pulse_id[channel]+ outside the if status.
BUT - I only see one packet, and the UDP packet I send for debugging is sent at the same level as the counter increment, and I have the event detect for the callback to be GPIO.RISING, not GPIO.BOTH.

Possibly ought to pop over to that thread, but I’m starting to doubt the script - I think I might be double counting yet missing occasional pulses… neither of which are good.
Given that we’ve got callbacks in play - why are we tight looping the process pulse code.