Archived Forum

How do you know it is not adding up accurately? Are you reading the same numbers that it is adding up? I can't read your picture accurately, but at first sight you seem to be doing the calculation in the wrong place. Can you attach the complete sketch - not a screenshot - to a post so that we can see it in its entirety?

Hi Robert , thanks for looking.  I've attached the sketch. The problem calc is at line 567 in "case 70"

I have another calculation at line 597 in "case 90" which seems to be working as predicted but it's just a simple addition of two CT Wh values.

Robert, sorry I missed the question when I first read your post. As far as I know I am using the same values to do the calcs.  I have used the individual Wh values that the emontxv3 is sending to my nodes page to check the calculations.

I checked using the totals recorded since the emontxv3 was reset during sketch upload, with several resets to make sure. I also checked using the values recorded by the Wh accumulator processor from midnight to midnight the next day and also the kWh to kWhd feed values. All these values agree with each other and match my utility meters yet the calculation is way off.

I was concerned that one of the values was being changed by accident elsewhere, but that's not the case. I can't see a reason for the sum being wrong, I suspect something is getting corrupted along the way. On the face of it, this "All these values agree with each other and match my utility meters yet the calculation is way off." is self-contradictory. I'm sure you didn't mean that - it's a case of what you mean by "all of these values".

It's still not clear to me where you are reading the values, and which ones. Do the sums work and are the numbers from the Serial.print directly out of the emonTx mutually consistent, are you reading the numbers after they are imported into emonCMS and are they mutually consistent? This "I have used the individual Wh values that the emontxv3 is sending to my nodes page to check the calculations." seems to say that the numbers emonCMS is seeing are not mutually consistent. Is that the case? If so, and if the Serial.print values are correct, then have you checked that you have counted the bytes correctly at the emonCMS nodes page and you're allocating the bytes to the correct variables?

I've just rechecked the numbers I'm receiving in emoncms and it seems the figures on the nodes page are working out correctly. ie. the onboard calculations are working ok. 

However the same calculations based on the kWh to kWhd 'feed' values and also on the realtime graphs Wh accumulator based 24hr elapsed values are way off the stored calculation.  

What is confusing me is the kWh to kWhd and Wh accumulator based feeds match each other and my utility meters exactly yet I can't get the simple plus and minus calcs to match the emontx calc value when it's stored as a feed.

The two screenshots attached where taken within a second or so of each other. The first shows the nodes page whose values calculate out ok with the calc below.

expWh CT2 - (expWh CT1 + Wh CT3) = pvused Wh CT2

The second screenshot shows the feeds page where the same calculation doesn't work despite the values coming from the same source.

pvWhd produced - (pvWhd exported to grid + pvWhd diverted to immersion) = pvWhd used in house

I wouldn't expect these values to match unless you have started with a totally clean slate since midnight,

1st screenshot

expWh CT2 - (expWh CT1 + Wh CT3) = pvused Wh CT2

34697-(1258+19085) = 14354

This is the total "used in house" since counting began

2nd screenshot

pvWhd produced - (pvWhd exported to grid + pvWhd diverted to immersion) = pvWhd used in house

8668 - (327+5792) =2549

This is the total "used in house" since midnight

When you created the wh accumulators you would of allocated names to those feeds, those feeds should match the values in screenshot 1 and continue to increase throughout today and tomorrow etc, where as the feeds you refer to in screenshot 2 should reset at midnight  and record tomorrows figures only. if you were to sum each of the daily totals since you started counting they would  match the wh accumulator totals.

the wh accumulator has been designed to not reset the feed to zero if the emontx is disconnected or powered down etc. in theory if you manually edit those feed values in emoncms to your current meter readings they should continue to increase in line with your meters regardless of whether you reset the emontx.

So this means that the actual values being used in the emontx sketch will not necessarily match the values you see in emoncms but the rate of change should be the same. For that reason I think you would be better doing these calculations in emoncms rather than the emontx, emoncms has the persistent database storage where as the emontx will count from zero at each reset.

Paul

Thanks for the comments Paul. Sorry I wasn't very clear with my explanation.

