Archived Forum

I have waded through - I think I roughly understand, and yes I think it's do-able. (I'd need to draw out your distribution in a single-line diagram and have you confirm it to be totally happy.)

Here's my breakdown: 4 emonTx's, two measuring generation and local loads; and two measuring nett import/export. One GLCD per phase.

Because all 4 emonTx's will almost certainly use the same radio band and channel channel, there would be a small chance of them blocking each other, the effect would be you lose the occasional reading. The RF protocol tags each message with its source, so the displays know where the measurements relate to.
Just one question: I assume you have a two- or three-phase supplier's energy meter, our understanding of multi-phase meters is the energy is summed across all the phases, so generation on one phase can be balanced (as far as your bill is concerned) by a load on another phase. If that's the case, would it make sense, provided there's enough screen space to display what you want,  to know the nett power across both phases, as both GLCDs can and will receive all four emonTx's. The GLCD software will need customising to sort that out. If you choose the rather smart display with energy icons, the processor in the GLCD is tight on memory and you might find that you are limited in what extra you can squeeze in.

Robert, thanks so much for taking a look at this.

I've attached a schematic showing how things are connected - hope that makes sense.

Would it be necessary to measure the loads or could the consumption be calculated (generated + imported/exported)?  It could be done with an extra CT on all four emonTx's, so it wouldn't be an issue if it would be better.  I would then have to add the load from both locations to get the total load on each phase?

Regarding your question on metering:  Nothing fancy here, just two separate single phase import/export meters. A condition on application was that the PV system had to be split to export on both phases wired to the property for balancing purposes.  The silly part is that if I'm running the pool heat pump (3.2kW single phase) I can still be importing on that phase, and at the same time exporting 3kW + on the other.  They bill and reimburse on the sums of both the individual meter readings.  As some very different condition's occur between the two phases I would like to have a separate display for both, rather than just having a nett of the two.

I didn't mention it in the first post but I was intending to run an emonBase as well so I could tinker with the emoncms.  Would it be feasible to do it this way and run the GLCD's from the base?

Thanks again............Mike L.

Dealing with the simple part first, although it's not all that clear from the general illustrations, both the GLCDs and the base will receive the same information by radio from the emonTx's. The base will receive server time and transmit it to the GLCDs that will enable a display of time-of-day, and allow things like daily totals to be reset.

Unfortunately, I have had commitments today and have more tomorrow, I'll try to find time after that to take a serious look at your scheme.

Basically, for accuracy what you don't want to be doing is calculating a value that is the difference between two nearly equal quantities, so that will have a bearing on where you measure.

[Edit]

This appears to be the simplest way of doing it.  You need to obtain the total consumed as the sum of generated + imported powers. It means there may be, unless you are very careful with the calibration, quite large errors in calculating it when it is small and there is significant generation (that is of course mostly exported).

If you don't like that, you can add 2 c.t's on the remaining loads of the pool shed board feeding into emonTx's 1 & 2, and a further 2 on the feed into the house distribution board feeding into emonTx's 3 & 4.  Power consumed would then be the sum of a number of small(ish) positive powers, which stands a chance of being more accurate.

Robert, that is great what you have done for me here - greatly appreciated.  I think I will go with your second suggestion.  I didn't realise at the time that is wasn't going to be that hard to actually measure the loads.  And as the heat pump is the only load on that phase at the Pool shed sub board, for the cost of three more CT's it would be silly not to do it this way.

Well I better get some hardware and get busy.

Thanks again.

Like this then?

