Showing 3 posts.

Efficient Selectors

by Ed Hemphill

Simple example:

A single relay A executes:


This will turn all devices tagged as a ‘light’ to off. The most efficient way to do this is use a broadcast for certain devices, in this case the ZigBee devices.

  1. Relay executes code, triggering two asynchronous network events
  2. The relay sends unicast network traffic to the single 6loWPAN light… and at the same time sends a broadcast ZigBee message to the ZigBee lights.

Selectors Across Physical Locations

When you have a selector which spans multiple locations, DeviceJS distributes commands to multiple locations simultaneously:

Back to our example code


If this script was executed in a DeviceJS configuration such as below from relay A:


then relay A would determine that all lights were on downline relays.

The steps would be:

  1. Relay A evaluates the script, and sees that all the devices are off relays B and C. It sends a message stating it’s reached this portion of the script, and B and C need to execute it from this point.
  2. Relays B and C would turn off the lights.


Selectors may be used to trigger events. Here a motion sensor is added into the scenario. Relay B talks to this motion sensor. When looking at this example, remember that DeviceJS scripts run on a system of relays, not a single relay. So the same script is residing at every relay, and is actively running. (In this case waiting for ‘motion’). [How it works]


function func1(){
dev$.trigger('motion', func1);


  1. Relay B gets a message from the motion sensor. This event is mapped to the functionfunc1func1() executes. Locally it immediately turns on the locally connected light. It also sends a message to the upline relay A that the motion event has happened.
  2. The upline relay A receives the message that ‘motion’ has occurred and passes the message to other relays – the only other relay is C. It also executes func1 which does nothing locally.
  3. Relay C recieves the message of ‘motion’ triggering the execution of func1. It turns its local lights on.


DeviceJS is Javascript for the Physical World

by Ed Hemphill

Why JavaScript?

JavaScript is by far the most widely used language in the open source community. It’s easy to write simple scripts and it’s powerful enough to do complex tasks. Most importantly, it’s very well known by many programmers.

One script, execute it everywhere

Real world, complex sensor networks and automated systems often span multiple locations. In traditional systems, this means maintaining multiple controllers and managing programs which run on these different systems, ensuring they can talk to one-another. DeviceJS let’s you write a single program and distribute it over multiple controllers in different locations transparently. This means from a developer’s or maintainer’s viewpoint, the system can be much simpler. DeviceJS can distribute a script across any relay capable of running the DeviceJS run-time.

More: How it works

Patterns you already know

DeviceJS aims to enable developers familiar with client side web development libraries to easily make things happen dynamically in the physical world.


A simple example is the selector pattern, seen in frameworks like jQuery and d3.js.

Turn all paragraph text to red in jQuery:


The same thing in d3.js:


A similar pattern in DeviceJS – turn all lighting in a location red:



In jQuery this would pop-up an alert dialog box on a ‘click’:


In the physical world, we could handle things similarly with DeviceJS:


DeviceJS also allows trigger evaluation functions, which can help determine whether a sensor event issignficant.

More information will be available when DeviceJS is released on github and the API is published.



How it works

by Ed Hemphill

Beyond this DeviceJS adds a number of capabilities:

  • A realtime, distributed JSON database, which updates live directly into the DeviceJS runtime.
  • Object based API, roughly based of base2 and Prototype
  • Service hooks to native device drivers for protocols like: 6loWPAN, Z-Wave and ZigBee
  • A Catalog which allows devices of all kinds to be categorized and cross-referenced in a variety of ways
  • APIs for dealing with complex, asynchronous Javascript, similar in concept to async.js


The most important difference of DeviceJS over other Javascript runtimes is how it executes. DeviceJS is a distributed system. Scripts/applications written for DeviceJS can execute and consequently control devices in many locations. Applications control a system, and a systemmay involve devices which reside in different locations. An application runs not a single DeviceJS runtime, but on a team of runtimes, and those may be located together on the same LAN (for instance floors in a building) or, instead, geographically apart across a WAN (buildings in different cities across the world).

From the application programmer’s view point, the physical location of the runtimes does not have to be a factor – although it can be considered if desired. This also means that if devices jump, or move between locations, an application does not need to be modified. An example might be a mobile sensor which moves from one location to another.

Script distribution
When an application is started the same script is sent to every DeviceJS runtime in theteam. It’s how each runtime executes this script that makes the difference. Which ever DeviceJS runtime that kicked off the script is considered the leader. The leader leads execution down the script. Let’s take an example:



    .byTag("light")// select devices tagged as a 'light' // here the lead relay signals the downline relays.setOn();// Relay B & C turns lights on...

There are two steps:

  1. In this very simple script, which turns all devices categorized as ‘light’ on, the execution kicks off from the leader, Relay A.
  2. Relay A has no lights, so it does nothing locally. It informs Relays B & C that the script is kicked off. They have the same script and execute it, turning their own local lights on.