emonTX posting sporadically

Hardware emonTx
1

I have two emonTXv4s connected to the same emonBase. Both are set to post data every 10 seconds. One works fine and the other is very sporadic. Over the past 16 hours, I had 6,421 10 second time slots. For one emonTX, I received 6,410 messages. For the second emonTX I only received 1,836 messages.
Both TXs have strong signal (~ -27) so this isn’t the issue.

From my emonHub, both configurations look identical (my config file is below). Node 17 is the problem TX. (I deleted my API key from this post for security).

Any help in determining what needs adjusting is greatly appreciated.

thank you,

Gordon

#######################################################################
#######################      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
    autoconf = 1
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
#######################       Interfacers       #######################
#######################################################################

[interfacers]
    ### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
    [[EmonPi2]]
        Type = EmonHubOEMInterfacer
        [[[init_settings]]]
            com_port = /dev/ttyAMA0
            com_baud = 38400
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            subchannels = ToRFM12,
    
    [[USB0]]
        Type = EmonHubOEMInterfacer
        [[[init_settings]]]
            com_port = /dev/ttyUSB0
            com_baud = 115200
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            subchannels = ToRFM12,
            nodename = emonTx4
    
    [[SPI]]
        Type = EmonHubRFM69LPLInterfacer
        [[[init_settings]]]
            nodeid = 5
            networkID = 210
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
    
    
    [[MQTT]]
        Type = EmonHubMqttInterfacer
        [[[init_settings]]]
            mqtt_host = 127.0.0.1
            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 = 0
            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/
            
            # Single JSON payload published  - use with Emoncms MQTT
            node_JSON_enable = 0
            node_JSON_basetopic = emon/
    
    [[emoncmsorg]]
        Type = EmonHubEmoncmsHTTPInterfacer
        [[[init_settings]]]
        [[[runtimesettings]]]
            pubchannels = ToRFM12,
            subchannels = ToEmonCMS,
            url = https://emoncms.org
            apikey = 
            senddata = 1    # Enable sending data to Emoncms.org
            sendnames = 1    # Send full input names (compression will be automatically enabled)
            interval = 10    # Bulk send interval to Emoncms.org in seconds

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

## See config user guide: https://github.com/openenergymonitor/emonhub
## If autoconf is enabled above, node configuration will automatically
## populate based on templates listed in available.conf

[nodes]
    
    [[17]]
        nodename = HVAC3_Front
        [[[rx]]]
            names = MSG, Vrms, P1, P2, P3, P4, P5, P6, I1, I2, I3, I4, I5, I6, T1, T2, T3, pulse
            datacodes = L, h, h, h, h, h, h, h, h, h, h, h, h, h, h, h, h, L
            scales = 1, 0.01, 1, 1, 1, 1, 1, 1, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 1
            units = n, V, W, W, W, W, W, W, I, I, I, I, I, I, C, C, C, p
    [[18]]
        nodename = HVAC1_BackL
        [[[rx]]]
           names = MSG, Vrms, P1, P2, P3, P4, P5, P6, I1, I2, I3, I4, I5, I6, T1, T2, T3, pulse
            datacodes = L, h, h, h, h, h, h, h, h, h, h, h, h, h, h, h, h, L
            scales = 1, 0.01, 1, 1, 1, 1, 1, 1, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 0.01, 1
            units = n, V, W, W, W, W, W, W, I, I, I, I, I, I, C, C, C, p
2

Is this a new problem, or new emonTx4s?

Is that the actual value, or have you rounded the number for convenience? Transmissions should be slightly faster than every 10 s, normally the default for the datalogging period is 9.8 s. This is so that any delays in processing the data (or if it needs to retry) don’t miss their ‘timeslot’ in emonCMS.

Are the 4-5000 missing messages missing in your local emonCMS and in emoncms.org, or just one of those (and which)?

Are both emonTx4s being received at the correct intervals in emonHub?, or is the ‘bad’ one not making it that far even?

3

Hi Robert,

The “bad” emonTx is a new one. The count is missing in both the local cms and emoncms.org

4

And what about the emonHub log?

5

Sorry, I was away from my desk for a while. It looks like the “bad” emon is not sending messages regularly according to the emonHub log. See attached.
New emonhub.txt (150.2 KB)

6

Are they both posting at the same time? I have two tx3 units and if I have a power cut, they clash after the power is restored. Unplugging one and counting to a random number before restoring power usually solves that.

