hi
I have a ApolloGem installed to divert any excess solar to a immersion heater, this appears to working ok. I bought the emonpi to monitor and log power usage and hopefully see how much power was being exported. armed with this info I would have been able to see is a battery system made any financial sense.
After installed the emonpi its showing 2 odd behaviours.
Every time the apollogem starts to diverts power their is a spike in total power usage to the point where extra power is drawn from the grid, where usage is about 3kw, solar generated about 1kw and therefore import from the grid 2kw. This spike is about 1 minute long and occurs about every 5 minutes.
The apollogem shows that its sending ~800w to the heater and 0w import. After this spike the apollogem is still sending about 800w to the heater and emonpi is then reporting that I’m exporting about 800w to the grid.
Im not sure what is going on here but it looks like it is working ok once enough solar generation for the heater hit full power, the apollogem then report the same export amount as emonpi. The emonpi pi total for import is about the same as the meter reading as well as the solar generation total.
Can anyone help.
thanks
Welcome, Nigel, to the OEM forum.
I can’t remember ever seeing Apollo Gem being mentioned here, so there might be little experience to share. I’ve had a quick look at the website, and one point I noticed is “uses a variable power technology starting from 0.1KW [sic]” On that basis, it should start diverting at 100 W export (assuming they mean kW).
Do I understand you correctly: Are you saying that the “spike” condition is when your usage is 3 kW, and the PV contribution is 1 kW, you are importing 2 kW but the Gem turns on and is feeding 800 W to the immersion heater?
If that’s the case, it’s certainly not working as I would expect it to. It should not be feeding power to the immersion heater while you are importing, unless there’s a timed program somewhere in the set-up to maintain a supply of hot water even when there’s no surplus PV available. Could that be happening?
Again, that’s not what I’d expect and not what I’ve read so far seems to say. I would expect it to turn on and start feeding a minimum amount of power to the immersion heater when export hits 100 W, and then it should increase the power to the immersion heater to maintain that level of export as PV production increases, up to the capacity of the immersion heater, at which point the remaining power is exported.
What is your emonPi monitoring? i.e. are the c.t’s where you think they are, and measuring what you intend? The last paragraph does seem to say that, but it’s worth making sure.
hi
Thanks for looking at this, below might be clearer.
when power consumption in the house is 200w, sun comes out solar generation goes upto 1kw, the apollogem then diverts 800w to the heater and reports no export,. This is what is displayed on the screen for the apollogem. The emonpi displays a that 3kw is being used and 2kw is coming from the grid,after about 1 minute this spike drops off back to the background load and exporting 800w. The apollogem is still feeding 800w to the heater. So from 1kw solar, 200w is used in the house, 800w to the heater and 800w being exported.
But when there is more sun for example 3.5kw of solar the apollogem diverts 3kw to the heater and reports 300w export. the emonpi shows the same thing with 3.2kw used 300w export.
The ct for the apollogem is on the tail too the meter and the emonpi the other side of the meter before the consumer unit. I have tried swapping the round, placing them on the same section and no change in behaviour. The emonpi ct for the solar is on live to the generation meter. the reading for the solar on the emonpi shows the same within few % of the what the inverter says its outputting.
from my observation when the apollogem is at full power everything works as it should, when its at variable power output, there is a spike 1 minute spike every 5 minutes as shown by the emonpi, between the spike the emonpi shows an export when the apollogem is diverting power.
The are 2 question from this behavior, does the apollogem truly draw power from the grid for a minute before settling down every 5 minutes?
does the switching generate noise interference and the emonpi shows it as this odd behavior? I will need to see if i can get a clamp meter on the immersion heater to check how much power is going to it.
Photos of the CT locations would probably help.
Look at the ‘Inputs’ page - are they what you expect them to be at any point in time.
the solar generation value is correct, the use and import from the grid is correct when the apollogem is not running in variable power output, ie off or fully on. In the image above the wide ~2kw band is the kettle being on, all reads are what is expected at this point as the apollogem is off. pics of ct below
blue ct are for emonpi and the black ct is for the apollogem
another pic, the
again the 2kw band is the kettle. the other spikes is the apollogem. between the spikes the apollogem is still appling power tot the heater (checked with clamp meter, same bouncing numbers)
Meaning that the emonPi is correct and the 1500 W spikes are power going into the immersion heater?
Did you check the Gem manual for
We’ve never heard of “interference” generating that sort of output from an emonTx/emonPi. That’s not to say it’s impossible, we expect upto a couple of hundred watts more-or-less constant noise/pickup from a breadboard lash-up, but I can’t see an obvious mechanism that might give you that much “error” with that periodicity.
So my thinking at the moment is it’s doing what it thinks it ought to do or is programmed to do, but that’s not what you expect and not what you want.
the spike seem to follow the same trend as the solar generation, more generation bigger spike.
this doesn’t explain why power is going into heater and emonpi not registering it.
cyclic spike… harmonics???
will be contacting apollogem later to see if they have any answers.
looking back at my weekly meter reading (import/generation/apollogem) we are imoprting more per day this summer than last summer, with above dont know if this down to change(nothing obvious comes to mind) in use or a problem with the apollogem.
But what are those blue spikes in the screenshot? Isn’t the emonPi registering it, and that is how you first found out that there’s unexplained consumption? The emonPi has two inputs, according to your pictures, one is the PV infeed and the other is on the grid infeed your side of the main meter. Therefore the emonPi sums those two to get the total house consumption. So wherever the power comes from, to go to the immersion heater (or anywhere else for that matter), it will show up on one of the emonPi inputs and appear in the total “use”.
Maybe you’ve done this, and maybe a stupid question - what happens if you isolate the AppolloGem and the immersion heater? Do the spikes cease?
Yes the spikes go away when the heater or apollogem is switched off.
When there is no excess solar there are no spikes
If I set the apollo gem to boost ie full on the total used is correct and if no solar excess then I’m importing if solar excess I’m exporting energy.
When exporting energy with use at 3.2kw (apollogem at full power) the amount displayed as export on the apollogem is a about the same as the emonpi.
Between the spike the apollogem is putting excess energy into the heater (clamp meter/volt meter show bouncing numbers) I’m not able to measure this properly on a cheap meter.
Ah, that seems to indicate that the AppolloGem might be using the “burst fire” technique. (There’s a full explanation of that in “Learn”.) I could see no mention in the data that I saw that told me how it controlled the power, and I wouldn’t have expected a commercial unit to do it that way, on account of the likelihood that it could cause flicker of your lights (assuming you have a light on when it’s diverting!). If it is using burst fire, that means that the emonPi won’t measure accurately while the Gem is diverting. This is because the emonPi only samples the current for 200 ms every 5 s - over time it’s likely to average out correctly, but if it happens to sample each time the power is on, it will read the background consumption plus the full immersion power, and if it samples when it’s off, it will only measure the background consumption. [I’m working on an update that will correct that, but it’s some way off.]
I am currently awaiting a call back from Bob at Apollo Solar eletric.
The spike is proportional to the surplus solar.
Will put a oscilloscope on the heater to see what it looks like
spoken to Bob and he has confirmed that the Apollo gem uses burst fire with zero point switching. If I remember correctly is does this in 250ms cycles( half power would be 125ms on 125ms off).
Would it possible to change the sampling time frame so it captures the ApolloGem?
Umm… Those numbers don’t fit - one UK mains cycle is 20 ms, so if it is on and off in complete cycles, you will get blocks of n × 20 ms ON and m × 20 ms OFF. (and I’d guess that n + m is a constant, and either can be zero).
I’m working on a CM version of the emonPi. It’s nowhere ready for release yet, but if/when it is, that will - as the name suggests - Continuously Monitor and give you the average power over 10 seconds, so the problem will largely go away, unless n + m is larger than 10 s, in which case you’ll still see some ripple.
It is possible to change the sampling time, but I have a well-founded suspicion that the emonPi won’t be able to work properly as a base station if you do. If you want to try that route, it’s quite fiddly as it will involve getting the “emon” software for Github, change it, compile it, transfer it onto the emonPi and from there transfer it into the “emon” front end that does the power measurements. Then you must update selectively or it gets wiped and “restored”.
I will check it again to see if it only switches at full cycles. Are you not able to do half cycles as at half cycle your at zero (this is above my pay grade).
I will have a look at Github route. don’t currently need to use the emonpi as a base station.
Do you require a beta tester for the CM version as this could solve my problem.
I wouldn’t expect it to do half-cycles, as that could lead to a d.c. component - and in any case, half-cycles give 10 ms steps.
Have a look a the PV Diversion pages in ‘Learn’ if you’d like some background information.
It needs changes to emonHub to allow you to configure and calibrate it “on-line”, and Trystan’s working on that. Without those changes, I can manage to calibrate it but I’ve got in a mess several times, it’s all too easy to screw up doing it via SSH & minicom.
And the working version I have at the moment is non-radio, so the emonPi will neither receive data from an emonTx or emonTH, nor transmit anything to an emonGLCD by radio (Ethernet & Wi-Fi are fine).
I’m not looking at using a emonTx or emonTH for now maybe next year, I have the kit version of the emonpi so no emonGLCD.
Is calibrating the emonpi via SSH easier then recompiling the emonpi from github? if so might be my best bet for a fix.
I can’t answer that one. To develop the sketch, I took the emonPi apart and treated the “emon” pcb like an emonTx, plugging the programmer in directly and not going via the Pi. With the need to upload every few minutes as I changed things, taking the emonPi apart was a lot quicker and easier in the long run.
You’d still need to compile and upload the CM sketch anyway, either doing as I did or by loading it into the Pi’s SD and then transferring it to the processor on the “emon” pcb.
I actually have software switches in the code so that it will run on an emonTx - so everything to disable the LCD is there.