MEA billing when sending multiple measurements in one JSON via MQTT call

Forum
1

Hi all,
I am creating multiple measurements using JSON via MQTT including multiple time fragments in one message. As the data is send together, the creationTime fragment will be the same.

Does this count as 1 or multiple MEA in terms of billing?

Stating it more general: What is the exact technical characteristic used as billing metric?

1 Like
2

The MEA (Measurement, Event, Alarm) metric in Cumulocity counts the number of measurement, event, and alarm objects that are created or updated.

  • If you create multiple measurement objects, each one is counted separately for billing purposes, regardless of whether their creationTime is the same.
  • A single measurement object that includes multiple measurement series (i.e., different fragments/values under one object) is still counted as one MEA.

In your case:
If your MQTT message results in the creation of multiple individual measurement objects—despite sharing the same creationTime—each of those objects will count as one MEA.

2 Likes
3

Thanks you for your fast answer :+1:.

Summarizing in my words:
When trying to save money by batching data together and sending it in a way that creates only 1 MEA billing unit, the limit is that all datapoints must be send in one measurement object.

Looking at the structure of such an object:

 {
    "source": { "id": "681200" },
    "time": "2020-03-19T12:03:27.845Z",
    "type": "temperatureMeasurement",

    "MyMeasurementFragment1": {
        "MySeries1": { "value": 42.7, "unit": "C" },
        "MySeries2": { "value": 13.37, "unit": "%RH" }
      },
    "MyMeasurementFragment2": {
        "MySeries3": { "value": 50, "unit": "F" },
        "MySeries4": { "value": 60, "unit": "Watt" }
      }
}

All datapoints inside this objects must have:

  • The same time
  • The same type
  • The same source (implicitly set by the topic when using JSON via MQTT)
2 Likes
4

Hi Eric, yes, indeed, your understanding is correct.

If you send multiple measurements in a single message, then each measurement would be counted individually. For example, if you sent the following payload, two measurements would be created and counted:

{
  "measurements": [
    {
      "c8y_SpeedMeasurement": {
        "speed": {
          "value": 25,
          "unit": "km/h"
        }
      },
      "time": "2013-06-22T17:03:14.000+02:00",
      "source": {
        "id": "3201"
      },
      "type": "c8y_SpeedMeasurement"
    },
    {
      "c8y_SpeedMeasurement": {
        "speed": {
          "value": 22,
          "unit": "km/h"
        }
      },
      "time": "2013-06-22T17:05:14.000+02:00",
      "source": {
        "id": "3201"
      },
      "type": "c8y_SpeedMeasurement"
    }
  ]
}

However, if you send a single measurement with multiple data points, it will only count as one measurement. For example, if you sent the following payload, only one measurement would be created and counted:

{
  "measurements": [
    {
      "c8y_SpeedMeasurement": {
        "speed": {
          "value": 25,
          "unit": "km/h"
        },
        "speed2": {
          "value": 22,
          "unit": "km/h"
        }
      },
      "time": "2013-06-22T17:03:14.000+02:00",
      "source": {
        "id": "3201"
      },
      "type": "c8y_SpeedMeasurement"
    }
  ]
}
3 Likes
5

Is it clear from License metrics - Cumulocity documentation?

1 Like
6

Hi Andre,

these license metrics are only valid for customers who are on the new contract model that is being gradually rolled out starting with new customers.
The MEA metric is not part of that model but has been extended towards the “Messages” metrics that is explained here.
@Eric_Sander your feedback on wether the metric explanation is clear and easy to understand would still be helpful!

Cheers,
Niko

1 Like
7

Hi Nikolaus,
I think the definition works well from a business perspective. However, some more precise technical words e.g. on REST / HTTP verbs and their impact on billing as well as the the example from Tal would support to make understanding this topic easier.

2 Likes
8

Can you please help me with the semantics of a measurement type? If the type defines the kind of measurement (e.g. speed, like above) it would not make sense to send a speed measurement plus, let’s say, a pressure measurement in one object, since you end up with a pressure measurement labeled as a speed measurement. While in Tal’s example above, two speed measurements with the same time stamp (one of the three requirements for being counted as one message) does not make sense too, since a physical object can have only one speed at a point in time.

Hence saving money by combining measurements makes only sense for combined measurements. e.g. colour that is composed by three measurements for hue, saturation and brightness. Or acceleration with x, y, z values measured. Right?

For all other cases, you mess up the semantics of your measurements. It this thought right, or am I missing reasonable examples for grouping measurements?