Hello everybody !

Long time not post ... but we were busy working on both the next version of the prototype given the inherent technological and technical limitations of the V1 prototype, and finding a concrete field experiment to test and iterate on the various level of the DAISEE project. On the first step we're on track of building the next prototype version (documentation to come soon on the 2017 hackaday prize entry; on the second step we have now a field experiment building up in the south of France and another on track in Villeurbanne near Lyon in France.

We're also back in the hackaday prize race in 2017 on the "Internet of Usefull thing" challenge: https://hackaday.io/prize/details#two with this entry: https://hackaday.io/project/21954-daisee-buiding-the-internets-of-energy

You can then carry on following our development on the previously shared entry.

By the way, we kindly invite you there: http://daisee.org as well as here: http://chat.daisee.org to chat on the various aspects of the project.

Hope to reading you soon,

Rieul for the DAISEE team ;)

Today the blockchain trend looks a bit like that:

Blockchain technologies are interested to think transparent and secured peer-to-peer distribution in sectors where a limited amount of middle-men takes the large majority of the room. To put it in a more practical way:

• in the banking and financial ecosystem trusted by few banks, funds and multi-national companies, Bitcoin (based on a blockchain technology - with all the known limitations) makes it possible in specific activities, to get ride of the middle-man and enable direct peer-to-peer transactions.
• in the same manner, in the energy sector, depending on the countries, grid and production are usually trusted by a few actors, and clearly not inter-operable with other infrastructures operators (EV for instance). A bit like for Bitcoin - but with a much more complex ecosystem, thus requiring to think beyond blockchain - blockchain technologies are an excuse to think distributed, transparent and secured peer-to-peer systems. We do use the word EXCUSE because, as we'll notice later, blockchain technologies do not answer every needs of decentralized peer-to-peer energy transactions, and even bring limitations that necessitate to choose the part of the blockchain technology that we can use in a contexte where hybridization with other technologies is essential.

To be a bit provocative, we would then say that blockchains as blockchain won't revolutionize anything. What's interesting however, and ground for potential revolution, is the spirit and the potential of hybridization and interoperation with other technologies, and appropriation by sectors and communities that are "outside-the-blockchain-box" of blockchain.

What are we capable of doing with blockchain technologies at our scale ?

From now on, in our case, the blockchain technology that we use (local private Ethereum blockchain) makes it possible to automate virtual electricity transactions between peers based on a algorithm ("smart-contract" that have nothing such as smart nor contract) on a 4-nodes distributed, transparent and "secured" database. We are also capable of making physical effective electricity transactions from the required producer to the necessitated consumer: switching based on the actual transaction switch operated by the "smart-contract" that triggers from which producer the calling consumer buys its electricity.

And what are the limitation that we came across while applying it to the energy sector ?

Please note that those limitations might have been overcome by other people. However, for the moment we do not have enough details in our hands to assure that those have been effectively overcome.

Here we'll try to spot the main limitations of the blockchain technologies applied, in our case, to the energy sector :

• "Blockchain technologies makes it possible to make small transactions at a really low-cost" : the low-cost of small-amount transactions is verified in the case of limited interaction with the blockchain. If continued and permanent interaction with the blockchain is required (such as registering in-real time production and consumption of each peer), then the fees pilling up can entails high amount bills.

