Simple DIY emonpi

Ok, so you have two serial ports…
One of those is connected to the Tx and Rx pins on the Pi3 GPIO header, depending on what you’ve done with bluetooth.

You need to change the SerialDirect settings to use that device and make sure your baud rate is also correct, then restart emomHub.

If you’ve done nothing with your Pi3 to disable bluetooth or swap the serial port used for bluetooth, then the Tx and Rx pins on the GPIO are connected to /dev/ttyS0. If you’ve swapped the serial ports, then the pins on the GPIO are connected to /dev/ttyAMA0

This post has a good description of the various scenarios:

Hopefully you can work out which serial port you are actually connected to, update the emonhub.conf file appropriately and you’ll be sorted.

On the emonSD/Pi the GPIO UART uses the primary serial port (/dev/ttyAMA0) due to changes made in config.txt. As that port is usually used for the emonPi or RFM69Pi add-on boards, emonhub is already configured to use that port for the [[RFM2Pi]] interfacer. That will need editing/disabling/removing to allow the new [[SerialDirect]] exclusive access.

If you intend adding RFM to your “simple DIY emonpi” it may be worth considering using a EmonHubJeeInterfacer as that has functions to control the RFM module, otherwise using the EmonHubSerialInterfacer is more straightforward.

For future ref the command

ls -la /dev/{tty{ACM,AMA,S,USB},serial}*

will return a shorter list of dev’s of interest.

Actually the only time you should need to restart emonHub is to start using updated emonhub source code following an update.

All settings are picked up just by saving emonhub.conf and changed during runtime (or at least they did in the original version) and even pulling in updates via git etc can be done whilst running, but the new code won’t be used until emonHub is restarted.

ok, I believe its trying to do something after the change. what does this mean?


2018-11-07 01:40:16,005 WARNING  MainThread SerialDirect thread is dead.
2018-11-07 01:40:16,006 WARNING  MainThread Attempting to restart thread SerialDirect (thread has been restarted 603 times...
2018-11-07 01:40:16,007 INFO     MainThread Creating EmonHubSerialInterfacer 'SerialDirect' 
2018-11-07 01:40:16,009 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2018-11-07 01:40:16,010 DEBUG    MainThread Setting SerialDirect pubchannels: ['ToEmonCMS']
2018-11-07 01:40:16,113 WARNING  SerialDirect Exception caught in SerialDirect 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 102, in run
    rxc = self.read()
  File "/home/pi/emonhub/src/interfacers/EmonHubSerialInterfacer.py", line 90, in read
    c.nodeid = int(f[0])
ValueError: invalid literal for int() with base 10: '4.54'

2018-11-07 01:40:16,212 WARNING  MainThread SerialDirect thread is dead.
2018-11-07 01:40:16,213 WARNING  MainThread Attempting to restart thread SerialDirect (thread has been restarted 604 times...
2018-11-07 01:40:16,215 INFO     MainThread Creating EmonHubSerialInterfacer 'SerialDirect' 
2018-11-07 01:40:16,217 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2018-11-07 01:40:16,217 DEBUG    MainThread Setting SerialDirect pub channels: ['ToEmonCMS'] 

The SerialInterfacer is expecting all values provided to be int’s. The value it is receiving there is a float, not an int.

int values are whole numbers only.

Normally, the emonTX sends all data as integers (usually a float multiplied by 10 or 100 to remove the decimal point). You need to match that in your input device.

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.

1 Like