Updated to include results of the EDP IoT hackathon and additional resources

We live in an age of innovation in the energy sector. Renewable energy has been growing significantly over the last decade and EDP, the leading producer, distributor, and supplier of electricity in Portugal, has been an early promoter of the clean energy revolution. The integration of IT and communication technologies with the secular distribution grid, resulting in the complex infrastructure commonly known as smart grid, has been key to allowing the growth of renewable energy and to maximizing the potential for energy efficiency.

The challenge

EDP has decided to challenge startups to find an inexpensive end-user solution for home energy monitoring that is easy to install and use. This solution should enable the customer to collect data on energy consumption and explore ways of using the information. It aims to explore new business models that can include open-source approaches to commercial products, exploring possible integration with the home automation industry.

EDP decided the best approach to address the challenge would be through a hackathon, working closely with Microsoft to prepare for the event.

Customer profile

EDP logo

EDP – Energias de Portugal, S.A. is the largest generator, distributor, and supplier of electricity in Portugal, with significant operations in electricity and gas in Spain as well. EDP is the third-largest electricity-generating company and one of the largest gas distributors on the Iberian Peninsula.

EDP has a relevant presence in the energy world, operating in 14 countries, with more than 10 million electricity customers, 1.4 million gas supply points, and more than 12,000 employees worldwide. On December 31, 2015, EDP had an installed capacity of 24.4 GW, generating 63.7 TWh, of which 72% comes from wind and hydro plants.

EDP is a strong believer in open innovation. It works with universities, scientific institutions, startups, value chain suppliers, and many other innovation sources. EDP partners with entrepreneurs, large corporate business angels, venture capital funds, and other investors. It makes available a set of tools that include funding, management support, and a business-oriented test base with an international footprint. EDP is committed to be at the forefront of energy innovation.

EDP Starter

EDP Starter is the entrepreneurship ecosystem from EDP. It’s the ultimate program to support projects in the energy industry, from the idea stage to venture capital investment.

It’s an innovative incubation concept for startups in the energy sector. Much more than a physical space, EDP Starter is a networking enhancer, inside and outside of the EDP Group, and a disseminator of knowledge, enabling startups to better prepare themselves for growth in both the domestic and international markets. The partner network is a catalyst for success, guiding startups through the different stages of their journey. EDP Starter already has appraised 500 projects, helped 25 startups, and created 250 jobs.

Narrow Net

Narrow Net Logo

Portugal has always been a pioneering country—The Discoveries is a clear example. But nowadays technology is core to Portugal’s pioneering. Among the technological examples we can highlight are the pioneering and rapid adoption in Portugal of Via Verde, massification of ATM machines by Multibanco© boxes, and penetration of mobile phones. All these discoveries and adoptions were aimed at improving people’s quality of life.

Narrow Net follows this philosophy. This Portugal-based company has defined as its mission to help Portugal lead one of the most exciting challenges of this century: to allow objects to speak to each other, improving people’s quality of life, with insignificant costs.

To do this, the company provides availability to all the Ultra Narrow Band (UNB) communication technology, exclusively designed for the Internet of Things (IoT), and with the possibility of becoming a standard of communication between objects in the future. But mostly, this technology, with negligible costs, allows access to services by the entire population, something not possible before, making it a great social benefit.

Narrow Net holds the exclusive rights to deploy SIGFOX technology (patented) in Portugal, aimed at developing a specific communication network in this country while simultaneously developing the ecosystem.

Startup ecosystem

Despite its relatively recent startup history, 40 scaleups (startups with more than $1 million in funding raised since their founding and at least one funding round in the last 5 years) have been identified in Portugal. They have cumulatively raised over $166 million from venture capital since inception, with an average of $4.2 million each. At least 24 other companies have secured funding in the range of $0.5-$1 million.

Today the Portuguese startup scene is in a very different position from where it was a few years ago. Startups, entrepreneurs, and the various players have become more mature. Now, startups such as Uniplaces, Feedzai, Unbabel, Talkdesk, Veniam, and Seedrs are leading the way. Entrepreneurs such as Miguel Amaro, Cristina Fonseca, Nuno Sebastião, João Barros, Vasco Pedro, and Carlos Silva are showing how it’s done and are inspiring a new breed of entrepreneurs to build companies with an international mindset. And today, international VC firms such as Index Ventures, Balderton, and Accel Partners are looking at Portugal as a place where great startups can be found.

