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?