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.

Energy tokenization: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.Operation mode: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.

Fig 2: Demo Hive software interactions

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

Simulation results: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.

Fig 3: Profiles of two simulated days (light blue: SOLAR, dark yellow: LOAD)

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 DHT12: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 DHT12:10-12:20 (CLOUDY):
HIVE = 590 DHT
BAU = 725 DHT
HIVE-BAU = -123 DHIt 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

Next steps: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.

‍