Portugal is rising from the late-2000s financial crisis and rapidly emerging on the European startup map, with a very vibrant entrepreneurial community able to produce tangible results, despite its relatively young history. Although it can’t yet be compared with leading countries like UK, Germany, and France, Portugal does share many of the same similarities—and a smaller gap—with Spain and, particularly, Italy.

Home automation and smart meters

Smart metering systems measure electricity consumption and are implemented to replace manual methods of gathering information about energy use. By allowing a look at real-time consumption, smart meters are a useful tool to understand where energy use can be cut and where cost-effective measures need to be implemented. Likewise, they can communicate with home automation systems to help control energy use, particularly at times when costs are at their highest.


Preparing for a public hackathon of this nature requires a lot of work involving technical skills with hardware and software. EDP early on set a goal of opening this hackathon to 20 teams of 3 members each. The team applications would be evaluated by EDP and Microsoft. That was the challenge. The solution is detailed in this report.

We soon realized the main challenge would be the hardware development allowing teams with fewer hardware skills to compete fairly. We hoped that strong teams in software development would have the opportunity to apply their knowledge without necessarily having to develop the hardware. Likewise, we wanted teams with hardware expertise—the makers—to be rewarded appropriately.


  • SIGFOX Compression Algorithm – to compress data from 16B to less than 12B.
  • SIGFOX Callback, IoT Hub, Azure Stream Analytics, Power BI, Logic Apps, Notification Hub Setup – to process SIGFOX messages through to visualization and notifications.
  • EDP IoT Box – custom Arduino Shield, Custom 3D Printed Enclosure.
  • edpComm Library – C++ library for communicating with the EDP IoT Box.
  • Azure ramp-up material – docs, walkthroughs, and code samples.
  • Arduino ramp-up material – docs, walkthroughs, and code samples.
  • EDP Hackathon website – visit it at http://edpiothackathon.edp.pt.

The team:

  • João Almeida – Senior Technical Evangelist, Microsoft Portugal
  • Luis Calado – Principal Technical Evangelist, Microsoft Portugal
  • Jon Gallant – Principal Software Developer, Microsoft Corporation
  • Francisco Maria Santos – Software Developer, EDP
  • Diogo Ribeiro – Electrical Engineer, EDP
  • João Sabido – Entrepreneurship & Business Incubation, EDP Starter
  • António Baptista – Entrepreneurship & Business Incubation, EDP Starter

Team's White-board and Francisco Santos

Hackathon prep

One of the major objectives was defined as creating documentation suitable to all the participants in the public hackathon. When assessing the hackathon’s audience, three distinct personas were identified: Beginner, Intermediate and Advanced. The goal would be to create appropriate documentation for each persona.

  • Beginner: Teams with less experience in hardware and/or software. They may be startups dedicated to hardware development that will easily be able to deduce and extract data from the EDP smart reader (EDP Box); likewise, candidates might only have strong skills in software development, particularly in the areas of data visualization or even cloud.

  • Intermediate: Teams with intermediate knowledge in hardware and/or software areas. The goal will be to provide adequate documentation to the level of knowledge and be as productive as possible. Learning is a clear objective and the ideal conditions must be created for this to happen. In this way the results will be more valuable. This type of candidate should easily apply their knowledge, evolve, and be successful creating added value.

  • Advanced: It is EDP’s goal to have startup applicants with proven experience in hardware and/or software. For the hackathon to be a valuable experience, it is recommended to have challenges and proper documentation. These candidates will want to apply their skills and investigate innovative approaches framed in the challenges presented. It is desired that these candidates have the right guidance to surprise the jury.

We decided to provide appropriate documentation for each of level of knowledge, segmenting the documentation also by software and hardware.

From a technical standpoint, the challenge would be to give a hardware development experience to the candidates that was not overwhelming for beginners. Given that there may be participants with little hardware knowledge, it would be important to be able to give a solution tested and guaranteed. It would be desirable for these startups to want to invest more around software where they have strong skills.