If each emonTx could measure real power on 4 channels simultaneously (something I've been looking at recently), then only two of them would be required.  With the V3 emonTx platform, the fourth CT channel would need to supplied on stripboard or similar, but that's easy enough to do.  Code to follow shortly ...

Robin:

But the c.t's would need very long cables - it's 30 m plus the house from one location to the other. By the time the cable is bought and installed, another emonTx and radio is possibly cheaper and certainly easier.

Or were you thinking of measuring two phases in one emonTx - which would imply a second voltage input as well, so all 6 analogue inputs would be in use, plus 2 temperature measurements on one? I think that would really stretch the processor.

(Sorry Mike, if we've lost you there! - The emonTx is designed for single phase installations, so it has only one voltage input. But the ADC has 6 multiplexed inputs, 1 voltage and 3 current are used, leaving two unequipped spares coming out to ports on the pcb. By adding two lots of interface circuit externally, these can be used, which would give you 1 emonTx in each location.)

That 's fine Robert.  So far I understand all that.  As I've only had limited tinkering with electronics, I think your version 3 of the schematic will be the way to go for me.  The only disadvantage being the number of transmitted signals.  At least I can use hardware that already exists without modification, and firmware that will require a small tweak as opposed to a complete rewrite.

Thanks all the same Robin.  Appreciate the input.  

OK Mike, I'd not appreciated the distance aspect.  I've recently written some code which continuously monitors real power on four channels, and your project seemed a good opportunity to test it.  It seems to work OK on the bench and will hopefully appear on Github soon for anyone who may be interested.

With appropriate care on the HV side, I see no reason why the functionality of emon TXs 1 & 2 (and, separately, 3 & 4) can't be combined.  Is there any fundamental reason why voltage and current on different phases can't be sensed by one emonTx?

Is there any fundamental reason why voltage and current on different phases can't be sensed by one emonTx?

Not a fundamental one, but two practical ones - the signal conditioning interface must be added externally, and then there's the matter of processor load. If you're using emonLib and sampling the phases alternately, that's not a problem. If you are running the interrupt-driven code and sampling continuously, then the sample rate is going to suffer. OK, it's only one more than your 4+1, but it's still more - and don't forget the temperature measurement too.

With all six analogue inputs in operation and the ADC going flat out. the sampling rate would drop to 32 per 50 Hz mains cycle.  My gut feeling is that this should be OK for this application.

Rather than having six pairs of reference dividers, each with its attendant 10 uF cap, this would seem an ideal opportunity to use the single buffered reference that I introduced for my Uno-based Mk2 router.  A strip-board front end for all six channels should be easy enough to construct.

It would be important to ensure that the main processor has sufficient time to do all of its processing activities within the time that is available to it (i.e. 6 x 104 uS).  Integer-based maths is much quicker, but FP maths would probably be OK.  Time might be short at the moment when all the data is to be dispatched.  Maybe it would be possible to process the data on some kind of rota basis, so that several channel's worth of infrequent data does not all have to be done at once.

Sounds an interesting project, I look forward to seeing how it develops.

Robin:

You're assuming Mike wants to go with your new software.

Mike:

The new software Robin mentions offers the advantage over the Github demonstration sketches and emonLib in that it measures the power continuously, whereas the latter, being originally intended for battery or mains operation, only takes a short sample of the voltage and current every 5 seconds (and we presume that sample is representative of the period).
Note: if you do add to the hardware, you won't be able to use the published sketches straight off - they will need to be customised.

By "buffered reference", Robin is referring to the input circuitry. If you look at Building Blocks, the input has to be biased mid-way up the input voltage range (1.65 V for a 3.3 V emonTx) and in the emonTx this is done with a simple voltage divider and capacitor. In the software, that offset is removed by a high pass filter, one per channel because due to resistor tolerances, the offsets are never the same. Robin's Mk2 input had a common bias source provided by an op-amp, which meant a single low-pass filter could be used to extract the bias value, which is very simply subtracted from each input signal to remove the offset (thus speeding up the maths!).

If you have confidence in your building skills, knocking up a 6-way front end (even if you do attach it to a partially complete emonTx) would be fine; but if you have reservations, maybe you will be better sticking to the emonTx kit (2-off) and when it's proven, add a 2-way front-end via the headers. If you have even bigger reservations, it is four emonTx kits.

(Personally, I'd go for 2 emonTx's with a 2-channel front end: 1 extra current & 1 extra voltage.)

Robin:  You're assuming Mike wants to go with your new software.

Robert:  No, I'm just making Mike aware that an alternative solution for his project may be available.

Mike:  I'll send you a PM.

Mike, here is my suggested solution for your project.  It requires two Arduino Unos, each of which deals with two voltage signals (one on each phase) and four CTs, two on each phase.  The signal-conditioning circuits for all six channels are mounted on a single front-end board along with a single buffered-reference, diagram attached.  The Uno operates over a 5V range rather than the 3.3V range that an emonTx uses, hence the various resistor values may need to be adjusted for optimal performance.

Each Arduino will also require an RF adapter.  The one that I built yesterday follows the design on the BB page.  The RFM12B chip that I used has had a difficult history because some months ago I unhelpfully soldered it onto an emonTx upside down. Having separated these components by brute force, both have now proved to be entirely serviceable.  These days, electronic components can take an awful lot of abuse, much like cartoon characters that keep coming back for more!  The attached photos show:

i) the Uno with its front-end and RF adapters;

ii) My voltage source, a twin secondary '9V' transformer;

