by Ed Hemphill
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.
- Relay executes code, triggering two asynchronous network events
- 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:
- 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.
- 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]
- Relay B gets a message from the motion sensor. This event is mapped to the function
func1() 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.
- 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.
- Relay C recieves the message of ‘motion’ triggering the execution of
func1. It turns its local lights on.
by Ed Hemphill
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.
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
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.
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:
- In this very simple script, which turns all devices categorized as ‘light’ on, the execution kicks off from the leader, Relay A.
- 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.