The feeds Whd section in the 2nd screenshot also has the calculated value feed taken from the emontx all time calculated value. This also resets at midnight. see feed 44196 which is showing 3844 Wh since midnight whereas it should be showing 2549 per your workings out.

I used the Whd screenshot as it illustrates the discrepancy better than the all time Wh accumulator feeds which also have the same discrepancy.

I am trying to do the calcs in the emontx to try and increase the robustness of the all time calculated Wh figures in the same way the other Wh figures direct from the emontxv3/ CT's are more robust than emoncms derived ones. Losing the odd days worth of Whd figures is not a problem as long as the all time Wh accumulator figures can be relied on.

Aha, sorry for the confusion, I can see what you're saying now. 

If the 3844wh is direct from an input feed it does indeed contradict the other inputs, since all the wh values are immediately passed through wh accumulators you don't actually get to see the raw data, 

Until you have reliable data I would recommend adding a 'log to feed' as the first processing step to each of your wh inputs, this won't effect the results but it will allow you to see the the raw input values to assess if emoncms is getting the correct data.

Paul

I took screenshots of my Node and Feed pages at midnight last night and again this morning and went through them feed by feed and node by node then calculated the PVusedWh manually from the recorded figures for the period. From this I was able to identify where the discrepancy is occurring but can't understand why its happening.

1. The CT Wh figures and the PVusedWh calculation are reaching the emoncms Nodes page accurately from the emontxv3.

2. The CT derived Wh figures from the Nodes page are being transferred to the feeds page accurately via Wh Accumulator and Wh to Whd processors.

3. The PVusedWh calculation figures are not being transferred from the Nodes page to the Feeds page via Wh Accumulator or via Wh to Whd processors accurately.  At first It looked as though this feed value error was increasing exponentially each day ie. midnight to 3pm yesterday gave figures 32% high and figures midnight to 9am today gave figures 12.7% high. However this morning I deleted and then recreated the PVused Wh accumulator feed and the error seems to be very inconsistent so far which doesn't make sense.

I've added log to feed processors as the first process for each node but so far they are mimicking the nodes values exactly as they should.

It seems as though the Wh accumulator and Wh to Whd processors don't like the data presented from my PVused Wh Node but what could be making this data any different to the other Wh nodes which the processors have no problems with?

Okay, that's progress.

This is new territory for me I haven't got that involved with wh accumulator before now, but if I understand it's workings correctly then the easy way to diagnose it further would be to add a "subtract feed" immediately after the wh accumulator to subtract the original received/input value feed, this should give you the difference between the 'since reset' value  and the 'since counting started' value, this should be constant and only change if the emontx is restarted.

Since this is only a theory I would suggest also doing it to a feed that is behaving correctly for a reference.

If the difference varies it would suggest the wh accumulator is not behaving and if it's unique to this feed I can only guess it's to do with the range of values or rate of change breaching the 25kw/h filter. I would be surprised if it was but stranger things have happened I guess.

Any change in value on additional "difference" feeds will highlight when an issue occurs, this should at the very least give you a point in time to examine the values closer to understand what's happening.

you could try editing the filter out of the picture as a test eg 100000 /Modules/input/process_model.php line 602 to see if that has any effect. It has previously been increased from 10k to 25k although I'm not sure why.

I wouldn't worry too much about the Wh to Whd just yet as that can't function correctly unless the Wh accumulator is correct.

Paul

Thanks for the suggestions Paul, I  edited the 25k filter value to 25025k.

Next I added a log to feed at the beginning of two of the Nodes then subtracted that log to feed value at the end. The "PV produced" Node I applied it to has stayed stationary so far. However the PVused "problem" node is showing  an erratic increase in the feed value. (See screen shot).

The increase in the error seems to be affected roughly by the energy diverted to the immersion feed as can be seen from comparing the two screenshots. 

That's puzzling, they are too similar to be unrelated.

have you used the same feed for the subtraction eg

log to feed "ABC"

wh accumulator "ABC_wh_total"

subtract feed "ABC"

If not then you should try changing it so it is the exact same feed being subtracted, because for that value to increase the lost wh's that resemble the immersion value, are either being lost in the wh calc or are missing from the subtracted feed.

