The #MQTT content standard

How many variants of this

{
        "Battery" : 255,
        "Level" : 34,
        "RSSI" : 12,
        "description" : "",
        "dtype" : "Light/Switch",
        "hwid" : "3",
        "id" : "00014070",
        "idx" : 32,
        "name" : "kapu nyit\u00e1s",
        "nvalue" : 2,
        "stype" : "Switch",
        "svalue1" : "34",
        "switchType" : "Dimmer",
        "unit" : 1
}

have you seen. A hundred? Thousands? A million?

Well it’s the “IoT standard” as long as this is transferred over MQTT.

• Not a single of the fields above is in any way “standardized”. No consensus around with anything. Not even a topic.
• A tiny device will have problem when reading this type of textual information.

Result: Fragmentation. No one understands anyone else data.

The solution

The solution for many is to do another definition of the above. Yes it is NOT an intelligent approach. It’s just like banging your head against a wall over and over again.

VSCP started to look at things from the other end for more then twenty years ago. Her the standardization was centered around what you send and not what you send it over.

VSCP consist of a set of well events with defined content.

• You know what to send.
• You know what to expect to receive.

Yes also from someone else.

This content can be transferred on many different transport mechanism. Yes MQTT to. You still know what to send and what to receive.

Look at a measurement unit for example. Is a temperature given as A Kelvin temperature, a Fahrenheit temperature, a Celsius temperature? Well all are defined in VSCP. Actually all SI units and SI defined units are defined with pseudo language conversions between the units.

For a tiny device the byte order and coding of data is important. In VSCP all that is well defined. Byte order is always big endian. No exception. You know what to get an how to interpret it.

So for a temperature measurement in VSCP for example the above would have the form as below if we use JSON (more info here)

{
    "vscpHead": 2,
    "vscpObId": 123,
    "vscpDateTime": "2017-01-13T10:16:02",
    "vscpTimeStamp":50817,
    "vscpClass": 10,
    "vscpType": 8,
    "vscpGuid": "00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:02",
    "vscpData": [1,2,3,4,5,6,7],
    "note": "This is some text"
}

“Note” is an optional field used mostly for log diagnostic. For a measurement events some additional fields are optionally available for convenience.

measurement {
    "value" : 1.23,
    "unit" : 0,
    "sensorindex" : 1,
    "zone" : 11,
    "subzone" : 22
}

So look at the filelds

• vscpHead – This a bitfeiled with flags with different meaning.
• vscpObId – Applications can use this 32-bit unsigned integer, the way the want. Typically used as a session id or similar.
• vscpDateTime – UTC date and time. If not set the current UTC time is set.
• vscpTimeStamp – Microsecond precision timestamp. A relative time that can be used to measure very precise inter event timeing for events from a specific device.
• vscpClass – The VSCP class is a code for a group of events. Typical a VSCP class specify events for alarms, measurement, information etc etc. For a temperature it is coded as 10. But as events are such a common IoT property there is a group of VSCP classes available for measurements. Check the VSCP specification for available events.
• vscpType – The VSCP type identify the actual event in the VSCP class. For a temperature it is coded as 6.
• Check the VSCP specification for available events.
• vscpGuid – This is a globally unique id for the device sending the event. The event can be derived from most other id’s such as a IPv4 or IPv6 or MAC address. More about VSCP GUID’s in the VSCP specification.
• vscpData – The event data. Well defined content. Max 512 bytes. Or just eight in constraint environments. Defined to be easy to read rfor machines – not for humans.

For the measurement extra filelds

• value – A floating point value for the measurement.
• unit – The unit for the measurement. Set to zero for the default unit. For temperature this is Kelvin. Unit 1 is degrees Celsius and unit 2 is degrees Fahrenheit.
• sensorindex – A device can have many sensors. The sensorindex is the id for a sensor on a device.
• zone/subzone – Used for grouping of devices and sensors. Can be sensors in devices in a specific location.

Why is a well specified format an advantage

Most important. If you know what to expect you can write handlers once and then reuse them for many cases. Also you can user tools developed by others in your setup. A typical example is a graphical presentation. Write it for one type of measurements and the same solution will be valid also for other types.

Same is true when you send things. To turn something on/off is as clear and concise as sending a measurement value.

It all will work on a constraint environment such as a CAN-bus as well as over tcp/ip.

Why do it all again and again and again, instead of once. Join the free, open and gratis world of VSCP.

You find the full VSCP specification here.