# Avoiding wireless connections - EmonTX serial RPiZero solution

**URL:** <https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056>\
**Category:** Hardware\
**Created:** [11 August 2020 19:49 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056 "2020-08-11T19:49:12Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [12 October 2020 13:13 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/62 "2020-10-12T13:13:25Z")

</div>

Do you have debugging messages coming out of your emonTx?

It looks as if you might have some “human readable” output from the emonTx as well as the format (“MSG:45,Vrms:247.75,P1:0,E1:0,pulse:1”) intended for machine consumption. That’s the only way things like “ms” can be transmitted.  
“E1MSG” looks like there are some missing characters in the data. You could try reducing the baud rate on the serial connection between the emonTx and the Pi Zero.

Another thought - is the “Tx” line (actually a wrongly labelled Rx input) on the emonTx connected from your Pi Zero? That has caused trouble with non-Shop ESP8266’s in the past - but not exactly the same trouble as you’re reporting.

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [12 October 2020 13:17 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/63 "2020-10-12T13:17:01Z")

</div>

> [@](#):
>
> If you press the reset button on the TX, you will get the initial config info as well. Please post that.

Sorry, I missed this bit. Having restarted the PiZero, I pressed the Tx reset button, and this is the last bits of the emonHub log.

```auto

2020-10-12 14:12:20,058 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2020-10-12 14:12:21,062 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2020-10-12 14:12:22,065 INFO MainThread Setting RFM2Pi group: 210 (210g)
2020-10-12 14:12:23,068 INFO MainThread Setting RFM2Pi quiet: 1 (1q)
2020-10-12 14:12:24,072 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2020-10-12 14:12:25,076 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2020-10-12 14:12:25,077 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2020-10-12 14:12:25,089 INFO MainThread Creating EmonHubTx3eInterfacer 'SerialTx'
2020-10-12 14:12:25,094 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 115200 bits/s
2020-10-12 14:12:25,102 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2020-10-12 14:12:25,124 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2020-10-12 14:12:25,126 DEBUG MainThread Setting MQTT subchannels: ['ToEmonCMS']
2020-10-12 14:12:25,128 INFO MainThread Setting MQTT node_format_enable: 1
2020-10-12 14:12:25,129 INFO MainThread Setting MQTT nodevar_format_enable: 1
2020-10-12 14:12:25,141 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2020-10-12 14:12:25,145 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2020-10-12 14:12:25,148 DEBUG MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2020-10-12 14:12:25,160 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2020-10-12 14:12:25,162 WARNING MainThread Setting emoncmsorg apikey: obscured
2020-10-12 14:12:25,164 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2020-10-12 14:12:25,167 INFO MainThread Setting emoncmsorg senddata: 1
2020-10-12 14:12:25,169 INFO MainThread Setting emoncmsorg sendstatus: 1
2020-10-12 14:12:34,868 WARNING SerialTx Exception caught in SerialTx thread. Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/openenergymonitor/emonhub/src/emonhub_interfacer.py", line 32, in wrapper
    return func(*args)
  File "/opt/openenergymonitor/emonhub/src/emonhub_interfacer.py", line 99, in run
    rxc = self.read()
  File "/opt/openenergymonitor/emonhub/src/interfacers/EmonHubTx3eInterfacer.py", line 46, in read
    self._rx_buf = self._rx_buf + self._ser.readline().decode()
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 509, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

2020-10-12 14:12:34,886 WARNING MainThread SerialTx thread is dead.
2020-10-12 14:12:34,889 WARNING MainThread Attempting to restart thread SerialTx (thread has been restarted 0 times...)
2020-10-12 14:12:34,904 INFO MainThread Creating EmonHubTx3eInterfacer 'SerialTx'
2020-10-12 14:12:34,908 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 115200 bits/s
2020-10-12 14:12:41,171 DEBUG SerialTx invalid input name: 
2020-10-12 14:13:01,484 WARNING RFM2Pi Exception caught in RFM2Pi thread. Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/openenergymonitor/emonhub/src/emonhub_interfacer.py", line 32, in wrapper
    return func(*args)
  File "/opt/openenergymonitor/emonhub/src/emonhub_interfacer.py", line 99, in run
    rxc = self.read()
  File "/opt/openenergymonitor/emonhub/src/interfacers/EmonHubJeeInterfacer.py", line 85, in read
    self._rx_buf = self._rx_buf + self._ser.readline().decode()
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 509, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

2020-10-12 14:13:01,579 DEBUG SerialTx 9 NEW FRAME : MSG:1,Vrms:246.21,P1:0,E1:0,pulse:1
2020-10-12 14:13:01,605 DEBUG SerialTx 9 Timestamp : 1602508381.578269
2020-10-12 14:13:01,607 DEBUG SerialTx 9 From Node : Serial_PiZero_barn
2020-10-12 14:13:01,630 DEBUG SerialTx 9 Values : [1, 246.21, 0, 0, 1]
2020-10-12 14:13:01,632 DEBUG SerialTx 9 Sent to channel(start)' : ToEmonCMS
2020-10-12 14:13:01,635 DEBUG SerialTx 9 Sent to channel(end)' : ToEmonCMS
2020-10-12 14:13:01,643 WARNING MainThread RFM2Pi thread is dead.
2020-10-12 14:13:01,645 WARNING MainThread Attempting to restart thread RFM2Pi (thread has been restarted 0 times...)
2020-10-12 14:13:01,649 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2020-10-12 14:13:01,665 INFO MQTT Connecting to MQTT Server
2020-10-12 14:13:01,695 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2020-10-12 14:13:01,770 DEBUG emoncmsorg Buffer size: 1
2020-10-12 14:13:01,812 INFO MQTT connection status: Connection successful
2020-10-12 14:13:01,815 DEBUG MQTT CONACK => Return code: 0
2020-10-12 14:13:01,932 INFO MQTT on_subscribe
2020-10-12 14:13:03,703 WARNING MainThread Device communication error - check settings
2020-10-12 14:13:03,706 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2020-10-12 14:13:04,709 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2020-10-12 14:13:05,713 INFO MainThread Setting RFM2Pi group: 210 (210g)
2020-10-12 14:13:06,717 INFO MainThread Setting RFM2Pi quiet: 1 (1q)
2020-10-12 14:13:07,721 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2020-10-12 14:13:08,724 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2020-10-12 14:13:08,726 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']

```

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [12 October 2020 13:32 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/64 "2020-10-12T13:32:39Z")

</div>

> [@Robert.Wall](#):
>
> Do you have debugging messages coming out of your emonTx?
> 
> It looks as if you might have some “human readable” output from the emonTx as well as the format (“MSG:45,Vrms:247.75,P1:0,E1:0,pulse:1”) intended for machine consumption. That’s the only way things like “ms” can be transmitted.  
> “E1MSG” looks like there are some missing characters in the data. You could try reducing the baud rate on the serial connection between the emonTx and the Pi Zero.
> 
> Another thought - is the “Tx” line (actually a wrongly labelled Rx input) on the emonTx connected from your Pi Zero? That has caused trouble with non-Shop ESP8266’s in the past - but not exactly the same trouble as you’re reporting.

Hi @Robert.Wall - I think our messages crossed.

It could well be that I mis-wired the connection between the PiZero and the emonTx, but I am 99% sure I followed the second diagram in @pb66 's post here. [4 CT emonBase using emonTx and Pi Zero W - #17 by pb66](https://community.openenergymonitor.org/t/4-ct-emonbase-using-emontx-and-pi-zero-w/6580/17)

But I will make up a second set and see if that changes anything.

 ![2020-10-12_14_30_04](https://community.openenergymonitor.org/uploads/default/original/2X/e/e7598f067d0b710ff4694ac75a440eca1814da70.jpeg)

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [12 October 2020 13:58 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/65 "2020-10-12T13:58:06Z")

</div>

> [@haffle](#):
>
> But I will make up a second set and see if that changes anything.

I don’t think it will, and it’s pretty clear that’s not your problem. So don’t.

There’s an historical problem:  
On @pb66’s diagram, the mistake is off the diagram inside the emonTx, where the Tx and Rx pins are wrongly labelled - the emonTx’s “Tx” pin **receives** data, and its “Rx” pin **transmits** data. So Paul’s diagram is correct, but you don’t _need_ the Tx - Tx wire, the violet wire in your picture, in normal use.

The problem with the ESP8266 (different device, same purpose) was it sent unwanted data **TO** the emonTx and reconfigured it, hence that connection doesn’t exist in the shop-prepared ESP8266 conversions. Until you want to recalibrate or reconfigure your emonTx, you are only interested in one-way data - out of the emonTx (on its “Rx” pin) and into the Pi Zero on its Rx pin.

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [12 October 2020 14:13 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/66 "2020-10-12T14:13:50Z")

</div>

> [@Robert.Wall](#):
>
> It looks as if you might have some “human readable” output from the emonTx as well as the format (“MSG:45,Vrms:247.75,P1:0,E1:0,pulse:1”) intended for machine consumption. That’s the only way things like “ms” can be transmitted.  
> “E1MSG” looks like there are some missing characters in the data. You could try reducing the baud rate on the serial connection between the emonTx and the Pi Zero.

I’ll revise that - I don’t think it is the first part at all. “ms” is a legitimate part of the desired output: “Vrms”, so I think you’re looking for something that’s interrupting the data and causing the interfacer to interpret an isolated “ms” - having lost its “Vr” off the front - as another data item.

One thing you need to be aware of is if you’ve got two things inside your Pi trying to use the same port, the messages will get mixed up. That’s why Brian says to stop emonHub before you connect miniterm/minicom, and restart it when you’ve disconnected.  
So if you are talking to the emonTx via the purple wire and it replies and emonHub is still running, whatever the emonTx says will get mixed in with its normal output - not a problem for you - but emonHub will do its best to interpret the mixed-up data.

So I think your problem is either, the data is getting mixed up causing part-messages to be interpreted wrongly, or the Pi Zero is missing a few characters here and there, likewise causing the data to be mis-interpreted.

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [12 October 2020 15:40 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/67 "2020-10-12T15:40:09Z")

</div>

I have no idea why, it now looks like it is all working, but only intermittently. Trouble is, I can’t work out what causes the drop outs.

It could be physical (90 deg PiZero header soldered on by me / wires crimped badly / etc), but I have even swapped in a Raspberry Pi 4 with pre-soldered headers and shop bought wires, but that still doesn’t make things work.

Following on from doing this earlier …

> [@](#):
>
> To test, stop emonhub - `sudo systemctl stop emonhub.service` and open a terminal

Did I need to actively re-start it, and if so can I just use the orange Restart button within the emonTx’s emonHub page?

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [12 October 2020 17:07 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/68 "2020-10-12T17:07:29Z")

</div>

> [@haffle](#):
>
> (hmmm, despite three ``` top & bottom this next section doesn’t get abbreviated. Sorry!) …

No looks fine.

> [@haffle](#):
>
> Not knowingly (didn’t know I ought to have, and don’t know how to anyway.

You often don’t **need** to, but it does ensure everything is fresh.

```auto
sudo systemctl restart emonhub.service

```

> [@haffle](#):
>
> > [@](#):
> >
> > If you press the reset button on the TX, you will get the initial config info as well. Please post that.
> 
> Sorry, I missed this bit. Having restarted the PiZero, I pressed the Tx reset button, and this is the last bits of the emonHub log.

No you need to do it with **miniterm** running.

> [@haffle](#):
>
> > [@](#):
> >
> > You also need to turn RF Off especially if you have not attached an antenna.
> 
> Where would I do that? I can’t see anything RF related in the emonHub.conf

I’ll show you - you will see a config menu when you press the reset while `miniterm` is running.

> [@Robert.Wall](#):
>
> It looks as if you might have some “human readable” output from the emonTx

emonhub is not very discerning in this regard (there is an issue open), part of the reason I suggested a JSON output directly from emonTX. It does pick up odd bits of text, usually at startup that appear as inputs. The repeated restarts due to the exceptions isn’t helping.

> [@Robert.Wall](#):
>
> Another thought - is the “Tx” line (actually a wrongly labelled Rx input) on the emonTx connected from your Pi Zero?

Wiring looks correct to me (ref [EmonTX to Rpi - Direct Serial Connection - #61 by borpin](https://community.openenergymonitor.org/t/emontx-to-rpi-direct-serial-connection/13114/61))

I do wonder if there is a poor connection though.

> [@haffle](#):
>
> ```auto
> 2020-10-12 14:12:34,868 WARNING SerialTx Exception caught in SerialTx thread. Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 501, in read
> 'device reports readiness to read but returned no data '
> serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
> 
> ```

Clearly there is a serial comms problem.

The other thing to run is

```auto
tail -f /var/log/emonhub/emonhub.log | grep "NEW FRAME"

```

**However** there is clearly something wrong with the serial comms (hence all the exceptions).

**suggestion**

- stop emonhub
- open miniterm
- wiggle connection and see if the data becomes corrupted
- try pre made breadboard jumper wires instead of connector
- check header soldering
- Remove the `[[RFM2Pi]]` Interfacer - it isn’t needed as the Pi does not have an RFM board.

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [12 October 2020 17:11 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/69 "2020-10-12T17:11:18Z")

</div>

> [@haffle](#):
>
> Following on from doing this earlier …
> 
> > [@](#):
> >
> > To test, stop emonhub - `sudo systemctl stop emonhub.service` and open a terminal
> 
> Did I need to actively re-start it, and if so can I just use the orange Restart button within the emonTx’s emonHub page?

You do need to restart it, but a reboot will do that else just the opposite of stop `sudo systemctl start emonhub.service`

Stopping it just means there is only one thing reading the serial port.

Just leave miniterm running for a while and look for bad data and a correctly incrementing MSG count.

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [12 October 2020 17:23 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/70 "2020-10-12T17:23:35Z")

</div>

**GOT IT** (I think)

@haffle the RFM interfacer is trying to access the same `com_port`.

Remove the RFM interfacer from the emonhub.conf file.

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [13 October 2020 07:47 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/71 "2020-10-13T07:47:21Z")

</div>

> [@borpin](#):
>
> **GOT IT** (I think)

Amazing! It now works - thank you SO much!!!

I let it run overnight having #'d out the RFM section in the emonTx’s emonHub config, and no “rogue” inputs were sent or received. Thank you!

Moving on to deployment, how or where do I get the emonTx c/w PiZero to send the same Inputs across to the emonPi as other emonTx (c/w ESP8266’s) do? IE, how to get it to send CT1, CT2, CT3 etc. I am unclear what the relationship is between the list of Inputs on the emonTx (along with their various “nodes”(?) such as T1, T2, pulse etc), and what appears on the emonPi’s section where the emonTx reports in to. At present, all of the entries within the emonTx are n/a (in red), whereas in the emonPi the emonTx is feeding through 5 entries in green (MSG, Vrms etc).

The screen grab below shows both, and the second image is a screen grab from the emonTx/PiZero’s emonHub log.

 ![Screenshot 2020-10-13 at 08.37.40](https://community.openenergymonitor.org/uploads/default/original/2X/5/50ebef9e75d5691f3bf40bc4a181e2a5a22862d7.jpeg)

 ![Screenshot 2020-10-13 at 08.37.58](https://community.openenergymonitor.org/uploads/default/original/2X/3/3f23f2df8fe4955196547803d4cbbe6d62c94c59.jpeg)

This is the current emonHub config (emonTx / PiZero)

```auto
#######################################################################
####################### emonhub.conf #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
#######################################################################
####################### emonHub settings #######################
#######################################################################

[hub]
### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
loglevel = DEBUG
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
####################### Interfacers #######################
#######################################################################

[interfacers]
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
#[[RFM2Pi]]
# Type = EmonHubJeeInterfacer
# [[[init_settings]]]
# com_port = /dev/ttyAMA0
# com_baud = 38400 # 9600 for old RFM12Pi
# [[[runtimesettings]]]
# pubchannels = ToEmonCMS,
# subchannels = ToRFM12,
#
# group = 210
# frequency = 433
# baseid = 5 # emonPi / emonBase nodeID
# calibration = 230V # (UK/EU: 230V, US: 110V)
# quiet = true # Disable quite mode (default enabled) to enable RF packet #debugging, show packets which fail crc
# # interval = 300 # Interval to transmit time to emonGLCD (seconds)
        

[[SerialTx]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           com_port= /dev/ttyAMA0
           com_baud = 115200
      [[[runtimesettings]]]
           pubchannels = ToEmonCMS,

           nodeoffset = 0
           nodename = Serial_PiZero_barn

[[MQTT]]

    Type = EmonHubMqttInterfacer
    [[[init_settings]]]
        mqtt_host = 192.168.2.50
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016

    [[[runtimesettings]]]
        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,

        # emonhub/rx/10/values format
        # Use with emoncms Nodes module
        node_format_enable = 1
        node_format_basetopic = emonhub/

        # emon/emontx/power1 format - use with Emoncms MQTT input
        # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
        nodevar_format_enable = 1
        nodevar_format_basetopic = emon/

[[emoncmsorg]]
    Type = EmonHubEmoncmsHTTPInterfacer
    [[[init_settings]]]
    [[[runtimesettings]]]
        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,
        url = https://emoncms.org
        apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        senddata = 1 # Enable sending data to Emoncms.org
        sendstatus = 1 # Enable sending WAN IP to Emoncms.org MyIP > https://emoncms.org/myip/list
        sendinterval= 30 # Bulk send interval to Emoncms.org in seconds

#######################################################################
####################### Nodes #######################
#######################################################################

[nodes]

## See config user guide: https://github.com/openenergymonitor/emonhub/blob/emon-pi/conf/emonhub.conf

[[5]]
    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, L
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,p

[[6]]
    nodename = emontxshield
    [[[rx]]]
       names = power1, power2, power3, power4, vrms
       datacode = h
       scales = 1,1,1,1,0.01
       units = W,W,W,W,V

[[7]]
   nodename = emontx4
   [[[rx]]]
      names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
      datacodes = h,h,h,h,h,h,h,h,h,h,h,L
      scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
      units = W,W,W,W,V,C,C,C,C,C,C,p

[[8]]
    nodename = emontx3
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[9]]
   nodename = emontx2
   [[[rx]]]
      names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
      datacodes = h,h,h,h,h,h,h,h,h,h,h,L
      scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
      units = W,W,W,W,V,C,C,C,C,C,C,p

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[11]]
    nodename = 3phase
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p
       
[[12]]
    nodename = 3phase2
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[13]]
    nodename = 3phase3
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[14]]
    nodename = 3phase4
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[15]]
    nodename = emontx3cm15
    [[[rx]]]
       names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
       datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
       scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
       units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
       whitening = 1

[[16]]
    nodename = emontx3cm16
    [[[rx]]]
       names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
       datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
       scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
       units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
       whitening = 1

[[19]]
   nodename = emonth1
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[20]]
   nodename = emonth2
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[21]]
   nodename = emonth3
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[22]]
   nodename = emonth4
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[23]]
    nodename = emonth5
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[24]]
    nodename = emonth6
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[25]]
    nodename = emonth7
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[26]]
    nodename = emonth8
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