iii) my 4 CTs, two with one coil passing through each, and two with two coils passing through them.  Within each pair, their directions are reversed.  By this means, I get to see 4 separate waveforms: two small, in anti-phase; and two at twice the size, also in anti-phase;

Three sketches are attached in the .zip file:

i) TwoPhaseFourChannel_RPmonitor_1.ino   This is the main workhorse (sorry for the unweildy name!)

ii) RawSamplesTool_6chan_ino   A variant of my existing tool, which uses all 6 analog inputs

iii) emonTxV3_4chan_Rx.ino   A suitable receiver sketch with which to display the transmitted data.  The payload has 5 integer fields: the first contains a message ID, the other four contain the Real Power in each of the four CTs.   The on-board LED blinks in line with the LSB of the message ID.  This sketch will hopefully be appearing on GitHub soon, and works fine for this application too.

The modified RawSamplesTool, as above,  confirms that the front-end is working as expected.  Here is a display when around 2 kW is flowing through my bank of CTs.  As mentioned above, my CTs have been arranged to provide four distinct traces for current.  My two voltage sources are identical and wired in anti-phase:

>>free RAM = 725
millis() now = 0
recordingMayStartAt 5000
4
3
2
1
0
No of cycles recorded = 1
cycleCount 252,  samplesRecorded 28
|                                  235 0.14                                     |
|                            3   5      .    401                                |
|                       3      5        .       4   01                          |
|                 3 2        5          .         4       1                     |
|            3  2          5            .          4          10                |
|         3   2           5             .           4            1 0            |
|       3    2            5             .            4            1   0         |
|       3     2           5             .           4             1    0        |
|       3      2           5            .           4             1    0        |
|          3     2           5          .         4             1     0         |
|                3    2        5        .       4          1     0              |
|                      3    2     5     .    4        1    0                    |
|                             3  2   5  .  4     1  0                           |
|                                    3 25  1  0                                 |
|                                   41 0.  532                                  |
|                              10 4     .     5   3                             |
|                        10    4        .       5      23                       |
|                   01       4          .         5        2 3                  |
|              0 1         4            .           5          2  3             |
|          0  1           4             .            5           2   3          |
|        0   1            4             .            5           2     3        |
|       0    1            4             .           5            2     3        |
|       0    1             4            .           5           2      3        |
|        0     1             4          .         5          2     3            |
|             0     1          4        .       5       2     3                 |
|                   0    1        4     .    5     2   3                        |
|                          0  1     4   . 5   2  3                              |
|                                0  1  52 3                                     |
 

Note that the number of sample sets is only 28 whereas I have confidently predicted 32 per mains cycle for 6-channel operation.  That's because this tool controls the ADC via the highly inefficient analogRead() routine. 

In the main workhorse sketch, the ADC is running continuously.  An Interrupt Service Routine tells it which of the six available inputs to service next.  Because the next conversion has already started by the time that the ISR is run, the 'next' channel is always two ahead of the one that has just finished.  This can be seen in the switch() block in the ISR routine, ISR(ADC_vect).

To demonstrate that the main sketch is running at the predicted rate, I've added a line which displays how many samples per mains cycle have been seen.  The answer is indeed just over 32, its actual value depending on the local mains frequency:

Go!
samples per mains cycle = 49.53
0, 0, 0, 0, 0
samples per mains cycle = 32.06
0, 0, 0, 0, 1
samples per mains cycle = 32.06
0, 0, -97, 238, 2
samples per mains cycle = 32.06
1049, -1295, -699, 700, 3
samples per mains cycle = 32.06
1422, -1378, -698, 699, 4
samples per mains cycle = 32.07

