EmonGLCD sketch issues

pb66 · 2019-01-13T18:13:31.347Z

Just having a quick look at the emonglcd sketch and the datacodes

datacodes =b,b,b,h,h,H,H

show an 11byte payload is expected, am I looking at the right page? GitHub - openenergymonitor/EmonGLCD: Wireless graphical LCD display unit

or have you modified it at all? just wondering where the “12bytes” size comes from.

[edit - ok, so the typedef struct seems to want a 12byte payload afterall,

github.com

openenergymonitor/EmonGLCD/blob/master/firmware/SolarPV/SolarPV.ino#L77-L80

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

is it the readme that’s wrong? what do you have defined in your emonhub.conf?]

pb66 · 2019-01-13T19:26:03.341Z

I’m trying to work through the code but I’m struggling a bit. AFAICT you should also see a

node = 20 node_data = ???

type message in the log,

github.com

alandpearson/emonhub/blob/96d8fe246244a2dc85216ae008ba36a05329697a/src/interfacers/EmonHubJeeInterfacer.py#L243

    
      
          
          

          

          
def _process_post(self, databuffer):
              """Send data to server/broker or other output
          
          
    """
          
          
    for i in range(0,len(databuffer)):
                  frame = databuffer[i]
                  self._log.debug("node = " + str(frame[1]) + " node_data = "+json.dumps(frame))
                  self.send(frame)
          
          

          
    return True
          
          

          
def send (self, cargo):
          
          
    f = cargo
              cmd = "s"

although the message would in fact not be totally accurate as the “node id” would appear in both the “node =” and the “node_data =”, it would give us some indication of whether/how the packets are being processed. I’m starting to suspect the encoding is happening as part of the MQTT interfacer rather than the Jee interfacer, but I can’t be sure. The content of this log message would help.

However!

The message that we do see is triggered at a point in the code that I would be surprised if it didn’t get sent.

github.com

openenergymonitor/emonhub/blob/6f1cb07c7330c2b6d5a8b285a434099ce10ab006/src/interfacers/EmonHubJeeInterfacer.py#L269

    
      
          
          
payload = ""
          for value in data:
              if int(value) < 0 or int(value) > 255:
                  self._log.warning(self.name + " discarding Tx packet: values out of scope" )
                  return
              payload += str(int(value))+","
          
          
payload += cmd
          
          
self._log.debug(str(f.uri) + " sent TX packet: " + payload)
          self._ser.write(payload)

and given the content appears correct, why is it not confirmed as sent or received? And how doers it reach that point without the former log message?

Can you please post a longer section of emonhub.log so we can see the payloads whole journey through emonhub? Please include a section long enough to be able to rule out slow or incorrectly ordered log messages as the interfacers are threaded and the order the log messages are printed can seem odd occasionally.

Robert.Wall · 2019-01-13T21:03:00.860Z

Robert.Wall:

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.

@pb66
The debugger sketch is totally indifferent to the source, destination, length or make-up of a message. Provided it is on the correct frequency and in the right group, it will be displayed. So if @moojuiceuk isn’t seeing anything with that, I’m confident it is not being transmitted.

pb66 · 2019-01-13T21:16:50.300Z

I’m not sure I’ve said anything contrary to that have I? The information at hand doesn’t even confirm the payload is being sent serially to the emonpi let alone over the air. My debugging has focused on the path through emonhub and to the emonpi board. The node id length and make-up of the message could well stop it in its tracks way before transmission, as it appears to be. The emonpi should just send the string of bytes ending in an “s”, regardles of the make up too, so either the payload is not exiting emonhub or the emonpi is not sending or even confirming receipt.

Robert.Wall · 2019-01-13T21:24:08.935Z

No - but I got the impression that you weren’t sure what it was capable of, and I wanted to clarify that. All I’m saying is you can, for now, rule out the GLCD sketch itself as the source of the problem. That’s not to say it cannot become a problem once the RFM69 launches something into the ether.

alandpearson · 2019-01-16T12:20:45.101Z

Hi Folks,

I’m the guilty one who provided the new emonglcd firmware and helper programs to run on emonpi.
I can assure you it all works.

some comments when using with emonpi - disable the time sending from emonpi ie. comment out the 'interval = ’ line in emonhub.conf. The time is sent as part of the packets by the helper program.

Please have a read here and see if that helps.
Ensure you edit emonglcd-send.cfg and set the mqtt_topics and mqtt_hostname appropriately.