```

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [13 October 2020 13:07 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/72 "2020-10-13T13:07:43Z")

</div>

> [@haffle](#):
>
> Moving on to deployment, how or where do I get the emonTx c/w PiZero to send the same Inputs across to the emonPi as other emonTx (c/w ESP8266’s) do? IE, how to get it to send CT1, CT2, CT3 etc.

It doesn’t as it is different release of the firmware, but that doesn’t matter as you just convert those inputs to a feed. The “P” is the power (W) and the “E” is Wh which is an accumulating figure (until next reboot/reset of EmonTX). If you add more CTs, you need to power off/on the EmonTX to detect further CTs which will be reported as P2, E2 etc.

Personally I use the WhAcc input process and scale that to give the kWh Feed.

[edit]

> [@haffle](#):
>
> ```auto
> node_format_enable = 1
> nodevar_format_enable = 1
> 
> ```

You don’t need to enable both these, in fact you will bet better off using the new JSON format `node_JSON_enable = 1` as I mentioned [above](https://community.openenergymonitor.org/t/avoiding-wireless-connections/15056/55) (although this is currently only in the master branch).

The reason is, each MQTT Publish takes time and potentially, the first topic posted could land on a different ‘slot’ in emoncms. By sending all the data as a single publish it is guaranteed to stay together (especially as it can be timestamped).

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [13 October 2020 14:49 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/73 "2020-10-13T14:49:45Z")

</div>

Thanks for that.

Another question: within the EmonTx (c/w PiZ)'s emonCMS / WiFi, is the section effectively redundant as the PiZ has taken over wifi comms have been offloaded on to the PiZ, or is it still important? (I have tried re-Scanning, but it never finds an alternative SSID).

I have had trouble changing the wifi network from my office SSID to the barn SSID, and not sure whether to do this within emonCMS / WiFI or via ssh` sudo raspi-config`

For the next devices I will rig up a tempo WAN with the desired end use SSID to make this switch unnecessary.

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [13 October 2020 15:08 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/74 "2020-10-13T15:08:17Z")

</div>

> [@haffle](#):
>
> within the EmonTx (c/w PiZ)'s emonCMS / WiFi, is the section effectively redundant as the PiZ has taken over wifi comms have been offloaded on to the PiZ, or is it still important?

The emoncms accessed via the IP of the PIZ, will show you the WiFi setup of that PiZ.

The scan work for me. I need to click it twice…

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [16 October 2020 08:58 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/75 "2020-10-16T08:58:33Z")

</div>

To help me - and hopefully others in the future - I am in the midst of writing up a Dummies Guide for how to switch over to using a Pi Zero. I am part way through setting up my second one, but am a bit stuck once again.

I have done almost all of the setting up, and copied the emonHub config from the PiZ #1 (that works fine & continues to report through to my main emonPi) to a second one (PiZ #2), just changing the [[SerialTx]] nodename from `nodename = Serial_PiZero_barn` to `nodename = Serial_PiZero_hotwater`. However, the PiZ #2 is not reporting through to the emonPi, and the emonHub config log isn’t looking good.

```auto
2020-10-16 09:43:31,997 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2020-10-16 09:43:32,009 WARNING MainThread Setting emoncmsorg apikey: obscured
2020-10-16 09:43:32,011 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2020-10-16 09:43:32,013 INFO MainThread Setting emoncmsorg senddata: 1
2020-10-16 09:43:32,014 INFO MainThread Setting emoncmsorg sendstatus: 1
2020-10-16 09:44:33,867 DEBUG MainThread Setting MQTT timestamped: False
2020-10-16 09:44:33,879 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2020-10-16 09:44:33,881 INFO MainThread Setting MQTT node_format_enable: 1
2020-10-16 09:44:33,882 INFO MainThread Setting MQTT nodevar_format_enable: 1
2020-10-16 09:44:33,884 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2020-10-16 09:44:40,587 DEBUG MainThread Signal 15 received.
2020-10-16 09:46:21,793 INFO MainThread EmonHub emonHub (emon-pi variant) v2.1.5
2020-10-16 09:46:21,796 INFO MainThread Opening hub...
2020-10-16 09:46:21,803 INFO MainThread Logging level set to DEBUG
2020-10-16 09:46:21,805 INFO MainThread Creating EmonHubTx3eInterfacer 'SerialTx'
2020-10-16 09:46:21,821 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 115200 bits/s
2020-10-16 09:46:21,829 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2020-10-16 09:46:21,842 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2020-10-16 09:46:21,844 DEBUG MainThread Setting MQTT subchannels: ['ToEmonCMS']
2020-10-16 09:46:21,846 INFO MainThread Setting MQTT node_format_enable: 1
2020-10-16 09:46:21,858 INFO MainThread Setting MQTT nodevar_format_enable: 1
2020-10-16 09:46:21,860 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2020-10-16 09:46:21,869 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2020-10-16 09:46:21,872 DEBUG MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2020-10-16 09:46:21,874 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2020-10-16 09:46:21,876 WARNING MainThread Setting emoncmsorg apikey: obscured
2020-10-16 09:46:21,888 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2020-10-16 09:46:21,889 INFO MainThread Setting emoncmsorg senddata: 1
2020-10-16 09:46:21,893 INFO MainThread Setting emoncmsorg sendstatus: 1