The above snippet is from the results file, RP_4chan_results_2.txt, which is also included in the .ZIP file.  Note the four power values (the fifth value is the message ID).  For this run, the load was my room heater on its low-power setting, nominally 750 Watts.  The 3rd and 4th CTs show around 700 Watts, their sense being opposite because their CTs are opposite ways around.  The 1st and 2nd CTs show double this value because the cable goes  around each of them twice.

An RF message is dispatched every 2 seconds (every 100 mains cycles at 50 Hz), the payload for each message being assembled in several stages.  After 20 mains cycles, the average real power for CT1 during the last 2 seconds is calculated and lodged into the appropriate field in the payload.  At 20 cycle intervals, the data for CTs 2, 3 and 4 are treated similarly.  At mains cycle 100, the pre-assembled RF message is dispatched.  By this means, workload that occurs infrequently is spread out rather than being all bunched together at one point.  So how effective is this approach, when combined with integer maths throughout?

With no Serial display, and the RF message being assembled but not sent, Workload Check shows that the main processor is idle for around 480 uS out of  every 624.  That's a processor occupancy of just 25%!   When the RF activity is reinstated, the displayed value falls greatly; I expect there is some interaction between all the various interrupts that are flying around the place.

This code has been optimised for monitoring real power on several channels.  PowerCal and phaseCal can be individually set for each CT.  I think the Uno platform is well suited for this particular project, but similar code could be run on an emonTx with additional front-end circuitry as required.  I hope that it will be of use to anyone who has need of such a solution.  

Excellent work....!!!!

Just one question, what lines must be changed to 120V and 60Hz
Can we make a deal?. What would need to consider for this?

José, As far as I can see, this code should work OK for you without requiring any changes.  However, because of your lower mains voltage and higher currents, it may be useful to alter the component values in your input sensors. 

For best performance, each of the signal sources should use most of the available range of the ADC.  The 6-channel version of RawSamplesTool that I included will show you when this situation has been achieved. 

Because this sketch measures power, rather than energy, I think it should work equally well at 50Hz or 60 Hz.

Is that a deal?

What values ​​are you referring to?

only I require measure a current signal (up to 100A) and voltage (120), at a frequency of 60Hz, for monophase installation, but I require the measurement of real power and energy, then send the data using a shiel wi-fi arduino to a server.

Is this code would be good?

I have the arduino Mega2560 and TFT where I will display the measured values.

In truth I have reviewed some codes here, but I failed to interpret. The codes that I understand are more accomplished, the Seller and the EmonLib the one in this post, I reviewed the one here, which is also very good, but I think for so many functions that I have had difficulty interpreting it.

What would be the most suitable for my requirements?

Thanks for reply ..!

José, the 6-channel code that I have written is intended for use in New Zealand which has the same voltage and frequency as the UK.  If you wish to use this code in Spain, then it is up to you to make any adjustments that are necessary. 

In my last message, I explained that you may wish to change the values in your input circuits so that they use most of the available range of your ADC.  These input circuits (or sensors) are fully explained in the Building Blocks sections.  I can't tell you exactly what component values to use.  You need to assemble and test a system for yourself, and then adjust these component values to suit your particular needs.

The ASCII display above shows that all six of the analogue channels in my test rig are using a reasonable proportion of the ADC's range.  If a sensor is too sensitive, the output values will "clip" at the peaks of each waveform (your sine wave will look square).  If it is not sensitive enough, your output values will be very small, and will suffer from quantisation distortion (i.e. granularity or lumpyness) when only small signals are present.

A 10-bit ADC has 1024 output values, from 0 to 1023.  These values span a certain range of input voltage, which may be 5V or 3.3V or 1.1V depending on your system.  It is up to you to adjust the signals from your sensors so that they are well suited to your ADC.

Hello, excuse me for not responding in due time been out of this a good time! ...
Thanks for the help, I advance a lot so far in my code.

