Actually emonHub only expects the first value to be an int (c.nodeid = int(f[0])
) as that should ideally be a node id to identify the source device.
Currently emonhub is objecting to using the first value in the payload (4.54) as a node id.
A quick (backdoor workaround) fix is to just add a line to your [[[runtimesettings]]] to inject a defined node id using the nodeoffset
setting (Assuming you will only have one USB device connected) eg
[[SerialDirect]]
Type = EmonHubSerialInterfacer
[[[init_settings]]]
com_port = /dev/ttyUSB0 # or /dev/ttyAMA0 or/dev/ttyACM0 etc
com_baud = 9600 # to match the baud of the connected device
[[[runtimesettings]]]
pub channels = ToEmonCMS,
nodeoffset = 30
or alternatively you can edit your sketch to output a leading node id in the payload eg
nodeid val1 val2 val3 …
A fuller explanation
This is true for data sent over the RFM, originally the emonTx serial output was just debugging info and full of text. When the serial interfacer was created to accept the format above and relied on users to edit the emonTx sketch to output a serial payload (not debug info), more often than not users did not add the leading nodeid and seeing this error, their thinking was “emonhub should know what device it is as it’s the only device connected by the serial port” . I therefore added this backdoor method to use the existing nodeoffset setting to help with this.
The problem with the device not indicating who it is is fine if you only have one device, if (for example) you have 3 emonTx’s connected by USB, it becomes almost pot luck which device is ttyUSB0, ttyUSB1 or ttyUSB2 and emonhub can only add a nodeid to the device by address, eg ttyUSB0 will always be node 1 regardless of which emonTx is called ttyUSB0 today.
Although the emonTx FW’s now output a serial payload to work with the emonESP, it still doesn’t identify itself so this issue remains even now in the latest FW.
As for the values themselves, the scaling by 10 or 100 is something that was (originally) needed to send data over RFM, the introduction of datacodes in emonhub means this is no longer the case, but the convention has stuck. However it is not needed for serial comms (there is no real convention) as floats are totally acceptable.
You can therefore send data in “RFM format” as a string of byte values to be decoded by defining the datacodes or you can indeed send all integer values and then just scale down in emonhub or you can just send plain old float values, the choice is yours, but the datacodes and scales settings obviously need to suit your choice.