7

@greentangerine
Not if you look at the emonHub log. The errant device is sending 61 bytes - or so emonHub thinks, not the 40 bytes it’s expecting.

@grod55
I’ve no idea why that should be, I need to look at Trystan’s sketch and try to work out where 61 bytes comes from. It’s consistent - far too consistent to be anything other than the sketch going wrong - at first sight anyway. Not a job for today, I’m in the UK and it’s 00:50 local time.

8

hmm. Not sure how I would have them post at different times. I hope the unplugging solution isn’t the only way to resolve this as these will be installed in a remote location where doing this is impractical. Also, this has started since firing them up a couple of days ago without any power outages.

9

If you’re using JeeLib, that’s entirely possible. If you’d updated to my rfm69nTxLib, that checks that the band appears to be free before transmitting, and LPL will retransmit if it doesn’t get an acknowledgement.

I’m fairly certain @grod55 will be using LPL as they are emonTx4s (am I right? - I can’t tell from the log).

10

Yes. Both units are emonTxv4s

11

Just because emonhub is not receiving the data, doesn’t mean the TX is posting sporadically.

First question - are both TX4s green LED flashing at ~10s intervals?

Second, are they flashing at the same time? If so try and make it so they flash at different times.

Third, are they in close proximity to each other and/or the emonBase?

Most likely issue is that there is RF clash (yes I know in theory the new code should help that).

Best solution would be to connect one by USB and the other by RF (or both by USB). Alternatively, get a Wi-Fi module for one of them.

12

@borpin
What about the 61-byte data packets that emonHub is seeing?

They are being rejected by emonHub because they don’t fit the 40-byte Node definition, hence the NULL values being recorded.
But there are good packets being received in between.

So where are the bad ones coming from? I see these possibilities:

  1. The emonTx sketch is going haywire.
  2. The transmit half of the LPL library is going haywire.
  3. The receive half of the LPL library is going haywire.
  4. emonHub is going haywire.
  5. There’s another transmitter on the channel, sending valid but not the expected data packets.

@TrystanLea
Which sketch is @grod55 likely to have had in his emonTx4s?

13

@glyn.hudson can you answer Robert’s question on the sketch version? This is the new emonTX4 that I just received from you.

Robert, et al, I am going to add a 3rd emonTX4 to see if it has similar issues or not.

14

Not sensible, bearing in mind the other thread Null Data and Wireless where @grod55 said he wanted to move from Wi-Fi to ISM band.

15

@grod55
Which is the emonTx4 you converted from Wi-Fi? (Null Data and Wireless)

16

Ok. I added a 3rd emonTX4 and it is reporting fine. I am beginning to think that Node 17 is bad. Node 18 continues to report good, as does the new Node 19.

Wondering if I should reload the firmware on Node 17 - thoughts?

Before I added the 3rd node, I noticed that I have a new “device” showing up in my list of inputs. I have no idea what “73” is and it has not reported data over the past 23 hours. I am wondering if this is an interferer (signal strength is showing as -92) and it lists 61 inputs plus rssi. I’ve attached a print of the inputs. I do not see any reference to “73” in emonHub - so not sure what to make of this.
Emoncms - input view.pdf (133.5 KB)

Device 73 unknown
Device 73 unknown2097×891 50.3 KB

17

I converted Nodes 18 and 19 from wifi - both of which are working fine. The new ISM emonTX4 is Node 17 and is the one giving me problems.

18

61 inputs (do you mean ‘bytes’) corresponds to the rejected messages i saw in your emonHub log.
Clearly an interfering signal from somewhere - do you have anything else that uses 433 MHz - alarm, garage door opener, doorbell? How far away is a neighbour who might have something like this?

@TrystanLea More trouble from your ‘auto-configure’ - it needs to be capable of being permanently disabled.

19

I have also noticed that the red indicator light on Nodes 18 and 19 flashes at regular intervals, but the red indicator light for Node 17 is on solid - not flashing at all. I swapped cables and that did not make any difference.

Then unplugging the cable and plugging it back in gets it to report, and then the light goes out and flashes at non-regular intervals.

20

I saw the 61 inputs listed on the input page of the local emonCMS (ie when you click on the header it usually shows P1, P2, P3, etc. - when I click on the header for this “device” it lists 1 thru 61 and then rssi at the end).

I have a garage door opener less than 20 feet away - would changing the node ID from 17 to something else (eg 20) change the channel away from any interferer?