The biggest technical challenge in the development of the EDP IoT Box was the integration with SIGFOX. The SIGFOX communication, as a low-power wireless protocol, sets a limit of 12 bytes for message size and a maximum of 140 messages in Europe (ETSI 300-220). The data read from the EDP Box has a larger length, hence it would be necessary to define data structure conventions and/or implement a compression algorithm.

Device architecture

The technical architecture was previously defined after research done by the EDP engineering teams. One of the relevant points was the SIGFOX communication and it involved the collaboration with Narrow Net, responsible for the network deployment in Portugal.

This architecture would correspond to the hardware proposal from the hackathon organization team. This way the teams struggling more with the hardware development would be able to follow the instructions based on the diagrams.

In this project, the main objective would be to define, test, and document this assembling, which was given the name of EDP IoT Box.

Akery 3.3 beta

EDP Box - Smart Meter

Component Provider Details Description
IoT Development Board Snootlab Akeru beta 3.3 This new version of Akeru offers better access to advanced modem functionality and low power consumption. Allows rapid prototyping with SIGFOX and Arduino / Genuine technologies. Direct application developing devices for water/electricity meter readings, hives weighing systems, run count or warning pollution. Communication via IoT SIGFOX technology is done by sending data to a serial port through the Arduino.
EDP Box EDP (Janz C380 Prime) Energy Counter Single phase, ranges of current 10-80(A), voltage range 220/230V, active and reactive energy, AMM solutions and for Smart Grids, 32 tariffs (able to operate with 2 tariff structures simultaneously). Capacity of communication GSM, GPRS, PSTN, Ethernet and PLC.

The EDP IoT Box underwent several iterations until the final format.

EDP IoT Box Diagram

Prototyping phase for EDP IoT Box

Integrated Circuit

Several components were used:

Phase Component Details Description
Prototyping Bread board ABS Prototyping Board A bread board was used in the prototyping phase to test the connectivity between the EDP Box (Han port) and the Akeru board. Boards like this are found at any electronics supplier.
Prototyping Fritzing (software) Fritzing Fritzing is an open source application that makes electronics affordable. A software tool that allows you to define electronic diagrams and is strongly supported by the community. It promotes a creative ecosystem that allows users to document their prototypes, share them, teach electronics, and make professional PCBs.
Prototyping MAX485CPA+ IC MAX485CPA+ The MAX485 is a low-power transceiver for RS-485 communication. Each part contains one driver and one receiver. It features reduced slew-rate drivers that minimize EMI and reduce reflections caused by improperly terminated cables, thus allowing error-free data transmission up to 250 kbps.
Enclosing Prototyping Board 54T9823 A prototyping board was used to create the integrated circuit (IC) in a single piece. The actual Standard PCB used was bought locally. The main concern was to create a small IC that could fit next to the Akeru board inside the envisioned enclosing box.
Enclosing 3D Printed Enclosure Fusion 360 Model Once the prototyping board was ready, together with the Akeru board it was possible to create a 3D model and print an enclosing for the EDP IoT Box. Fusion 360, from Autodesk, was used for the model while the printing was done by the EDP Labelec team and their FabLab.

Edp IoT Box with enclosing

EDP Box and EDP IoT Box with enclosing

The Akeru board

The Akeru board is indeed an Arduino Uno, and we may even use the Arduino development tools.

The development in Akeru is also done with the Arduino language, which is merely a set of C/C++ functions that can be called from your code. We can create sketches that undergo minor changes (for example, automatic generation of function prototypes) and then is passed directly to a C/C++ compiler (avr-g++).

This development consisted of an implementation relying on the Modbus protocol, used to communicate through the HAN port in the EDP Box. We used the open source project Modbus-Master-Slave-for-Arduino to ensure Modbus communication.

To implement the SIGFOX communication, Snootlab provides an Akeru Library, where functions are made available to initialize communication and send data.

The main challenge was the data compression algorithm to apply in SIGFOX communication. Based on the information collected via Modbus from EDP Box, the relevant data was identified and analyzed:

  Year Month Day Offset Clock Status AMR Profile Status Payload
