Archived Forum

If you take out the lines that change the NodeID based on the switch selection, then the nodeID will be and remain as it was initialised when the variable was created. If you want to be really sure, change the definition to be "const", which will cause an error if the code subsequently tries to change it.

Then in emonHub, you edit the config file to create a section that responds to the new nodeID. If there isn't a section that defines how the data from a node will be handled, that node is ignored.

Thanks.  In my case the problem was my emonhub.conf file for node 9 listed old firmware string and old datacode string.  Apparently emonhub will ignore the incoming transmission if ?one or both? of these are not set right.  ( It wasn't even listing the ?ignored? node 9 transmission in the debug mode emonhub log.)

Yes, emonHub will ignore ANY inconsistency in the data. Unless you use the form that is common for each field (i.e. datacode = in the singular) then the count for each must exactly match the number of data items sent.

I wrote this formal definition a few days ago, it's yet to be verified/approved by Paul (pb66), so don't rely on it being totally accurate:

[[10]]
A numeric NodeID. This identifies the node to emonHub, and every node within your system must have a unique ID. There may be only one definition for each NodeId. The NodeID is programmed into the node firmware, either in the sketch and/or by switches.

nodename =
A text string, for your benefit in identifying each node.

firmware =
A text string specifying the sketch running on the node. (At present, this is for information only. At some future time, it might be used to auto-configure emonHub and/or the sketch.)

hardware =
Indicates the host environment.

[[[rx]]]
Must be "rx"
"rx" - emonHub receives the data from this node.

names =
A comma-separated list of names identifying the meaning of the data values. There must be exactly one name for each item of data, and except where the short form is used, each name on the list must have a corresponding datacode, scale and unit specified.

datacodes =
A comma-separated list of code letters from the table. Each code letter must exactly match the corresponding data item sent by the node both in type and in its position within the list.
short form: If all data items are of the same type, "datacodes = [a list]" can be replaced by (for example) "datacode = h"
default: if nothing is specified, "datacode = h" is used. "datacodes = [a list]" will override "datacode = [one code]"

scales =
A comma-separated list of multipliers. The value received from the node is multiplied by this coefficient and passed forwards to emoncms for logging and display. e.g, a voltage received as the integer 23153 with a multiplier 0.01 is passed forwards as the floating point value 231.53 A value of 1 should be used when no scaling is to be applied.
short form: If all data items require the same multiplier, "scales = [a list]" can be replaced by (for example) "scale = 1"

units =
A comma-separated list of engineering units to describe the data. Common units are W, kW, V, A, C, %.

"If there isn't a section that defines how the data from a node will be handled, that node is ignored."

Actually it is the nodes module that ignores the data if there is no entry in emonhub.conf, emonhub will still process data without an entry in the [nodes] section of emonhub.conf, it will then publish and/or send that data to emoncms(s) but the nodes module will only process nodes that have an entry in emonhub.conf.

emonhub will not be able to pass data IF it has been specifically defined and the data received doesn't fit, the legacy method of processing all data using default values can be overridden by specifying the exact definition of the node, but if that is then not adhered to it will discard the packet as being "wrong" by the definition given.

"In my case the problem was my emonhub.conf file for node 9 listed old firmware string and old datacode string.  Apparently emonhub will ignore the incoming transmission if ?one or both? of these are not set right.  ( It wasn't even listing the ?ignored? node 9 transmission in the debug mode emonhub log.)"

The firmware version is not used or even read by emonhub as yet (future feature) it is only read and displayed by the nodes module and it has no verification process. The datacode string will cause a packet to be discarded but it will provide details of that in the log, the scales should also provide a log entry if the packet gets discarded.The names and units are not used in emonhub and have no error checks.

"emonHub will ignore ANY inconsistency in the data"

This is the appearance and may even be true in some instances for the "emonpi" variant of emonhub, I haven't tried every scenario but, emonHub is (was?) designed NOT to impose any mandatory configuration requirements whilst providing the facility to do so if the user wishes or if the application demands. emonhub should also provide in-depth logging of all steps, under no circumstance should emonhub just "ignore" data and this is true in most instances as we know emonhub.logs are probably the most valuable asset we have when debugging an emonBase and traffic from connected nodes.

Robert - Most of those definitions seem like a pretty accurate current status. The important parts are the [[node]] which must be a unique section heading in the conf and currently, yes it is closely tied with the 1-31 node ids of the rfm2pi, but the node ids can relate to any interfacer and therefore could be any number since the 32 node limit has been changed in emoncms to be a count not a max node id. In fact the nodes in emoncms no longer even need to be numbers they can be names, emonhub does currently have some filtering to accommodate the  1-31 rule but that can be removed when some node id to node name mapping is introduced.

And datacode(s), there is a basic check within emonhub to check the total data size if "datacodes" is provided so if a node of 2 longs is defined and a node of int,long,int is passed emonhub cannot tell the difference it is still 8 bytes, but the output will be very different to what is expected. So the important fact here is that the datacode array exactly matches the sketches typedef struct (payload).

If there are no datacode(s) defined then emonhub will use a default, this default can be set for the node in question by using datacode (no plural) in the nodes conf or if it is not defined there it will fall back to the interfacers default which is 'h' for the commonly used rfm2pi interfacer, but it is '0' for the serial and socket interfacers.

Scales are not yet implemented in v1.2, but in the "emonpi" variant scale(s) is pretty straight forward and applies the same scale vs scales logic but the validation is done on the number of scales equaling the number of decoded values rather than total (data)size.

The rest is pretty much (currently) eye candy for the nodes module and have no checks in emonhub, for the data to be displayed correctly in the nodes module though you would need to ensure each values datacode, scale, name and unit all align. 

The [[[rx]]] is only used in the "emonpi" version, the original version has the datacodes in the [[node]] section. and to me the [[[tx]]] and [[[rx]]] do actually seem the wrong way round, since we are defining "the node" and the nodes "tx" payload definition is labeled "rx", ie from emonhub's position not the nodes position. This may well be changed in v2 as part of a larger overhaul as the whole [nodes] section is under re-evaluation.

Paul.

Robert, I like that you describe how a field is used.  Perhaps you could also indicate how the units field is or might eventually be used?

Anyway, it will be good to have a document like this.

Thanks!!