The only change you should have to make in the code on the emonGLCD itself (assuming you are using my solarPV.ino sketch) is to #undef EMONTX and #define EMONPI <emonpiNodeid - normally 5>

Finally, ensure you are using the latest and greatest emonhub software on the emonpi itself - I submitted a patch to enable Tx a month or so ago. Update the emonPi and it should have that patch.
Also, apply the correct config (as in the readme from the link above) for your emonGLCD to emonhub,conf

Regarding the comments about ‘whole numbers’ - the sketch has been written so we don’t have to deal with floating point numbers. Send whole numbers only and the sketch divides them by the relevant multiplier to turn them into floats.

Please give that a go and post back here.

Robert.Wall · 2019-01-16T14:11:58.998Z

alandpearson:

I’m the guilty one who provided the new emonglcd firmware and helper programs to run on emonpi.
I can assure you it all works.

For a start, it would have been helpful if you’d actually told people you’d changed everything, instead of sneaking it in and expecting everyone to have a crystal ball.

Then if you’d properly documented what you’d done, you wouldn’t have wasted a lot of time for the people who were trying to help @moojuiceuk.

alandpearson · 2019-01-16T19:06:31.427Z

Sorry Rob and all.

It wasn’t sneaked in, an announcement was made with Trystan and Glyn both aware including updating the docs…

I’ve been snowed under or would have picked this up quicker.

Does it work now ?

Alan

moojuiceuk · 2019-01-17T23:46:14.814Z

Hi

Just had a chance to look at this again this evening and still having no success. As I have no solar PV, just a single CT for a 1phase supply, I just want to be able to display that for now on the GLCD.

The Pi is “emonSD-07Nov16” but on EmonCMS low-write 9.9.5.

I have updated the emonglcd-send.cfg as follows:
#mqtt params
mqtt_hostname: 127.0.0.1:1883
mqtt_user: emonpi
mqtt_pass: emonpimqtt2016

#mqtt topics for publishing
mqtt_pub_topic: emonhub/tx

#mqtt topics for subscribing to
#mqtt_sub_solarW:emon/emonpi/power2
#mqtt_sub_solarKwh:emon/samilpower/ETODAY
mqtt_sub_utilityW:emon/emonpi/power1corrected
mqtt_sub_utilityKwh:emon/emonpi/use_kwh

#CSV list of RF IDs of emonglcd displays
emonglcd_nodeid:20

My emonhub.conf file has:
[[20]]
nodename = emonglcd
firmware =V1_1
hardware = emonglcd
[[[rx]]]
names = temperature,
datacodes = h
scales = 0.01,1
units = c
[[[tx]]]
names =nodeid,hour,minute,second,utilityW,solarW,utilityKwh,solarKwh
datacodes =b,b,b,h,h,H,H
units = h,min,sec,W,W,kwh,kwh

The interval = line has been commented out now.

Within NodeRed, I have used the supplied file from here: EmonGLCD/emonglcd_updater_nodered.json at master · openenergymonitor/EmonGLCD · GitHub
Corrected the “Utility kW” input to emon/emonpi/power1corrected and “Utility kwh” input to emon/emonpi/use_kwh. Username & password set correctly and looking at “localhost:1883” as a server. When deployed, there is no output to the debug

As a test, I have set up an “Inject” input of an empty string, injecting every 10 seconds into a “function http request” that fetches every 10 seconds from “http://127.0.0.1/emoncms/feed/value.json&apikey=my read only key&id=22” then it fetches the emon/emonpi/power1corrected feed values correctly. I have done the same thing for emon/emonpi/use_kwh which is “http://127.0.0.1/emoncms/feed/value.json&apikey=my read only key&id=8”.
It’s hacky, but it seems the only way I can fetch these two feeds. An example of the output of these two HTTP fetches are: 559.545 for emon/emonpi/power1corrected and 6387.7614416546 for emon/emonpi/use_kwh. These are fed into the “convert to watts & store” and “convert to int & store” functions already provided.

When these two are fed into the provided NodeRed sketch, I get an output on the debug line as: 23,24,23,750075,0,638764.02981548,0 and an error from EmonHub as:

