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.
@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 emonCMS.org?
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?
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)
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.
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?
Thanks,
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.
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.
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.