EmonGLCD sketch issues

Hardware
,
1

Hi

Just spent this evening assembling an EmonGLCD, having noticed it now supports the EmonPi.
I’ve gone to EmonGLCD/firmware at master · openenergymonitor/EmonGLCD · GitHub and found that the links to rtclib, glcdlib and maxim temp sensor libraries are broken. I assume I need all these libraries “seen” by Arduion IDE before I can compile and upload a sketch to the Arduino.

Also is there a recommended version of Arduino IDE to use and any other tips to make either the tester sketch or the main “HomeEnergyMonitor” sketch compile and upload? I’ve got very little experience with Arduino - mostly updating Marlin firmware on 3D printers which seemed to need an older version of Arduino IDE in many cases!

Also, should the backlight work when first powering up the emonGLCD, even if there is no sketch on the Arduino? My backlight is not lighting up at this point (LCD screen yet to be soldered in place).

Cheers

2

I don’t know of a reason why the latest IDE won’t work, there have been changes that made some sketches fail, but if that happens, post again with the details. I’ve just recompiled the tester sketch and there’s one warning for a redefined pin, but it still compiled, loaded and worked. The install instructions in ‘Learn’ for the Arduino IDE lists and tells how and where to put all the libraries that you need, including the ones for the GLCD. I’m not aware that those are out of date, but some might be.

The test sketch for the GLCD that’s mentioned in the assembly instructions does control the backlight. The backlight won’t work without a sketch, because it’s on a PWM output that controls the brightness.

DO NOT solder the LCD in place until you’re sure the pcb is assembled correctly and works. If you don’t keep all the legs making good contact, it can hang and you need to restart the sketch. That can easily confuse you (it did me, the first time).

3

I never realised there was an Arduino guide in the “Learn” section of this site!

I still have an issue where there are 2x libraries that are specifically needed for EmonGLCD:
RTClib https://github.com/jcw/rtclib
GLCD_ST7565 https://github.com/jcw/glcdlib
The latter seems rather important! Both are 404 errors!
Any suggestions please?

4

Try

GitHub - openenergymonitor/EmonGLCDlib: Based on JCW glcdlib for ST7565 LCD's, adapted for Vatronix LCD
GitHub - openenergymonitor/glcdlib: GLCDlib is a graphics library for 128x64 displays based on the ST7565

If they don’t work, I can upload the ones I’m using (almost certainly not up-to-date, but hey, they work).

5

Thanks for that! I’ve managed to upload a sketch that works, but found the LED backlight was not working! That was fixed by following this post: GLCD V1.5 not drawing display correctly, no backlight, no temp? - #2 by Robert.Wall

Time to solder on the LCD and get the pi sending some data to it!

Cheers :grinning:

6

Well I’m rather foxed right now! I’ve compiled & uploaded the SolarPV sketch into the GLCD and it does run. What I don’t get however is any clock update or power data.

In the sketch, I’ve set RF69_COMPAT 1 and made sure undef EMONTX is set.
(I only have an emonPi, not an emonTX). Node for the GLCD is 20, the Pi is 5. This is also reflected in my emonhub.conf file.

I’ve enabled interval = 6 within the emonhub.conf file and see a time signal within the Emonhub log output every 6 seconds. I can also see the emonglcd within “Inputs”, so I can see the GLCD temperature and rssi correctly within Emoncms. Still no current time shown on the GLCD screen!

I tried Roberts debug sketch and I can see the various EmonTH nodes transmitting and Node 5 sending its 4 byte time signal, so I know the pi is sending that time signal. It’s just SolarPV sketch that doesn’t want to play ball. I did note on another post that jeelib needs to be an older version. Tried putting the older version of jeelib library into Arduino IDE, recompiled and uploaded but still no joy! What am I missing here?

7

A deep knowledge of OEM history, I suggest! Combined with some not ideal coding practises way back in history.

Getting the time.
Look at line 154 in the GLCD sketch:

if (node_id == 15)

This hard-coded value of 15 is wrong. It needs to be what you’ve already discovered:

Pretty clear when you know where to look. :wink:

The powers:
The same goes for line 152 and

if (node_id == 10)

That needs to match the Node ID of your emonTx.
Also, take a look at lines 68 & 69

typedef struct { int power1, power2, power3, Vrms; } PayloadTX;         // neat way of packaging data for RF comms
PayloadTX emontx;

That needs to match exactly the payload that the emonTx uses to send the data to the emonPi (and no, the power comes direct from the emonTx, not via the emonPi). And that is in lines 144 - 149 in the emonTx sketch:

typedef struct {
  int power1, power2, power3, power4, Vrms, temp[MaxOnewire];
  unsigned long pulseCount;
} PayloadTX;     // create structure - a neat way of packaging data for RF comms