• "Blockchain technologies makes it possible to identify a verifiable, auditable and authentic user" : the users are pseudo-users (it's not anonymous but pseudonymous). Moreover, the blockchain technologies do not verify, label or guaranty the user, or the data the user puts in it. As we put it lovely : "shit in shit out", blockchain technologies are transition tools with inputs and outputs. The inputs need to be validate in order to call the blockchain a "tool for the guarantied and validated information".

• "Blockchain technologies certify and make transaction more secured, reducing the risk for fraudulent actions" : this is true, provided the consensus process of validation of the transaction.

• "Blockchain technologies make information transparent for peers" : this is true, provided that you give the necessary keys to read the information.

• "Blockchain technologies make real-time transaction possible" : not really. It is faster than a Western Union transaction. However, due the consensus process validation (mining process), blocks validation, for a blockchain used on a regular basis, takes from a few second to few minutes. This is not real-time and that is a limitation in the case the energy where it is necessary to guaranty in real time the consumed and produced amount if we want to keep the link between the transaction process and the physical electricity exchange process.

• "Blockchain technologies make it possible to store any kind of data" : it depends on the blockchain technology and it comes a limitation while talking about the amount (volume) of the stored information. Blockchain technologies are not designed to store huge amount of data, since the more data you store, the heavier the blockchain; thus you loose in flexibility as well as in distributed potential.

• The Proof of Work (PoW) process uses a lot of computational power, thus consuming a lot of energy. This is quite paradoxical while running a project/program around the optimization and rationalization of energy use. This is a hard point that required to be worked out since scaling would require strong computational power if using PoW. Other potential consensus validation process can be used such as Proof of Stake (PoS) for instance.

Consequently, there are currently strong limitations to the use of blockchain technologies, taken alone, for making scalable distributed peer-to-peer electricity exchange and transaction. However, blockchain technologies are strongly good bases to start working on such a system.

That's what we've achieve during those past 5 month : to define the relevance of the use of blockchain technologies in the energy sector to build the conditions that favor transparent, secured, pseudonymous peer-to-peer electricity transaction; and, if not completely relevant, what are the ways we need to work to answer the issues we are facing. We've also achieve strong community federation around the DIASEE program.

We've still got more questions than answers, since in any exploration phase you experiment things that few or none have tried or worked out. We are convinced that we've build strong expertise on blockchain technologies and it's time to explore the hybridization of the technology with other emerging technologies that could answer our current and possible future issues.

So what's next and how do we see a workable distributed peer-to-peer electricity exchange/transaction system ?

A workable distributed peer-to-peer electricity transaction system won't be a blockchain-energy system; it would probably be a blockchain-IPFS-BigChainBD like system.

However, other solutions are emerging such as Proof of Stake (PoS) or lightning process (off-chain transaction and validation processes) helping to leverage the current blockchain barriers.

Given the current limitations of the main blockchain technologies with regards to the energy sector, it would be interesting to work on :

• How to make real-time transaction ?
• How to store the data and keep immutable track of it ?
• how to make the use of blockchain-like technologies less power and energy consuming ?
• How to make it cheap to use ?
• How to make sure that i the initial information is correct and validated, and that energy-fraud is not possible ?

Why are those questions relevant ?

• Because local flexibility required reactivity, thus the necessity to link the physical electricity exchange with the data-based electricity transaction;
• Because energy data (meaning consuming and producing patterns and predictions) are key for the grid operators and producers;
• Because its absurd to implement at large scale an, apparently, highly energy consuming technology to optimise energy consumption and production;
• Because you dont want your energy bill to be more expensive than it's already; you'll even want it to be less expensive so as for anyone to have access to it;
• Because auditability as well as guarantied and validated data are key to trust within an open environment

Today, we hardly see a workable distributed peer-to-peer electricity exchange / transaction system without current large stakeholders, like energy producers, grids operators, local governments... we also hardly see its development without a data operator. And last of all, we do not see it without the ones who consume the energy.

As a result, we will carry on working on the 3 levels of the DAISEE program:

• the hardware level : the convergence between IoT, blockchain and other enabling distributed system to propose an open-hardware relevant and consistant energy meter ;
• the software level : using Ethereum blockchain as a basis to build a distributed energy data infrastructure with the possibility to run automated, transparent and secured peer-to-peer contract;
• the infrastructure and governance level : how to physical deal with peer-to-peer energy exchange and to build a local energy market place.

What are the next steps for the future development of DAISEE with the DAISEE team, and what will we do and need after the hackaday challenge (if we're top finalist and if we're not...) ?

• The very next step for te DAISEE team is to consolidate the accumulated documentation during those past 5 month and capitalise on those.
• The second step for us is now to clearly set the technologies we will use for the IoT part and the distributed energy data infrastructure.
• The third one is to carry on building strong links with diverse contributors around the world, and consolidate either partnerships or at least cross work with them.
• The fourth step would be re-work both the IoT part and distributed energy data infrastructure on the other part with both economical, institutional and citizen shareholders.
• The fifth step will be to effectively deliver a pilote functioning in real-usage conditions.
• The sixth step will be to work-out what could be called the business model of DAISEE, which might look like something like that:

The hackaday prize challenge clearly gave us a line to prototype and test the technical development of part of the DAISEE program. It has been a great experience we will carry on wether or not we're top finalist.

However, not only the prize but also the incubation potential would clearly help to accelerate the project and put it a another scale. In any case, the hackaday community expertises and skills potential is huge; As we tend to bet more on people than money, we will carry on seeking for contributors who share the core vision and values, and challenge the developments!

The next big step for us is to transform a deal for experimenting in territories in real-usage conditions with either local governments or companies, or both. It would help accelerating R&D development in a process of research-action experimentation program, that may transform into a viable pilote.

Here is ours now : carrying the development while building an ecosystem for it. Now that we have a working draft prototype, let's build a fully functional prototype by the end of the year, work it through the real-life experience at the beginning of next year and finalize an operational and scalable system by the second half of next year!

Well... the future is ours, with you onboard it would be far more impacting.

There are mainly 3 steps to build a local micro-electricty sharing network (and when we mean micro... we mean real-micro - 3 nodes with small solar panel and consuming devices such as smartphones or bulb connected to electricity meter connected to a local Ethereum blockchain - does it sound comprehensible ?):

• first, the hardware step: building the electricity sensor coupled to the IoT that will enable the sensor to talk to the local Ethereum blockchain and make it possible to the sensors to talk one with another
• second , the software step: connection to the local ethereum blockchain, make it possible for sensor to communicate with each other and share data, call a "smart-contrat" that automate the virtual energy transaction and the effective tokken exchange
• last of all, the infrastructure: make the system capable of effectively sharing electricity with peers on the network in line with the actual real production and consumption, thus assuring the switch when one production source is down to make a one that over-produce capable of providing the necessary electricity to the consumer.

This log is 1.0 since it concerns the prototyping of the all system at the micro-scale.

• Instruction 3 of the process ( gather all the necessary information on the Hardware part and Software part for prototyping. Instruction for the full prototype are not yet online since we're still in the prototyping process. To come...
• Documentation of the prototype can be found HERE (in french for the moment).

Hardware step : CitizenWatt + Pine64+ + Arduino

Note: we use Pine64+ because we tried to use Raspberry Pi III to make ethereum Geth client running and make it possible for transaction to diffuse, but it turns out that it was not possible to mine on a Raspberry Pi III.

• Documentation can be found HERE (in french for the moment, please excuse us for the inconvenience).
• More ressource can be found on our GitHub Repository.
• For the CitizenWatt sensor building process see INSTRUCTION 2.
• For the CitizenWatt/PINE64+/ARDUINO interaction see INSTRUCTION 3.

Software step : Local Ethereum nodes + Smart Contract + Sensors' communication

• From the previous logs (mainly log DAISEE 0.8) most of the software steps have been prototyped.
• Please see INSTRUCTION 1 and 3 for the Ethereum set up process.
• For the smart-contract and DApp development see INSTRUCTION 4 and 5.
• Finally, see INSTRUCTION 6 for update of the consumption and production data on the blockchain (necessary to automated through the smart-contract the transactions

Infrastructure step : Production + Consumption + Arduino (for automated switch)

This phase is still under construction and concerns only the micro-scale prototyping. For real scale prototyping (micro-grid scale) we are under discussion with some grid operator to test the solution with few houses (if consistent with the finding of our micro-scale prototyping phase).

The principle is to have various sources of production and consumption connected to an Arduino switch with is connected to the various PINE64+ that gather and manage consumption and production data. The switch is activated by the consumer that need electricity. The switch is controlled by the output of the smart-contract: who gives what to who ?

We come with more news in this log as soon as possible.

Note: for the sake of the experimentation we'll do our best to test in real usage conditions. However, at first we'll simulate the production and consumption data.

This second DAISEECamp (#2) is, at first, part of two camps :

• A multi-sites SummerCamp initiated by friends from Le Biome
• A design purpose camp call DozeCamp in the context of the comingInternational Biennale du Design 2017

Documentation of the DAISEECamp#2 can be found HERE (still really sorry, it's mostly in french we are working on the translation).

Explanation of what is CitizenWatt by Olivier Blondeau from Citoyens Capteurs (in french not yet translated):

3 main purposes for this camp

• Consolidate the documentation process by slightly switching toward full GitHub support and link with Multibao
• Debug issues with the CitizenWatt sensor and make them work
• Make it possible for Raspberry Pi or any Ethereum node support to mine at least a block

1st goal : to have the prototypes of each of the necessary bricks that work to focus during the next month on the articulation of each bricks in order to have a functional prototype within a month.

2nd goal : answer to the Automation challenge since the core of our work since le last 4 logs are about how to automate the peer-to-peer transaction process with the blockchain (please see : last Log for instance)

CitizenWatt Sensor : make it work

For the purpose of this session, @Olivier Blondeau came at our local hackerspace (La MYNE) to help us solve the issues we had with the CitizenWatt sensors.

The first step was to compare the hardware part to make sure there were no issues compared to a CitizenWatt sensor that works:

No issues were found. It appears that the trouble came from the software and more particularly the way we flashed the ATMEGA. (Update of the instruction are to come concerning the CitizenWatt sensors then).

Indeed, after following the flashing process using a FTDI programmer (Code source: sketch Arduino)

e ended up with 5 CitizenWatt sensors working:

Once the CitizenWatt sensor are working it is necessary to couple the sensor to a Raspberry PI in order for the sensor to communicate the data it senses (through RF in this v1 version of the board and through Low Energy Bluetooth in the coming v2 version of the board). This means that it is necessary to install the CitizenWatt disk image and interface on the Raspberry Pi.

It turns out that it works well with the Raspberry Pi 1 but not with the more recent ones since this is not the same architecture. This leads us to another issue then : we need to build the CitizenWatt UX image and boot for a Raspberry PI 3 (that is more powerfull than a Raspberry 1 and might be right to mine as an ethereum node). Clement D., one of the core developer of CitizenWatt thus took some with us to build and test. Exchange and procedure are HERE (instructions on this part are to come ASAP).

However, we did test the good functioning of the CitizenWatt on site with a Raspberry Pi 1 install... and it worked well. However, it turned out that RF is not powerful enough to push data from a floor to the other.

Testing has been carried out with a electricity consuming device:

Plugging the Amp plier to the brown cable (the one that get electricity into the device basically)

Enables you, through the local interface, to follow the consumption (yep... do not bother with the guy taking the photo instead of sreen-printing :-) ):

At the end of the day, we still have some trouble to boot the CitizenWatt disk image on a Raspberry Pi 3. Moreover, architecture of the v2 PCB of the CitizenWatt sensor is to come and should be more interesting for our need. However, for the sake of experimentation we carry on with the v1 for the moment. You'll find all the necessary information about the PCB plans and codes of the CitizenWatt sensor AT THIS LINK (GitHub repo).

Moreover, we still carry on installation and work on Open Energy Monitor.

Ethereum mining nodes on Raspberry PI 3 or any other support

As stated on the previous LOGs we do not have so much trouble to make raspberry pi as ethereum node of a common private blockchain. Our issues come from the fact that in order for the nodes to participate to the validation and transmission of blocks to the common private blockchain, it is necessary for this node to have mined at least once to generate the DAG file (necessary for the propagation of the blocks in the blockchain). The fact is that for the moment raspberry pi (1, 2 or 3) does not have enough power to mine.

Here are some of the trials made to overcome this issue:

• Increase the swap memory of the card
• Generate the DAG file without mining (meaning to generate the DAG file on a computer and copy it onto the Raspberry card)

None of those tests are conclusive. As a result, we've decided that it could interesting and more relevant to change the ethereum node support : from a Raspberry to a PINE64+. This choice was made because @Sam got one and because it is more powerful than a Raspberry.

After installing an Ethereum Node onto the PINE64+ it turns out that... MINING WORKS and PROPAGATION of the the blockchain also WORKS with this card. Documentation is HERE.

Conclusion

• CitizenWatt sensors are working well however we still have issues on the installation of the CitizenWatt disk image on a Raspberry PI
• Mining does not work on a Raspberry PI ethereum node but works on a PINE64+ as well as block propagation on the chain

We are approaching the possibility for full automation from the data captation to its transmission and processing (using it for automated transactions between peers) to end up at the end of the chain with the DApp interface to manage peer-to-peer energy transaction.

What's remaining to be done ?

• Install the CitizenWatt image on the PINE64+ to have a full Ethereum node running on a Energy Monitor IoT
• Make the articulation between the collected data from consumption and production (CitizenWatt and OEM) with the Blockchain
• Investigate and practice IPFS and BidChainDB

As part of the development of some bricks of the DAISEE program, two of the main technological bricks are:

• How to make Smart Energy Monitoring/Meter IoTs as Ethereum blockchain nodes that can talk to each other via a blockchain and make and validate transactions ?
• How to automate the transactions management ?

Documentation can be found here (documentation is still mainly in french, we'll do our best to translate it - if by any chance you wanna help you're more than welcome):

• For the Ethereum Installation (RaspberryPi) using GETH and an alternative way for the Installation of an Ethereum node on a Raspberry Pi using PARITY
  
• For the Design & Deployment of SmartContrat Peer-to-peer Energy
  
• For the Design & Deployment of DApp

You'll also found more detail instruction on the instruction web page.

Building Ethereum Nodes

Documentation: Ethereum Installation (RaspberryPi) using GETH and an alternative way for the Installation of an Ethereum node on a Raspberry Pi using PARITY

In the related documentation, you'll find the process for the installation of an Ethereum node on a Raspberry PI using various techniques. It also focuses on the problems and difficulties we've been facing and how to overcome some of them.

Please note that the first attempts have been carried out on the emonpi which is a costumed raspberry pi for the Open Energi Monitor. However, the process is further described in the document for Raspberry Pi in general.

3 ethereum nodes on Raspberry PI talking to each other on a common private blockchain

Building a peer-to-peer energy transaction smart-contract

Documentation: Design & Deployment of SmartContrat Peer-to-peer Energy

The first step before building the smart-contract is to define

• why do we need a smartcontract
• what does it need to do
• how does it do it and when

Why do we need a smartcontract ?

We need a smartcontract in order to automate the energy and currency transaction processes between peers. Indeed, the aim is to make it simple for the prosumer to manage the transactions with other prosumer while keeping the process transparent and appropriable.

What does it need to do ?

For us and at the moment, it need to automate transactions while called automatically by a prosumer either selling or buying energy.

How does is do it and when ?

It does it while comparing on an "energy market" who's producing to much and who needs energy for consumption. Then it triggers the transaction while being called by a prosumer automatically. Finally, it updates the energy and currency account while providing both account with the necessary (positive or negative) balance.

Building a dApp

Documentation: Design & Deployment of DApp

The dApp enables to have a user interface to manage the smartcontract and, thus, the transaction process. The related documentation focuses on the development of decentralized application based on Ehtereum Javascrip API WEB3.

The dApp makes it possible to see :

• The ether balance of the prosumer account
• The energy account of the prosumer account
• The latest transaction
• Other information about the blockchain

The accounts are updated each time there is a transaction from a producer to a consumer. Here is a video showing the transaction virtually happening between two accounts:

Conclusion

From now, we are able to :

• make Raspberry PI ethereum nodes talking with a common private blockchain
• build an energy smartcontract making it possible for two or more prosumers to make virtual energy transaction on a private blockchain
• have an user interface making it more appropriable and visual (some more work remains to be done on the UX side)

Our problems :

• CItizenWatt IoT sensor are not yet ready since we still got issues to build them and make them work
• Raspberry PI are ethereum node but are not yet able to validate and transmit transaction because it requires to mine once to initiate a block while generating a DAG file, which is necessary for the Raspberry PI, as a node, to participate to the network. This is due to lack of memory and power of the Raspberry PI 3

What's remaining to be done :

• one of the priority is to articulate the CitizenWatt and OEM sensors with the blockchain
• fixing the technological choices
• investigating IPFS and BigChainDB for hydridization with a blockchain

Extracted from the BlockChainDB white paper.

After both the #compteurconnect and the #blockfest hackathon, it is time for us to build stuff related to a local and concrete experimental context. That's how the DAISEECamp #1 was build: in order to define in which context and how the current DAISEE development can interact with the local relality of the ground.

As a result, we found a potential experimental ground with a local (near Lyon) group of households including Louis' father house. The documentation (in French for the moment we do are sorry about that) can be found HERE.

The experimental context ground

An picture is far more representing than a bunch of words...

Basically, the set of houses are located remotely from the town in the country side with some really interesting assets for experimentation :

• First Louis' father is already committed to experimentation int he field of energy, agriculture and a lot of things related to sustainable development

• Secondly, the house is well set for experimentation of the DAISEE program since it already gather : 3 independent sources of solar electric production, 3 independent sources of local consumption (which means : 3 production meters and 3 consumption meters).

• Photovoltaïc pannels linked to SMA Sunny Boy SB2500HF-30 (SB20F-30HF-IA-fr-32.pdf) UPS

Picture from @Nicolas Loubet - 16/07/16 - CC-BY-NC-SA.

Picture from @Nicolas Loubet - 16/07/16 - CC-BY-NC-SA.

Picture from @Sam 16/07/16 - CC-BY-NC-SA.

Note: The UPS can be connected via Bluetooth. Unfortunately, the bluetooth module is not installed, and it is not possible to get back the date via bluetooth for the moment.

Moreover, there is a local project about building a distributed solar powerplant divided around 10 site of 9kW each.

What is energy and what do we want to do here with DAISEE

The aim of this session was to clarify what energy is, what are the interest of the contributors in the DAISEE program and what are the next steps.

What we've done during this Camp

• Test the Open Energy Monitor on site

Picture from @Sam 14/07/16 - CC-BY-NC-SA.

It turns out that data from the EmonPi (OEM) does not seem relevant. Even if the EmonPi is not connected, is still mesure a 34W power. It can be the sensibility (noise) of the sensor. We have to check if an AC/DC adaptor can improve reliability.

• Take some time with Louis' father to discuss the needs and understand into details the photovoltaïc solar panel installation and use chain : from first contact with the contractor to the electric production and invoicing to the electricity buyer. We gathered a lot of data and sources that helped us to understand where DAISEE can add value for both the consumer and the contractor/buyer/distributor.

Discussion about the DAISEE's orientations

This camp was also the opportunity to discuss the relevance of the blockchain technologies for he DAISEE project.

It turns out that the blockchain technologies are part of the solution but have current limitation that make them not fully relevant for the energy sector. Some points are:

• Real time data management on a blockchain is really limited from both the validation time of a block, the size of the blockchain and the necessary fee for each transaction (that can add-up to really costly overall fee)
• Identity management and securing the viability and relevance of the energy data that are collected
• It's relevant for transaction and automation of the processes
• It will require to be hybridized with other technologies related to data storage (IPFS for instance) and database management (BigChainDB for instance)

Between the 6th and 12th of June, the Blockfest was held at Ecole 42 in Paris.

We were there to welcome new members to the contributors team and work on a very first prototype: how to make 3 independent RaspPi Ethereum blockchain nodes to communicate with each other and make transaction.

You'll find the detailed documentation following THIS LINK. More specific documentation can be find HERE about how to deploy a local ethereum blockchain on one or more RaspPi. More specific documentation about the SmartContract is HERE. Last of all, our presentation about our production can be found HERE.

Who were the contributors ?

• Core Team (on site)

• Samira (full dev)

• Louis (hardware)

• Aude (TheDAO)

• Xavier (Ethereum)

• Rieul (facilitator)

• Nicolas (facilitator)

• Clément (curiosity)

• Core Team (remotely)

• Paul (Energy Monitor / CitizenWatt)

• Isabelle (design)

• Timothée (design)

• Alizée (design)

• Contributors (sprint)

• Sprinters Code

• Catherine : student at 42 / dev

• Yannick : IT Engineer.

• Petar : PhD in Physics and IT dev / SmartContract

• Sentia : PhD in Climate and Ice study / Engineer in environment / Dev PYTHON and atmosphere simulation/modelisation

• Olivia : PhD in ARtificial Intelligence / Digital Innvoation at TOTAL SA

• Sprinters Energy

• Laurence : digital usage professor. Co-founder CitoyensCapteur

• Antoine : Renault Co. IT engineer / Innovative project officer (Tweezee, 1L) / Electronic

• Mentors

• Jean-Henry : Professor at Geneva University (blockchain oriented IT)

• Jörn : PhD thesis in IT applied to law.

• Serge : note taking / Education / Badges for trust creation

• Observers

• Jean-Christophe : Renault Co. / Finance at Renault Nissan / Blockchain applied to banking and insurance.

---

Smart contract


Mentors reviewing smart-contract. Photo RIeul (CC-BY-NC-SA)

• 1st iteration : fonctional description of a smart contract (SC)
• Assumption: each user pushes electric production and consumption data all together in real-time.
• For each user, the SC assesses which one is sur-producing and which one is over-consuming.
• The SC then calculate if electricity is available and/or needed depending on the information on the blockchain.
• If a user does not own enough electricity :
• If electricity is available on the blockchain, he buys some.
• If not enough electricity on the blockchain he buys at the main producers.
• If a user is sur-producing, then it put it on the blockchain ans making it available.
• If there is a need of electricity on the blockchain, he sells it.
• If there is no need, he sells at the main producers.
• 2nd iteration : Design of the SC transaction

Exchange with Pierre-Alexis Ciavaldini (co-organiser of the BlockFest, student at 42).

Triptique :


• Tokken
• Exchange
• Ethereum

Principle :

• Energy IoT Monitor
• if Positive Differencial > The Information fuel the IOT with electricity.
• UX with wbe platform either based on the IoT or using IPFS .

To be defined :

• Do we directly sell energy or difered in time ?
• Can the consumer directly buy to a specific producer ?

Paradigm :

• Priority for direct exchange
• Stockage enables delays in time
• If no one on the grid need electricity then you store

How would it work between a producer and a consumer ?

• Electricity production for the producer
• Get back the production data from the IoT
• Store the data on the IoT (or use IFPS)
• Producer has a an "Wallet Ethereum" with coin on his/her IoT
• Get back the consumption data from the IoT
• Store the data on the IoT (or use IFPS)
• Producer has a an "Wallet Ethereum" with coin on his/her IoT
• Executing the SmartContract with buying rules
• The cosumer's account buying electricty
• Transaction is made towards the producer
• The producer's account is credited with the right amount of money (less the potential fee for running the grid

Transactions :

• from address to address
• towards a specific 0 address on the blockchain pointing towards the SC

2 timing :

• one for the currency transaction
• one for the energy transaction

Ethereum / IoT

An Ethereum node running on a Raspberry Pi. Photo RIeul (CC-BY-NC-SA)

• Equipment
  • 3 Raspberry Pi with ethereum client installed (each rasp is a node of a local ethereum blockchain)
• 3 SD cards
• 2 computers
• Other Solution
• Using wiolink to simulate energy production and consumption.
• Get the energy balance data on the blockchain from the past hour
• Call the SC with input and show the effective SC transaction
• Ethereum Transaction
• Following steps to be followed here : https://github.com/EthEmbedded/Raspi-Eth-Install




For each 3 Pi, here are the steps for setting up a local blockchain:

• install Raspbian Jessie Lite on the SD card for each Raps https://www.raspberrypi.org/downloads/raspbian/
• Turn on the raspberry and SSH connect : ssh <user>@<ip_adress>
• Install Go Ethereum on the raspberry
• wget https://github.com/EthEmbedded/Raspi-Eth-Install/archive/v0.3.3.tar.gz
• tar -xvzf v0.3.3.tar.gz
• cd Raspi-Eth-Install-0.3.3/
• ./geth-installer.sh
• Add "geth" in the PATH
• export PATH=$PATH:$HOME/go-ethereum/build/bin
• Get and copy the folder "data4" from Xavier containing a local blockchain (few nodes/blocks)
• Modification of the key in nodekey in order to make each node unique
• vi /home/pi/data4/nodekey
• Launch the node on the Raspberry
• geth --rpc --rpcaddr <ip_adress> --rpccorsdomain="*" --networkid <network_id> --identity <node_name> --datadir <data_dir> --verbosity N --maxpeers M --ipcpath <ipc_path>
• <ip_adress> : ip of the raspberry
• <network_id> : common id for all the raspberry
• <node_name> : name of the node of a raspberry which will be different for each raspberry
• <data_dir> : folder
• N : log level
• M : max number of nodes
• <ipc_path> : path to geth.ipc
• Connect to node
• geth attach <ipc_path>
• <ipc_path> : path to geth.ipc
• Add the other Rasp

• PI Information
  • b8:27:eb:20:64:45 / bf7-1 / ssh pi@10.19.244.249
• b8:27:eb:7c:65:bc / bf7-2 / ssh pi@10.19.244.247
• b8:27:eb:e4:ae:c6 / bf7-3 / ssh pi@10.19.244.240

Note: If the Geth command does not work > export PATH=$PATH:$HOME/go-ethereum/build/bin


• To launch the Geth console :
• geth attach ipc:/home/pi/data4/geth.ipc
• Users
• Sur bf7-1,
• Account #0: {60d6f22d9b5684160065542a9a1c76f6139019a4} /home/pi/.ethereum/keystore/UTC--2016-06-12T05-11-22.486302973Z--60d6f22d9b5684160065542a9a1c76f6139019a4
• Passphrase = bf71
• Sur bf7-2,
• Account #0: {088a02f7ab6ea9f007ce4cd4b0aa2710a2e99725} /home/pi/.ethereum/keystore/UTC--2016-06-12T05-11-50.666476289Z--088a02f7ab6ea9f007ce4cd4b0aa2710a2e99725
• Passphrase = bf72
• Sur bf7-3,
• Account #0: {655eb76642212093c8d2a5f59ae671c9601607fc} /home/pi/.ethereum/keystore/UTC--2016-06-12T05-12-03.156618517Z--655eb76642212093c8d2a5f59ae671c9601607fc
• Passphrase = bf73
• Adding nodes in static-nodes.json for automatically adding nodes

RaspEth communication

• Before making 2 rasp commnicate on a same blockchain it is necessary to mine a first block manually to get a common base (same root)
• In the specific case of the Blockfest, the fist blocks have been given to us by the mentors.

Anything Goes challenge : define the constrains and the vision of DAISEE on... Mars ! Yep... "Anything Goes". here is the related video:

Why Mission to Mars ?

Basically,SpaceX aims at sending people on Mars and we'll be needing to build the energy infrastructure on Mars in a way that is more sustainable and resilient than on Earth.

More over, Tesla is building the future of energy storage infrastructure and energy distribution network complementing the "well-known" "conventional" grid or micro-grid.

Then we think that, given the conditions on Mars and the necessity for energy production and distribution, DAISEE could be the future of the energy infrastructure on Mars.

Energy basics on Mars

• No fossil fuel
• Solar energy (about 50% of the earth's solar irradiation)
• Wind power energy : Mars is a windy planet
• Nuclear fission/fusion since there are nuclear fuel on Mars
• Plant based electricity production
• Carbon dioxide sublimation (solid to gas transformation) > energy generation

Grid infrastructure basics

• Low pressure and gravity (surface gravity: 38% of that on Earth...)
• The Mars landers Viking I, Viking II, Pathfinder, Opportunity Rover, and Spirit Rover identified aluminium, iron, magnesium, and titanium in the Martian soil" (see Wikipedia), confirming that materials on site con be used to build the infrastructure
• Temperatures are very low, thus enabling more efficiency for electrical distribution systems.

What's you thoughts about the feasibility and technical constrains on Mars to build this infrastructure ? You might have some ideas about how to work it out ?

We thought about this Mars project because it makes it possible to really think out of the box the potential application of DAISEE in a both new and known environment: new since it put some more constrains that we are not used to deal with, known because Mars is a planet with limited ressources as we know it on Earth. Thinking and building DAISEE on Mars, enables to think about innovative ways to distribute and exchange energy.

We would be glad to heard about your thoughts. Please let us know.

The DAISEE Team

2016-05-21: Hackhaton #CompteurConnect - DAISEE has been revealed :-)

The #CompteurConnect hackathon held by the French ministry for environment, energy and ecology has given the DAISEE team the opportunity to:

• Make the project vision clear & work on the global design of the project
• Work on a (proto) smart contract based on the ethereum blockchain that simply enable to a person who produce a surplus of electricty to exchange this surplus with another person who is consuming in exchange for a token.

This smart contract is the first energy peer-to-peer contract based on the Ethereum blockchain. It works more or less... still need improvement and it's modest in its structure and on what it is doing but still... the first energy smart contract.

If you wanna look a bit into it it's in the GitHub repo. Please feel free to improve! You'll also find our final presentation in the shared files called DAISEE slide-deck.

The documentation (in FR, so sorry) of our process during the hackathon is here.

As winter and the deadline for the first challenge are coming, it is time to state how advanced we are today (2016-07-19). Moreover it's been a while since we haven't post something about our advances its because... we're trying to progress !

2016-07-19

Technically

• We've installed Ehtereum node on independant Raspberry Pi II and III and made them communicate with a local ethereum blockchain
• We've made some basic transaction on the local blockchain between the Raspberry PI
• We've code a energy "smart contract" that has not been tester yet
• We've finished soldering on the CiizenWatt PCB, unfortunaltely it doesnt't work yet (we've got some trouble with it... we'll explain later in antoher log)

Functionnally

• We are looking for experimental territories to test in real conditions
• We've found another playground remotely from Lyon at the @Louis Villard parents' house engaged in a transition process
• We still don't understand why our CitizenWatt are not working
• Open Energy Monitor is functional but suffers from weak sensitivity and consistance in consumption data.

The related documentation :

• for the CitizenWatt
• for the installation of Ethereum on a OpenEnergyMonitor
• for the SmartContract

Lot of work has been lead by @Sam @Louis Villard and @Paul Fl on soft and hardware.

Extensive work has been lead by @Nicolas Loubet @Rieul Techer @Aude Omn and @xavier on the ecosystem and community building around te DAISEE project.

Carry on following the feed... more logs to come.

2016-04-25

Technically

• We can measure and log current thanks to the current clamp
• We installed the Ethereum client on a Raspberry Pi
• We can perform some basic smartcontracts

Functionally

• We have the building that will serve as playground for the project (La M[y]ne, the physical space hosting la Paillasse Saône, eco hacklab in Lyon, France)
• We are in the process of building 5 pairs of Citizen-Watt + Raspberry Pi

We will use a Citizen Watt board to measure and tokenize the energy production and consummation : this is basically a current clamp connected to an home made customized Arduino (ATMega368 based PCB).

On a Raspberry Pi, we will manage the blockchain capabilities (via Ethereum), the smart contract between actors, allowing a smart and decentralized governance.

Planning of the project

Step 1

We use each room of a house to act as various actors in a simulated energy market.

Step 2

We scale up the POC to a few houses to create a real small energy market, some actors producing energy, some other consuming, and some actors doing both.