Solar PV generation, pulse counter & virtual feeds

Tags: #<Tag:0x00007f16af2079a8> #<Tag:0x00007f16af207818>

(Ben Price) #1


Relatively new user of the EmonPi and EmonCMS here - I think this is the right subforum but please feel free to point me elsewhere if I’ve judged wrong. I have just had SolarPV with a Solar Edge inverter fitted in my house. The installers have done such a neat job that there is no live cable for me to put a CT clamp on coming out of the inverter! It is all bundled into a single armoured cable, so I can’t monitor the PV production that way.

What I do have is a CT clamp on the grid feed that dutifully shows negative values when we are exporting and positive values when importing from the grid. There is also the generation meter from the PV units which has a pulse LED with 1000 pulses per kWh.

I have two questions, both of which I think ought to be possible but I’m not entirely certain:

  1. Is there a way using the feed processing machinery to separate the positive and negative CT clamp readings into separate Import and Export kWh counters?

  2. If I put a pulse counter on the generation meter can I use that to provide information on the power coming from the panels reliably?

And a final third question that I’m really not sure of: if 1 & 2 are possible is there then a way to derive from that data the overall useage of the house as a feed?

Many thanks,

(Paul) #2
  1. Yes, no problem, there are “allow pos” and “allow neg” processes for that purpose.

  2. Yes(ish), you can reliably record the energy generated and from that you can sort of calculate the power, but it will not be any where as good as the CT derived power data.

  3. Grid + Solar = Use, so from your grid ct a positive import of 1kW + 2kW of solar = 3kW of use, whereas a negative export of -1kW + 2kW = 1kW of use.

However, following on from point 2. above, if you are calculating from a grid power CT and a solar energy pulse, you might get unusual results sometimes.

Can you not access the solar live feed at the generation meter or at the dist’ board? It is possible to do what you ask, but if there is any way of getting another CT in there, it would be better for the realtime power data. pulse counting is generally more accurate for recording energy used, not so hot for a realtime picture.

(Ben Price) #3

Hi Paul,

Nope - no way to get a CT in without undoing the whole wiring and I’m not qualified for that.

However the SolarEdge inverter is pretty smart as these things go and exposes a Modbus TCP server from which I can pull data directly. I don’t know if you can get Modbus direct into Emon CMS but I have a good deal of experience in my day job using tools like NodeRed to access Modbus TCP data so I’m going to pursue that angle.

Thanks for the information, I shall keep this updated with how I get on!

(Bill Thomson) #4

Hi Ben,

This thread may have some helpful info regarding Modbus and emonCMS:

A forum search for modbus turns up several other threads that may also be of help.

(Paul) #5

If you using an emonPi, the “emonpi” variant of emonhub is installed and as far as I’m aware, it can communicate with modbus TCP devices, including solaredge inverters.

(Peter Galbavy) #6

The problem you may find mixing a CT on the grid supply with API based numbers is timing and calibration. I do not know how often the SolarEdge publishes generation data “but”…

I use both CTs on my grid/solar/evse and also optical pulse sensors on the grid (inbound) and solar meters.

Their usage is very different and trying to compare the two is apples and oranges. That’s even ignoring any calibration issues.

I had my non-grid CTs places in the CU by the installers at the time and it was worth it. Perhaps grab a handy electrician to come help - but make sure you are in place to test the direction of install before they put the casing back on!

(Ben Price) #7

Modbus isn’t really an publish based API in the way that, say, a REST interface is. It’s a polling based industrial protocol designed for near real time use. According to the specs the response time of the Modbus interface is <100ms for a single inverter (although that’s for RS-485 based connections, may be slightly more for TCP use).

So I use the arrival of the raw CT data packet on the MQTT bus as the trigger to fetch and process the inverter data via Modbus TCP it should result (although I haven’t measured it) in the inverter data being logged within 1s of the corresponding CT read on the incoming mains cable. Which, for my purposes, should be good enough. I’m interested in broad trends over time rather than pinpoint accuracy. YMMV of course.

I should also point out that I’m probably not making full use of the emonCMS, I’m effectively only using the emonPi as a very capable data aquisition device. I use an off system Node-Red Implementation which pre-dates my emonPi to do a lot of seperate processing and I log data to a seperate InfluxDB instance with Grafana on top for my dashboarding needs.

(Peter Galbavy) #8

I understand that, but I think my point got muddled. Measuring the “real” current in the wire is, effectively, instantaneous (yes, yes…) but what I am not sure about is how often the inverter publishes generation data. The official API for my Enphase is every 5 minutes regardless of the transport for the data.

(Ben Price) #9

Ah, I see what you mean.

On the SolarEdge inverter it seems to be near real time. At least every reading is different when taken at 10s intervals and the result via Modbus tracks the display on the front of the inverter (to the best of my ability to test) which very clearly varies in real time with production.

(Ben Price) #10

A useful note for anyone looking at this in the future, on the SolarEdge inverter there are two values published via Modbus that you need: I_AC_Power and I_AC_Power_SF. See this doc for the register numbers:

To get the Power you have to take the value in the I_AC_Power register and multiply by 10^I_AC_Power_SF to get the result you want. The values of both vary together so it is best if you pull them as a single 2 register read (for a total of 32 bits) and split that into the two 16 bit int16 integers before peforming the calculation. That way you are guranteed to get the scaling factor that is right for the I_AC_Power number.

If you try and do what I originally did, which is read them seperatley, then they can get out of step and you can end up with some embarassing power of 10 errors like your 5kW of panels reporting they are generating 24kW (when it should have 0.24)!