The Zigbee Alliance this week offered — nine months after announcing it was forthcoming — an update on Project Connected Home over IP, an effort by Apple, Amazon, Google, Samsung, and others to create some kind of interoperability standard for the smart home. There are A LOT of cooks in this kitchen, with 145 separate companies and more than 1,300 individuals signed working on CHIP. It is a titanic effort.The good news is that the standard is still on track, with a certification coming later this year and actual certified products anticipated in 2021. The Alliance also provided a list of devices that CHIP will focus on; it includes lighting, HVAC, locks, security, shades, and more, but neither smart speakers nor white goods, such as large appliances. And to round things out, it offered a GitHub repository and a detailed look at some of the levels where CHIP will seek standardization. (The diagram can be found in the photo accompanying the podcast post below). But in many ways, the update was disappointing.

Source: Stacey on IoT | CHIP products will be out next year

The mailbox sensor still works. Not for I trust it fully yet. But I will, eventually.

For me its always been a bit strange to dub MQTT as an IoT protocol.  Well noways it’s even a standard. Strange to. It just does not solve the ‘problem’ as VSCP (Very Simple Control Protocol) for instance (and others) do. But nevertheless, as a general transport protocol, it is VERY useful. There is tons of code out there making it even more interesting to use. Very useful. Love it.

I know. It is tempting to send “ON” and “OFF” or “23.789”  on a topic to a MQTT broker. Simple and easy to understand and handle. The one problem is that others solving problems like the one you solve will send  “AUF” and “AUS” and “74.8202” meaning the exact same thing. It is hard to write stuff that can be reused and even work with stuff from different vendors with that approach.

It’s better to standardize what is what and stick to that standard. In that case an “ON” from one vendor of a device is understood by another vendor with a different device. Same for measurements. There are just a few SI units. But many units derive from them. If standardized a temperature in degrees Celsius is equally understandable on the receiving side as a temperature in degrees Fahrenheit (or even Kelvin).

VSCP defined events and other solutions for this twenty years ago. Not many people use VSCP today and have ever been using it for that matter (or will use it) and hopefully one of the big companies make a similar solution – calling it a new invention and revolutionizing – so we get an adoption of a system that help us write thing once and use it many, many times. Move things forward instead of we doing the same thing over again and again. I will be the firsts to applause such a thing when it happens. Because it will. One day.

I will not go further into VSCP and what it is and what it can do here. You are probably not interested (if you are look here https://docs.vscp.org/ ) anyway. That is OK. But I will show how VSCP events are transferred over MQTT. Or rather, I will show one way to transfer VSCP events over MQTT (guess which one is the IoT protocol and which one that is the transport protocol).

VSCP events are more or less the same as messages.  But “event” better describe the asynchronicity of events,  a button is pressed – an event is sent. VSCP events have a source, a class, a type and some data. The source tells who sent it. The class what class of events (measurement/information/data…) it is. The type is more specific of the event type. Data holds the actual info of the event.

Depending on the medium that carry the event a VSCP event is packed in different formats. Ethernet and CAN, for example, use a binary format for efficiency. Higher level protocols like MQTT does not (normally) need this efficiency. So here a VSCP event is packed as either a XML or JSON formatted message.

We are just interested in JSON format here but you have both described in the VSCP specification.

A VSCP event looks like this in JSON format

{   
   "vscpHead":0,
   "vscpObId":0,
   "vscpClass":10,
   "vscpType":6,
   "vscpGuid":"ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00",
   "vscpTimeStamp":1234567,
   "vscpDateTime":"2018-03-03T12:01:40Z",
   "vscpData":[1,2,3,4],
   "note":"Some optional note about event",
   "unit":0,
   "sensorindex":0,
   "coding":0,
   "value":1.2345
}

There are some extra fields we did not explain above and you have to read the VSCP specification to get info about them. But you recognize vscpGuid which is the ‘source’, this is the id/address for the device that sent the event. vscpClass is the class, vscpType is the type. VscpData is the actual data. This data is always in bytes but very well specified in both format and such things as byte order. Usually on a higher level you can handle this data with higher level functions and don’t need to care about the actual format it have.

So when a VSCP event is sent over MQTT this is what is sent.

For “ON” this will look like

{   
   "vscpHead":16343,
   "vscpObId":9,
   "vscpClass":20,
   "vscpType":3,
   "vscpGuid":"ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00",
   "vscpTimeStamp":1234567,
   "vscpDateTime":"2020-08-03T12:01:40Z",
   "vscpData":[0,0,0],
}

This is the  VSCP ON event.

Similar for a VSCP OFF event which looks like

{   
   "vscpHead":16343,
   "vscpObId":9,
   "vscpClass":20,
   "vscpType":4,
   "vscpGuid":"ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00",
   "vscpTimeStamp":1234567,
   "vscpDateTime":"2020-08-03T12:01:40Z",
   "vscpData":[0,0,0],
}

or for a temperature measurement

{   
   "vscpHead":16343,
   "vscpObId":9,
   "vscpClass":10,
   "vscpType":6,
   "vscpGuid":"ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00",
   "vscpTimeStamp":1234567,
   "vscpDateTime":"2020-08-03T12:01:40Z",
   "vscpData":[0xa8,0x41,0xcc,0x41,0x00],
}

In this case a temperature in degrees Celsius, coded as a 32-bit floating point value.

It is now possible to send VSCP events on any MQTT topic. But it is good to follow a specific scenario for the topics as well. Suggested for VSCP events is

prefix/guid/class/type

‘prefix‘ can be ‘vscp‘ or ‘/aaa/bb/cc/tt/yy‘ or something else.

Using this schema we can subscribe to the MQTT topic

/prefix/#

to see every event that is received from our setup.

If we just want all events from a specific remote node we can subscribe to

/prefix/guid/#

or if we want all all temperature events from a specific node

/prefix/guid/10/6

or temperature events from all VSCP nodes in the setup

/prefix/%/10/6

It’s just as simple as that.

Don’t just send magic numbers or “ON” or “OFF” anymore. Please!