PayloadTX emontx;

(and you need the value of MaxOneWire too, from line 112 const byte MaxOnewire = 6;).
It doesn’t match, so your GLCD is throwing it out as rubbish. You need to copy the emonTx version into your emonGLCD sketch. You can’t use the power4 and temp[MaxOnewire] array without heavily rewriting the sketch, but they must be present even if you don’t use them.

Those changes should get you going - but I haven’t tested them.

8

How does the EmonGLCD work if:

9

Looks like it should work directly with an emonpi now, hence why I took the plunge and ordered one. Looks like it’s sold out now. Guess we won’t see any more of them in the future.

10

I was pretty sure it DOES work, but I don’t know the exact mechanism…

As @Robert.Wall indicated, normally the GLCD gets the power data via the RFM on an emonTX, and it only gets the time from the EmonPi - so maybe something needs to change in the EmonPi configuration to enable power output appropriate for the GLCD?

11

I missed that. The emonPi software needs modifying to transmit the power values. I don’t know the structure of the Pi’s front end software that well, but the time is passed through the '328P sketch, so it should be easy to modify that to incorporate the powers, rather than only sending them serially into emonHub. It’s more than a configuration change.

The big problem if you do that is, if you update the emonPi, there’s a danger you’ll lose the altered sketch.

[EDIT]
It appears that the GLCD sketches have been changed, but nobody bothered to mention it anywhere. (I’m looking towards North Wales.)

I haven’t had time to analyse the “new” GLCD sketch, but it appears it now expects, if “EMONTX” is not defined (I thought that was a mis-type, not knowing about it), a totally different message from the emonPi. This of course pre-supposes that the emonPi software is the correct version that transmits the data that the GLCD is expecting.

My tester sketch will show exactly what data is being received from the emonPi - if that fits the byte count of the new data structure

typedef struct {
  byte nodeId ;
  byte hour, min, sec ;
  int utilityW, solarW, utilityKwh, solarKwh;
} PayloadTX;         // neat way of packaging data for RF comms

which is 12 bytes by my count, then the sketch should display something. But apparently, that’s not happening

so that’s been changed too - without so much as a mention anywhere. As @Greebo suggests, there’s probably a new setting in emonHub to turn it on - somewhere.

12

I was hoping the standard time signal the pi can send would work before I get to grips with the NodeRed solution of exporting the watts and kwh usage to RFM2PI for transmission. Just playing with that bit of the puzzle now and whilst I can see NodeRed sending the time and the watts in a long string of numbers, emonhub is not happy:

2019-01-13 00:55:08,920 WARNING  RFM2Pi     Exception caught in RFM2Pi thread. Traceback (most recent call last):
  File "/home/pi/emonhub/src/emonhub_interfacer.py", line 40, in wrapper
    return f(*args)
  File "/home/pi/emonhub/src/emonhub_interfacer.py", line 123, in run
    self.add(frame)
  File "/home/pi/emonhub/src/interfacers/EmonHubJeeInterfacer.py", line 81, in add
    txc = self._process_tx(cargo)
  File "/home/pi/emonhub/src/emonhub_interfacer.py", line 576, in _process_tx
    for b in ehc.encode(dc,int(scaled[i])):
  File "/home/pi/emonhub/src/emonhub_coder.py", line 46, in encode
    result = struct.unpack(e + b*s, struct.pack(e + datacode, value))
error: short format requires SHRT_MIN <= number <= SHRT_MAX

And the GLCD is still sat there non the wiser!

13

The time and powers are sent in the one packet, so they are dependent on one another and on the whole packet being sent and received consistently. As I mentioned, it must match at both ends or the receiver - the GLCD in your case - throws it out as rubbish.

I know nothing about Nodered - a lot of people talk about it but I’ve no idea what it might be useful for. The power values and radio transmission are all, or should be, contained within the ATMega 328P sketch in the emonPi front end.

14

So, I’m pretty convinced the issue is with how Emonhub & RFM2Pi accepts injected commands from NodeRed. If I am using real world data with any decimal points, then that data causes Emonhub’s RFM2Pi to crash out.

Example:

2019-01-13 12:25:49,314 DEBUG    MQTT       Nodeid: 20 values: 12,25,22,498.225,0,6335.8210548683,0
2019-01-13 12:25:49,315 DEBUG    MQTT       10127 Sent to channel' : ToRFM12
2019-01-13 12:25:49,513 WARNING  RFM2Pi     Exception caught in RFM2Pi thread. Traceback (most recent call last):
  File "/home/pi/emonhub/src/emonhub_interfacer.py", line 40, in wrapper
    return f(*args)
  File "/home/pi/emonhub/src/emonhub_interfacer.py", line 123, in run
    self.add(frame)
  File "/home/pi/emonhub/src/interfacers/EmonHubJeeInterfacer.py", line 81, in add
    txc = self._process_tx(cargo)
  File "/home/pi/emonhub/src/emonhub_interfacer.py", line 576, in _process_tx
    for b in ehc.encode(dc,int(scaled[i])):
