As a consequence of the foreseen significant increase in stochastic generation in the electrical grid, the need for flexibility and coordination at demand side is expected to rise. Decentralized energy markets are among the most promising solutions allowing to boost coordination between production and consumption, by allowing even small actors to capitalize on their flexibility. The main purpose of Hive Power is to develop a blockchain-based platform to support groups of prosumers that want to create their own energy market. The core element of this framework is the so-called Hive, i.e. an implementation of an energy market based on blockchain technology (see our white paper on hivepower.tech to have detailed informations about Hive Power platform).
This article describes Demo Hive, the first testbed developed by our team and presented during the Energy Startup Day 2017 in Zurich, Switzerland on November 30th 2017. Practically, the demo is a simple but also meaningful case of a hive; it is constituted by a producer and a consumer, the so-called workers. A third element is the QUEEN, whose aim is to manage the interaction between the workers and the external grid and to track the measurements related to the power consumed/produced by the workers. The producer, following named SOLAR, simulates a photovoltaic plant with a nominal power of 5 kWp. Instead the other worker (LOAD) generates data about a load consumption. Fig. 1 shows the demo testbed.
Fig1: The Demo Hive testbed
Essentially, the main hardware components of Demo Hive are:
- two SmartPIs, one for each worker. This device is constituted by an acquisition board for the electrical measurements (voltages and currents) connected to a Raspberry Pi 3. In Fig. 1 the two workers are the black boxes on the bottom.
- A Raspberry Pi 3 in order to provide the Queen functionalities.
- A 5G router to provide the Internet connectivity and a WLAN inside the testbed.
One of the most meaningful aim of Demo Hive is to tokenize the produced/consumed energy and to save the related information on a blockchain. For that reason an ERC20-compliant smart contract was deployed on the Ropsten network in order to create a demo token, called DHT, which has the following fixed value:
- 1 DHT = 1 cts = 0.01 CHF
The basic idea of Demo Hive is that LOAD owns a certain amount of DHTs and sends part of them to the producers (typically SOLAR, but also the external grid through QUEEN) to buy energy. In the following chapter this aspects will be exhaustively described.
A set of applications runs on the aforementioned devices to actuate the Demo Hive platform, a part of them developed by Hive Power. In this article only the main behavior of the demo testbed will be described, avoiding to explain all the code in details. The following image reports the software interactions inside the demo and outside with the Ropsten network.
As written in our whitepaper, periodically the real Hive platform will save data about the tokenized energy on a blockchain. This is quite unconvenient in a demo testbed because the period can be too long. For that reason the demo software considers virtual days with a duration of just 10 minutes. This means the SOLAR worker produces in 10 minutes the same energy really performed in 24 hours. Similarly the power measurements, in a real application performed off-chain and usually acquired every 15 minutes, in Demo Hive are measured every 5 seconds. As shown in Fig. 2, during the virtual day of 10 minutes the power measurements are saved by the workers in QUEEN (black arrows) in an InfluxDB database, a time-series oriented DBMS commonly used in monitoring applications. When the simulated day ends, the workers energies are calculated and tokenized in DHTs considering the following static tariffs.
- Buy on grid: 20 cts/kWh
- Sell on grid: 5 cts/kWh
- Buy in the Hive: 10 cts/kWh
- Sell in the Hive: 10 cts/kWh
Consider that LOAD/SOLAR worker can only buy/sell energy. Instead QUEEN, managing the interface with the grid, is allowed to perform both the operations. At the end of a simulated day a tokenization algorithm tries to maximize the hive autarky using the following rules (see also Fig. 2):
IF 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 : LOAD buys 𝑬_𝑺𝑶𝑳𝑨𝑹 from SOLAR (10 cts/kWh) and 𝑬_𝑳𝑶𝑨𝑫−𝑬_𝑺𝑶𝑳𝑨𝑹 from QUEEN (20 CHF/kWh)
ELSE IF 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 : SOLAR sells 𝑬_𝑳𝑶𝑨𝑫 to LOAD (10 CHF/kWh) and 𝑬_𝑺𝑶𝑳𝑨𝑹−𝑬_𝑳𝑶𝑨𝑫 to QUEEN (5 CHF/kWh)
Practically the workers exchange all the available energy in the hive, exploiting the more convenient tariffs.
Thus, the energies are tokenized in DHTs and the related tokens (as written before, 1 DHT = 1 cts) sent by buyers (LOAD or QUEEN) to sellers (SOLAR or QUEEN) according to the aforementioned algorithm. In Fig. 2 these operations are represented by the red and light blue arrows. The DHTs transfers are then saved on the Ropsten blockchain. This can be performed because on each demo device a geth client maintains a node synchronized to the Ethereum testnet network. In order to minimize the required disk space, the geth instances run the Ethereum light client protocol. The Ropsten accounts of the components are reported below:
- LOAD: 0x888d0aafc4d7c95fcaff9264d4bc2c1829a575be
- SOLAR: 0x3b5b6bbF5A14259bdF499f526A51aE7bF21c7476
- QUEEN: 0x7ab0c357cf3ae3c36b7ee8d4a84722a96790a6bd
As explained above, the Demo Hive testbed simulates “virtual” days with a duration of 10 minutes. During a single day the produced/consumed power of the two workers is saved every 5 seconds. At the end of the day (i.e. 10 minutes) the related energies are calculated, tokenized and saved on Ropsten network. In order to have days with both the aforementioned cases of the autarky algorithm (i.e. solar production > load consumption and solar production < load consumption) the following power profiles are taken into account for the workers:
- SOLAR: two profiles are considered, the former (following named CLEAR) with a significant production, related to a day without clouds. Instead the latter (following named CLOUDY) has a poor production, simulating an overcast day. The sequence of the profiles in the simulated days is a continuous alternation, i.e. after a CLEAR day there is a CLOUDY one, and so on.
- LOAD: a unique typical profile is taken into account as baseline, then every day a noise is added to it. As a consequence, during the simulated days the resulting profiles are always similar, but never equal.
Fig. 3 shows an example of two simulated days. It is simple to note the difference between the CLEAR and CLOUDY cases.
The profiles shown in Fig. 3 were performed during the Energy Startup Day 2017. Considering the first profile (CLEAR), it is simple to understand how the SOLAR production exceed the LOAD consumption. As a consequence, all the energy needed by LOAD is locally bought in the hive from SOLAR producer at the convenient Hive tariff (i.e. 10 cts/kWh). On the other hand, the remaining amount of produced energy not bought by LOAD will be sold by SOLAR on the grid with a less convenient tariff (i.e. 5 cts/kWh). Acting as described, the local energy exchanging is maximized and, consequently, the two workers realize to save/profit money taking advantage of the Hive tariffs.
In the second case (CLOUDY profile), the production is not able to cover all the consumption. Thus, LOAD has to buy part of the needed energy from the grid paying 20 cts/kWh.
At the end of the simulated day the savings/profits data are then tokenized and the related DHTs distributed by the consumer (e.g. LOAD in a CLOUDY case) to the producers (e.g. SOLAR and QUEEN in a CLOUDY case) in order to pay the used energy. In the following list the energy profits/costs in DHTs are reported comparing the cases of Demo Hive against a business as usual (BAU) situation, where the hive market does not exist (i.e. only the grid tariffs, 20/5 cts/kWh to buy/sell energy, are available).
- Solar revenues:
12:00-12:10 (CLEAR): HIVE = 432 DHT BAU = 254 DHT HIVE-BAU = 178 DHT
12:10-12:20 (CLOUDY): HIVE = 135 DHT BAU = 68 DHT HIVE-BAU = 67 DH
- Load costs:
12:00-12:10 (CLEAR): HIVE = 356 DHT BAU = 713 DHT HIVE-BAU = -357 DHT
12:10-12:20 (CLOUDY): HIVE = 590 DHT BAU = 725 DHT HIVE-BAU = -123 DH
It is easy to note how the saved/earned money of LOAD/SOLAR is much higher during the CLEAR day, being the solar production able to cover all the energy needed inside the hive. The following list reports the precise amounts:
- LOAD saves 3.57 CHF during CLEAR days
- LOAD saves 1.23 CHF during CLOUDY days
- SOLAR earns 1.78 CHF during CLEAR days
- SOLAR earns 0.67 CHF during CLOUDY days
The following URLs report the Ropsten transactions details related to the simulated days.
- TX_CLEAR_1: 356 DHTs sent by LOAD to SOLAR
- TX_CLEAR_2: 76 DHTs sent by QUEEN to SOLAR
- TX_CLOUDY_1: 455 DHTs sent by LOAD to QUEEN
- TX_CLOUDY_2: 135 DHTs sent by LOAD to SOLAR
The Demo Hive testbed implements a very simple case of hive. It is a significant starting point for the development of the complete framework, but some improvements have to to be implemented. The following list reports the most meaningful features still to develop.
- Prototype of a “blockchain-ready” meter: SmartPi device is based on a Raspberry Pi 3 board, a great hardware platform for prototyping and initial tests but not projected to be easily integrated in an industrial product. In order to develop a blockchain meter, naturally necessary in our framework, the idea of Hive Power is to take into account more industrial-oriented hardware platforms and using them to substitute the SmartPi devices.
- Power profiles: Currently the workers profiles are quite similar during the “simulated days” of 10 minutes. Practically there is a precise alternation of clear and overcast days for the SOLAR production. Regarding the LOAD, every simulated day a noise is added to the same predefined profile. In order to have a more realistic situation, new profiles have to be considered (e.g. two different LOAD profiles, the former for workdays and the latter related to the weekend)
- State channels: in our demo testbed, the power measurements are now acquired every 5 seconds and the related data saved in an database running on QUEEN. In order to have a fully decentralized approach, our idea is to handle power data using State Channels technology avoiding to use a local database.
- More workers: To have a more realistic simulation of a Hive energy market, the number of workers should be increased.
- Prosumer/Storage worker: Currently being in Demo Hive only a consumer (LOAD) and a producer (SOLAR), it will be meaningful to introduce prosumer and storage workers in order to have a complete market. It is interesting to consider that with storage systems it would be possible to implement load-shifting algorithms to maximize the costs savings.
- Dynamic tariffs: In Demo Hive only static tariffs are taken into account for the energy buying/selling. Clearly, this is not a realistic situation and consequently a dynamic system of tariffs has to be implemented.
The integration of IoT and Ethereum is emerging as a powerful solution for data management using the blockchain technology. Unfortunately, at present the speed and storage requirements of a typical IoT application exceed the capabilities of the public Ethereum blockchain. The reasons are mainly two, the former is the block time, currently too high to be able to track IoT data. The latter is the gas cost: each transaction has a cost on Ethereum, thus the global amount of gas paid for all the transactions would be highly expensive. As a consequence, currently an interface among the “fast” world of IoT and the “slow but decentralized” one of Ethereum is needed.
Raiden (https://raiden.network/) is a framework for the fast management of transactions. Being built as a off-chain solution, it provides a fast exchange of data among the Raiden nodes using the state channels technology, avoiding the long response time and the gas costs related to on-chain transactions. On the other hand, the starting and the end points of each Raiden state channel are tracked on the blockchain (currently only on Ropsten network) with the related initial and final balances.
In this article the procedure to install Raiden (https://raiden.network/) on a Raspberry Pi 3 is explained. I chose this well-known hardware platform because it is widely used for IoT applications. It is assumed that Raspbian Jessie 8 is the operating system running on the Raspberry Pi 3.
The installation steps can be summarized into the following list. For each point an explanation is reported together with the related bash commands.
- Step1: Installation of libraries and tools required by the following steps.
# sudo apt-get install geth pip cmake libboost-all-dev
- Step2: Creation of a temporary swap file to avoid memory overflows. The available memory in a Raspberry Pi 3 is 1 GB and ~20% of RAM is used by Raspbian and other processes. The remaining RAM is not sufficient for the following compilation processes, so a swap space has to be used. I performed some tests without swap, but I always encountered memory overflows. In the example below I created a swap file of 0.5 GB, enough for the compilations. Consider that after the following two steps the swap file can be deleted and so the space reallocated to the root partition.
# sudo dd if=/dev/zero of=/swap bs=1M count=512 # sudo mkswap /swap # sudo swapon /swap
- Step3: Installation from source of the tool Z3 (https://github.com/Z3Prover/z3), required by the solc compiler. On the Raspberry Pi this process was very long, about some hours.
# mkdir ~/software # cd ~/software # wget https://github.com/ethereum/solidity/releases/download/v0.4.16/solidity_0.4.16.tar.gz # unzip z3-master.zip # cd z3-master # python scripts/mk_make.py # cd build # make # sudo make install
- Step4: Installation from source of the Solidity compiler (solc). This software is required by Raiden but, unfortunately, currently no binary package is available for the hardware architecture of Raspberry Pi 3 (armv7). This is the cause of the compilations and, definitely, the main reason of this article. Under the computational point of view, also this step has a meaningful duration, although faster than Step3.
# cd ~/software # git clone --recursive https://github.com/ethereum/solidity.git # cd solidity-0.x.y # scripts/install_deps.sh # scripts/build.sh
- Step5: Installation of Raiden. The final step is much simpler than Step3 and Step4, being Raiden a set of Python scripts, thus no compilation is required.
# cd ~/software # git clone https://github.com/raiden-network/raiden.git # cd raiden-x.y # sudo pip install --upgrade -r requirements.txt # sudo python setup.py develop
Now all the tools are properly installed and we can start using them. Currently Raiden network is available only on Ropsten network, thus the first passage is to start geth in light mode (the unique I realized to launch on a Raspberry Pi) and sync it to the test network.
# geth --testnet --light --v5disc --cache 1024 --rpc --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*" --rpcapi "eth,net,web3" console
Once the node is synced, a Ropsten account has to be created and an amout of at least 0.1 ETH assigned to it. After that we can start Raiden as shown below:
# raiden --keystore-path ~/.ethereum/testnet/keystore
To test if Raiden has been successfully installed, it is possible to query its REST interface with the following command and to check the result:
# curl -X GET http://127.0.0.1:5001/api/1/tokens [ “0x2d3632ea6f06b2aad472d3f8cf49eefd98b96d71”, “0x9aba529db3ff2d8409a1da4c9eb148879b046700”, “0x53c9884988058dd583d816aae9976775fb94b4a4”, “0x25a8004bd889a0c31e9382f50272e596bf5d8a88”, “0xa87d050d6ebbbabf1095d50c493a41a51f57a44e”, “0xc67f4b9a7592b43a474df44939c0630e24c414dd”, “0xbaa4589a1a49f722293360e352fed692e741442d”, “0xd7f14d6bff222c650e1ebd60fc4673c737c40134”, “0xd73860f000e675c15ca8b060da0128f5473b4d96”, “0xc90e57fe7da3b8f6c86e20f640dd9785c52906f7”, “0x683aca737b264ae43c91ea3196dd017b186b0e0b”, “0x78a9b00be464351471f73d3c26485fe0434c92dc”, “0xcd0d53a45cdda84fee9edb5874a7897ebdc9624e”, “0xf025f2ddb226684ab66df9fdf3928d053a237dce”, “0x79fc539d3207a172959d1cb6a73fae18621e96c8”, “0x3791165e88164c0256a652d746a4a60b11eacb93”, “0x583cbbb8a8443b38abcc0c956bece47340ea1367”, “0x4d55ca1059f95a77f5a88a80fff918f095136c2b”, “0x33511d2c9c1f05036e4b2aea602ac2a5028c113a”, “0x501a3ea063a97fcc76afba2b1779864c98ad89c8”, “0x0f114a1e9db192502e7856309cc899952b3db1ed”, “0xe987ea391d45b837f12601e0a8298779dc17d903” ]
If you find something similar, you have Raiden working on your Raspberry Pi 3, have fun!
The power sector is facing a paradigm change, moving from a centralized approach with big power plants (hydro, coal, gas and nuclear) leading the energy market to a decentralized scenario adopting distributed energy resources (DER), such as solar and wind.
In this picture, a new actor is emerging: the prosumer, i.e. households or organizations which at times produce surplus energy and feed it into the local distribution network; whilst at other times (when their energy requirements outstrip their own production of it) they consume that same energy from the grid. DERs are by their nature distributed and easily accessible, so accessible that even a single residential consumer can install a small solar power plant and become a prosumer.
The transition to a prosumer-driven electrical grid can be quite bumpy¹. The lack of a centralized planning and the increase of intermittent electricity production in the lower levels of the grid raise the stress on the electrical distribution grid and can lead to severe power quality problems, while distribution system operators (DSOs) need to cope with these new issues.
Though many utilities rightly see the impending arrival of solar-plus-battery grid parity as a threat, they could also see such systems as an opportunity to add value to the grid and their business models. The important next question is how utilities might adjust their existing business models or adopt new business models — either within existing regulatory frameworks or under an evolved regulatory landscape — to tap into and maximize new sources of value that build the best electricity system of the future at lowest cost to serve customers and society.
Rocky Mountain Institute
These problems are further emphasized by the increase of electricity consumption driven by the electrification of heat generation (heat pumps) and mobility (electric vehicles), which will tend to further increase power excursions in the distribution grid.
To overcome this problem significant investments in the grid infrastructure are expected. This could initiate a so called business “death spiral”², or “grid defection”³. Prosumers reduce their regular power consumption from the central grid in favor of self-produced power. Besides they can install batteries to further increase their energy independence. Reasonably, these customers will still depend on the central grid for emergency or peak use, so electric utilities will have to operate their costly infrastructure and power-generating capabilities even as revenues from consumption decline.
We believe this bleak scenario is not the future we want. A future with a widening gap between autarkic prosumers, almost disconnected from the rest of the grid, and simple consumers forced to pay for a more expensive and inefficient grid.
On the contrary, the future electrical grid should be characterized by an increase of energy sharing between prosumers, consumers and electric utilities, optimizing the energy resource and the usage of the infrastructure. In several countries, the current unbundled situation allows the end-users to freely choose their energy supplier.
In this context, enabling technologies like blockchain, and more specifically Ethereum, will allow decentralized prosumers to safely buy and sell electricity to each other at negligible marginal costs. New aggregators exploiting this technology can act as energy suppliers and compete in the global market. In this context, distributed energy storage systems (DESS) could also participate to the energy market and thanks to their high flexibility they could quickly respond to dynamic price signals. This represents a big opportunity of cost reduction for the end user.
Today we present the Hive Power platform, a decentralized autonomous organization (DAO). The goal of Hive Power is to create energy sharing communities where all participants are guaranteed to benefit from the participation, reaching at the same time a technical and financial optimum for the whole community.
This is achieved by devising a mathematically sound market mechanism that incentives the participants to collaborate with each other, coordinating their production and consumption. In contrast to other energy sharing market schemes, the Hive Power platform takes also in account technical aspects, such as cables power rating and voltage limits in order to reach a multi objective optimal solution.
By using the Hive Power platform users are empowered to create decentralized energy communities. The scope and the size of these communities can be quite heterogeneous.
The first application of Hive Power will be the creation of self-consumption communities (SCC) on a condominium, where the members of the community consume together the produced solar electricity from their own roof by increasing their energy autarky.
Starting from this initial application, Hive Power will grow in size by including any kind of producers and consumers in the low voltage electrical grid in cooperation with DSOs.
Hive Power will also support micro-grid communities, where the connection to the main grid is not ensured continuously and the requirements of technical and financial operation are strict.
We believe Hive Power is perfectly tailored to the current grid transition, enabling a safe and cost effective operation of the electrical grid by ensuring a fair and resilient energy market for all actors involved.
We are just getting started and we are really excited for the future ahead of us.
Join Hive Power Telegram chat:
Learn more about Hive Power:
- Perez-Arriaga, C. Knittle, and M. E. Initiative, “Utility of the future: An mit energy initiative response to an industry in transition.”, http://energy.mit.edu/publication/utility-future-report, 2016.
- P. Bronski, J. Creyts, L. Guccione, M. Madrazo, J. Mandel, B. Rader, D. Seif, P. Lilienthal, J. Glassmire, J. Abromowitz, et al., “The economics of grid defection: When and where distributed solar generation plus storage competes with traditional utility service,” Rocky Mountain Institute, pp. 1-73, 2014.
- The Economist Group Limited, “A world turned upside down.” https://goo.gl/hWu16z, 2017