Now I encounter a problem, because I want the energy consumed is stored for years. In code that is using review kwh calculated the millis () function, but this is restored in approximately 49.7 days, and my idea is to continue indefinitely measuring kwh.

I hope to finish soon and share my modified code, so that they serve those in need.

How do the calculation without the millis () function? or

What setting should I do to not be reestablished?

THANKS AGAIN..!!

You must change the size of the units you measure.

We humans count small amounts of time in seconds, larger amounts in minutes, still larger in hours, etc. Likewise we measure small amounts of energy in Joules, large amounts in MJ or kWh, larger still in MWh.

You must do the same. I have not looked again at calypso_rae's code, and it depends on the degree of accuracy and how many years you want to count, but if for example you have an unsigned long integer (max value 4,294,967,295), then you can use that to count seconds, and every second (using the millisec timer) you increment it and at the same time check your energy register. If it is more than 1 kWh, you subtract 1 kWh and add 1 to another "kWh" register. That way you have the exact time to 1 s, and the exact energy held in two registers, and you can carry on like that for approx. 136 years.

This is my code to calculate the energy in the variable (kwhDay) I store dirio consumption (it resets every day at noon) in the variable (kwhMonth) I store the monthly consumption (resets the 7th of each month) and the variable (kwhTotal) want the total consumption was stored for years. The problem that I have is when the millis () function is restored, my varible (Timems also will reset), and that all comes to low.

ltmillis = tmillis;
  tmillis = millis();
  timems = tmillis - ltmillis;
  timems =0;
  //Calcular en  kwh de consumo.
   
kwhTotal = kwhTotal + ((realPower*timems/3600000)/1000);
costo = 0.08*kwhTotal;
kwhDay = kwhTotal;
kwhMonth = kwhTotal;
   DateTime now = RTC.now();
   int last_hour = hourReset;
   hourReset = now.hour();
   int last_day=dayReset;
   dayReset = now.day();
   // minute = now.minute();
  
  if (last_hour == 11 && hourReset == 12) {kwhDay = 0 ;}
  if ((last_day == 10 && dayReset == 11)&& (last_hour == 11 && hourReset == 12) )
  {kwhMonth = 0 ;}

The purpose of the code that I've posted on this thread is to transmit (using RF) the real power on each channel.  This data can then be received and processed by some other platform.  That could be a pair of emonGLCDs or a nanodeRF which links in to emonCMS etc.

With all six analogue channels on the go, this code is fairly busy as a multi-channel data gatherer.  Keeping track of cumulative energy flow totals for each channel as well seems an unnecessary overhead.  Also, any accumulated values would be lost when the system restarts.

With my new Mk2 hardware, there is a second CT which can measure the actual flow of energy to the dump load; this data can be accumulated within the associated code.  To keep the code efficient, energy flow is calculated using integer maths in linear units of high precision; there are several million of these per WattHour.  Even when using a 4-byte long, such calculations could soon overflow. 

To avoid this problem, I've included a WattHour register which is incremented whenever the energy accumulator exceeds the 1 WH mark.  The value in my (long) accumulator is then reduced by exactly 1 WH's worth.  The content of the WattHour register is routinely displayed to the front-panel screen and/or transmitted by RF for use elsewhere.   As an unsigned int, the WattHour register will record up to 63 kWh which is plenty for one day's worth, and it auto-resets each night.  Longer term storage of data needs to be done elsewhere.

This arrangement is like recording "now" as being 25.123 seconds past 09:15 on 11/1/2014.  By this means, millisecond accuracy can be provided for a unique moment in time without the need for a local millisecond clock that can run has been running for thousands of years.

[This arrangement appears to be just as RW had suggested :-) ]

José:

If I understand you correctly, you have a problem when the millis() timer wraps round to zero?  That is a well-known problem and it has a solution: http://playground.arduino.cc/Code/TimingRollover

My idea is to be like a commercial accountant regarding the storage of measured kwh. That is my big problem, try to fix it, the idea of ​​Robert Wall, is very good (change the size of the variables), but as change these units without using milis (), to measure, ie as that has elapsed one hour, or 1 day, and this will continue to increase. Actually I'm half confused, I need a lot of science, if someone understands me agradesco you greatly.

