The vast and growing world of IoT data is tracking more real-world objects and processes than ever before. Chainlink External Adapters are well-suited to deliver IoT data through secure and reliable oracle networks to all kinds of IoT smart contract use cases, such as on-chain supply chain logic or tracking temperature data for smart contract insurance claims. Integrating RFID scanner (Radio Frequency Identification) data into the blockchain is one such example.

The Best Open Project Prize winners in the Chainlink Virtual Hackathon, developers Aram Moghaddassi and Aaron Wasserman, used a Chainlink External Adapter to connect an Arduino RFID to a Chainlink oracle for use in a decentralized book check-out and tracking system, called the Open Library Project.

In this tutorial post, Aram Moghaddassi explains how they implemented the project.

By Aram Moghaddassi

Hardware systems enabled on blockchains are a new frontier for smart contract developers. This post will cover inspiration, applications, and technical design for building such systems and be a tutorial (with examples) on how to integrate a simulated hardware backend for an RFID sensor on a Chainlink node into a smart contract.

The Potential for IoT Hardware and Smart Contracts

Blockchains and smart contracts have the potential to secure the tens of billions of IoT devices that are currently deployed and generating zettabytes of data each year. From smart homes, cities, factories, supply chains, and more, IoT devices are revolutionizing legacy infrastructure, and automated systems have the potential to create powerful efficiencies and business logic in this space. To this end, we’ve developed custom external adapters that allow smart contracts to interface with real-time hardware systems. We’re currently hosting an RFID external adapter with a virtual hardware backend, so you can follow along with this tutorial and try it out yourself.

Our objective: in under 10 minutes, you will have deployed a smart contract that can query data from our RFID adapter. We want to make it as intuitive as possible for existing Web3 developers to start building hardware integrations into your dApps.

Suggested Prerequisites

• Familiarity with Solidity development using Chainlink is important. We’ll use the Remix Ethereum IDE on the Kovan testnet.
• No hardware is needed! We have integrations for an RFID sensor live now (with more devices coming soon). It sends sample data that you can use to get a dApp up and running quickly.

This tutorial will be a written version of the demo found on our GitHub repo, which you can familiarize yourself with before you get started.

Building the RFID Data Provider Smart Contract

Job/Oracle Specs

To follow this guide, we’ll be using this job and node running on the Kovan testnet.

The RFID scanner adapter will return an example card UID in bytes format.

Bare Bones Contract

Here is a basic contract that calls the node’s RFID job and stores the response in a variable:

Deploy this contract with Remix:

pragma solidity ^0.6.0;

import "https://github.com/smartcontractkit/chainlink/blob/develop/evm-contracts/src/v0.6/ChainlinkClient.sol";

contract Client is ChainlinkClient {
    // where to store the last id scanned
    bytes32 public last_uid;
    // Chainlink vars for communicating with the RFID external adapter
    address private oracle;
    bytes32 private jobId;
    uint256 private fee;
   
    constructor() public {
        setPublicChainlinkToken();
        oracle = 0x42149D794A135989319b66Dbcb770Ad36075a92e;
        jobId = "785558e0bed6466b9567322cc2f4ca91";
        fee = 1 * 10 ** 18; // 0.1 LINK
    }

    function requestData() public returns (bytes32 requestId) {
        // creates the Request
        Chainlink.Request memory req = buildChainlinkRequest(jobId, address(this), this.fulfill.selector);
        // Sends the request
        return sendChainlinkRequestTo(oracle, req, fee);
    }
    
    function fulfill(bytes32 _requestId, bytes32 uid) public recordChainlinkFulfillment(_requestId) {
        last_uid = uid;
    }
}

Deploying and Interacting with the Contracts

Follow this Chainlink guide for how to deploy the contract and fund with testnet LINK. We recommend funding the contract with at least 10 LINK.

The requestData method of the contract will make a Chainlink request to the RFID job, and after completing, will put the UID of the last scan in the last_uid variable.

Applications and Future Integrations

Our RFID integration is a proof of concept that we can run a real-time hardware device on a smart contract. We hope to keep building out hardware integrations and eventually bootstrap a hardware ecosystem within the Chainlink community. Still, it is ultimately up to developers to find the killer applications that use this technology.

Here are some ideas we had with the RFID adapter that you can work on right now:

• Custody management for physical goods – An item tagged with an RFID chip can be scanned at various waypoints to track location securely. This system could be beneficial for blockchain-based supply chain management applications.
• Hospitality check-in/out system – Airbnb/hotels could automatically initialize a rental contract when a user checks in to a location. The smart contract could automatically charge any late fees incurred in real time.
• Physical verification system for signing digital agreements – Use the RFID scan to authenticate a user’s physical presence.
• Get creative! The RFID interface is generic enough that anything you can imagine is probably possible to build.

The best on-chain hardware applications will leverage smart contracts’ unique properties to gain an edge over traditional software. Smart contracts are deterministic, decentralized, digital agreements. In the context of hardware, the most valuable benefits that blockchains enable are (1) robust machine-to-machine communication protocols and (2) tamperproof data feeds from sensors.

Building Your Own Hardware External Adapters

There are a few lessons our team learned while building the Open Library Project. If you’re considering building hardware external adapters yourself, these are principles that we found useful. Though we made design decisions when building the RFID scanner’s hardware adapter, the principles should apply to any real-time hardware sensor integrations.

Principle 0: The adapter server structure is the same as all others. You can use any of the existing external adapter templates as a starting point. The main differences are in the following principles.

Principle 1: The hardware must have some software interface/API that the external adapter can call.

For the RFID scanner, we used pyserial to write a custom parser that created a simple interface to get UID codes from each scan. Then we could write a simple flask server that accepts POST requests to read the UID.

For less custom hardware (i.e., not Arduino), this software interface might be provided by an out of the box API. In that case, you only have to worry about writing the external adapter interface.

Principle 2: The external adapter must be run locally (ignoring virtual hardware backends).

To those familiar with deploying adapters on cloud servers, this might seem odd. However, considering that we’re moving data from a local hardware sensor to a remote Chainlink node, the adapter server that provides data to the node must be run locally. We imagine an optimal setup that uses a dedicated Raspberry Pi to run the hardware and server (though we used our laptops during development).

Start Building With External Adapters Today

If you’re a developer and want to connect your smart contract to existing hardware or data outside the underlying blockchain, reach out here or visit the developer documentation.

If you learned something new here, want to show off what you’ve built, or developed a frontend for some of the demo repos, make sure you share it on Twitter, Discord, or Reddit, and hashtag your repos with #Chainlink.

Website | Twitter | Discord | Reddit | YouTube | Telegram | Events | GitHub | Price Feeds | DeFi