Definition of inputs MSG, Missed, and Missedprc

I’m looking for some definitions of inputs MSG, Missed, and Missedprc. I did see part of the answers in this post, but I’m looking for a more expanded explanation.

Specifically when using the emonPi2:

MSG - this is a count of messages but where are they originating from and going to?
Missed - I am assuming it is the difference between messages sent vs messages received - related to my question above.
Missedprc - what is this and how is it different from Missed?

My goal is to clean up my inputs and feeds and feel that the three inputs above are good as diagnostic tools if I am missing data, but not really sure what it is telling me.

Any insight is greatly appreciated.

See Which emontx4 inputs to create feeds for? - #2 by Robert.Wall
Null Data and Wireless - #6 by Robert.Wall
Documentation of data keynames? - #2 by Robert.Wall

Robert thank you for the links.

@TrystanLea Am I correct in concluding the following:

  • MSG is the number of messages originating from the probes (eg CT, Temp, etc, both onboard an emonPi or an emonTX) being sent to emonHub and emonCMS

  • Missed is the number of received by emonHub from a 433Mhz TX unit (eg emonTX4) subtracted from the number of messages sent from probes and/or TX units.

  • Missedprc is the number of messages that failed to get processed by emonHub or emonCMS

If the above is true, are there equivalent messages from the local emonCMS (on emonBase or emonPi2) when sending inputs/feeds to



I don’t know if I’m correct, but I’ve always assumed from the name that missedprc is the percentage of messages that were not received correctly?

If that is correct, I don’t know what period missedprc is calculated over - it doesn’t seem to be 100*(missed/MSG), but must be over a shorter period, i.e. over some number of the most recent messages?

Hello @grod55

  • MSG is the message count on the emonTx4 since last power cycle.
  • Missed is a count of missed messages in the expected sequence. E.g If we receive MSG 10 but the next message received is MSG 12 then we know we have missed one message.
  • Missedprc is the same expressed as a percentage e.g 100 x (Missed / MSG)

Hope that helps!

thanks for the info. Still need to understand the message count a bit deeper.

What are the messages from and to? Is this the input messaging to the emonTX4 or is it the emonTX4 messaging to the emonHub?

Is there any message count from the emonhub to



This. The count originates in the emonTx.

Not that I’m aware of.

Ok, to belabor this a bit longer to make sure I fully understand. Is the following correct?

If the emonTx has one CT attached and is collecting data every 10 seconds, then the emonTx would generate 6 messages per minute or 8,640 messages per day.
Each additional device (CT, temperature probe, or emonTH) would generate the same number of messages each (assuming 10-second intervals as well).

Further, I suspect the major reason for missed messages is the RF environment (433 or WiFi). Therefore, with CTs and Probes directly connected to the emonPi2 the opportunity for missed messages is minuscule.



The emonTx4 message count is independent of the number of CT sensors and temperature sensors attached, it is a device level message count.

The emonTH does not provide a message count field and therefore it does not have these associated inputs.

The device e.g emonTx4 has to have a message count field defined.

This is what the code looks like in emonhub for reference:

    if len(names) and names[0].upper()=="MSG":
        msg = rxc.realdata[0]
        if not node in self.last_msg: 
            self.first_msg[node] = msg
            self.last_msg[node] = msg-1
            self.missed[node] = 0
        if self.last_msg[node]>msg:
            self.first_msg[node] = msg
            self.last_msg[node] = msg-1
            self.missed[node] = 0

        self.missed[node] += msg - self.last_msg[node] - 1
        self.last_msg[node] = msg
        msgcount = msg - self.first_msg[node]
        if msgcount:
            missedprc = 100.0 * self.missed[node] / msgcount;
            missedprc = 0

and is located here: emonhub/src/ at master · openenergymonitor/emonhub · GitHub

Even more specifically, all sensor data from the emonTx is packaged into a single message, the count is the serial number of the message before it is passed to the radio library (ISM band radio) or the WiFi module for transmission.
Therefore, any automatic re-transmission that happens entirely within the library or WiFi module due to failed messages or collisions does not affect the count.

@Robert.Wall @TrystanLea
thank you both for helping to educate me. It is greatly appreciated.
So, am I correct that I should expect 8,640 messages per day as a reference point?


From an emonTx? Unfortunately, no.

Explanation of Fixed Interval TimeSeries.

Think of the emonCMS FITS Feed as a line of boxes moving along a conveyor. The speed of the conveyor - the time it takes a box to go past a fixed point - is the “Feed Interval” If there’s a box going past every 10 s but data falls onto the conveyor every 30 s, two boxes out of three will move on empty, with no data in them (a NULL value). The device sending data to emonCMS needs to send it just slightly more frequently than the Feed interval you choose when you create the Feed. If there’s already data in the box and it hasn’t moved on, it will overlay the data already in there, which is lost. But you won’t have null values in the Feed.

The same applies to any Feed and any timebase - and the boxes move on the Internet minute, or multiples or sub-multiples thereof. i.e., a 10 s feed happens on the minute and at 10, 20 etc seconds past.

If you can always guarantee that the source will send the data in the middle of a time slot by Internet time, you can safely match the rates exactly.

Where the sender, the emonTx for example, depends on a crystal tolerance for its timebase, or there might be transmission delays, we set it to send every 9.96 seconds and use a 10 s feed interval. Similarly, the emonTH is set to send every 58 s approximately and uses a 60 s interval.

Great analogy. I get it now.
Thanks so much for taking the time to explain this.
Best regards,

I am still a bit mystified by the numbers here - from my emonBase, for different nodes:

MSG          missed       missedprc    100*(missed/MSG)
205343       27899        26.16         13.59
195584       10825         9.91          5.53 
211192        3249         2.98          1.54
 34962        3515        10.05         10.05
249743        4073         3.71          1.63

A bit of nit-picking here, but only the 10.05% result is consistent?

The only thing that comes to mind is a power failure at either or both the TX and the RX. I can see from the Arduino code that after a restart, the TX will reset MSG to zero.

Any thoughts?

Hello @rupert

The missed count is reset in a couple of different situations:

  • EmonTx4 or other radio node power cycle - emonHub detects that MSG has reset to zero and therefore resets the missed count.

  • emonHub service restart, missed count is also reset in this instance even if e.g MSG count form the emonTx4 has not reset and could be 100000 and climbing.

If we take your first result there:

205343       27899        26.16         13.59

emonHub was likely restarted at some point after the first node power cycled. It has therefore only been counting missed packets over 27899/0.2616 = 106647 packets or from message 205343 - 106647 = 98696 onwards.

A good way to illustrate this is if you restart the emonHub service now but do not power cycle your nodes. You will notice that missed and missedprc reset to zero.

Hi @TrystanLea

Thanks very much for the explanation. I think I did restart emonHub a few times lately!

It’s nice to know how the numbers are derived!

Might we worth adding to the docs?

1 Like