Heartbeat message

[martinjaeger]

As suggested by @b0661, it would be good to get informed if a device got disconnected. If the device does not send regular statements with e.g. measurement values, one could require it to send a regular heartbeat message.

Message content

The heartbeat message should be a normal statement. The content of the message is yet to be defined.

Possible options:

1. The node ID. This is useful to be able to assign e.g. CAN addresses to the node ID without requesting it from the device.
2. The uptime of the device in seconds. This would allow a gateway or a cloud service to store the previously received uptime. If the current uptime is less than the previous one, it means that the device has been restarted or disconnected in between, so some of the device data may have to be requested again.
3. An update counter (also suggested by @b0661 in Updates for ThingSet Protocol draft v0.5 thingset-device-library#24). This would allow a gateway or cloud service to know if the content of the data objects has been updated. If the counter value doesn't match the one it knows, it may want to request some data again. In addition to that, the counter would also allow to detect if a device has restarted if the received counter value is lower than the known one.

Message frequency

As ThingSet can be used in many different contexts, the message frequency has to be adapted to the underlying protocol. Here is a first suggestion for suitable frequencies of the heartbeat.

• CAN bus: 1 second
• Serial interface: 60 seconds
• LoRaWAN: 1 hour

These are some first ideas for further discussion. I personally think that the uptime and/or the update counter would provide more useful information than the node ID.

[b0661]

My suggestion for the heartbeat statement

• The node ID.
• Update counter.
• Protocol version 0.
• Actual period of heartbeat statements. It is defined in units of 1 second.

Actual period should be a property of a communication port. It may be controllable by a data object.

personally think that the uptime and/or the update counter would provide more useful information than the node ID.

You are right in case of a node on a CAN bus as you might get a unique node identification from the CAN ID. If you imaging communication without explicit addressing this may be different.

[martinjaeger]

For the CAN bus we are limited to 8 bytes per frame for any broadcast message, so it's not possible to fit that much data into the heartbeat message. For CAN we should have very short messages, but send them often to realize quickly if a device has disappeared in control application. So we should avoid to send any static information like protocol version and node ID repeatedly.

So we'll may have to define different heartbeat content depending on the context. I agree that for your mesh approach it may be required to have more information in the heartbeat.

[b0661]

So we'll may have to define different heartbeat content depending on the context. I agree that for your mesh approach it may be required to have more information in the heartbeat.

I would prefer to have the same heartbeat. We could have a sequence of heartbeat messages that in total provide all the info. This way we may well stay in the 8 bytes limit of CAN.

[martinjaeger]

Unfortunately, the 8-byte node ID does not even fit into a single CAN frame, as it consumes 9 bytes (first byte for CBOR specifier saying that 8 bytes of string data follow).

Segmented messages also create additional difficulties as you need to keep track of the state. What happens if one part of the combined heartbeat message is not received? Should the rest be discarded? How do we know which segment belongs to which heartbeat message? That's all handled by the ISO-TP protocol for 1:1 communication, but it does not work for broadcast messages.

[b0661]

Unfortunately, the 8-byte node ID does not even fit into a single CAN frame

I think you are addressing a more general problem of CAN messages - how do I transfer longer payloads?

In the case of node-ids one may use only part of the id and provide a data object to fetch the whole node id. A CAN port may handle that transparently. If these short parts of the node-ids clash you may at least issue an error message.

In my mesh example I have two messages - a heartbeat statement and an originator statement.