2019-01-17 23:24:19,120 DEBUG    MQTT       Publishing: emon/emonpi/power1 685
2019-01-17 23:24:19,122 DEBUG    MQTT       Publishing: emon/emonpi/power2 0
2019-01-17 23:24:19,123 DEBUG    MQTT       Publishing: emon/emonpi/power1pluspower2 685
2019-01-17 23:24:19,125 DEBUG    MQTT       Publishing: emon/emonpi/vrms 231.71
2019-01-17 23:24:19,126 DEBUG    MQTT       Publishing: emon/emonpi/t1 18.1
2019-01-17 23:24:19,128 DEBUG    MQTT       Publishing: emon/emonpi/t2 18.5
2019-01-17 23:24:19,129 DEBUG    MQTT       Publishing: emon/emonpi/t3 0
2019-01-17 23:24:19,130 DEBUG    MQTT       Publishing: emon/emonpi/t4 0
2019-01-17 23:24:19,131 DEBUG    MQTT       Publishing: emon/emonpi/t5 0
2019-01-17 23:24:19,134 DEBUG    MQTT       Publishing: emon/emonpi/t6 0
2019-01-17 23:24:19,137 DEBUG    MQTT       Publishing: emon/emonpi/pulsecount 55369
2019-01-17 23:24:19,140 INFO     MQTT       Publishing: emonhub/rx/5/values 685,0,685,231.71,18.1,18.5,0,0,0,0,55369
2019-01-17 23:24:19,142 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 0 0 0 0 0 0 32 0 0 32 0 16 0 0 32 0 0 32 0 32 (-108)
2019-01-17 23:24:21,756 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 32 32 0 0 0 0 32 0 0 32 0 16 0 0 32 0 0 32 0 32 (-106)
2019-01-17 23:24:22,464 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 32 0 0 0 0 0 0 32 0 32 32 0 0 32 32 32 0 32 32 0 (-109)
2019-01-17 23:24:23,359 DEBUG    MQTT       Nodeid: 20 values: 23,24,23,750075,0,638764.02981548,0
2019-01-17 23:24:23,360 DEBUG    MQTT       105160 Sent to channel' : ToRFM12
2019-01-17 23:24:23,482 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