```

I have obviously forgotten to do something somewhere, but not sure where. Comms are good, I can log in to the PiZ #2 via the dashboard and via ssh. But it is not getting through to the emonPi, despite having an effectively identical emonHub conf, with only a nodename changed.

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [16 October 2020 11:23 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/76 "2020-10-16T11:23:11Z")

</div>

Use the JSON format as I suggested above (twice). It is better as it is a single MQTT publish.

Possibly 2 issues;

Do you see the serial data stream from the EmonTX when using Miniterm?

Is the EmonTX running the same firmware version?

**note** You never came back and I didn’t walk you through actually turning off the RF - it would be better to do so.

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [16 October 2020 13:35 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/77 "2020-10-16T13:35:04Z")

</div>

> [@](#):
>
> Use the JSON format as I suggested above (twice). It is better as it is a single MQTT publish.

I think I now have (see conf below), & I restarted emonHub.conf on both PiZ #1 & #2b; had to pop out for an hour, **and now both are getting through to the main emonPi’s Inputs page** 🥵

I will update my crib sheet & start again with PiZ #3 🤪

> [@](#):
>
> Possibly 2 issues; Do you see the serial data stream from the EmonTX when using Miniterm?

Earlier today I did run (via ssh to PiZ #2) `miniterm /dev/ttyAMA0 115200` and `miniterm --rtscts /dev/ttyAMA0 115200` but that didn’t seem to help; part of the problem is that I don’t know what miniterm is / does, so will go away and read up about it …

> [@](#):
>
> Is the EmonTX running the same firmware version?

Comparing all the version numbers in the emonCMS Admin section of both Pi Zeros, and all seem to be exactly the same

> [@](#):
>
> **note** You never came back and I didn’t walk you through actually turning off the RF - it would be better to do so.

I half hoped that by hashing out the RFM2PI section within the emonTX’s emonHub conf meant that the issue of RF would go away (& it did with PiZ #1), but will re-read your comments and revert.

For clarity, herewith my emonHub conf from the emonTx / PiZ #1. It is the same was for PiZ #2 except for the nodename.

```auto
#######################################################################
####################### emonhub.conf #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
#######################################################################
####################### emonHub settings #######################
#######################################################################

