Archived Forum

It probably won't have been done, but it's not difficult, it just needs a big chunk of patience tracking the variables through the system to the GLCD and to where/how they are displayed.

But first, why did your emonTx 'die' when you loaded the 'continuous' sketch? The ac power supply is deliberately limited in order not to disrupt the ac waveform that it is measuring, so using a separate 5 V dc supply should have removed that problem completely. So it was more likely a configuration setting that stopped it. The likeliest revolve around the radio: did you select 868 MHz and did you get the correct RFM module ("#define RF69_COMPAT 0" for the RFM12B or "#define RF69_COMPAT 1" for the RFM69CW)

Your starting point is the "Tx_struct" in the emonTx sketch. You need to copy that into the GLCD sketch to ensure that the transmitted data is interpreted correctly. If the names are different (as in the 'continuous' sketch), you can either rename the variables in the 'struct' to keep the names used in the GLCD sketch, or rename them throughout the GLCD sketch and keep the names used in the emonTx sketch. See the BB article "RFM12B - Part 2..." about how the data is transmitted for the reasoning and background info. (You might need to edit your Pi's configuration too, to match that.)

Did you find the write-up on the GLCD software - it's attached to the "Solar_PV" sketch so presumably you have? What you'll probably want to do, rather than using the temperature display directly (which is only updated relatively slowly), is to put the CT4 power into the same place on the screen but update it along with the main display, i.e. in the 'fast' loop. To do that, You'll probably want to do as is done with the other powers around line 170 (i.e. accumulate kWh - but see below), then you'll need to add CT4 power to the parameter list passed into draw_solar_page (and remove the temperatures that you don't need any more), and then in the templates file, you need to convert the number to a string and write it to the correct place, following the example of the other powers.
[Don't be tempted to just use temperature and not rename it to power - you'll trip yourself up when you forget at some time in the future!]
One more point: the GLCD History does its own accumulation, so you might want to change that to use the values from the emonTx if/when you get the 'continuous' sketch working.

One final warning: the sketch uses pretty much all of the available memory, so if it fails after you've added things, you'll need to remove unused stuff (e.g. the installation 'type' you're not using).

Thank-you Robert, for your detailed answer, very much appreciated.

When I said dead, I was expecting the Red Led to start flashing. Thinking back, I did not try the Ardunio Serial Monitor. Computer not near the Consumer Unit.

Can a 5V psu just be plugged in, or is there any links, switches or software to be changed?

Yes, I had set   "#define RF69_COMPAT 1" for the RFM69CW, and the frequency to 868MHz.

With the "emonTxV3_4_DiscreteSampling" sketch  working with only these two changes, I was probably expecting "emonTxV3_4_continuous_kwhtotals" to do the same. Armed with the pointers you've given me, I will certainly  be giving it another go.

Re  emonGLCD. I am very pleased with it, even if a little late to the party. Hopefully I will not have to go down the route of changing the sketch. I take your point about the units.

John.

The 'continuous' sketch does not flash the LED, so it may well have been working, but (depending on what you're doing with your RPi) the data might have been rejected.

The serial output is:

----------------------------------
Sketch ID:  emonTxV3_continuous_kwhtotals_noeeprom.ino
ADC mode:       free-running
Extra Features: none
powerCal_CT1 =      0.2619
phaseCal_CT1 =      0.22
powerCal_CT2 =      0.2619
phaseCal_CT2 =      0.41
powerCal_CT3 =      0.2619
phaseCal_CT3 =      0.60
powerCal_CT4 =      0.0478
phaseCal_CT4 =      1.25
----
voltage thresholds long:
  upper: 64000
  lower: -64000
Go!
samples per mains cycle = 57.67 
3:0, 0:0, 0:0, 0:0, samples per mains cycle = 38.43 
2:0, 0:0, 0:0, 0:0, samples per mains cycle = 38.43 
1:0, 0:0, 0:0, 0:0, samples per mains cycle = 38.43 

... etc. (Power:Wh per channel × 4)

The 'discrete' and 'continuous' sketches are completely different, so don't expect too many similarities. The 'continuous' is Robin's work and is essentially the same sketch as is derived from and has much in common with the diverter.

You should remove the link at the end of the battery holder if you're using a 5 V supply with your V3.4.

Mine seems to work at ~250 V with the ac adapter, but at full rf power, operation below 230 V isn't guaranteed.

At least I can see now why it didn't work.

Now I have to decide the best place to make the changes.

Thanks for your help.

Some progress made, thanks.

Installed the 3.4 continuous monitoring, as standard apart from frequency.

Serial Monitor  came out as per your printout. So emonTx was working.

I'm getting  some readings but not always where I expect them.

emonTx   Nchanges made to structure

 typedef struct {
   unsigned long msgNumber;
   int realPower_CT1;
   int realPower_CT2;
   int realPower_CT3;
   int realPower_CT4;
   long wh_CT1;
   long wh_CT2;
   long wh_CT3;
   long wh_CT4;
} Tx_struct;    // revised data for RF comms
Tx_struct tx_data;

EmonHub

[[10]]
    nodename = emonTx_1                                     # changes for continuous kwhtotals
    firmware =emonTxV3_4_continuous_kwhtotals   #V1_6_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:OFF)
    [[[rx]]]
        names = realPower_CT1, realPower_CT2, realPower_CT3, realPower_CT4, wh_CT1, wh_CT2, wh_CT3, wh_CT4,
       #datacode = h
       datacodes = L, h, h, h, h, l, l, l, l
       #scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1 #Firmware V1.6
       units =W,W,W,W,wh,wh,wh,wh            #units =W,W,W,W,V,C,C,C,C,C,C,p      
       #scales = 1,1,1,1,0.01,0.1    #Firmware =<V1.4 (un-comment)
       #units =W,W,W,W,V,C         #Firmware =<

The results I get in Nodes are:-

Nodes result
Name: emonTx_1
Node id: 10
Node key: emonTx_1
Node hardware: emonTx_(NodeID_DIP_Switch1:OFF)
Node firmware: emonTxV3_4_continuous_kwhtotals

Rx Variables
Rx ID     Name     Last updated     Value     
1     realPower_CT1     3s ago     1461 W     
2     realPower_CT2     3s ago     -13 W     
3     realPower_CT3     3s ago     366 W     
4     realPower_CT4     3s ago     0 W     
5     wh_CT1     3s ago     0 wh     
6     wh_CT2     3s ago     150 wh     
7     wh_CT3     3s ago     142 wh     
8     wh_CT4     3s ago     0 wh     
9         3s ago     0     
Tx ID     Name     Last updated     Value     

 CT1 value rises all the time

Could you tell me if the Node data is correct, please?

You've lost count of the data items! Where is the name and the units for the message number? So everything is out of step. A clue is that CT1 value rises all the time, then surely that is (part of) the message number, not CT1 power. Message number is a tally to allow missing transmissions to be identified (check the code for what it actually is, I can't remember without checking). It is NOT the NodeID.

And DON'T DOUBLE-POST. I only have to compare both, then delete one or the other. The reason you didn't see it is under "Site Map" > "Read this before posting".

sorry