Try editing the filter well out of range 99000 for example

Paul

I used the exact same log to feed value for the subtraction, see screenshot. I had to do it that way as the nodes page doesn't have any + - node input processors yet. The old inputs page + - input processors don't work any more now I've switched to the new Node inputs page method.

 I've suspected there was something going on with the diverted to immersion feed for the past week as I've noticed a few times that all the daily feed values are in equilibrium until the immersion starts diverting at about 7am each morning.

It's as if the immersion value is being added to the PV produced value instead of being subtracted, but that can't be the case or the node input values wouldn't add up and the error value is not a match for the immersion value anyway.

I''ve got the filter value set at 100000000 now so it should be well out of range.

Sounds like you're on the right track, see what happens when the sun comes up in the morning, I guess.....

Paul

The error stopped overnight but, as can be seen on the screen shots, started again at 05:50 when diversion to immersion and export to grid started again.

I can't think why the rate of error addition is roughly mimicking the diversion to immersion and export to grid inputs yet I can't see a link with the "PV used" log to feed.

As all the calculations for the "PVusedWh" input have already been done on board the emontxv3 and the input values from the calculation are correct, the Wh accumulator is just working out the difference between two Wh numbers and storing that difference to a feed value exactly the same as it does for all the other Wh inputs. It's as if it is rounding this feed up or changing the data type before saving to the feed.

It's not easy to tell from screenshots but  it looks like the increases are equal to the difference between what's being diverted to immersion and the PV being exported  

That's exactly what I thought but when I examined the data the error/ increase was varying a lot. Between 05:50 and 0810 this morning the error worked out at 84% of the diverted to immersion and exported to grid total, however looking at earlier data the error amount  is much smaller than the actual diverted and exported amounts. eg. Over three days midnight 15th to midnight 18th the diverted to immersion + exported to grid Wh was 33156 and the error was 6607Wh so 20%

I also checked the error as a percentage of the PV produced and this also varied between 16% and 12 % for the same two periods respectively.

Having re read my last post it wasn't quite what I meant. I happened to notice the increases in error (22wh) plus the increase in exported amount (8wh) seemed to equal the increase in the diverted amount (30wh) and the graphs seemed to show the same at any time ie not proportional  but the sum of the changes to exported and pv used = the change in diverted, but It was a very small sample and early in the day so may be just a coincidence.

After a few hours, assuming nothing has been changed and the emontx hasn't been restarted, if the sum of  "pv used in house Whd bare" and 'PV Whd exported to grid' is equal to 'Wh diverted to immersion' then it's not just a coincidence.

It's odd it only happens to that feed, especially as the log to feed is so steady. maybe as a last resort you should try substituting a fixed value in place of the calculation in the sketch for a short burst just to see if the error still occurs in emoncms or if not then the issue lies in the sketch. if you substitute the current value from the emoncms log to feed there should be no increase or movement on that feed in emoncms and if you keep the test short the data loss should be minimal as emoncms can pick up where it left off after editing sketch back to the calculation.

How are you diverting? could this be "energy bucket" related. I use MartinR's PLL sketch and with the anti flicker i always record some export during times that I know i'm not exporting due to the bucket filling and emptying being counted. my nett value will be correct but import and export figures are exaggerated.

Paul

I substituted the calc for a fixed value of  15473 and for the last 35 minutes the "PVused after subtracting feed" feed has remained fixed suggesting the problem is in the sketch.

It's strange that the node inputs all seemed to be in equilibrium when the calc was running previously.

I'm using a homemade standalone diverter that uses an anologue comparator to maintain a steady 20 to 80W export whilst varying the output to the immersion with a crydom in phase shift mode.

I did some more substitutions in the sketch (as below) to try and identify the source of the error and it seems to be suggesting that the Wh accumulator can't handle data derived from a calculation with a subtraction in it but the input on the node page can.

1.  tx_data.PV_usedwh_CT2 = tx_data.expwh_CT2 - (tx_data.wh_CT3 + tx_data.expwh_CT1);     gives correct input values but processing the input value further with the Wh accumulator feed gives errors.

