Challenges with the Current HELIO Messaging API v0

• The current version of the Messaging API has caused conflicts with specific types of PLC.
• The problems seem to arise from the fact that we assume far more freedoms that cannot be covered with the actual development tools. For example setting a variable of type Date to null.

1. Challenge: acknowledgeMessage receives an argument that is not PLC-conformant

In version 0, the acknowledgeMessage method defines a parameter named messageId. However, the actual parameter is not a single id, but a JSON array that includes one messageId. This appears to cause problems with certain PLCs.

<aside> <img src="/icons/light-bulb_gray.svg" alt="/icons/light-bulb_gray.svg" width="40px" /> Desired Solution

Send only a single messageId as String variable:

→ acknowledgeMessage(messageId:string)

</aside>

2. Challenge: Using dates to mark messages as active, incoming, or acknowledged is not precise and requires acknowledgedOn to be nullable

Marking a message as incoming/active requires the PLC to set the acknowledgedOn variable which is of type Date to Null . This cannot be achieved on some PLCs.

<aside> <img src="/icons/light-bulb_gray.svg" alt="/icons/light-bulb_gray.svg" width="40px" /> Desired Solution

• Introduce an additional boolean property for messages called wasAcknowledged which has to be set to false if the message is incoming and to true if the message has been acknowledged.

Before

interface message {
	acknowledgedOn: Date | Null;
	arrivedOn: Date;
  canAcknowledge: boolean;
	...
} 

After

interface Message {
  // Initial value: false
	// Once acknowleged: true
  WasAcknowledged: boolean;

  // Initial value: Same as ArrivedOn
	// Once acknowleged: Date of Acknowledgement
	AcknowledgedOn: Date;

	ArrivedOn: Date;

	CanAcknowledge: boolean;
	...
} 

</aside>

3. Methods and properties are defined using camelCase, instead of the more commonly used PascalCase in the PLC context

All methods (e.g. acknowledgeMessage) or properties (message.id etc.) of messages are defined in camelCase while PascalCase is the default way to name things – at least in OPC UA. In order to avoid confusion we should follow this way.

<aside> <img src="/icons/light-bulb_gray.svg" alt="/icons/light-bulb_gray.svg" width="40px" /> Desired Solution

Make all methods, properties and parameters pascal case.

</aside>

How would the updated API look like?