[hub]
### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
loglevel = DEBUG
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
####################### Interfacers #######################
#######################################################################

[interfacers]
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
#[[RFM2Pi]]
# Type = EmonHubJeeInterfacer
# [[[init_settings]]]
# com_port = /dev/ttyAMA0
# com_baud = 38400 # 9600 for old RFM12Pi
# [[[runtimesettings]]]
# pubchannels = ToEmonCMS,
# subchannels = ToRFM12,
#
# group = 210
# frequency = 433
# baseid = 5 # emonPi / emonBase nodeID
# calibration = 230V # (UK/EU: 230V, US: 110V)
# quiet = true # Disable quite mode (default enabled) to enable RF packet #debugging, show packets which fail crc
# # interval = 300 # Interval to transmit time to emonGLCD (seconds)
        

[[SerialTx]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           com_port= /dev/ttyAMA0
           com_baud = 115200
      [[[runtimesettings]]]
           pubchannels = ToEmonCMS,

           nodeoffset = 0
           nodename = Serial_PiZero_hotwater

[[MQTT]]

Type = EmonHubMqttInterfacer
    [[[init_settings]]]
        mqtt_host = 192.168.2.50
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016

    [[[runtimesettings]]]
        subchannels = ToEmonCMS,

        timestamped = True        

        node_JSON_enable = 1
        node_JSON_basetopic = emon/

#
# Type = EmonHubMqttInterfacer
# [[[init_settings]]]
# mqtt_host = 192.168.2.50
# mqtt_port = 1883
# mqtt_user = emonpi
# mqtt_passwd = emonpimqtt2016
#
# [[[runtimesettings]]]
# pubchannels = ToRFM12,
# subchannels = ToEmonCMS,
#
# # emonhub/rx/10/values format
# # Use with emoncms Nodes module
# node_format_enable = 1
# node_format_basetopic = emonhub/
#
# # emon/emontx/power1 format - use with Emoncms MQTT input
# # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
# nodevar_format_enable = 1
# nodevar_format_basetopic = emon/

[[emoncmsorg]]
    Type = EmonHubEmoncmsHTTPInterfacer
    [[[init_settings]]]
    [[[runtimesettings]]]
        pubchannels = ToRFM12,
        subchannels = ToEmonCMS,
        url = https://emoncms.org
        apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        senddata = 1 # Enable sending data to Emoncms.org
        sendstatus = 1 # Enable sending WAN IP to Emoncms.org MyIP > https://emoncms.org/myip/list
        sendinterval= 30 # Bulk send interval to Emoncms.org in seconds

#######################################################################
####################### Nodes #######################
#######################################################################

[nodes]

## See config user guide: https://github.com/openenergymonitor/emonhub/blob/emon-pi/conf/emonhub.conf

[[5]]
    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, L
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,p

[[6]]
    nodename = emontxshield
    [[[rx]]]
       names = power1, power2, power3, power4, vrms
       datacode = h
       scales = 1,1,1,1,0.01
       units = W,W,W,W,V

[[7]]
   nodename = emontx4
   [[[rx]]]
      names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
      datacodes = h,h,h,h,h,h,h,h,h,h,h,L
      scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
      units = W,W,W,W,V,C,C,C,C,C,C,p

[[8]]
    nodename = emontx3
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[9]]
   nodename = emontx2
   [[[rx]]]
      names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
      datacodes = h,h,h,h,h,h,h,h,h,h,h,L
      scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
      units = W,W,W,W,V,C,C,C,C,C,C,p

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[11]]
    nodename = 3phase
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p
       
