We continue in our example. After configuring our iOT device (see my previous post) so that it can transmit data to the REST Server, let’s see how to configure the API service that will transmit the data to the blockchain after receiving them from the device. In the below picture you can see the architecture of this Proof Of Concept:

The server API is an ASP.Net Core server consisting essentially of a single controller API. The controller receives the data from the device through a POST call (see the python client deployed on the device Linklt), receiving a very simple Json that is mapped in a POCO class structure of this type:

The controller method that implements the POST does nothing more than prepare the message to transmit the transaction data to the Blockchain and wait for the response of the transaction on the blockchain itself. In the next section we’ll see what kind of response the server is receiving. Here the server controller code

[HttpPost]
        [Route("api/temphum", Name = "TemperatureAndHumidityFromDdevice")]
        public async Task<IActionResult> TemperatureAndHumidityFromDdevice(IOTData iotData)
        {

            var web3 = new Web3(ethereumAddress);

            var gasForDeployContract = new HexBigInteger(6000000);
            var deploymentMessage = new IotDataDeployment()
            {
                FromAddress = BC.GetDefaultAccount(),
                Gas = gasForDeployContract,
                DeviceID = iotData.DeviceID,
                Temperature = iotData.Temperature,
                Humidity = iotData.Humidity,
                Lat = iotData.Lat,
                Lng = iotData.Lng,
                IotDataManagerContract = BC.GetIotDataManager_Address()
            };

            var deploymentHandler = web3.Eth.GetContractDeploymentHandler<IotDataDeployment>();
            var transactionReceipt = await deploymentHandler.SendRequestAndWaitForReceiptAsync(deploymentMessage);
            var newIotAddress = transactionReceipt.ContractAddress;


            String result = newIotAddress;
            return Ok(result);
        }

Solidity

How are smart contracts structured on the blockchain? The figure below describes one of the two smart contracts deployed on the blockchain called iotDataManager.

This smart contract works as a database of device data. Whenever the API Server makes a call it actually invokes the constructor of the smart contract called iotData whose code is reported entirely below

import "./IotDataManager.sol";
contract IotData {
     string public deviceid;
     string public temperature;
     string public humidity;
     string public lat;
     string public lng;   
     constructor (
         string memory _deviceid, string memory _temperature, string memory _humidity, string memory _lat, string memory _lng, address _IOTDATAMANAGER_CONTRACT) public {
             deviceid = _deviceid;
             temperature = _temperature;
             humidity = _humidity;
             lat = _lat;
             lng = _lng;
             IotDataManager manager = IotDataManager(_IOTDATAMANAGER_CONTRACT); 
             manager.storeIotDataReference(address(this), _deviceid, _temperature, _humidity, _lat, _lng);             
         }        
          function ()  external {
            // If anyone wants to send Ether to this contract, the transaction gets rejected
            revert("no eth accepted");
        }
}

The constructor receives the device data and the smart contract address iotDatamanager as input. Inside the constructor we already know the address that the Ethereum Virtual Machine has assigned us and this allows us to invoke the iotDataManager method that stores data in correspondence with the newly created smart contract address. As you can see from the figure above the smart contract iotDataManager will then offer the Dapp the possibility to invoke the other method to retrieve data at the respective address, but we will see this in the next post in which we will describe the web app that will use web3.js.

Caveat

An important thing to take into account is the fact that after creating the Server API and verifying that everything works using IIS Express, everything must be published on an IIS Server otherwise our device will not be able to communicate. IIS Express is in fact just a process that uses the Loopback interface which is fine for all the processes inside our machine, but which is not visible to any external client to our machine.

Results

Once our API Server is published we can run the Python program on the device and see how the blocks related to each call are concatenated on the Blockchain, while on the console of the device we see the addresses of the smart contracts iotData created for each call

Conclusion

see you to the next post where we will see how to build a web app that using web3.js technology will display real-time data coming from the device