Things management & control

The main way for Nodes and the Cloud to exchange information about Nodes’ Things are the Things Get/Set messages


A Things Get request can be used by either the Cloud or Nodes to request information from the receiver. Its contents are:

public class ThingsGet : ApiMsg
    public eThingsOperation Operation;
    public string ThingKey
    public int RevNum;
    public ThingsGet() : base() { }

Any endpoint can send this message at any time to request any Things-related update from the other end. The message contains:


The ThingsSet message is either a response to a ThingsGet message, or a new message that must be handled by the receiver. In both case it must follow the previously mentioned conventions about blocking messages. If it initiates a new action, then it expects a GenericRsp message as a response. Otherwise it itself is a response to a previous ThingsGet message.

public class ThingsSet : ApiMsg
    public eThingsOperation Operation;
    public bool Status;
    public Thing[] Data;
    public int RevNum;
    public ThingsSet() : base() { }

The message’s fields are:


Possible Things Operations are the following:

For operations Get and Scan, the responding device is free to choose the proper Operation id for its response (Update to add a few new Things, or Overwrite to send a new full suite of Things)

 Updating Things’ configuration parameters
The cloud side will also set new configuration values this way, i.e. it will send a ThingsSet message with updated contents of Thing.Config[] fields and the Node is expected to parse them and update its internal configuration accordingly, as well as reply with a GenericRsp

However if you're using the existing Yodiwo Agents (iOS, Java) or helper libraries (C#) you shouldn't have to worry about this, as they handle such scenarios and call the callbacks that you provide