[[12]]
    nodename = 3phase2
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[13]]
    nodename = 3phase3
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[14]]
    nodename = 3phase4
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

[[15]]
    nodename = emontx3cm15
    [[[rx]]]
       names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
       datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
       scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
       units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
       whitening = 1

[[16]]
    nodename = emontx3cm16
    [[[rx]]]
       names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
       datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
       scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
       units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
       whitening = 1

[[19]]
   nodename = emonth1
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[20]]
   nodename = emonth2
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[21]]
   nodename = emonth3
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[22]]
   nodename = emonth4
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[23]]
    nodename = emonth5
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[24]]
    nodename = emonth6
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[25]]
    nodename = emonth7
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[26]]
    nodename = emonth8
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

```

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [16 October 2020 13:45 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/78 "2020-10-16T13:45:48Z")

</div>

> [@haffle](#):
>
> Earlier today I did run (via ssh to PiZ #2) `miniterm /dev/ttyAMA0 115200` and `miniterm --rtscts /dev/ttyAMA0 115200` but that didn’t seem to help; part of the problem is that I don’t know what miniterm is / does, so will go away and read up about it …

So this is important. If you stop emonhub (as mentioned above) and then run miniterm, you should see the data printed out.

**Then** press the reset for the emonTX and you will see some configuration text, the firmware version and a settings menu.

> [@haffle](#):
>
> Comparing all the version numbers in the emonCMS Admin section of both Pi Zeros, and all seem to be exactly the same

You **cannot** see the emonTX firmware version except as above directly from miniterm.

Some changes require emonhub to be restarted.

---

<div class="post-metadata">

**Author:** ![haffle](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/h/d07c76/32.png) [@haffle](https://community.openenergymonitor.org/u/haffle)\
**Post date:** [16 October 2020 14:24 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/79 "2020-10-16T14:24:52Z")

</div>

OK; I now see that `miniterm /dev/ttyAMA0 115200` stops activity in the emonHub log, and one can see what would have been sent in Terminal instead.

Pressing the Reset button on the emonTx connected to the PiZ #1 brings up this info.

```auto
emonTx V3.4 EmonLibCM Continuous Monitoring V1.20
OpenEnergyMonitor.org
RFM69CW Node: 15 Freq: 433MHz Group: 210
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
AC present

