User manual

2. SNAP Overview

SNAP is a family of soware technologies that together form an integrated, end-to-end soluon for wireless

monitoring and control. The latest version is 2.5, which this document covers.

Key features of SNAP

• All devices are peers – any device can be a bridge for Portal, do mesh roung, sleep, etc. There are no

“coordinators” in SNAP.

• SNAP implements a full mesh topology. Any node can talk directly to any other node within radio range,

and can talk indirectly to any node within the SNAP network.

• Communicaon among devices can be unicast (addressed to a speciﬁc desnaon, with acknowledged

receipt, retrying as appropriate) or mulcast (unacknowledged, only sent once, and potenally acted on

by mulple recipients).

• Remote Procedure Call (RPC) among peers is the fundamental method of messaging.

• The PC based user interface (Portal) appears as a peer device on the SNAP network.

RPC

Remote Procedure Calls are a hallmark of SNAP interoperability. With RPCs, any node can make a request to

another node that it perform some task by running a funcon it knows. The calling node doesn’t need to know

anything about the task to be performed other than its name, and the task might or might not involve sending

data back to the calling node. (Such a data transfer would happen via a separate RPC call, this from the second

node back to the ﬁrst.)

All SNAP devices implement a core set of built-in funcons (procedures) to handle basic network conﬁguraon,

system services, and device hardware control. Addional user-deﬁned funcons may be uploaded to devices as

well. Funcons are deﬁned as SNAPpy scripts, in an embedded subset of the Python language called SNAPpy.

This upload process can occur over directly connected serial interfaces, or over the air.

Once uploaded, both the built-in funcons and the user-deﬁned funcons are callable locally (from within the

user-deﬁned script) or remotely by RPC from another node. These funcons may themselves invoke local and

remote funcons.

For example, imagine an HVAC system where the compressor unit communicates with the thermostat using

SNAP nodes. This could potenally allow a PC to become part of the network, to either query or control the

system.

The PC could send an askCurrentTemp RPC request to the thermostat, which could respond with a tellTemp RPC

back to the PC. The PC could send a setDesiredTemp RPC call to the thermostat, which (depending on how

things are set and the ambient condions) might then make RPC calls to the compressor unit to turn the unit on

or to change its mode from heang to cooling, for example.

Each of these commands in a SNAP network is a separate, independent RPC call, acted on by the recipient of the

call. In each case, the calling node does not need to know the implementaon of the funcon at the called node.

For example, the SNAPpy script in the PC node does not need to have an askCurrentTemp() funcon deﬁned in

order to be able to request that the thermostat node run its askCurrentTemp() funcon.

4 SNAP® Network Operang System