I have been using the emonPi out of the box for a few years no probs. I recently had my switchboard upgraded to remove all the old circuit breakers and replace them with residual current circuit breakers (RCBOs) as this is now the legislation when adding circuits to the board (which I also did). This obviously required disconnecting the 2 CTs and then placing them back. I have the emonPi setup for a type 2 solar system monitoring. consumption +/- and solar generation which then feeds via nodered to PV output.
After this work the emonPi is now exhibiting some behaviour it never did previously. Firstly and most annoyingly, if there is a power cut I have to (when power is back on) turn off the pi then turn back on so that the voltage measurement transformer is on before the pi reboots. I have never had to do this before, failure to do it now and the pi measures all imports as consumption. eg does not know whicjh way the current is flowing.
Secondly, the solar measurement never goes to zero, it drops to about 68w and stays there till morning. It used to go to zero prior to this work. I can only assume it is now measuring the keep alive arrive the inverter draws overnite, prev it just went to zero.
This is puzzling - the RCBOs themselves should not have caused any problems. It means there is some kind of “sequencing” going on in your switchboard which means the a.c. adapter is getting powered up late. If you can identify the cause of this, and possibly move the adapter onto a circuit that doesn’t do this, it should cure the problem. Failing that, the second solution is very simple but implementing it will be quite hard: either delay the ‘front-end’ sketch in the emonPi where the power is measured and calculated inside the Atmel '328P, or disable its ability to revert to the “no a.c. available, guess the voltage instead” mode. Both are relatively simple changes, implementing them and retaining them across updates could be a major problem.
I would actually expect it to go negative overnight. If it doesn’t, you’re still calculating apparent rather than real power. The solutions are in emonCMS as a step in the input processing of the PV power, either subtract 68 W (which will of course introduce a different error) or add an “allow positive” step to kill the negative overnight consumption.
If you want to tackle altering the sketch, I can suggest the changes needed and the steps to load them into the '328P.
Thanks for replying, for clarification both the voltage monitoring plug pack and the plug pack that supplies the pi are both connected to the same double gpo outlet.
Regards adding an allow positive to the solar CT reading, it is always positive. When the sun shines I measure the power from the inverter, when its dark oit still reads around 40-60W positive (still generating).
I don’t understand why removing and then putting back the CTs has caused this issue. I have tried the differnet combinations of reversing the CTs but same still occurs.
Regards CT orientation, the arrow on both CTs are pointing in the load direction. EG. consumption CT arrow follows incomer current into board and solar CT follows solar current into board.
I don’t think it has. Something else has happened at or nearly at the same time that’s the real cause of the problem.
If you reverse the c.t., the power you read must change sign if you are calculating real power. It won’t change sign if your a.c. adapter (is this a Jaycar one?) isn’t connected or it isn’t providing a voltage sample as or before the emonPi is powered up, because as I intimated above, the software tests for a voltage during the start-up procedure, and if it doesn’t see it, it locks into calculating apparent power using an assumed and constant voltage, never to revert until the next power-up (rebooting the Pi doesn’t change anything).
The software is here: emonpi/startup.ino at master · openenergymonitor/emonpi · GitHub
Once ACAC has been set, it never changes.
Does your voltage reading vary at all - with time of day or the amount of load, or is it a rock solid 230.0 V? Have you measured the output of the a.c. adapter - it should be about 10.4 V for 240 V in for the Jaycar one?
The voltage monitoring plug pack is the one that came with the emonpi as purchased from UK (blue CTs as well). I haven’t measured the voltage but if it is not connected to emonpi then all consumption readings are import only. The recorded voltage varies correctly in PV output as it did before, low at night and high during day.
Reversing the consumption CT will reverse the import/export figure provided the voltage plug pack is switched on first before the pi. Reversing the solar CT does not change the polarity of the reading, its always generation positive.
I’m assuming this meant that the solar power when generating is correct - is it?
Where is your solar c.t. located, exactly? All I can think is what you are seeing is pick-up, maybe from an adjacent cable or cables - which to give a reading of 40 - 60 W in addition to overcoming the “keep-alive” power drawn by the inverter, must be touching and carrying a substantial current. When I did the test, 100 A in a touching cable (actually, 5A × 20 bunched turns) induced a current equivalent to 160 mA (i.e. 40 W) in the c.t. under test. But that makes little sense either - that too should have reversed when you reversed the c.t.
Where were you looking? I don’t believe the c.t. stopped working. You must have something in the input processing that had inhibited the reading when the numbers reached the place where you were reading its value.
When I say stopped working I mean its reading stayed at zero until I turned it around the other way, arrow facing towards load, and it started reading again.
I am using the type 2 solar template on the pi which sets up the tag names and feed processing, I have not added to or altered these in any way.
I have been analyzing the MySolar graphs and just after dusk and just before dawn I get a zero reading on the solar generation for around 10 minutes. Could it be that the solar CT/pi is reverting to reading the inverter draw from grid when there is absolutely no generation?