Example 16 09 26 xx xx xx xx
Length 1B 1B 1B 1B 1B 1B 4B


  • Assuming implementation until the year 2099. Only allowing year with two chars (1 byte).
  • Offset should be considered as a Day offset as in the number of 15-minute intervals after 0:00.
  • A total of 96 intervals is expected.

With this algorithm it was possible to construct a message with a total length inferior to 12 bytes—the limit for SIGFOX.

Here are some code snippets from the EDPComm library. This library gathered all the implementations around EDP Box data reading and sending data through SIGFOX:

// Initialize Libs
Akeru akeru(RX, TX);
Modbus master(0); //0 for master and [1,247] for slave
modbus_t telegram; //structure for query slave
SoftwareSerial mySerial(10, 11); //Create a SoftwareSerial on pins 10&11
EDPComm edpComm(&mySerial, &akeru); //start EDPComm lib

To send data through SIGFOX, the code is quite simple to use, thanks to the library made available by Snootlab:

void EDPComm::sendToSigfox(const String payload)
	bool send = akeru->sendPayload(payload);
		Serial.println("Message sent to Sigfox.");
		Serial.println("Message could not be sent to Sigfox.");

Reading data from the EDP Box required respect for the Modbus protocol and some custom extensions implemented by the EDP Box:

