Interconnection Concepts and Topology


An abstract block diagram of the platform’s components and logical interconnections is shown here:

Alt Yodiwo Cloud Platform

The following block diagram shows the various entities that make up the Yodiwo ecosystem in more detail:

Alt Yodiwo Ecosystem

It can be summarized as follows:


A Yodiwo Node is any IP-aware device or software entity that implements the Plegma API and can directly connect to Alcyone,regardless of protocol used

Nodes can simultaneously mix and match several features:


A Node must be assigned to a known Yodiwo user and given a globally unique Node Key and Secret Key via a process known as Pairing.

API messages may only be exchanged with paired Nodes.

After pairing the Yodiwo cloud service accepts, saves,maintains and presents (through Cyan) a list of Things from each Node. User state and context are retained across user sessions and can be used in Stories where they are interconnected with Services via Logic that the User defines and fine-tunes.

Types of nodes

A Yodiwo Node can be a monolithic entity created from scratch to provide specific features, or it can use a Plugin architecture to support live, on-the-fly, additions and removals of functionality bundles.

Yodiwo makes extensive use of the cross-platform .Net framework to provide SDKs for both of the above scenarios.

Yodiwo also provides many Node examples in various other languages and platforms:

Execution environment

Nodes can run on:

Obviously not all of the features mentioned in the previous paragraphs are available on all HW/SW combinations.


A Yodiwo Thing is a model of a physical device or virtual service that virtualizes specific functionality.

In practical terms, Yodiwo Things encapsulate and represent “bundles” of related functionality, e.g. a Thing may be a thermostat which has an output (its temperature readout) and one or more inputs (for controlling and configuring it).

In general any Thing:

Other Entities


Sub-nodes are groups of Things that belong to a Node but are in separate subcategory of it

For example, they can be used:


Endpoints are identical but “physically” different Nodes. They share the same code, UUID and keys.

Sensor-type events one of them sends are broadcast to all other Endpoints of the same Node. Actuation events are sent to all registered Endpoints.

Keys and Addressing

Every single entity in the Yodiwo topology (Nodes,Endpoints, sub-Nodes, Things, Ports, etc) is uniquely and individually addressable via the Plegma API.

There is clear and strictly defined hierarchy between them:

Each of them has a unique Key that is derived from the previous one in its hierarchy, i.e. a Node Key is used to create a Thing Key and this in turn is used to create a Port Key.

Thus, receiving a message about a single Port (channel) indicates:

Any operation can be cross-checked and validated:

“Broadcast” keys are also supported:

Thing Grouping & Thing Sharing

Thing Grouping

A Yodiwo Thing may have a Type and belong in one or more Hierachies.

A Type:

A multitude of basic types (button, location, NFC, BLE beacon, actuator, etc) are defined by Yodiwo. However, Types may also be defined by a 3rd party Node Publisher and provided to Yodiwo at Node connection (via the Plegma API).

Users may also assign one or more Tags to Things via Cyan or the Warlock API.

Things may be grouped per Type, Tag, Hierarchy or manually by the User, again either via Cyan or the Warlock client API.

Each Group has a unique Group Key according to the rules defined in the previous section. Groups appear as a single entity in Cyan and can be used in “Stories” to apply the same logic to a bundle of Things.

Events from any Thing in a Sensor-type Group (Input to Cloud) will trigger all stories the Group has been used in, while still retaining the Thing Key of the triggering device or service. This Thing Key may then be used as the key to database accesses, etc.

An actuator-type group may also be placed into stories (Graphs) and the user may choose if the event should be propagated to all Things of the Group or a single one.

Groups may also be used to perform large scale device management. A user may mass-apply configurations or set the state for a specific Port in all Things of a Group.

Thing Sharing

Users may share any Thing they own to other Users.

Shared Things then appear on Cyan in a separate, per-sharer category, and can be used in Stories.

Sensor-type Events from Shared Things trigger:

Actuator-type shared Things may be triggered by:

Sharing preferences may be defined by users via a UI client. Users (the “Sharees”) receiving the shared Things may have chosen to:

Re-sharing a shared Thing is never allowed.