2. tx_data.PV_usedwh_CT2 =  127543      using a fixed number gives no errors in input or Wh accumulator feed.

3. tx_data.PV_usedwh_CT2 = tx_data.expwh_CT2 + tx_data.wh_CT3 + tx_data.expwh_CT1;       Removing the subtractions gives no errors in input or Wh accumulator feed.  

4.   tx_data.PV_usedwh_CT2 = tx_data.expwh_CT2 +  (-1*tx_data.wh_CT3) + (-1*tx_data.expwh_CT1);  I tried this as a long shot but still got errors the same as 1. above.

The tests certainly do seem to suggest the Wh accumulator is not handling values derived from a calculation containing a subtraction, but how would it be aware of a values history? surely a number is a number, there must be something else happening that is not easily spotted.

You could try putting the whole calc in parenthesis 

tx_data.PV_usedwh_CT2 = ( tx_data.expwh_CT2 - (tx_data.wh_CT3 + tx_data.expwh_CT1))

or splitting the calc

long temp_val = tx_data.wh_CT3 + tx_data.expwh_CT1

tx_data.PV_usedwh_CT2 = tx_data.expwh_CT2 - temp_val

or splitting the calc and changing the sign

long temp_val = (tx_data.wh_CT3 + tx_data.expwh_CT1) * -1

tx_data.PV_usedwh_CT2 = tx_data.expwh_CT2 + temp_val

or just  try to subtract a fixed value maybe

tx_data.PV_usedwh_CT2 =  tx_data.expwh_CT2 - 123

These sort of tests may narrow the search for where it's struggling but should really be irrelevant to emoncms, it would be better if we could see the absolutely raw values, perhaps adding some code to serial print the tx_data.values in the "void send_rf_data()" so you can see exactly what is being passed to the rf module may show something.

Unfortunately using bytes directly into the nodes module method you cannot see the actual real values in transit , but  if you can post some emonhub.log file contents both when faulting and when behaving, or copy the log file to dropbox we can look at the byte values to see if there is anything obvious, we would need some time/date info to locate areas of interest.

Paul

Paul, I tried some of your suggestions...

tx_data.PV_usedwh_CT2 = ( tx_data.expwh_CT2 - (tx_data.wh_CT3 + tx_data.expwh_CT1))     gave the same errors as before.

tx_data.PV_usedwh_CT2 =  tx_data.expwh_CT2 - 123       gave no errors

I couldn't get the other two code suggestions to compile without other mods to the sketch but ran out of sunlight before I could get them to run.

Below are links to a log from today and also some serial output taken when the error was happening.

I checked the subtraction graph and small errors where being produced around 17:50. I'll try and save a better log tomorrow when more diversion/ errors are happening.

https://www.dropbox.com/s/x2qs9yojz5l467u/emonhub.log.1dd

https://www.dropbox.com/s/flv63lf3xbmp5xb/serial_output.txt

Paul,

Below is Dropbox link to emonhub.log from this morning when lots of errors where being produced. 

I don't understand what the log is showing. I read your explanation of how ints are transferred on another thread but don't understand how longs are transferred.

https://www.dropbox.com/s/432gayyov395ekr/emonhub.logDD

I was looking at your post from last night earlier and have spotted a few things of interest, your comment "-123 gave no errors" suggests it's the subtraction of those variables/values rather than the subtraction itself that's an issue.

The log is quite bulky and difficult to pin point errors in values so I won't look into that in too much depth until we're fairly sure that what's coming out of v3 is "suitable". Having said that I have noticed what I can only describe as a "stutter" on several occasions the same message number is resused but with different values. I would assume the message number should be unique to each frame/message.

There are several "anomolies" in the serial data but that data is "as sent" so may not be an issue. none the less the data is not useful for it's intended use because there are several instances where numbers are concatenated eg val1 = 11 val2 = 33 is displayed as a single value 1133, but that's easily fixed with some additional separators.

There is a new line occurring every 5th cycle and there is a "bump" in the values every 5th cycle, which moves across to the next Wh value every 3rd or 4th occurrence. (my guess is the case statement timing is playing a big part here)