int EDPComm::getLoadProfileData(uint16_t dataArray[16]){
	/*this function returns the last load profile data considering the default load profile structure with a variable size of 4 bytes
	 int profileValue_1half= (((dataArray[6]<<8)&0xFF00) | ((dataArray[7]>>8)&0xFF))*0x10000; 
     int profileValue_2half= ((dataArray[7]<<8)&0xFF00) | ((dataArray[8]>>8)&0xFF);
	 int totalValue = profileValue_1half+profileValue_2half;
	return totalValue;         

Cloud architecture

To allow EDP Box readings to be sent to a cloud platform, such as Microsoft Azure, it would be necessary to define an architecture for the cloud back end. The main objectives identified were:

  • Ingest data sent via SIGFOX into the Microsoft Azure platform.
  • Persist the data received in the cloud platform and ensure its veracity. Data should be processed and reused for different types of analysis. Ideally it should be possible to use any data solution to process the data.
  • Implement an architecture that would allow readings to be read in near-real time, using Microsoft Azure services.
  • Test and investigate scenarios of anomaly detection.

Cloud Architecture

The implementation followed the concepts described in the Azure IoT Reference Architecture. Communication and data ingestion were the main points at which Azure IoT Hub was identified as a key piece. However, to reach this service we had to work around the communication protocol, as follows.


SIGFOX is a French company that builds wireless networks to connect low-energy objects such as electricity meters, smart watches, and washing machines, which need to be continuously on and emitting small amounts of data. SIGFOX was founded in 2009, providing global cellular connectivity for the Internet of Things. Its infrastructure is independent of existing networks, such as telecommunications networks.

SIGFOX deploys Low-Power Wide Area Networks (LPWAN) that work in concert with hardware that manufacturers can integrate into their products. In terms of compatibility, the network takes a similar approach to traditional GSM networks. Any device with integrated SIGFOX hardware can connect to the Internet—in regions where a SIGFOX network has been deployed—without any external hardware, like a Wi-Fi or ZigBee router. But, in another sense, the SIGFOX network is entirely different than traditional GSM networks, in that it can only transmit small amounts of data.

The main factors that led to the choice of SIGFOX are its low energy consumption and the reliability of communication. Here is a summary of the technology:

SIGFOX Radio Technology  
Purpose Specially conceived for M2M/IoT.
Identity Each device has a unique ID (NOT an IP);
Ultra Narrow Band - Energy-efficient; - Resistant to jamming;
Spectrum ISM free-to-use (ETSI 300-220); Forces 1% duty cycle; Base stations MUST comply as well;
Frequency 828 MHz (Europe); 902 MHz (USA);
Long Range & Protocols 2-way communication with 162 dB path loss;
Customer Payload 12 byte messages with a MAXIMUM of 140 message per day in Europe (ETSI 300-220).

In this project, it would be necessary to send consumption readings of EDP Box to the cloud platform. SIGFOX provides ways to integrate with application systems through custom callbacks. Callbacks are a service that allows SIGFOX to push an event to your server upon an event. For example, a device might send a SIGFOX message upon an external trigger and get notified once the event had occurred. This would be the ideal case for using a callback; the SIGFOX service can relay the messages via a POST/GET request to a specific location (service, app or server). In addition to defining your own server and data, SIGFOX also allows you to transfer your data to cloud services such as Microsoft Azure or AWS.

Creating a new Sigfox custom callback

With the SIGFOX device registered and capable of sending messages, it was possible to create a custom callback from the SIGFOX service page. In the case of EDP, the configuration was quite simple, focusing on the following items:

  • Custom payload config. This field allows you to specify how you would like SIGFOX to decode the payload of your device. You may, for example, want to decode an input byte as an unsigned integer. The configuration in this case was:
year::uint:16:little-endian month::uint:16:little-endian day::uint:16:little-endian offset::uint:16:little-endian amr::uint:16:little-endian payload::uint:16:little-endian
  • Connection string. The Azure IoT Hub access configuration (see below). In idio it is possible to evaluate the structure of connection string that identifies which instance of IoT Hub and also provides the respective security configurations.
  • JSON body. This is the main content of your message. You can specify any custom data you want to configure within the payload. It is also possible to use variables available for any message. In this case the format of the message had the following structure:
"deviceId" : "{device}",
"year" : "{customData#year}",
"month" : "{customData#month}",
"day" : "{customData#day}",
"offset" : "{customData#offset}",
"amr" : "{customData#amr}",
"payload" : "{customData#payload}"

Sigfox custom callback

In this way we were able to integrate the devices through SIGFOX communication with a cloud-based back end, namely Microsoft Azure. The Azure service we used for data ingestion is the IoT Hub, which we describe next.

IoT Hub

The key to cloud back-end implementation is Azure IoT Hub, a cloud service that allows uploading high volumes of data in a secure and reliable way. This process is usually described as data ingestion. In the case of EDP, the cloud back end had the requirements of persisting data and being able to do a multipurpose processing.

In particular, although using an Arduino-based device (Akeru), it was not necessary to resort to one of the Azure IoT SDKs available to communicate with IoT Hub. This communication is guaranteed by SIGFOX through its custom callbacks and Azure bridge.

One of the concerns was the possibility of handling IoT Hub input data. The scenario was considered involving the need to handle message compression. Currently the IoT Hub does not provide the ability to custom process the incoming messages, hence to decompress messages. However, it was a scenario we provided as feedback to the product group and will be analyzed.

Stream Analytics

We used Azure Stream Analytics directly integrated with IoT Hub to process the stream of data being ingested by the devices. Stream Analytics corresponds to a service that provides a complex event processing (CEP) system. We could create multipurpose data processing, based on the different needs, as we describe next.

Configuration for Azure Stream Analytics

  • For data visualization purposes, a query was defined outputting data to Power BI (see below). However, data is transformed implementing the data compression algorithm. Here it is important to emphasize the limits in payload size within SIGFOX communication. This way we could recover all the data while guaranteeing a transparent data protocol between the devices and the cloud platform. In this case, Stream Analytics is responsible for decompressing data sent from the EDP Box.

  • Simultaneously, the second query outputs data to Service Bus. This query initiates a different data flow implementing an energy consumption anomaly detection scenario.

Data visualization with Power BI

In order to demonstrate data visualization in near real time, one of the immediate options was Power BI. Power BI is a set of data analysis tools with a strong visual component. It offers advanced control panels and is multiplatform, meaning it can be consumed through the web or any mobile device. The creation of a report or a dashboard is quite simple, since the access to the data is very agile. You can combine databases, web services data, or even Analysis Services models.

While reading messages from IoT Hub, in Stream Analytics, we have direct integration available with Power BI. You can set Power BI as a Stream Analytics output. Note that you need to authorize Stream Analytics to access your Power BI subscription. Once data is submitted and processed by Stream Analytics, it is made available in Power BI via a dataset. From this point on we can create reports and dashboards. In this project, we customized a page that shows data coming from a real device and an emulator.

Data Visualization with Power BI

For additional information, we recommend this excellent tutorial: A real-time analytics dashboard for streaming data.

Anomaly detection

The objective would be to actively detect anomalies in energy consumption, read by the EDP Box. After setting up Stream Analytics, a specific data flow for detecting energy consumption anomalies was created. This means all readings above a specific threshold would be identified and sent to Service Bus Topics. This service provides a one-to-many form of communication, in a publish/subscribe pattern. Since in a real scenario, we would have multiple users, the use of Topics is adequate. Each published message is made available to each subscription registered with the topic. Messages are sent to a topic and delivered to one or more associated subscriptions. Messages are not received from the topic directly. Instead, they are received from subscriptions. A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Messages are received from a subscription identically to the way they are received from a queue.

In this scenario, a topic called energy was created as shown in the following figure.

Service Bus Configuration

The consumer of the messages in this topic has been ensured by the Logic Apps service. This service provides a simple way to implement integrations in a scalable way. It provides a visual designer to model and automate any process as a series of steps known as a workflow. A set of connectors is made available to help integration with other services and protocols. In the anomaly detection scenario, the Logic App is responsible for detecting messages in the Service Bus Topic and forwards it to a Notification Hub.

Logic App Configuration

The end goal would be to notify users via a mobile application. This service provides a multiplatform, scaled-out push infrastructure that enables sending mobile push notifications. Using Notification Hubs ensured notifications were delivered to all platforms: Windows, iOS, or Android. The biggest advantage of the Notification Hubs service is allowing the abstraction of details from the different platform notification systems (PNS) with a single API and with flexibility in recipients (one or millions of users).

Notification Hub Configuration

With this implementation, the goal was to detect changes in energy consumption patterns, and to notify the user. The scenarios of applicability are vast, and there will certainly be surprises in the EDP IoT Hackathon.


During this hackfest, while technically preparing for the public hackathon, security was not a subject addressed heavily in the implementation. The hackathon will take place in a controlled environment and against EDP Boxes linked to simulated energy points. This is both to assess the accuracy of the data collected and to test security measures possibly to be applied in residential scenarios.

It was decided that security would be one of the evaluation areas for all participants. EDP intends to explore various techniques to prevent misuse of the technology. During the hackathon, some measures were discussed, including executability by EDP:

  • EDP IoT Box installation and setup, protected by a lead seal similar to EDP Box.
  • EDP to manage, SIGFOX identifiers matching them to real customer accounts.
  • Communication between EDP IoT Box and cloud, guaranteed only by code. Installation on client, would not need customization and/or configuration.
  • Security model inheritance: SIGFOX and Microsoft Azure.


The relevant conclusions from this project are a mix of technical and business aspects, but all with a strong impact for EDP.

From a technical standpoint, the conclusions are inherent to IoT. In this particular scenario, it was possible to prove the use of a Low Power Wide Area Network (LPWAN) technology as a viable solution. Technologies such as SIGFOX or LoRa should be considered when other wireless networks are not appropriate—Bluetooth and BLE (and, to a lesser extent, Wi-Fi and ZigBee) are often not suited for long-range performance, and cellular M2M networks are costly, consume a lot of power, and are expensive as far as hardware and services are concerned.

In IoT, there are several architectures for device deployment. Among them are star and mesh architectures. Particularly in EDP’s scenario, a near real-time solution is sought, but the energy readings can be spaced out over time, saving energy consumption drastically. The need for Internet connectivity cannot depend on end customers, so the choice of SIGFOX becomes the most appropriate.

Energy consumption, range, and volume of data are particularly important in the choice of technology:

Characteristic Description
LONG RANGE The end-nodes can be up to 10 kilometers from the gateway, depending on the technology deployed.
LOW DATA RATE Less than 5,000 bits per second. Often only 20-256 bytes per message are sent several times a day.
LOW POWER CONSUMPTION This makes very long battery life possible, often between 5 and 10 years.

For EDP this initiative is transformative since it bets on a totally different execution model. With a focus on promoting initiatives related to IoT, EDP is keen on getting closer to the European startup ecosystem. This way they can innovate, discover talent, improve networking, and renew their business processes.

In this case, the focus of these efforts closely connected to EDP’s core business—energy and residential space.

“The hackathon has become one of the latest vogue terms in business”

—Ferry Grijpink, principal at McKinsey, Singapore

With the results of the EDP IoT Hackathon, a set of new scenarios is expected within the context of remote monitoring solutions including real time aspects while integrating with the EDP Box. Strategically, EDP’s vision includes reaching a final solution that allows companies/startups to go to market with products easily integrated with the EDP Box. Ideally, there’s the possibility of developing applications based on economically viable hardware. Also possible is that the community and developers will create energy-monitoring solutions. This open source approach may be an important engine for the IoT proliferation within EDP. In the end, the result will help EDP customers to control their energy consumption.

Opportunities going forward

This project was totally oriented to future opportunities. This model of preparing a public IoT hackathon organized by the largest energy company in the country promotes a set of benefits that we consider promising:

  • Analyzing the results of participant startups in a business and technical perspective, considering the clear goals of EDP as a company in the residential energy sector.
  • Follow up the best ideas and implementations presented to EDP, moving toward consumer-oriented products (EDP customers).
  • Discover, through a hackathon, new ways of collecting energy readings from an EDP Box—a Smart Home Meter. It is a clear goal to challenge startups in the cloud-based software and hardware components.
  • Promote EDP’s collaboration with startups in the IoT area. Improve EDP’s service to consumers. Allow an energy consumption suited to the needs of each family. As EDP is the largest energy supplier in Portugal, the impact can potentially transform the country.

Labelec & Hackfest team

EDP results from the IoT hackathon

The EDP IoT Hackathon took place between February 8 and February 24, 2017. Teams were given 15 days to work remotely. EDP made several EDP Boxes available to be used on development and testing. Final evaluation was done through several vectors including pitch, product design, hardware technical strength, and software technical strength.

The eight final teams had the opportunity to pitch and present their projects in the closing event. The best projects were awarded with prizes and possible incubation within EDP Starter. Here are the projects:

1st, Crowd2DataJoana Albuquerque, Nuno Santos, Rafael Evaristo

Their objective was to create two devices: a first one that is next to the EDP smart meter, collects energy consumption readings and sends the values via SIGFOX. Additionally, this equipment also allows the reading via Bluetooth through an app exclusive to EDP technical personnel. The second device, installed inside the house of the EDP customer, collects temperature data of humidity and presence and relates them to the energy consumption of the house. Their plan was to create a technological open foundation to be installed within residential houses, promoting innovation and allowing integration with other devices that implement this open protocol of communication and integration. As an end goal, other devices/brands could build their solutions using this technological hub. The work went on to construct the code so that the Akeru board could read from the EDP smart meter and send the consumption data to Azure using SIGFOX. For this they used the event hub, integrated with a REST endpoint called by an Azure function. They created an Android app and a web interface using the Web Apps feature of Azure App Service with an Azure SQL database. This way they could index service costs to energy usage, without having to pay infrastructure fixed costs. They fostered a true pay-as-you-go model into an energy consumption model.

2nd, iThings/NESTOMarcelo Lopes, Michaël Memeteau

Focused on EDP’s customer satisfaction with a solution bringing high added value. The hardware used ARM® architecture (32 bits Cortex®-M0 +) and unique chip for encryption. In addition to open source tools such as InfluxDB, Grafana, and Linux, powerful Azure services (IoT Hub, Stream Analytics, Azure Functions, Web Apps, SQL, Virtual Machines, Bing Maps and Power BI) were used to bring the project to life. The final result allows EDP’s customers to track their detailed consumption and get notifications (SMS/push) for devices left turned on at home. The team plans to evolve the project using Azure Machine Learning to perform non-intrusive load monitoring (NILM).


3rd, Innowave/Thought CreatorJoão Amaro, José Araujo, Pedro Moscoso, Rafael Pires

The system used the Azure platform as a service (PaaS) to handle the reception and management of SIGFOX messages from the smart meter. Those messages contained all the information needed to create a real-time dashboard that provides not only information to the EDP client but also technical energy indicators. On top of that, a gamification engine was created to give “energy points” to the clients who manage their energy consumption patterns through the application. Those points could later be exchanged in the EDP partners network.

Additional resources