I shall try to explain again. You have two problems: (1) millis() returns to zero every 50 days ( approximately) and (2) your numbers get too big. Here is a general idea for what you must do:

Inside your main loop:

You use millis() to measure a duration of exactly one minute. You must use the TimingRollover code to make sure everything happens correctly during the minute after millis() has returned to zero.

You accumulate Joules each time you measure energy (2500 times per second?).

When 1 minute has passed:
     Add 60,000 to the milliseconds to know when the next minute is due.
     Add 1 to your count of minutes.
     If the Joules accumulator is greater than 3,600,000 (= 1 kWh) then
          Add 1 to the kWh register and subtract 3,600,000 from the Joules register
     else do nothing.
 

At any time the total kWh is the number in the kWh register + (the number in the Joules register / 3600000).
Likewise the total time in minutes is the number of minutes + (the number of milliseconds / 60000)

If the maximum number in your Joules register is greater than the biggest number you can use, then you must do this in three steps and not two. (1) accumulate Joules, (2) Joules -> Wh ( 1 Wh = 3600 J) , (3) Wh -> kWh.
 

Thanks, about the size of variables and I resolved to do what you mentioned, what time (millis ()), I'll fix now with your suggestions. I hope to solve it today.

Thanks Robert Wall.

The multi-channel code that I posted on this thread calculates the average power (in Watts) for each channel during a 2-second period.  To convert this to energy (in Joules), just multiply each power value by two (because Energy = Power x Time). 

If you want to know the total amount of energy that has been recorded, your energy accumulator variable will need to be updated every two seconds, not every millisecond.  To prevent the accumulator from overflowing, you will need to keep track of whole WattHours separately, as Robert and I have both described.

Once the start-up period has passed, my code doesn't use millis().  To keep track of time, e.g. for when an RF message should be transmitted, it uses cycleCount which increments once every mains cycle (20 mS in the UK).

After being trying all day not e able to solve it, I always toss and turn and came to the same thing, I have this code, but clearly I still have the same problem (when startTime2 reach the limit) or is making me hard this apparently is simple.

"You use millis() to measure a duration of exactly one minute. You must use the TimingRollover code to make sure everything happens correctly during the minute after millis() has returned to zero."  This is what I can not understand, apparently the language is again affecting me.

Excuse me, could you give an example that tells me about it, I would infinitely thanked him.

José,

Te di un enlace: http://playground.arduino.cc/Code/TimingRollover.  No puedo explicar nada mejor que eso.

I think that link needs an extra '/'

http://playground.arduino.cc//Code/TimingRollover 

<Sniff>! I checked it, then the automatic formatter screwed up! I have changed it  - I must learn to always write the HTML by hand, it is much safer!

<p>Te di un enlace: <a href="http://playground.arduino.cc/Code/TimingRollover">http://playground.arduino.cc/Code/TimingRollover</a>.&nbsp; No puedo explicar nada mejor que eso.</p>

Thanks friends, I still have much to learn I'm aware of that, that was very helpful.

Hi, With your help I managed to have my first version of the power meter and I make it public to your reviews .
This is based on the library " EmonLib " .

Necessary changes (calibration ) was performed at a voltage of 120V at 60Hz. The low values ​​of the current I miss that when no measure is unloaded ( unlikely because almost always will be a charge of the same prototype measurement) wrong values.

Power variables are displayed on the TFT, the power is calculated every second ( Joules ), three parameters enrgía consumed ( Daily,  Monthly, and Cumulative ) is measured , also the cost per kWh is calculated for a month.

This is my first version I have not checked for a long time , but the few tests I've done is satisfactory. Any criticism would be welcome.

Thank you ..!  This Is https://github.com/jdarduino/EnergyMeter/blob/master/.gitignore

The next part is to send this data to the internet, I tried xively library, but the display on the TFT , fell to low. This time delay in the connection, and no connection when the program stops unexpectedly .

I would very much if I recommend which is the best option for sending data to internet, quickly checked the " emoncms " page but I have absolute ignorance of their operation and as sending data from my ethernet shield Arduno .

I hope my program will be useful for someone.

Sorry for my weird English. :-)