2019-01-17 23:24:23,657 WARNING  MainThread RFM2Pi thread is dead.
2019-01-17 23:24:23,659 WARNING  MainThread Attempting to restart thread RFM2Pi (thread has been restarted 5 times...
2019-01-17 23:24:23,660 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2019-01-17 23:24:23,662 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2019-01-17 23:24:25,674 INFO     MainThread RFM2Pi device firmware version: [emonPi.29.00]
2019-01-17 23:24:25,674 INFO     MainThread RFM2Pi device current settings:  E i5 g210 @ 433 MHz q0 USA 0 
2019-01-17 23:24:25,675 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2019-01-17 23:24:26,677 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2019-01-17 23:24:26,678 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2019-01-17 23:24:26,682 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0
2019-01-17 23:24:26,787 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 0 0 0 0 0 0 0 32 0 32 32 0 0 32 32 32 0 32 32 0 (-107)
2019-01-17 23:24:27,419 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 0 32 32 0 0 0 0 32 16 128 0 32 0 0 32 0 4 32 0 0 (-109)

I’m still running the debug sketch on GLCD and node 5 never transmits. I make the assumption here that my use_kwh feed raw data number of 6387.7614416546 as an example is still causing the transmission to fail due to the sheer number of decimal points so I try another test.

I have fashioned a corrected packet without the decimal points 23,42,45,750075,0,638764,0 that is sent into the msg.payload part of the NodeRed example. This too manages to trigger a crash of Emonhub:

2019-01-17 23:43:00,460 DEBUG    MQTT       Nodeid: 20 values: 23,42,45,750075,0,638764,0
2019-01-17 23:43:00,461 DEBUG    MQTT       105471 Sent to channel' : ToRFM12
2019-01-17 23:43:00,651 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 0 0 32 33 128 52 225 0 2 0 0 0 0 114 5 32 32 0 35 128 0 (-109)
2019-01-17 23:43:00,653 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

2019-01-17 23:43:00,846 WARNING  MainThread RFM2Pi thread is dead.
2019-01-17 23:43:00,847 WARNING  MainThread Attempting to restart thread RFM2Pi (thread has been restarted 19 times...
2019-01-17 23:43:00,849 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2019-01-17 23:43:00,851 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2019-01-17 23:43:02,857 INFO     MainThread RFM2Pi device firmware version & configuration: not available
2019-01-17 23:43:02,858 INFO     MainThread Setting RFM2Pi frequency: 433 (4b)
2019-01-17 23:43:03,540 DEBUG    emoncmsorg Buffer size: 9
2019-01-17 23:43:03,860 INFO     MainThread Setting RFM2Pi group: 210 (210g)
2019-01-17 23:43:04,862 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2019-01-17 23:43:05,864 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
2019-01-17 23:43:06,866 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2019-01-17 23:43:07,868 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2019-01-17 23:43:07,869 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2019-01-17 23:43:07,873 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0

At this point, I haven’t a clue what else to try and I am loathed to do a fresh install into the Pi, given that I’m on the current version of Emoncms.

pb66 · 2019-01-18T00:53:28.817Z

moojuiceuk:

names =nodeid,hour,minute,second,utilityW,solarW,utilityKwh,solarKwh
datacodes =b,b,b,h,h,H,H
units = h,min,sec,W,W,kwh,kwh

This section certainly isn’t right and I think that is what is causing the result = struct.unpack(e + b*s, struct.pack(e + datacode, value)) errors perhaps.

Each line must have the same number of entries, there are 8 names and only 7 datacodes and units.

I suspect it was intended be

names =nodeid,hour,minute,second,utilityW,solarW,utilityKwh,solarKwh
datacodes =b,b,b,b,h,h,H,H
units = id,h,min,sec,W,W,kwh,kwh

However, even with these corrections i think you will still get errors, or if you are lucky, just erratic results. The values you have passed 23,42,45,750075,0,638764,0 contains “” a value that exceeds 65536, the maximum positive range of an “h” (signed 16bit short int) is 32768, values between 32768 and 65536 will be negative (0 to -32767 “two’s compliment”). And the “638764” far exceeds the 65536 range of the “H” (signed 16bit short int). Again, I have to state that emonhub should really be coded and tested to ensure these error are handled gracefully and it should use the inbuilt scaling so that floats are acceptable and scaled/encoded accordingly.

Try using simple smaller positive integers say below 24 to get started, then once you get small values working, test the limitations with some bigger values.

moojuiceuk · 2019-01-18T01:13:12.504Z

Well I’ve given that a shot:

[[20]]
   nodename = emonglcd
    firmware =V1_1
    hardware = emonglcd
    [[[rx]]]
     names = temperature,
     datacodes = h
     scales = 0.01,1
     units = c
  [[[tx]]]
     names =nodeid,hour,minute,second,utilityW,solarW,utilityKwh,solarKwh
     datacodes =b,b,b,b,h,h,H,H
     units = id,h,min,sec,W,W,kwh,kwh

Manually injected 23,42,45,7500,0,6387,0

2019-01-18 01:03:16,916 DEBUG    MQTT       Nodeid: 20 values: 23,42,45,7500,0,6387,0
2019-01-18 01:03:16,917 DEBUG    MQTT       13 Sent to channel' : ToRFM12
2019-01-18 01:03:17,146 WARNING  RFM2Pi     13 TX datacodes: ['b', 'b', 'b', 'b', 'h', 'h', 'H', 'H'] are not valid for values ['23', '42', '45', '7500', '0', '6387', '0']
2019-01-18 01:03:17,149 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 82, in add
    self.send(txc)
  File "/home/pi/emonhub/src/interfacers/EmonHubJeeInterfacer.py", line 255, in send
    if self.getName() in f.encoded:
AttributeError: 'bool' object has no attribute 'encoded'

2019-01-18 01:03:17,345 WARNING  MainThread RFM2Pi thread is dead.
2019-01-18 01:03:17,346 WARNING  MainThread Attempting to restart thread RFM2Pi (thread has been restarted 0 times...
2019-01-18 01:03:17,347 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2019-01-18 01:03:17,350 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2019-01-18 01:03:19,361 INFO     MainThread RFM2Pi device firmware version: ?
2019-01-18 01:03:19,362 INFO     MainThread RFM2Pi device current settings:   1 0 32 0 168 80 9 0 64 0 4 0 0 100 65 48 32 96 0 41 16 (-94)
2019-01-18 01:03:19,364 INFO     MainThread Setting RFM2Pi frequency: 433 (4b)
2019-01-18 01:03:20,367 INFO     MainThread Setting RFM2Pi group: 210 (210g)
2019-01-18 01:03:21,369 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2019-01-18 01:03:22,371 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
2019-01-18 01:03:23,374 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2019-01-18 01:03:24,376 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2019-01-18 01:03:24,377 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2019-01-18 01:03:24,385 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0
2019-01-18 01:03:24,490 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0

So I think Alans original setup was right for b,b,b,h,h,H,H was correct. Going back to that config and sending smaller numbers of 23,42,45,75,0,63,0 gives this:

2019-01-18 01:08:56,576 DEBUG    MQTT       50 Sent to channel' : ToRFM12
2019-01-18 01:08:56,761 DEBUG    RFM2Pi     50 sent TX packet: 20,23,42,45,75,0,0,0,63,0,0,0,s

But no received data from Node 5 (pi) on the GLCD running debug. Ho Hum!

moojuiceuk · 2019-01-18T01:18:43.072Z

@alandpearson Can I see an example of your log files on Emonhub when you send a packet to your GLCD screen? Am I right in seeing 20,23,42,45,75,0,0,0,63,0,0,0,s for example rather than ending in 20s as @pb66 suggested?

pb66 · 2019-01-18T02:00:24.375Z

moojuiceuk:

So I think Alans original setup was right for b,b,b,h,h,H,H was correct.

It does indeed seem to prefer 7 values over 8, so the names entry in the conf must be wrong, there must be equal number of elements in names, datacodes and scales where used, unless something funky has been done to the core emonhub code.

Likewise the sketch seems to expect a 12 byte payload, you cannot expect to define a 11 byte payload in order for it to send a 12 byte payload, that just isn’t right. Something is out with the way the node is being defined and/or encoded.

moojuiceuk:

for example rather than ending in 20s as @pb66 suggested?

No. i have since looked at the sketch and it doesn’t use the node “20” as a true node id, it is just a leading value that is used to identify it’s intended for the emonglcd any payloads not beginning “20” are not used, the source node id will be 5 and the target node id is 0.

moojuiceuk · 2019-01-19T00:47:05.559Z

Well I’m still no further in. Just double checked the firmware of the pi:
Manually flashed 2.9.0 firmware to the EmonPi board with avrdude and have checked 1.4.0 is loaded for the RFM69 (thats the version sat in /home/pi/data/firmware).

As per example here:
emonhub/configuration.md at emon-pi · openenergymonitor/emonhub · GitHub under the tx section.

I have manually sent the following string from NodeRed:
14,38,34,700,138,2700,829
I see in the logs:

2019-01-19 00:35:42,749 DEBUG    MQTT       Nodeid: 20 values: 14,38,34,700,138,2700,829
2019-01-19 00:35:42,750 DEBUG    MQTT       695 Sent to channel' : ToRFM12
2019-01-19 00:35:43,030 DEBUG    RFM2Pi     695 sent TX packet: 20,14,38,34,188,2,138,0,140,10,61,3,s
2019-01-19 00:35:43,134 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0
2019-01-19 00:35:43,336 DEBUG    RFM2Pi     confirmed sent packet size: -> 12 b

Debug sketch and SolarPV sketch running on GLCD not seeing any transmission from the pi but the pi clearly hears the regular temperature readout from GLCD (when running the SolarPV sketch):

2019-01-19 00:39:13,748 DEBUG    RFM2Pi     760 NEW FRAME : OK 20 239 8 (-59)
2019-01-19 00:39:13,750 DEBUG    RFM2Pi     760 Timestamp : 1547858353.75
2019-01-19 00:39:13,750 DEBUG    RFM2Pi     760 From Node : 20
2019-01-19 00:39:13,751 DEBUG    RFM2Pi     760    Values : [22.87]
2019-01-19 00:39:13,751 DEBUG    RFM2Pi     760      RSSI : -59
2019-01-19 00:39:13,752 DEBUG    RFM2Pi     760 Sent to channel(start)' : ToEmonCMS
2019-01-19 00:39:13,752 DEBUG    RFM2Pi     760 Sent to channel(end)' : ToEmonCMS
2019-01-19 00:39:13,848 DEBUG    MQTT       Publishing: emon/emonglcd/temperature 22.87
2019-01-19 00:39:13,849 DEBUG    MQTT       Publishing: emon/emonglcd/rssi -59
2019-01-19 00:39:13,851 INFO     MQTT       Publishing: emonhub/rx/20/values 22.87,-59
2019-01-19 00:39:14,142 DEBUG    emoncmsorg Buffer size: 9

If I can’t get it working this weekend, I’m very tempted to say sod it, find an old Android tablet and design a custom dashboard for that. Shame as the screen is quite a natty looking thing and low power too.

moojuiceuk · 2019-01-19T01:26:22.640Z

Bingo!

I was using the recommended Jeelib v12 on my GLCD sketches. Using JeeLib from 10th Sep 2015 GitHub - jeelabs/jeelib at f097c0039c926881d80a74bec7a7aa020de610ee in my Arduino library instead has fixed it and the display has come to life!

Happy Bunny - now to send proper data rather than dummy data!

Robert.Wall · 2019-01-19T01:41:04.334Z

Hmm…
It seems like @alandpearson needs to do some more work on this.

DOCUMENT which version of emonCMS & emonHub it needs,
DOCUMENT which version of JeeLib it needs, or preferably, update his software to use the current version, and
DOCUMENT in plain English how the data is processed.

And I put the last one in because, if @pb66 can’t understand it, and given that he wrote emonHub, there’s something seriously wrong somewhere.

alandpearson · 2019-01-19T10:59:44.248Z

First, glad you got this working. Seems with my documented setup, it works… go figure.

Some comments

Robert.Wall:

DOCUMENT which version of emonCMS & emonHub it needs,

It clearly says it needs the latest versions with the TX patch added.
emonHub already has TX but for some reason, the jeeInterface did not.

Robert.Wall:

DOCUMENT which version of JeeLib it needs, or preferably, update his software to use the current version, and

This one is an issue. I discovered when updating firmware on my emonTH some months ago that using the ‘latest version’ of JeeLib made emonTH ‘deaf’. It appears to be the same issue here. My emonGLCD patch does not require anything different to the original versions, and in speaking with Glyn, for now, as for every emon* product, the openEnergyMonitor JeeLib fork should be used. For what it is worth I supplied a COMPILED firmware image that would have worked. Clearly there is something wrong with the JeeLib / RFM69 default setup, but no one has figured out what has changed to make it ‘broken’.

Robert.Wall:

DOCUMENT in plain English how the data is processed.

This too is documented pretty well. I’ve given the emonhub entry, which is correct. This is pretty self explanatory. If someone is sending random data (ie. unsigned ints or out of bounds) then emonhub crashes. That is out of my hands I think. I supplied BOTH a node red flow AND a program to send data to the display , both documented.

All in all, my patch has made the emonGLCD usable with the emonPI. The problems encountered here seem to be because the announcement was missed, documentation wasn’t read and a bug in the latest JeeLib.

I’m very happy it’s working and I hope the next user won’t have this issue.

moojuiceuk · 2019-01-19T17:22:21.754Z

In fairness to Alan, the bug in the library of JeeLib seems pretty obscure. I have NodeRed reading the feeds I want and sending them to the screen However, anything that can be done to make things work easier out of the box should be encouraged.

Going forwards - I can see another use for the screen - for those without solar PV and who are purely on-grid.

In the UK, the National Grid provide a Carbon Intensity API. This shows the UK carbon intensity in gCO2/kWh for the whole country, or for the local region along with forecasted carbon intensity and general “unplug” or “plug in” advice.

carbonintensity.org.uk

Carbon Intensity

National Grid ESO, in partnership with Environmental Defense Fund Europe, University of Oxford Department of Computer Science and WWF, have developed a Carbon Intensity forecast for the GB electricity system, with weather data provided by the Met...

All this data is available via API and looks like a good use for Node Red to scrape the data, then publish it to the GLCD screen. Perhaps making the LEDs glow RED when its a high carbon output time period and GREEN when carbon intensity is acceptably lower. There is also fuel mix generation data that could be shown - percentage of wind, nuclear, solar, biomass & hydro vs CCGT & Coal for instance.
I might have a look at this myself when I get a chance. I think the limitations in all this will be the memory contraints of the little Atmel CPU on the GLCD.

I’m sure some other countries probably have similar data available. I seem to recall the US has carbon data for each state electricity generation, but I don’t know if that is just on an annual summary basis, or live data.

alandpearson · 2019-01-19T23:23:20.985Z

Thanks MooJuiceUK.
The GLCD is an amazing little box and could do a lot more

You reminded me however that you mentioned that NodeRED wasn’t working nor was the helper program. Remember they will only update when the value changes as they both use MQTT which only posts when the value changes. Hope that helps

Alan

Robert.Wall · 2019-01-20T00:30:12.899Z

alandpearson:

The problems encountered here seem to be because the announcement was missed, documentation wasn’t read

It’s funny how three people quite independently missed or didn’t recall the “announcement” (which is just two sentences) and hence weren’t aware of any changes.