But the point is, although it was part of the payload struct at both ends, the two structs were different sizes, and it wasn’t in the same place.
The struct(data structure) assembles those integer (2 byte) variables into a single entity, in that order, that is 14 bytes long. They travel over the air as single pieces of data, like links in a chain, coming out in the GLCD in the same order, and in the same relative place. In the GLCD sketch, you need a matching struct to get the right pieces into the right variables. The struct you had didn’t stretch as far as Vrms, it was only 8 bytes long, so to get ‘Vrms’ into the GLCD, it needed to be in the position where ‘app2’ is in the emonTx sketch. So although all the data was being received by the GLCD, ‘Vrms’ wasn’t in the right place.
This is how I’ve changed it:
//---------------------------------------------------
// Data structures for transfering data between units
//---------------------------------------------------
typedef struct { int power1, power2, power3, sp1, sp2, sp3, Vrms; } PayloadTX;
// These map to{ int power1, app1, power2, app2, power3, app3, Vrms; }
//power1 = grid, power2 = not used, power3 = solar, Vrms = nains voltage consuming = grid + solar
PayloadTX emontx;
So you can see there that ‘power1’ appears as itself, and ‘power2’ comes out as ‘power3’. If you ever put a value into ‘app1’ in the emonTx, it will appear as ‘power2’ in the GLCD, likewise ‘app2’ will appear as ‘sp1’, ‘power3’ will appear as ‘sp2’ & ‘app3’ will appear as ‘sp3’. And finally, ‘Vrms’ is available (as itself) and appears in the sketch. Temporarily, I’ve put it on the clock page until you tell me where it wants to go.
It’s quite OK to use the same name for something that’s transient and only required for a brief period. As soon as you use it the next time and write a new value to it, as you do with ‘itoa( )’, the previous contents are overwritten and gone forever. There’s no need to try to “erase” it.