ValueError: invalid literal for int() with base 10: '498.225'

2019-01-13 12:25:49,666 WARNING  MainThread RFM2Pi thread is dead.
2019-01-13 12:25:49,668 WARNING  MainThread Attempting to restart thread RFM2Pi (thread has been restarted 2 times...

If I manually craft a string of numbers within NodeRed with no decimal point (not sure how to take a number and strip off any decimal points as a function…) and send that to emonhub/tx/20/values via MQTT then I get this log:

2019-01-13 12:24:37,407 DEBUG    MQTT       Nodeid: 20 values: 12,20,10,624,0,6335,0
2019-01-13 12:24:37,407 DEBUG    MQTT       10105 Sent to channel' : ToRFM12
2019-01-13 12:24:37,409 DEBUG    MQTT       Publishing: emon/emonglcd/temperature 23.12
2019-01-13 12:24:37,410 DEBUG    MQTT       Publishing: emon/emonglcd/rssi -61
2019-01-13 12:24:37,412 INFO     MQTT       Publishing: emonhub/rx/20/values 23.12,-61
2019-01-13 12:24:37,542 DEBUG    RFM2Pi     10105 sent TX packet: 20,12,20,10,112,2,0,0,191,24,0,0,s

So the reason my GLCD is still not responding is that RFM2Pi is mangling that string of numbers up as it pleases and the GLCD sees too many bits of info and rejects it?

[Edit] Using Roberts debug stetch, the GLCD doesn’t appear to pick up any transmissions from the pi on node 5, despite the TX packet 20,12,20,10,112,2,0,0,191,24,0,0,s being sent in the pi’s logs. Very odd! If I enable time signals from the pi, those do come through however, but they are not the time signals we’re now looking for, given the SolarPV sketch expects time and wattage data in the one transmission.

@alandpearson or @TrystanLea can you give your input on this, given the recent experience of the changes made? Cheers :slight_smile:

15

The logs state the nodeid is 20

2019-01-13 12:24:37,407 DEBUG    MQTT       Nodeid: 20 values: 12,20,10,624,0,6335,0

can you see a packet from node 20?

16

@pb66

Node 20 is the GLCD when running the SolarPV sketch. The debug sketch, which is receive-only, runs on the GLCD,and that’s apparently only seeing the 4 bytes of the time in the earlier format (hrs & mins as integers).

It looks to me as if the emonPi isn’t sending the correct length of radio packet - irrespective of the contents thereof.

I think the way @moojuiceuk has phrased this might be misleading you:

because it conflicts with

back in post no.5, so I think he means the TX packet is appearing in the log, as there seems to be evidence it’s not actually being sent.

17

Further testing…

The standard time signal seems to be intermittant. It is received, but only once in a while. I have set the update frequency to 5 seconds rather than 1 minute or longer and it clearly isn’t being received by GLCD every 5 seconds. It was the other evening when I tested, but not today. Ive moved the GLCD right next to the Pi - makes no difference, so it is not a range issue. I can see the log data thinks the time signal is going every 5 seconds however.

I know the only thing that is different, is that my EmonPi had been updated to 9.9.5 last night in desperation. It was on a release about 10-12 months old prior to this. Im sure the RFM69 module on the Pi was also updated at this time too in the process.

18

What does the tester sketch say now about the Node 5 message - its length & content. If it is the “new” format, it should be 12 bytes long:

typedef struct {
  byte nodeId ;
  byte hour, min, sec ;
  int utilityW, solarW, utilityKwh, solarKwh;
}
19

When I try to send that, I get the log:

2019-01-13 15:15:05,094 DEBUG    MQTT       Nodeid: 20 values: 15,13,14,50,0,63,0
2019-01-13 15:15:05,095 DEBUG    MQTT       1282 Sent to channel' : ToRFM12
2019-01-13 15:15:05,195 DEBUG    RFM2Pi     1282 sent TX packet: 20,15,13,14,50,0,0,0,63,0,0,0,s
2019-01-13 15:15:05,399 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0

But the screen does not see any message from node 5 running the debug sketch.

20

That strongly suggests that while the correct packet is being sent towards the RFM2Pi, nothing is actually being transmitted. What happens inside the emonPi is outside my area of expertise, so there’s not much more I can do to help.

I’d suggest you keep the debugger sketch in your GLCD until you see a 12-byte packet from Node 5, with numbers that look reasonably sensible.