While I haven't figured out why or how, I'm inclined to agree with Roberts opening comment about these calculations possibly being in the wrong place.

Until the sketch is acting correctly I recommend adding a print function like this

void print_rf_data()
{
  Serial.println (tx_data.msgNumber);
  Serial.print(', ');
  Serial.print  (tx_data.realPower_CT1);
  Serial.print(', ');
  Serial.print  (tx_data.realPower_CT2);
  Serial.print(', ');
  Serial.print  (tx_data.realPower_CT3);
  Serial.print(', ');
  Serial.print  (tx_data.realPower_CT4);
  Serial.print(', ');
  Serial.print  (tx_data.impwh_CT1);
  Serial.print(', ');
  Serial.print  (tx_data.expwh_CT1);
  Serial.print(', ');
  Serial.print  (tx_data.expwh_CT2);
  Serial.print(', ');
  Serial.print  (tx_data.impwh_CT2);
  Serial.print(', ');
  Serial.print  (tx_data.wh_CT3);
  Serial.print(', ');
  Serial.print  (tx_data.grosswh_CT1);
  Serial.print(', ');
  Serial.print  (tx_data.PV_usedwh_CT2);
  Serial.print(', ');
  Serial.print  (tx_data.expwh_CT4);
  Serial.print(', ');
  Serial.print  (tx_data.impwh_CT4);
)

to the end of the sketch (this is untested so may need tweaking) and a "print_rf_data()" line just before the send_rf_data() command, so that each time the data is sent it also prints an identical copy to serial. You will be able to see the real values in the serial window as they arrive in emoncms and compare then against the emonhub.log if needed.

It may help to comment out any other print statements as if it's still not clear you can copy and paste the serial output to excel if needed. also if you need to, you can temporarily have more than one print_rf_data command or move it around to locate an issue.

It's important that every wh is updated at each send as passing several increments in one or omitting values will bring the Wh logic and filter into play. any reductions at all or increases over 6.9Wh/sec will be ignored (based on default 25000).

The unsigned integer byte conversion for a byte pair 100 150 would be

100 + (150*256) = 38500

the calc for a signed int is as above but if result greater than 32768 then subtract 65536

38500 - 65536 = -27036

An unsigned long byte conversion for a byte array 100 150 200 250 would be

100 + (150*256) + (200*256*256) + (250*256*256*256) = 4194304000

the same applies to a signed long if it is greater than 2147483648 then subtract 4294967296

4194304000 - 4294967296 = -100663296

 I do think the sketch would benefit from some remedial work before delving into the byte values in emonhub.log

You appear to have 2 send_rf commands, It looks like somehow you have updated the sketch as per this commit by adding the new stuff but not removing the old.

if it was me, I would put the case statements back as they where and do all my maths in a custom function (like the print_rf_data example), then i could do the calcs where ever I put the relevant command. I would start by trying it just before the send_rf along with the print_rf.So that v3 can do its thing and then when it's ready to send do the final calcs -> print to serial -> send by rf. But that's me I'm no expert with arduino and there may well be better ways.

One benefit of this method is if you want to change/update the sketch, your sums (and print) can be copied over with minimal fuss.

Paul

Paul, thanks for taking the time to go through all that, it's given me a lot to go at. I originally had the calcs in case 100 with the msgNumber statement but I moved them when I found I was getting errors. You where right about the origin of the 2 send_rf commands I updated the sketch by eye but didn't spot the deletions.

I'll try and implement the changes asap.

I've been struggling to get the separated print function to send any legible data to serial so tidied up the serial print statements already present. 

I captured the attached serial output just before the sun was fading tonight and I think it is showing what the problem is. (The calculated fields are just before the text "samples" in the attached serial output)

The PV_produced Wh's are sometimes increasing before the diverted to immersion Wh's are clicking over to the next full Wh causing the calculated Wh values to increase temporarily before dropping back. The calculations are correct based on the serial outputs and as the Node inputs page just displays the values 'as is' they are correct too. This also explains why the Wh accumulator gave errors on the calculated fields but not on the straight Wh fields.

What I need to do now is implement some sort of ratchet function on the calculated fields in the v3 sketch if that's possible..

