Message & event passing

All event exchanges, i.e. asynchronous triggers, calls to action, state updates, etc, between Nodes and the Cloud exclusively happen through the PortEventMsg API message:

PORTEVENTMSG

            
public class PortEventMsg : ApiMsg
{
    public PortEvent[] PortEvents;

    public PortEventMsg() : base() { }
}
            
        

Each message contains an array of simple PortEvent entries:

            
public class PortEvent
{
    public string PortKey;
    public string State;
    public uint RevNum;
    public ulong Timestamp;
}
            
        
 Port Events for inactive ports
To aid power consumption on the Node side, and also save channel bandwidth, it is advised that Nodes do not send Port Event messages for Ports that are inactive.
See below at ActivePortKeys for what active/inactive means, and how to check

Synchronising states between Nodes and the Cloud


In the case where states of Ports between the Cloud and Nodes get out-of-sync, some tools are offered to rectify this, in the form of Port State messages. These messages exchange similar information about states as Port Events but do not trigger any action on the receiver apart from an update of their internal house-keeping.

PORTSTATEREQ

This Request is sent from either the Node or the Cloud Server to ask for an update, according to the message’s Operation field. The receiving end must respond with a PortStateRsp in an RPC-compliant way.

            
public class PortStateReq : ApiMsg
{
    public ePortStateOperation Operation;
    public string[] PortKeys;
    
    public PortStateRsp() : base()
    {
        this.Id = eApiType.PortStateReq;
    }
}
            
        

PORTSTATERSP

This message is the response to the previous PortStateReq message. As always, the message’s ResponseToSeqNo will be set to the original request’s SeqNo

In detail the message is:

            
public class PortStateRsp : ApiMsg
{
    public ePortStateOperation Operation;
    public PortState[] PortStates;
    
    public PortStateRsp() : base()
    {
        this.Id = eApiType.PortStateRsp;
    }
}
            
        

The message’s fields are:

 ‘Active’ Port
A port is considered active when:
  • its parent Thing is placed in at least one Graph that is currently deployed (not just saved)
  • the port itself is actually connected to another block's port

As expected, the PortState class is very similar to the previously described PortEvent class, with a simple addition:

            
public class PortState
{
    public string PortKey;
    public string State;
    public int RevNum;
      
    public bool IsDeployed; //<-- this one!
}
            
        

The extra field IsDeployed specifies whether the referenced port is currently active and connected in deployed graphs.

The rest of the field convey the same information as in a Port Event, but without acting/triggering any actions on this data.

ACTIVEPORTKEYSMSG

This message is an asynchronous message from the Cloud to a Node to inform the latter of which Ports are currently active. This usually happens because the user deployed or undeployed a graph (hence adding/removing Things or changing Port connections) through the Cyan environment.

The contents of the message are extremely simple, as the Node is expected to simply discard its old set of active PortKey values and replace it with the one specified by this message:

            
public class ActivePortKeysMsg : ApiMsg
{
    public String[] ActivePortKeys;

    public ActivePortKeysMsg() : base()
    {
        this.Id = eApiType.ActivePortKeysMsg;
    }
}
            
        

Nodes are expected to keep track of, and only send events for those Ports that are currently active, thus reducing power consumption on the node and traffic on the medium.