Discarded RX frame

Emoncms
, ,
1

Hi
I have error Discarded RX frame ‘string to short’

image
image937×192 9.24 KB

can someone give me a idea to what is wrong with my settings, my Emonhub settings is like below

#######################################################################
#######################      emonhub.conf     #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### http://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]
[[SerialTx3e]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           # Un-comment line below if using RS485 adapter
           #com_port = /dev/ttyRS485-0
 # default com port if using USB to UART adapter
#   com_port= /dev/ttyUSB0
# default com port if using USB to UART adapter
com_port= /dev/ttyAMA0          
 com_baud = 115200
         


    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        nodeoffset = 8


        group = 210
        frequency = 433
        baseid = 10                              # emonPi / emonBase nodeID
        quiet = true                            # Report incomplete RF packets (no implemented on emonPi)
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        # interval =  0                         # Interval to transmit time to emonGLCD (seconds)
        

[[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,
        node_format_enable = 1
        node_format_basetopic = emonhub/

        # emonhub/rx/10/values format
        # Use with emoncms Nodes module
        

        # 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/


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



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

[nodes]

## See config user guide: http://github.com/openenergymonitor/emonhub/blob/master/configuration.md

[[8]]
        nodename = emonTx_3
        firmware =V2_3_emonTxV3_4_DiscreteSampling
        hardware = emonTx_(NodeID_DIP_Switch1:OFF)
       [[[rx]]]
           names = Electric fan, Computer, power13, power14, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacode = 0
           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
2

Is this a stock emonpi install? When was it last updated?

I do not recognize the log entries (and please post the log text not pictures of it)

the “SerialTx3e mynode” line - where does the “mynode” come from? I do not see this used in your configuration settings.

the “NEW FRAME” line appears ok but without knowing the source I have no real idea as to what it should look like, certainly if it is a stock emonTx, it is indeed “too short”.

the line saying “too short” contradicts the line above as that warning is given when the payload is less than just a node id, that would appear correct for the accompanying empty array (ie “[ ]”) but not in line with the previous line so I cannot tell what’s going on there.

Your only node definition shows 11 values, but only 6 appear in the log as a “NEW FRAME” and even if they matched it doesn’t explain the empty array in the “too short” line.

tell us more about what you’re up to here.

3

Hello @rennyp I fixed this bug just over a week ago in this update, if you can update to the latest version that should solve it.

4

That interfacer needs some work, I don’t doubt the fix you implemented will stop the error but you have fixed redundant code

The emonTx doesn’t pass a node id over serial, therefore if there is no “nodeoffset” defined the code should exit, probably a lot sooner than it does.

If we are possibly looking at revising the emonESP code to be able to post to emonHub via a socket, we should perhaps also look at getting the emonTx to pass a nodeid over serial, even if the emonESP ignores it, if you want a “out of the box” serial connection option by sharing the output format, there needs to be a node id.

Having said that, does the emonTx really need to output key:value pairs over serial? It would be much nicer to allow users to define their own input names in the emonesp app, because the emonTx names are hardcoded, using the emonESP means users cannot change the names in emoncms. Ay least emonHub ignores the keys from the emonTx and allows users to define there own in the node definitions in emonhub.conf.

It also looks like this interfacer is hardcoded to check for the first key to be “ct1” so if users did edit the sketch and change the names, this interfacer would fail to work.

5

Aha yes!, I forgot, I then made further changes and removed that part all together :slight_smile: that will teach me to take more than a glance over the commit history.

Yes the checking for a string that starts with ct1 is less than ideal. I’ve now removed this check and replaced it with a check for an alphanumeric input name and numeric value: https://github.com/openenergymonitor/emonhub/commit/7aae5e913bc4731e3402567ce11d2363f2cc8add

yes good point

Yes it would be good to look at this. The intention was to make it possible to plug the esp8266 adapter board into different nodes or have one firmware for multiple devices e.g emontx esp8266 adapter and the heatpump monitor. By having the component that changes in this case the atmega328 set the names, the user does not need to know what the string of values coming from the emontx are, they just appear in emoncms pre-named.

The question is which one is most important, automatically having inputs appear in emoncms with their names and with no user configuration required or allowing for a more detailed level of user configuration in this case.

PS: I realise it might also be worth considering changing the name of this interfacer to something more generic and have it inherit the serial interfacer. It should just be a key:value format serial interfacer.

6

@rennyp if you would like to update again I’ve made a number of further modifications to this interfacer that improve things further.

7

Hi, thank you for answer, i have only read on my cellphone, out of office :slight_smile:
Its ok for me to make a New installation, if i know it can work :slight_smile:

I wondering, i have install this system before without this problem, so why it come now ?

8

Yes, That’s all I was implying at this point, I know why it was done I just can’t help thinking there might be a better route that fit’s more cases, we’ll never get it right for all cases but currently it’s a very narrow band.

This doesn’t necessarily have to be an either or case, with the discussions we are having about using both index and named inputs together in emoncms, and the further development of the device module, and the possibility of the esp posting via an emonhub socket so emonhub could take the strain of naming. Not to mention a possibility of making the esp recognize a node type by it’s default node id and choosing a template, There maybe a better way the naming could be moved out of the FW.

I agree, I think many of the interfacers will need revisiting to align with the way emonhub was intended and the changes we are making. I have been aware of several “issues” in most of those additional interfacers, but IMO the developers have done well to implement these interfacers without any assistance or documentation. They have done this by copying other interfacers that were themselves not quite right, so I have tried to refrain from pointing out any errors and/or correcting their efforts.

It was originally my intention to document the dev process and provide example templates to encourage development, the main reason I haven’t done this is simply because if I had documented how to write an interfacer “correctly” for how emonhub was intended to work, those interfacers wouldn’t fit the emon-pi variant and I am not happy about documenting how to do it “incorrectly” just so they fitted emon-pi.

Hopefully soon we will have all this resolved.

1 Like
9

@rennyp - Try updating first.

But I too am confused as to how the code even reached that point since you have nodeoffset = 8 defined.

10

hi :slight_smile:

when i install the other day, i use SD card adapter, and install with win32diskimager, today i buy a SD card to USB adapter, and install with Etcher, now no problems