Update 2015 system emonTx v3.4, emonGLCD v1.4 to add emonPi

Update 2015 system emonTx v3.4, emonGLCD v1.4 to add emonPi

I would like to update my system and add an emonPi.
While there is a great deal of usefull information and guides, when it comes to Arduino Verify/Compile I get many lines of errors. I feel sure this will be due to the libraries being wrong.

I uninstalled my old version of Arduino, and starting at the Learn section, Installed Arduino and Libraries for Ubuntu 64 bit. I am using Linux Mint 19.3. Renamed the folders as per the guide screenshot.
emonGLCD v1.4 with SolarPV sketch the links and both fail.

Updating “emonTx v3.4 with emonTxV3_4_continuous_kwhtotals” to the EmonTxV3CM [v1.7 library v2.03] produces approx 20 lines of errors,
config.ino: In function ‘void wipe_eeprom()’:
config.ino: In function ‘void readConfigInput()’:
some in emonLibCM.cpp and more in rfm.ino
But after these errors it produces a downloadable file, so can these errors be ignored?

Most of my problems are solved by a google search of your site, but on this occasion I would appreciate a list or pointer to the correct versions of the required libraries.

and the GLCD library is available on the OEM GitHub.

@Gwil - another documentation update please.

I don’t understand

“emonTxV3_4_continuous_kwhtotals” and “EmonTxV3CM” are two completely different sketches, the only commonality is they’re for the emonTx V3.4. Are you saying you’ve tried to merge them? If so, I’d strongly advise reading the emonLibCM documentation and looking at the examples that come with emonLibCM as a starting point and then incorporate the necessary parts of the emonLibCM API into your old sketch.

(And note, V1.7 of the EmonTxV3CM sketch is faulty, I understand an update to V1.8 was published late yesterday. I haven’t yet checked it myself.)

What sort of errors - my crystal ball is too hot to handle today, so I can’t use it. So I can’t tell what the problem might be.

CM v1.8.0 was up yesteday.

Just as a note in case you find a problem when you update your emonTx,
I’ve found that the GLCD I bought was running the standard HomeEnergyMonitor sketch and did not support the RF whitening which was configured on my emonTx v1.4 CM.

If you’re looking to upgrade to start using the CM code you may find the same - I recommend using it though in terms of monitoring it captures fine for me.

I think if you do see this crop up, you can fix it by configuring by the rf_whitening (setting “w”) setting which was set to “2” to a different number. If you read the docs its a 1 I think but I decided to keep it set to 2 as a form of grey coding transmitted data is not a bad idea.

So instead I added the RF whitening code to the emonGLCD which is fairly trivial and I can find it out from what I had if you do come across it.

It may not affect you though but just in case I thought it might be something you come across once updated (and if not ignore it :slight_smile: )

Thankyou @Robert.Wall for the link and info.

I was not trying to merge “emonTxV3_4_continuous_kwhtotals” with “EmonTxV3CM”.
I was loading EmonTxV3CM v1.7 library v2.03, to see if it Verified/Compiled without errors, before making any changes for my setup.
The fact that it produced so many errors, but still compiled, made me think/hope, they did not matter.
I appreciate this is a community run forum, so would not expect a line by line solution for so many.
I didn’t know if errors that allowed the compilation to produce a downloadable file could be ignored.
There must be something wrong with my setup as it is. I will install afresh. Thanks.

I don’t think I believe you. If they were “errors”, it wouldn’t produce an executable version, so I think they might have been warnings, which you can probably ignore. But if you post the first couple, I’ll look. (I’m not interested in any more - they probably are generated by the first few.)

Thankyou @Tim5000, this is worth knowing about.
For some time I had been running two emonBases , separete ip address and node No., backing up one from the other as microSD cards failed/corrupted. This served me well until recently, when I lost everthing local. When I saw an emoPi shield was now available I thought it would be a good upgrade.

I’m not sure what Tim’s on about: “whitening” (it isn’t true whitening) is there to prevent the radio modules losing sync on long streams of zeros. All that’s done is each byte is xor'ed with 0x55 at each end. It’s not intended as a form of coding, much less encryption.

In the emonTxV3CM sketch, whitening has 3 values: 0 = no rf at all, only serial output, 1 = rf on, no whitening, 2 = rf on, whitened. In the emonPi/emonBase, it’s 0 = unchanged (no whitening expected), 1 = de-whitened.

You are correct @Robert.Wall, they are warnings, my mistake. Because it produced a download file the “Copy to clipboard” is not available. Screenshot of first 3, to show its in other areas, “/home/???” removed from beginning of each line.
Thanks for your interest.

On my Linux, I can copy from the Arduino window without needing to “copy to clipboard”.

But the warnings that I can read appear to be unused variables, so they need getting rid of but they shouldn’t cause a problem.

I will have to try Ubuntu, I’m on Mint 19.3, Arduino 1.8.13 . Retried, sketch window works as expected, reporting window will allow text to be highlighted, cannot copy or cut.

Good to know the warnings should not be an issue.

There’s no right-click etc, but ctrl-C works just fine:

Sketch uses 27594 bytes (85%) of program storage space. Maximum is 32256 bytes.
Global variables use 1248 bytes (60%) of dynamic memory, leaving 800 bytes for local variables. Maximum is 2048 bytes.

And the compiler warnings are all OK. They’ll get corrected eventually.

Not sure if this is applicable to the Arduino IDE, but generally, in the Linux environment,
when text is highlighted, that is the copy operation.

1 Like

I’ve found that only protected .pdf files can’t have the text copied by highlighting and ctrl-C. But they are not immune to a screenshot. A terminal window needs ctrl-shift-C.

And ctrl-shift-v does the pasting.

Indeed it does.

Thank-you @Robert.Wall and @Bill.Thomson, I’ve learnt something.
Mouse copy/paste works for me in a terminal.

1 Like

It does actually use a ‘clipboard’ (or buffer), just you don’t do anything to load it into the buffer except highlight it - just like PuTTY on my Win PC. on PuTTY a right click pastes the buffer. On Windows 10, the Powershell window works differently.

How it happens is dependent on the application rather than the OS.

That was in inverted commas to point out that I didn’t click on/execute a command labelled "Copy to clipboard”, because in that situation, there isn’t one; but not just that - I almost always still use ctrl-c & ctrl-v for copy and paste operations. Old habits die hard. Of course it’s using the Linux equivalent of a clipboard, it isn’t labelled as such. So your point is pedantic.