The serial output looks much better. I think the update frequency would of played a large part because the sketch was sending every 2 seconds and again every 10secs on top.

If you removed the older send_rf and moved the calcs out of the case then the results should be more stable and with the improved serial print output it should be easier to follow.

With a lower posting rate the fluctuation should be minimal as at a 10 second post rate the filter won't kick in unless a 69wh increase is seen (@25k default) and the "late" wh will be counted next post.

How are the results in emonCMS behaving today? are they matching the serial output?

The data values in the serial prints are printed at different times spanning a 2 second interval so the if you were to have the same steadily increasing variable as the 1st and last printed, there would be a change. 2 seconds is quite a large window for the values to change, this was the reasoning behind the "print all at once" statement and the positioning just before the rf_send was to get values relevant to the values received at emonCMS.

If there are still errors at emoncms maybe we should try and get a Serial.print function working, 

Paul

I have removed the older send_rf statement so at the moment it is only sending at 10 sec intervals.

The errors are continuing today as before.

I understand that the late Wh increases will be caught next time, but if that is causing the calculated value result to momentarily drop then the Wh accumulator will count the same increase twice thus giving the errors I am seeing won't it?

ie. 3, 3, 3,4,4,4,4 will give 1 Wh increase and 3,3,4,3,3,3,4,4 will give 2 Wh increase with the Wh accumulator.

When I tried to implement the print all at once statement I was getting approximately a ten digit number followed by a load of garbage/ symbols on each line. I'll have another try this evening to make it work.

I did some more modifications to the sketch with mixed results....

1. Separated out the serial print but again it was printing symbols, see screenshot.

2. Modified the calculation to hopefully make sure the result of the calculation never drops. This seemed to be a success but errors eventually started to show. The magnitude of the errors seemed to be much less though I only tested for two hours.

3. Then I took the new calcs outside the case statements so they are only done every 10 secs. Again errors started to show up. On checking the log to feed raw data graph I can see that the results of the calc are still dropping occasionally so the new calc is not right yet. see screenshot2

I think I may have found why the errors are showing up in the Wh accumulator feed...

I noticedthat the Wh accumulator code in process_model.php has a   "if ($val_diff>0..."     line but not a    "if ($val_diff<=0"

I've tried to added in the following line:   "if ($val_diff<=0 && $power<$max_power) $totalwh = $last_input['value'];"

Can anybody tell me if this function is correct and if not let me know the correct way of doing it.

Been testing and now realise  the line I put in the Wh accumulator code whilst completely removing the errors also stops the code behaving as an accumulator meaning a reset of the emontx also resets the Wh accumulator feeds. 

Sorry for not responding, things have been a bit hectic and I've not been about much the last couple of days.

I see what you mean about the calculation resulting in a reduction rather than just not increasing until next sample. That reduction would cause a problem I guess.

I think it will always be a possibility as the core wh calculations are spread over the 2 seconds so I guess some sort of mechanism is required if these calcs are done within the sketch. Having said that, while I totally understand the need to calc the positive and negative flows in the sketch, as net wh is not of much use, I can't help but think the calcs involving more than one feed should be done in emoncms. the feeds in the equation will have passed through wh accumulators and the difference between them should always make sense as per your original findings.

Since PV_used = produced - (immersion + exported) then pv_used is the "unaccounted for" remainder, which may actually turn out to as accurate and robust in emoncms as the wh totals in the sketch count in whole wh units and the energy flow can switch direction anytime, effectively reseting the zero time from which the whole values are counted from, plus the 2 sec spread of readings and any in-accuracy in the power readings will result in some in-accuracy in the wh totals, If each channels wh totals (imp & exp) are accurate and robust then all wh values including those calculated in emoncms should be acurate to within the changes over the last 2seconds at any given time.

We can however, still try and get the results from the v3 if thats what you prefer.

The reason your modification to process_model php causes counting to restart will probally be due to using last_input rather than last_feed, but aside from including the filter I'm not sure the line adds anything as totalwh value would already be equal to $last_feed['value'].

