Sensors and Resources what is the difference?


In Waylay terminology, a resource is not strictly assigned to a device. Resource can be any entity you can think of, such as a physical device, a parking lot, a house or a city. Since Waylay platform is use case agnostic, naming entities only as devices would be limiting.

Waylay Rules Engine is a Smart Agent that observes its environment via software-defined sensors and acts on its environment through software-defined actuators, hence often people assume that resource and software-defined sensor is the same concept.

So, let’s first quickly go back to definitions of resources and sensors, before we see how they relate to each other.


How resources get created in Waylay? Every time data arrives, Waylay checks if a resource that is associated with that data already exists. If not, Waylay will create a new resource automatically.

Resource can also be created using REST interface or via UI. Resource concept is important in many different ways:

  • we can associate data with a resource
  • we can associate metadata with a resource
  • we can associate sensors or actuators to the resource (in that case a resource can be seen as the ‘address space’, allowing the rule engine to route calls to all sensors of the running tasks)

We have also seen how we can group resources together using resource type concept that enables applying the same rules (tasks) across all these resources.


Waylay is a cloud-based agent architecture that observes its environment via software-defined sensors and acts on its environment through software-defined actuators. Waylay lambda functions (𝛌) are defined as either sensors or actuators. Sensors are “typed” 𝛌 functions, which can return back a state, data or both - that is what we call an observation. As you can see from the picture below, observations are not limited to physical devices only.

Smart agent concept

We have already mentioned earlier that resources are not nessearly devices, but we still have to explain why software defined sensors are not just resources. Saying that sensor is actually a 𝛌 function rather than stored resource data is one way to explain it. But saying that sensor is a broader concept than resource, the same way resource is broader concept than device is not entirely correct. Reason being that sensors model information, while resources model entities. More over, as we shall see, Waylay Rules engine doesn’t model objects and their relations. Rules are based on the information flow, and in that respect, sensor is a different concept than resource all together.

Loose coupling between sensors and resources

When we want use a resource concept in the Rule Designer, we attach a resource to the node of the underlying sensor (allowing the Rule Engine to route calls to that node)

This is how you assign a resource to a sensor in the Rule Designer: resources

In this example, we attached the resource 151CF to the node. That means that any time data arrives for the resource 151CF, underlying sensor function will be called (if the node settings Execute on tick is enabled). Underlying function will also have the access to the payload which triggered the sensor execution (below presented as the streamdata variable), and the resource name, in this example 151CF, as given in this snippet below:

var resource = waylayUtil.getResource(options)
var streamdata = waylayUtil.getStreamData(options)

Similar code is used in all Streaming sensors. These are the sensors that are suppose to be called every time new data arrives. In the article Threshold crossing with stream data you can find how rules are created with streaming sensors.

In the next example, we see how the sensor that retrieves resource metadata gets input arguments:


Please note that we have used resource as a name in the input argument (right side of the screen) only for the convenience reasons. Let’s look closely into this line of code, since few things are happening here:

var thing  = waylayUtil.getProperty(options, "resource") || waylayUtil.getResource(options)

As written above, this sensor function uses as the input argument resource which is either:

  • defined via input sensor settings or as the output of other sensor execution (by chaining sensors), using this notation: waylayUtil.getProperty(options, "resource")
  • or given as the input argument via node settings: waylayUtil.getResource(options)

When we place this sensor in the rule designer, we can either type resource name - as a fixed name noted by A), or use node settings, in this case $ which allows resource template inheritance, noted by B) or retrieve the input variable from anther sensor result (by notation NODE.x, where x is the raw data output of the NODE sensor, noted by C)


In this example, we take as the input argument resource which is result of the database query (result of mysql node execution): resources

In case we want to use in the rule a data which is stored for a given resource (using our time series database), we can use for instance getAverageFromTS sensor:


If we check the code of this sensor, we will see some familiar lines:

var resource  = waylayUtil.getProperty(options, "resource") || waylayUtil.getResource(options) 
var metric = waylayUtil.getProperty(options, "metric")
var from = moment().subtract(parseInt(hours),'hours');
var qs = {from: from.unix() * 1000, grouping: "hour"};, metric, qs)
.then(data => {