```

Pressing the Reset button on the emonTx connected to the PiZ #2 brings up this info.

```auto
emonTx V3.4 Discrete Sampling V3.10
OpenEnergyMonitor.org
Loaded EEPROM RF config >
RFM69CW Node: 9 Freq: 433Mhz Group: 21 
POST.....wait 10s
'+++' then [Enter] for RF config mode
(Arduino IDE Serial Monitor: make sure 'Both NL & CR' is selected)

```

I see that new emonTx’s ship using Continuous Sampling Firmware rather than the Discrete Sampling that one of mine seem to be using; I have not got involved with the different types of sampling. Should I update what I have using [GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)](https://github.com/openenergymonitor/EmonTxV3CM) or not?

Would the differences in FW be the cause for the Inputs displayed in the emonPi’s emonCMS being different (as below)?

 ![Screenshot 2020-10-16 at 15.22.19](https://community.openenergymonitor.org/uploads/default/original/2X/c/cf6c5fa82e4c3f11f612a00fe60a7e03c04587e0.png)

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [16 October 2020 14:44 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/80 "2020-10-16T14:44:39Z")

</div>

> [@haffle](#):
>
> Would the differences in FW be the cause for the Inputs displayed in the emonPi’s emonCMS being different (as below)?

Yes! (hence my question).

@Robert.Wall, you are better to advise on which is best but I think the CM firmware is better.

On that github page, on the RHS are the releases

![image](https://community.openenergymonitor.org/uploads/default/original/2X/4/486dc8fcc23937c0ad7a4887722b055ceac9a3ea.png)

The firmware can be uploaded directly from the Pi

Ensure emonhub has been stopped - `sudo systemctl stop emonhub.service`

Download the firmware (note the version, so the URL might change - check github)

```auto
wget https://github.com/openenergymonitor/EmonTxV3CM/releases/download/2.0.0/firmware.hex