The spaces before the opening parenthasis could be the cause of the serial print function not working as expected (appologies if it is), You can see similar code is used in the emonTxV3_DirectSerial.ino sketch , (I also noticed that sketch only uses spaces rather than csv, I'm not so sure that matters though)

Paul

The reducing value error is caught by the kWh to kWhd processor but I realize now that modifying the Wh accumulator to do the same is not an option as it would break the Wh accumulators main function which is to preserve the data when emontx resets.

I now also realize that the "errors" are not actually errors just unwanted results caused by data used in the calc arriving sequentially like you said.

I agree that doing the calcs in emoncms based on accumulator feeds would be just as robust but setting this up is a laborious process each time emoncms needs rebuilding as each feed added or subtracted to build the calc needs removing again before the kWh to kWhd process can be added as the last process.

I have been trying to get the sketch to only forward positively incremented values for the calculated variables by comparing a variable value to a  previous variable value and am now struggling to figure out why it's still letting negatively incremented values through.

I just tried the serial.print without the spaces before the parenthesis but it's still not legible.

I agree that doing the calcs in emoncms based on accumulator feeds would be just as robust but setting this up is a laborious process each time emoncms needs rebuilding as each feed added or subtracted to build the calc needs removing again before the kWh to kWhd process can be added as the last process.

I'm not at home right now so I can't confirm this, but I think the kwh to kwh/d process has no effect on the chain, that is although the resulting feed resets each day, the next process in the chain receives the full value, so you could slot it in immediately after each wh accumulator before any calcs.

Paul

I had the calcs all set up on the  inputs of the earlier versions of emoncms but I've tried a few times now to set them up in the nodes version and gave up. I forget exactly what the problems where but it was a lot more straightforward to set up with the inputs versions of emoncms.

I'm not sure why that would be, I still use the input module rather than node module so have no in depth experience of the processing in the nodes module.

The inputs can still be used in exactly the same way as the node module is an alterative rather than a replacement,  If you prefer the input module you could try this version of emonhub  the node data you would need include in emonhub.conf for your current sketch would be 

[[10]]
  datacodes = h, h, h, h, l, l, l, l, l, l, l, l, l

This version decodes the data in emonhub and forwards the data as real numbers, so should be easier to diagnose any custom values, without print statements etc

Paul

I'm happy using the nodes input page now I've made the switch. It was a decision I put off because of not being able to import historical data, but hopefully someone will produce an import script.

For now I'm going to continue my quest to do the calculations onboard the emontxv3 and keep emoncms lean.

I moved the   Serial.print(prev_PV_usedwh_calc);  and  Serial.print(PV_usedwh_calc); statements to where they would show up what is being stored in the variables and found that nothing was being saved in prev_PV_usedwh_calc. 

I then changed the variables from long to static long and the serial output now shows the variable values being saved properly for use in the if else comparison.  The sketch now seems to be working as intended but I'll wait and see how it behaves during the day.

Good news, the sketch has worked faultlessly all day, not a single error was recorded, It looks like the issue is solved. Thanks for the help Robert and Paul.

I've attached the working sketch in case anybody else wants to use it.

Hi, thanks for this.  I wanted to do the same thing with import/export Wh totals so I've included those changes into my version of the emonTx_continuous_watthours sketch here: https://github.com/mattwire/emonTxFirmware/tree/master/emonTxV2/emonTx_continuous_importexport_watthours_V_temp

Hello im kinda new here . But i was wondering how can i get the energy reading from the power measurements. I am using the system in a Single Phase System.How do i convert the power readings to a Wh reading. 

You cannot convert from one to the other directly. They are different quantities. Power is the rate at which energy is used, in other words the rate of change - the time differential - of energy, energy (Wh) is the power integrated over time.

If you supplier's meter clocks up 3 kWh over a period of 90 mins, your average power over that period is 2 kW.

If you use power at 3 kW for 1 hour, then nothing for ½ hour, you've still used 3 kWh over that 1½ hour period.

Therefore you need to measure the power over small periods of time and accumulate the total, taking care of the units as you do so. The sketches on Github with "kwh" in the name do exactly that. You can also do the integration in emonCMS.

[If you want to continue this discussion, it would be better to start a new thread as it's completely off-topic for this one.]