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,
is it the readme that’s wrong? what do you have defined in your emonhub.conf?]
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,
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.
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.
@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.
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.
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.
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.
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.
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
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.
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.
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!
@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?
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.
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.
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.
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! 
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.
First, glad you got this working. Seems with my documented setup, it works… go figure.
Some comments
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.
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’.
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.
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.
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.
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
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.