Distributed Data & Physical Infrastructure for a Shared Governance of Energy | #Energy #P2P #DAO
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
What's DAISEE about ?
What's our prototyping focus now ?
We are focus on building usefull things out of the Internet Of Thing focus in the energy sector. More specifically, we're working on the v2 prototype of the energy monitor both from the software perspective and from the hardware perspective.
At this point, we have initialized the first 2 parts of the prototype:
- Monitoring of energy, using in-line current sensors (in replacement of non-invasive CitizenWatt sensors) and the CitizenWatt application. The sensors replacement allows to measure low currents more accurately. See intructions n°4 .
- Configuration of a local blockchain and deployment of new versions of smart-contracts. We introduced the notion of token to exchange energy between peers. See intructions 1 to 3.
The next step was to have these two parts communicate in order to:
- store the energy data on the blockchain,
- trigger automated exchanges according to predefined rules.
For now the rules are quite simple. Since the energy sources are batteries, the energy exchange is triggered when the battery of the consumer node (node 1) falls below a certain threshold. A Python script will read the data from CitizenWatt application, update the data on the Blockchain and activate the relay to switch to the power source of node 2 (producer).
The part is detailed in the instruction 5.
Using in-line current sensors improves the metering.
And blockchain setup changes allow to speed up transactions validation on single board computers with limited resources like Raspberry Pi (use of Proof-of-Authority instead of Proof-of-Work).
However, there are still improvements to be made, especially on :
- the python script to handle the triggering of the relay in the different possible cases,
- the smart-contracts, to simplify the process (for example: the tokens management).
The issue of data storage and access remains to be addressed (privacy, security...).
Then, the next step will be to be more closer the actual conditions (no direct echanges between 2 peers, but connection to a local grid with more peers), in order to prepare the field experiments.
After a first version of our prototype that allowed us to learn about the Blockchain technologies (see prototype v0.1 in 2016 entry), we started the year 2017 on a new iteration of the prototype.
The objectives are to better understand the technology and its limitations, evaluate its relevance to different use-cases and to prepare the future field experimentations.
The main goal of the prototype is to allow peer-to-peer energy exchanges between several nodes of a small-scale network by:
For this new version, we still rely on open-source CitizenWatt Application to display energy data and a local Ethereum blockchain for exchanges traceability (see the first intructions).
The focus will be on current measurement, data management and rules governing energy exchanges.
The first step is to install an Ethereum client and configure a local blockchain on the Raspberry Pi 3.
We chose Parity as a Ethereum client because of the features offered and its interface facilitating its use.
An image is available with Parity and Geth (another Ethereum client) :
➡ http://ethraspbian.com/downloads/image_2017-04-19-EthRaspbian-parity-1.6.6-lite.zip
(see GitHub repository: diglos/pi-gen for more informations).
This image is compatible with Raspberry Pi 2 and 3 and runs Parity Ethereum client as a boot service (full Ethereum node).
After turning on the Raspberry Pi, disable the Parity service for now:
Rieul Techer
$ sudo systemctl stop parity
$ sudo systemctl disable parity
Removed symlink /etc/systemd/system/multi-user.target.wants/parity.service.
$ sudo aptitude update && sudo aptitude upgrade
Parity can be easily configure through a configuration file:
➡ https://github.com/paritytech/parity/wiki/Configuring-Parity#config-file
For testing purposes and due to ressources limitations, a private/local blockchain will be set up with Proof-of-Authority consensus engine, for this version of DAISEE prototype :
[Proof-of-Authority] does not depend on nodes solving arbitrarily difficult mathematical problems, but instead uses a hard-configured set of "authorities" - nodes that are explicitly allowed to create new blocks and secure the blockchain. This makes it easier to maintain a private chain and keep the block issuers accountable.
All steps for setting up a local blockchain with Proof-of-Authority are described here:
➡ Demo PoA tutorial
After following the tutorial, here are the differents files used for one node of the prototype:
{
"name": "DemoPoA",
"engine": {
"authorityRound": {
"params": {
"gasLimitBoundDivisor": "0x400",
"stepDuration": "5",
"validators" : {
"list": [
"0x00Bd138aBD70e2F00903268F3Db08f2D25677C9e",
"0x00Aa39d30F0D20FF03a22cCfc30B7EfbFca597C2",
"0x002e28950558fbede1a9675cb113f0bd20912019"
]
}
}
}
},
"params": {
"maximumExtraDataSize": "0x20",
"minGasLimit": "0x1388",
"networkID" : "0x2323"
},
"genesis": {
"seal": {
"authorityRound": {
"step": "0x0",
"signature": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
},
"difficulty": "0x20000",
"gasLimit": "0x5B8D80"
},
"accounts": {
"0x0000000000000000000000000000000000000001": { "balance": "1", "builtin": { "name": "ecrecover", "pricing": { "linear": { "base": 3000, "word": 0 } } } },
"0x0000000000000000000000000000000000000002": { "balance": "1", "builtin": { "name": "sha256", "pricing": { "linear": { "base": 60, "word": 12 } } } },
"0x0000000000000000000000000000000000000003": { "balance": "1", "builtin": { "name": "ripemd160", "pricing": { "linear": { "base": 600, "word": 120 } } } },
"0x0000000000000000000000000000000000000004": { "balance": "1", "builtin": { "name": "identity", "pricing": { "linear": { "base": 15, "word": 3 } } } },
"0x004ec07d2329997267Ec62b4166639513386F32E": { "balance": "10000000000000000000000" }
}
}
3 validators are defined
[parity]
chain = "/home/pi/demo-spec.json"
base_path = "/home/pi/parity/"
[network]
port = 30300
bootnodes = ["enode://ff14ae0a273e08ffbbe20b4b398460eb471e23f1b4301ce46b92a86ad420f67b9b470d097f1939fa7b9b2aae7d24e72cf7c63fe67217bdf3fd6cb60bbb7ecc59@192.168.0.47:30300"]
discovery = false
[rpc]
disable = false
interface = "192.168.0.15"
port = 8545
cors = "*"
apis = ["web3", "eth", "net", "personal", "parity", "parity_set", "traces", "rpc", "parity_accounts"]
[ui]
force = false
disable = false
port = 8180
interface = "192.168.0.15"
path = "/home/pi/parity/signer/"
[dapps]
port = 8088
[account]
password = ["node.pwds"]
[mining]
engine_signer = "0x002e28950558fbede1a9675cb113f0bd20912019"
reseal_on_txs = "none"
exemple of a config file for one node
$ parity
Since the blockchain is private/locale, adding a node can be done with the configuration file in Network part.
[network]
bootnodes = ["enode://ff14ae0a273e08ffbbe20b4b398460eb471e23f1b4301ce46b92a86ad420f67b9b470d097f1939fa7b9b2aae7d24e72cf7c63fe67217bdf3fd6cb60bbb7ecc59@192.168.0.47:30300"]
discovery = false
Error: Engine(NotProposer(Mismatch { expected: 00aa39d30f0d20ff03a22ccfc30b7efbfca597c2, found: 00bd138abd70e2f00903268f3db08f2d25677c9e }))
Only 3 blocks are imported with the last version of chain-specs.json (3 validators). In order to import the next blocks, the last validator is removed from chain specs, and blocks are imported until block #55. After this message, using the last version of chain specs (with the 3 validators) allows to import the full blockchain.
The best solution would be to add the new validator account only after importing the full blockchain on the node.
The energy data and exchanges are stored on the blockchain thanks to 2 smart-contracts (in Solidity):
For now, the rules that trigger transactions are not implemented in a smart contract. Note: the smart contract is still under development, the code may change (see Issues).
To deploy the smart contracts, connect to the Parity UI.
In Contracts Tab, after clicking on "DEVELOP" button, paste the token smart contract code for the token and compile:
With Parity UI, the smart contract can be easily deployed ("DEPLOY" button):
Deploy the Daisee smart-contract:
The two smart-contract now appear in Contracts tab:
Note: the current version of DAISEE smart contract allows to update consumption and production directly (without connexion to a sensor):
Tutorial source:
➡ A simple smart contract Web UI using web3.js
The microframework Flask allows to display the interface from a Raspberry Pi node.
The current version displays Ethereum transactions and realtime data from the energy monitoring application
$ sudo aptitude install git
$ sudo pip3 install flask pyyaml
$ git clone https://github.com/DAISEE/DApp-v2.git
| Type | Field | Description |
|---|---|---|
| contracts | ||
| daisee | Daisee.sol address on the blockchain | |
| token | DaiseeCoin smart-contract address on the blockchain | |
| user | ||
| login | login for UI | |
| pwd | hashed password for the UI* | |
| coinbase | user address | |
| type | type of node ('C' for consumer, 'P' for producer). Not Used | |
| url | url of energy monitoring application** | |
| sensorId | url of energy monitoring application | |
| sensorLogin | login for energy monitoring application | |
| sensorPassword | password for energy monitoring application | |
| sensorSource | energy monitoring application : 'CW' for citizenWatt (only app supported for now)
|
|
| sensorPort | if necessary, port of energy monitoring application, example : ':8080'
|
still under development, it may change
* to obtain the hashed password, use 'url/hash/<password>' after running the server
$ cd dapp
$ export FLASK_APP=server.py
$ python3 -m flask run --host=0.0.0.0
John
jan.marcinowski
ensafatef
gpicron