```

```auto
$ avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:firmware.hex

```

If you want to configure the EmonTX do it now. Connect via `miniterm`. You can also check the update has worked via `miniterm` as well. Use `--rtscts` on the command.

```auto
miniterm --rtscts /dev/ttyAMA0 115200

```

Restart emonhub `sudo systemctl start emonhub.service`

**Note** on GitHub are instructions for switching off the RF via the `+++<rtn>` settings menu.

It is actually really useful for you to do this guide as you will pick up the sorts of things we probably take for granted.

---

<div class="post-metadata">

**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\
**Post date:** [16 October 2020 15:30 UTC](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056/81 "2020-10-16T15:30:05Z")

</div>

> [@haffle](#):
>
> Should I update what I have using [GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)](https://github.com/openenergymonitor/EmonTxV3CM) or not?

That’s up to you. The difference is minimal **IF** you have steady-state conditions and nothing fluctuates very much. If that is not the case, then the CM software, which as its name implies **C** ontinuously **M** onitors - exactly like your supplier’s meter does, rather than trusting that a 200 ms sample every 10 s is representative of your consumption - is going to be more accurate in the short term as well as in the long, whereas the **D** iscrete **S** ample version will tend to average out the errors over time (which could be many days, depending on your pattern of usage).

Obviously, I think the CM version is better, but then I am biased. The DS version remains available as it’s essential for battery-powered emonTx’s.

> [@haffle](#):
>
> Would the differences in FW be the cause for the Inputs displayed in the emonPi’s emonCMS being different (as below)?

Most definitely. The data they send is different. The CM sketch accumulates energy at the front end (until it restarts for whatever reason, when the count resets to zero) and that is also sent forwards to emonCMS or wherever.

> [@borpin](#):
>
> **Note** on GitHub are instructions for switching off the RF via the `+++<rtn>` settings menu.

They should also be printed in short form to the serial port (and thus displayed via Miniterm) when you enter the config & calibration menu immediately after the emonTx starts up.

> [@borpin](#):
>
> It is actually really useful for you to do this guide as you will pick up the sorts of things we probably take for granted.

I second that. It’s hard for those of us who are too close to the action to remember that somebody who doesn’t know the history and every detail doesn’t know that.

[Previous page](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056.md?page=3)

[Next page](https://community.openenergymonitor.org/t/avoiding-wireless-connections-emontx-serial-rpizero-solution/15056.md?page=5)