The sketches for the NanodeRF on Github https://github.com/openenergymonitor/NanodeRF might help you with your connection to the Ethernet.

You can try out EmonCMS with your web browser. Create an account, go to Input and Input API Help. You will find there the data formats that EmonCMS expects. There are two forms. The first (JSON) allows you to give a name to the input:

http://emoncms.org/input/post.json?json={power:200}&apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The second (CSV) only sends values:

http://emoncms.org/input/post.json?csv=100,200,300&  apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On the Input page these are named automatically as "1", "2", "3" etc and you can add a "Description", for example "Power from Grid".

(You can see your personal APIkey on the Input API Help page - use that instead of xxxxx.....)

If you can send data from your Arduino in one of these forms, you can use EmonCMS.
 

Thanks for responding, I am reviewing and trying to send emoncms damages. I see this <HttpClient.h> uses the library, this library has been giving me problems (there is something there, that achievement does not understand). Suppose I want to send data to emoncms every 30 seconds, and for a moment the connection is lost (may be a failure of router, cable etc..), There is that it gets stuck my program looking to establish a connection because I am calculating the energy every second (in Joules) if the time it takes trying to connect is greater than 1 second, give me erroneous energy values​​.

Here's how the energy calculation.

One more question. Can two-way communication from emoncms?, Would like to send messages (or to control the load from emoncms).

Gracias..!!

This is a really badly titled thread and is no longer involving the person who initially posted the query.  Any chance of renaming it?

Sorry, I could make as a new topic in forum ... Rename this is not how to do it.

A better solution would be to transplant the inappropriate comments into a new, relevant, thread. Unfortunately, there's no mechanism in Drupal that I know of to allow that to happen. So we're pretty much stuck with it.

However, the thread can be renamed. If you'd like to suggest a new name, I'll do that.

Well in this thread we talk a little of everything .. A general theme could be "Measuring Energy to  120V 60Hz and data sending with shield ethernet."  

Ok. I answered myself, I was using the library xively, and this has features that spend time, communicate, if there is no connexon be trying some time. which does not suit me, because you can spend a few seconds and that is equivalent to an error in the calculation of energy (Wh), deveria add a condition that if there is no connection at any given time (about 100ms). No more trying to connect to it to continue executing the rest of the program.

I pose the question again. Can I establish two-way communication from emoncms?

I agree that this thread has drifted away from its original topic, and that this situation is not ideal.  When this happens, the best approach is surely for someone to start a new thread with an appropriate title which can then head off in the new direction. 

Changing the title and/or content of an existing thread does not seem a good idea to me.  I spent several days creating and then posting a comprehensive solution which appears to satisfy all the requirements of the originator.  It's hard enough to locate things in this system as it is; if titles were to be changed, it would become even more awkward.

My suggestion is that someone now adds a suitable message to terminate this thread and refer any interested reader to a new one.  It won't be me.  I can understood the first half, but get lost when anyone mentions "apikey" and the like!

José: I think there is another active thread where commands back from emonCMS are being discussed http://openenergymonitor.org/emon/node/3733  though there does not seem to be a working scheme yet.

Hi Robin, I realize this is an old thread but it is exactly what I am looking for. I am new to the open energy monitor forum but have many years experience in electronics and computing and am now retired.  I have made projects with PICs, beaglebones, arduinos and PI's and would like to take your project a little further if it hasn't already been done before.  I would Like to make a PCB for the TwoPhase4chanMon_FrontEnd circuit that you came up with to tidy it up a bit an ot isd there a better way to handle this 2 phase monitoring with the solar pannels separate from the house main board on a sub board located about 50 meters away.

Cheers Mal

Hi Mal,

Yes, I was pleased with the way this code turned out.  It was the first time that I'd had all six of the analog IO ports in operation. 

I now have a 3-phase PCB which supports a pair of V & I sensors on each phase.  If you wanted to only monitor two phases, with 2 CTs on each, I'm sure that could be arranged with only minor changes to the PCB.  This PCB includes the processor rather than just being the front end circuits.

Details of this board are at http://mk2pvrouter.co.uk/61101.html   Send me a PM if you're interested, or there is an email address on my Shop page.

Robin (calypso_rae)