EmonGLCD sketch issues

Hardware
,
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.

21

Ahh ok! The logging in emonhub for this isn’t very helpful, that is possibly due to the awkward way the jeelib library has historically been used in OEM. Looking closer at it the “Node id 20” in the log is actually a little misleading in this instance.

When receiving, the following print out occurs in emonhub.

2017-10-24 18:31:00,652 DEBUG    RFM12Pi    55861 NEW FRAME : OK 10 15 1 0 0 0 0 238 94 (-75)
2017-10-24 18:31:00,655 DEBUG    RFM12Pi    55861 Timestamp : 1508866260.65
2017-10-24 18:31:00,656 DEBUG    RFM12Pi    55861 From Node : 10
2017-10-24 18:31:00,657 DEBUG    RFM12Pi    55861    Values : [271, 0, 0, 24302]
2017-10-24 18:31:00,657 DEBUG    RFM12Pi    55861      RSSI : -75

[borrowed from Zero power readings in EmonCMS during the morning? - #3 by Vster]

the node id is clearly marked “from” and is derived from the node id set in the sending code, not the payload (although that node id is added to the front of the payload in the serial output between the emonpi and emonhub, it is not part of the transmitted “payload” per se, but part of the the rfm packet config). it is unclear what “node id 20” actually meant, but it is formally neither the source or the target node id in strict jeelib terms. It is actually just the first byte of the payload and that may( or may not?) be used by the glcd sketch to identify the payload?

If 20,12,20,10,112,2,0,0,191,24,0,0,s is passed to the emonpi (assuming it too follows jeelib correctly) it should transmit a “broadcast” to node 0 due to the trailing “s”, this is the equivalent of 0s, likewise 30s would be transmitted for the attention of node 30, the absence of a number after the last comma before the “s” is assumed to be “0”, hence the command string is actually seen as 20,12,20,10,112,2,0,0,191,24,0,0,0s, all OEM stuff historically uses broadcasts (ie sent to node 0), which is why the first byte of the payload is being used instead in glcd. The source node id is automatically defined in the sent packet by the rfm config, (node id or in this instance baseid, “5”).

As for the outgoing bytes, they should be defined by another datacodes entry in the nodes section of emonhub.conf, this is where the confusion may be because the emonGLCD should be defined in there as node 20 and rather than broadcasting the payload for all nodes to see, the payload should be sent to node 20 ie the payload should be 12,20,10,112,2,0,0,191,24,0,0,20s, this would allow emonhub (if coded correctly) to encode the human readable decimal numbers to bytes as defined in node 20, and the emonGLCD sketch to only act on packets aimed at it specifically, after all, that’s the only payloads it would know how to decode.

I have not looked at the code (emonhub or the emonGLCD sketch) so I cannot comment on what the actual current position is. The ability to send in this way was already in the experimental version, but removed for the emonpi variant, then a different method was put forward but not implemented, then the latest code was merged without much discussion, so without delving into the code I have no idea if the development has gone full circle or continued on a different trajectory.

The ability to pass decimal is essential, and regardless of whether it can or can’t pass decimal, it should not crash out if a decimal value is encountered, so that bit is a bug for sure.

I’m not convinced, you might be right, but there is no confirmation. The

2019-01-13 15:15:05,399 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0

doesn’t mean the packet was sent (or possibly even received) by the emonpi

what you should see printed in emonhub.log is confirmation that the emonpi board has received the command to send eg

2016-09-19 14:49:43,170 DEBUG RFM2Pi RFM2Pi broadcasting time: 14:49
2016-09-19 14:49:43,279 DEBUG RFM2Pi acknowledged command: > 0,14,49,0,0s

[borrowed from GLCD time with RFM12Pi V2]

and then the size of the outgoing payload as confirmation it was sent, unfortunately I cannot find an example of that, but I would expect the above example to then show a line like

2016-09-19 14:49:43,279 DEBUG RFM2Pi confirmed sent packet size:  ->4b

or close to that.

that reaction is derived from this bit of code in emonhub.

the emonpi would pass a confirmation something like ->12b and emonhub would print something like “confirmed sent packet size: ->12b” (for a 12 byte payload. Those 12bytes would in this instance seem to include the leading “20” and all the trailing zero’s as the actual source node id of “0” is assumed by the lone “s”, so the size appears to be correct in the log excerpt if 12 bytes are expected by the glcd sketch.

Is there any other log entries after/aside from the device settings updated: E i5 g210 @ 433 MHz q0 USA 0 message?

22

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?]

23

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.

24

@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.

25

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.

26

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.

1 Like
27

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.

28

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.

1 Like
29

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

30

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 :cry:

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.

31

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.

32

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!

33

@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?

34

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.

35

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.