D4.2.2 Prototype of a Home Energy Hub and Home Energy Cloud Final version Deliverable report

D4.2.2 Prototype of a Home Energy Hub and Home Energy Cloud Final version Deliverable report ebadge project Page 1 of 93

Document Information Programme Project acronym Project Full Title FP7 Cooperation / ICT ebadge Development of Novel ICT tools for integrated Balancing Market Enabling Aggregated Demand Response and Distributed Generation Capacity Grant agreement number 318050 Number of the deliverable D4.2.2 WP/Task related WP4 / T4.2 Type (distribution level) 1 PU Due date of deliverable 30-09-2015 Date of delivery 30-11-2015 Status and Version Final, V1.0 Number of pages Document Responsible Author(s) 93 pages TS David Gustinčič, Luka Premelč, Boštjan Perme, Robert Tošnjak, Tomaž Lovrenčič, Marko Pesko, Marko Rizvič, Uroš Droftina, Bojan Dovč, Radovan Sernec TS Andraž Andolšek, Peter Nemček, Christoph Gutschi CG Marjan Šterk, Staš Strozak XLAB Reviewers Steve Xu VAASA ETT Boris Turha ELLJ 1 PU RP RE CO Public Restricted to other programme participants (including the Commission Services) Restricted to a group specified by the consortium (including the Commission Services) Confidential, only for members of the consortium (including the Commission Services) ebadge project Page 2 of 93

Issue record Version Date Author(s) Notes Status 1.0 30.11.2015 As listed Minor changes regarding reviewers remarks Final 0.9 26.11.2015 As listed Reviewed version Draft 0.8 20.11.2015 As listed internal review Draft 0.5 1.10.2015 Marko Rizvič Web apps fork. Draft 0.4 29.09.2015 Tomaž Lovrenčič, DB model Draft Uroš Droftina 0.3 23.09.2015 Marjan Šterk HEH and cloud system description Draft 0.2 18.09.2014 Robert Tošnjak, HEH installation procedures Draft Bojan Dovč 0.1 2.09.2014 Radovan Sernec Initial draft, main headings Draft NOTICE The research leading to the results presented in the document has received funding from the European Community's Seventh Framework Programme under grant agreement n. 318050. The content of this document reflects only the authors views and the European Commission is not liable for any use that may be made of the information contained herein. The contents of this document are the copyright of the ebadge consortium. ebadge project Page 3 of 93

Table of Contents Table of Contents... 4 Table of Acronyms... 10 1 Introduction... 14 1.1 Approach... 14 1.2 Relation to the Rest of the Project... 14 1.3 Outline of This Report... 15 2 HEH measurement platform... 16 2.1 Measurement and control board... 16 3 RaspberryPi platform... 18 3.1 Debian installation... 18 3.1.1 Image for RaspberryPi Version 2... 19 3.1.2 Image deployment... 19 3.1.3 Overview of installation... 19 4 Mobile 4G LTE communication... 20 4.1 USB connection... 20 4.2 Wi-Fi connection... 21 5 ebadge cloud services for HEH... 23 5.1 Debian SW repository... 23 5.1.1 Apt-cacher... 23 5.1.2 Custom repository... 23 5.2 Puppet provisioning... 24 5.3 Zabbix monitoring... 24 6 Measurement database... 26 6.1 Receiving data from RMQ... 26 6.1.1 Active data store... 28 6.1.2 Passive data store... 29 6.2 MYSQL table entities... 30 6.2.1 HEH capabilities... 30 6.2.2 HEH characteristics... 30 6.2.3 HEH appliances... 31 6.2.4 Web/app user... 32 6.2.5 Auxiliary data... 32 6.3 HEH server-side calibration... 33 7 HEH administrator panel... 35 8 Open access REST API... 40 9 ebadge web application... 41 9.1 User portal... 41 9.1.1 Login page... 41 9.1.2 Dashboard... 41 ebadge project Page 4 of 93

9.1.3 Live view graph... 42 10 ebadge Android application... 44 11 Fork of the original HEH SW design... 50 11.1 Data flow... 50 11.2 HEH firmware... 51 11.3 Server side applications... 51 11.3.1 Websocket daemon... 51 11.3.2 Aggregation worker... 51 11.3.3 Message format... 51 11.3.4 The database... 52 11.4 Web application... 55 11.5 User interface for data interpretation... 57 12 Field trial installation of HEHs... 61 12.1 Customer introduction to HEH... 61 12.2 Preparation for field trial... 62 12.2.1 Laboratory tests... 62 12.3 HEH installations... 63 12.3.1 Demonstration of various HEH installation possibilities... 64 12.3.2 Specifics of HEH installation at PV power plants, mobile base stations and EV charging stations 66 13 Conclusions... 69 References... 70 1 Appendix... 71 1.1 Preparation of software image for HEH... 71 1.2 HEH customer information forms... 73 1.2.1 Subscriber information... 73 1.2.2 HEH information... 74 1.2.3 HEH installation information... 74 1.1.1 Customer contract form to join the ebadge project... 74 1.2.4 Customer mobile subscriber form... 76 1.2.5 HEH installation procedure check list... 77 1.2.6 HEH wiring information form for Rogowski coils and relays... 78 1.2.7 HEH wiring scheme... 79 1.2.8 HEH inventory of installed material... 80 1.2.9 HEH detailed final installation diagram... 81 1.3 Measurement of electrical loads and wiring... 81 1.4 ebadge API... 84 1.4.1 Service availability API... 84 1.4.2 User info API... 85 1.4.3 Token acquisition API... 86 1.4.4 Graph for all HEHs for single user with time interval and resolution... 87 ebadge project Page 5 of 93

1.4.5 HEH list for single user with real-time data... 89 1.4.6 Get last Android application info... 91 1.4.7 Get last Android application... 92 ebadge project Page 6 of 93

List of Figures Figure 1: Measurement and control board for RaspberryPi.... 16 Figure 2: Measurement and control board details.... 16 Figure 3: HEH connection schematic to 230 VAC system mains.... 17 Figure 4: RaspberryPi and LTE modem prototype setup.... 21 Figure 5: Puppet provisioning server dashboard... 24 Figure 6: Zabbix monitoring server dashboard.... 25 Figure 7: Zabbix monitoring graph of CPU load (above) and network traffic (below) for one HEH.... 25 Figure 8: HOT data tables.... 27 Figure 9: COLD data tables.... 28 Figure 10: RMQ data tables.... 28 Figure 11: HEH data tables.... 31 Figure 12: HEH APPLIANCES data tables.... 32 Figure 13: USER APP data table.... 32 Figure 14: RECOMMENDATION data table.... 33 Figure 15: Various system data tables.... 33 Figure 16: HEH line fit plot for heat pump.... 34 Figure 17: Received measurement data ( HEH measurement ), reference power load meter ( Main mater ) and linear fitted data ( Fitted HEH data ) in 1-minute resolution.... 34 Figure 18: Admin panel menu.... 35 Figure 19: Edit ebadge user.... 36 Figure 20: HEH info.... 37 Figure 21: Load reports.... 37 Figure 22: Load report on geo map.... 38 Figure 23: Android application related panel.... 38 Figure 24: SMS notification panel.... 39 Figure 25: Script status overview.... 39 Figure 26: User portal login page.... 41 Figure 27: User portal dashboard.... 42 Figure 28: User portal Live view graph section.... 42 Figure 29: User portal Live view graph in real-time.... 43 Figure 30: My home application logo.... 44 Figure 31: "My home" login program flow.... 45 Figure 32: "My home" main program flow.... 46 Figure 33: Example screens of "My home" two login screens and a splash screen with login error. 46 Figure 34: "My home" main screen examples showing power consumption on a user's level.... 47 Figure 35: "My home" screen examples showing power consumption on a HEH's level for 7 days, 24 hours, and last 31 days.... 47 Figure 36: "My home" screen examples showing power consumption on default and changed MT names HEH level.... 48 Figure 37:"My home" screen examples showing power consumption on the device s level.... 49 Figure 38: Forked applications data flow.... 50 Figure 39: Stored procedure named get_watthours_today_total.... 54 Figure 40: Stored procedure named get_watthours_month_total.... 54 Figure 41: MySQL view named today_watthours_hourlyaggregated.... 54 Figure 42: MySQL view named month_watthours_hourlyaggregated.... 55 Figure 43: Web application GUI for real time monitoring of power loads 1.... 57 Figure 44: Web application GUI for real time monitoring of power loads 2.... 58 Figure 45: Web application GUI for real time monitoring of power loads 3.... 58 Figure 46: Web application GUI for real time monitoring of power loads 4.... 59 Figure 47: Web application GUI for real time monitoring of power loads 5.... 59 Figure 48: Web application GUI for real time monitoring of power loads 6.... 60 Figure 49: Web application GUI for real time monitoring of power loads 7.... 60 Figure 50: A demo board with two types of electrical power cabinets which are commonly installed in typical private households.... 62 Figure 51: Parallel testing of HEHs in a laboratory environment.... 62 Figure 52: The HEH label of a specific customer.... 63 ebadge project Page 7 of 93

Figure 53: Checking electrical connections and proper dimensioning devices with IR camera.... 64 Figure 54: Example of HEH deployment in an old electrical cabinet.... 65 Figure 55: Example of HEH deployment in a new electrical cabinet... 65 Figure 56: Example of HEH deployment next to an old electrical cabinet.... 66 Figure 57: Electrical distribution board with HEH for 50 kwp PV plant.... 66 Figure 58: PV solar plant with HEH installation.... 67 Figure 59: Installation of HEH in the PV power plant AC distribution cabinet.... 67 Figure 60: Installation of HEH in the EV charging station.... 68 Figure 61: Example a signed declaration to join the project.... 75 Figure 62: Mobile data subscriber information form.... 76 Figure 63: HEH installation check list.... 77 Figure 64: HEH wiring information form.... 78 Figure 65: HEH wiring scheme at installation.... 79 Figure 66: HEH installed materials form.... 80 Figure 67: HEH wiring scheme at installation.... 81 Figure 68: Measurement setup of power quality parameters.... 82 Figure 69: Measurement results of the power quality.... 82 Figure 70: Measurement results of the harmonics of the power quality.... 83 ebadge project Page 8 of 93

List of Tables Table 1: List of active data store tables and their characteristics.... 29 Table 2: Measurement table fields. The same fields are in JSON message except for id and tarifa... 51 ebadge project Page 9 of 93

Table of Acronyms Acronym ACER BM BRP BSP C Capex C&I CHP CHG CMB-T&M&M CPCC CPSC CPP CRM DMBS DER DG DR DSM DSO EDRC e-car ELLJ Energy market operator Energy Retailer ENTSO-E ESP EV FRR GPU GSM GUI HDD HEC HEH HVDC HW IaaS KPI MB Microgrid MO MT Opex PaaS Power exchange Meaning Agency for the Cooperation of Energy Regulators Balancing Market of electricity between VPP, DSO, VPP and TSO Balance Responsibility Party Balance Service Provider Consumer of electricity, in some cases also acts as producer (= prosumer) Capital expenditures or expenses, usually equipment Commercial and Industrial Combined Heat and Power systems Combined Heat and power Generation Translation, Management and Maintenance of Common Message Bus between all entities Customer premises Consumer Cloud; Residential and small-medium enterprises end users Customer premises Supplier Cloud; Residential and small enterprises end users Critical Peak Pricing Customer Relationship Management to end users (e.g. customer care, fault management, automatic service provisioning, technical support to end users) Database Management System Distributed Energy Resource (e.g. PV or wind power plant) Distributed Generation Demand Response Demand Site Management Distribution System Operator European Demand Response Center Electric car Elektro Ljubljana Entity for merging supply and demand of all electric energy Reseller of electric energy without own infrastructure (e.g. Petrol) European Network of Transmission System Operators for Electricity Energy Services Provider Electric Vehicle, electric car Frequency Restoration Reserves Graphics Processing Unit Global System for Mobile communications Graphical User Interface Heating Degree Days Home Energy Cloud Home Energy Hub High Voltage Direct Current Hardware Infrastructure as a Service Key Performance Indicator Message Bus based on message queuing (e.g. RabittMQ, MQTT) Local energy demand and supply closed loop with optimal local transport Market Operator Measurement Transformers Operational expenditures or expenses, usually personnel costs, yearly licenses Platform as a Service Entity for merging supply and demand of all electric energy ebadge project Page 10 of 93

Prosumer PV RES RMQ RR SaaS SW Telecom TS TSO VPP WSDL Consumer and producer of electricity Photovoltaics, electric solar Renewable Energy Sources RabbitMQ Message Queuing Replacements Reserves Software as a Service Software Telecommunication operator with own energy retail function and with own telecommunication infrastructure (e.g. Telekom Slovenije, T-Mobile, Orange) Telekom Slovenija Transmission System Operator Virtual Power Plant Web Services Description Language ebadge project Page 11 of 93

ebadge Project The 3rd Energy Package clearly boosts the development of an Integrated European balancing mechanism. In this context, ACER has started the development of the Framework Guidelines on Electricity Balancing in 2011. It is expected from the ACER statements that Demand Response (DR) will play significant role in the future integrated balancing market allowing Virtual Power Plants (VPP), comprising DR and Distributed Generation (DG) resources to compete on equal ground. The overall objective of the ebadge project is to propose an optimal pan-european Intelligent Balancing mechanism also able to integrate VPP Systems by means of an integrated communication infrastructure that can assist in the management of the electricity Transmission and Distribution grids in an optimized, controlled and secure manner. In order to achieve the above overall objective the ebadge project will have four objectives focusing on: 1. developing the components: simulation and modelling tool; message bus; VPP data analysis, optimisation and control strategies; home energy cloud; and business models between Energy, ICT and Residential Consumers sector, 2. integrating the above components into a single system, 3. validating these in lab and field trials, and 4. evaluating its impact. Project Partners Telekom Slovenije, d.d. Slovenia cybergrid GmbH Austria Ricerca sul sistema energetico RSE Spa Italy XLAB Razvoj programske opreme in svetovanje d.o.o. Slovenia ELES d.o.o. Slovenia Austrian Power Grid Austria Borzen, Organizator trga z električno energijo, d.o.o. Slovenia Elektro Ljubljana, Podjetje za distribucijo električne energije d.d. Slovenia Technische Universitaet Wien Austria Austrian Institute of Technology GmbH Austria EUDT Energie Umweltdaten Treuhand GmbH Austria SAP AG Germany Vaasaett Ltd Ab Oy Finland Project webpage http://www.ebadge-fp7.eu/ ebadge project Page 12 of 93

Executive Summary ICT tools will play a central role for proliferation of new energy services on a liberalised energy market. A holistic view of communication and IT solutions focuses on design of energy hub solutions that enable active prosumer participation on tertiary energy markets through VPP and consumers home management of power consumption. During the ebadge project, we developed Home Energy Hub (HEH) device which can be installed at prosumer premises, either residential or industrial. HEHs run open source operating system Debian (Linux distribution). HEH hardware is based on a small RaspberryPi embedded computer and a custom developed electrical energy measuring board. Its communication within the smart grid towards the VPP environment is based on messaging queue protocol RabbitMQ (RMQ). Multiple energy hubs within the utility power grid are securely connected to central cloud with RMQ exchange within the VPN or APN in case of mobile network. The RMQ exchange interconnects all stakeholder types that communicate with the same messaging protocol. For our energy balancing system, VPP SW is a key element. Messages content, exchanged between stakeholders is securely saved in a database within the telecom operator s environment. On one site, it is connected to a 3 rd party interface block, with a custom JavaScript SW (Node.js) and a Web server (Nginx) that accesses database and communicates with other 3 rd parties via known API and HTTP protocol. Such arrangement is the enabler for data democratization in smart grids and attracts into eco system of other parties or new types of stakeholders, also those that do not speak RMQ. Typical example is e-car or Electric Vehicle (EV) charging station operator that may have already developed its own Web based application. It can be seamlessly interconnected via our 3 rd party SW interface block via API exposure. Data democratization is achieved. Any operator can either integrate its operation via SNMP protocol within their own network management systems or establish open source management platform (e.g. Zabbix) that allows for topological and more detailed operation view on the energy hub level. HEH capabilities include energy curtailment either with simple power load switching (on/off) or SW API commands exchanged with power loads. In general, HEH can communicate with VPP via integrated or external modem, Ethernet or Wi-Fi and monitors power loads with AC current measurement sensors: Rogowski coils, current transformers or Hall effect sensors. The power curtailment is possible due to power relays switching of the selected power loads while the main circuit breaker and other line circuit breakers conclude the installation. The viability of HEH concept was demonstrated on the large scale field trial of 120 locations, including customer homes, photovoltaic (PV) power plants, EV charging stations and mobile base stations. To bring the field trial measurements from HEHs to the consumers the web-based user portal and Androidbased mobile application were developed. ebadge project Page 13 of 93

1 Introduction ebadge enables aggregated Demand Response (DR) and Distributed generation (DG) capacity with a real time energy information exchange between main energy market stakeholders, including prosumers and VPP as the main players. Home Energy Hub (HEH) acts as an information gateway between the end user (so called prosumer) and energy market stakeholders. Objective of this deliverable is to describe the field trial details of the HEH. This covers its prototype construction, installation, networking, standards, SW, hardware and power aspects. We describe how to build HEH and set up its working environment from scratch. In case when HEH is device installed at customer premises it should be able to: aggregate all data measured by smart measurement board via API, connect to the ebadge cloud over mobile connection or Ethernet connection, respond to Message Bus (MB) requests with ebadge Data Standard Protocol, store aggregated data in a local storage. Because HEH is installed at remote location it should run stable and robust to prevent unplanned electrical outages and connection failures. When power outages will occur HEH should be able to re-boot successfully, restore connections made to cloud and get ready for processing request from ebadge MB. Provider should be able to remotely upgrade HEH to deploy new features. Furthermore, the device lifetime is expected to be longer than the lifetime of many SW packages, thus it must be possible to develop and deploy critical updates of any third-party SW packages even beyond their support period. We explain the prototype and considered solution for HEH and how to connect it to the ebadge MB. It explains the SW stack used above the Linux operating system, the solutions for connecting to the ebadge cloud and the used hardware platform. Hardware platform used in this deliverable is based on RaspberryPI model B, Model B+ or RaspberryPi Version 2 ARM computing platform. These platforms are suitable for gathering measurements from different sensors and measuring boards, process gathered data and securely send it over connection to the ebadge cloud. We have discovered that implementation robustness is much improved by using Model B+ or Version 2 since they use microsd flash card connectors with latching capability. 1.1 Approach In the following, we describe a HEH platform and a field trial in detail. The HEH consists of compute node, measurement block and a communication device. Next, the used Linux distribution, SW implementation, cloud formation and packages that support home energy cloud are described. Focus is also placed on the data model of the HEH, i.e. its supporting database design. Access to HEH operation and measurements is possible via several types of Graphical User Interface (GUI) screens and different applications, either for customer or administrator purposes. Field trial installation is composed of two parts: forms that need to be prepared for each location and description of installation procedure itself. 1.2 Relation to the Rest of the Project Deliverable 4.2.2 is part of WP4 that combines design of HEH and cloud, while offering also business insights into the considered market operation. Reader is invited to pay the attention also to deliverable 4.1.2 that puts forward the requirements for HEH and communication solutions, and deliverables 4.3.2 and 4.4.2 [D442] that present the business modelling and user evaluation of the field trial, since this will point out the potential for market acceptance of new solutions that are presented in the project. WP3 offers a unique secure communication solution among the stakeholders, called the MB. The analysis of MB information flow is also presented in this deliverable. WP5 as a whole presents a holistic view of the VPP domain and is instructive to get the broader picture and to understand all the stakeholders that are active on a smart grid market place, VPP in particular. ebadge project Page 14 of 93

1.3 Outline of This Report Deliverable 4.2.2 Prototype of HEH and Home Energy Cloud Final version is organised into 13 chapters and appendices. Chapter 2 briefly addresses the measurement platform of the HEH, chapter 3 describes the RaspberryPi module used as the heart of the HEH and the installation of the operating system for HEH, chapter 4 covers the communication between HEHs and the ebadge cloud, chapter 5 describes the ebadge cloud services HEHs can use, chapter 6 addresses the database used for storing the measurements data and other data (e.g. HEH locations and access credentials), chapter 7 presents the developed HEH administration panel, chapter 8 describes the application programming interface for communication between the database and the web and Android applications. These applications are presented in chapters 9 and 10, correspondingly. Chapter 11 addresses the forking of large portions of the HEH design, chapter 12 describes the field trial installations of HEHs and finally, the document is closed with a short conclusion in chapter 13. ebadge project Page 15 of 93

2 HEH measurement platform HEH is a measurement, processing and communication device. This chapter treats its measurement part, while for further information the reader is referred to deliverable D4.1.2. 2.1 Measurement and control board HEH contains a measurement and control board, of which main capabilities include multi-channel (6), very fast (< 1 sec update) and accurate measurements (sigma-delta ADC, 8 khz sampling) of energy consumption and vital power parameters (U, I, P, Q, S,, THD, and harmonics) and 6 channel power load ON/OFF switching control. These are key functionalities to enable future DMS and DR programs, including auto ones. It is electrically and physically capable of connecting to RaspberryPi boards. The functional blocks of the measurement and control board are depicted in Figure 1, the assembled measurement and control board is depicted in Figure 2, while the HEH incorporating the measurement and control board connection to power lines is depicted in Figure 3. Figure 1: Measurement and control board for RaspberryPi. Figure 2: Measurement and control board details. ebadge project Page 16 of 93

Figure 3: HEH connection schematic to 230 VAC system mains. ebadge project Page 17 of 93

3 RaspberryPi platform The processing and communication capabilities of HEH are performed with RaspberryPi 2. RaspberryPi is an ARM-based small size embedded computer developed by RaspberryPi Foundation. The original version (model B), which was used for most of the HEHs uses Broadcom BCM2835 system on chip (SoC) and includes a single-core ARMv6 1176JZF-S 700 MHz processor. Its video core IV Graphics Processing Unit (GPU) has 512 MB of RAM and can be used by both, the system and the GPU itself. RaspberryPi does not contain any hard drive so the SD card can be used as an alternative solution for running operating system and permanent data storage. From the communication point of view it has two USB 2.0 ports for connecting peripherals such as LTE/UMTS modems and a standard 100 Mbit Ethernet compatible communication interface. On-board is also a Broadcom BCM2708 chip with Serial Peripheral Interface (SPI) and Inter-Integrated Circuit (I 2 C) communication interfaces. The SPI is a serial data link for communication between the devices which supports a full duplex mode. The devices communicate in a master slave mode and use four wires. Inter-Integrated Circuit (I 2 C) is a multi-master serial singleended bus which uses only two bidirectional open-drain lines. Finally, communication capabilities can be further extended with the use of general purpose input output (GPIO) pins. On the other hand, the newer RaspberryPi Version 2 uses a newer BCM2836 SoC, which incorporates 900 MHz ARMv7-based quad-core CPU and 1 GB of RAM. The layout of its board is improved in comparison to RaspberryPi model B as it has extension connectors on just two sides of the board instead of on all four sides of the board. This makes it considerably easier to integrate into devices such as the HEH. There are also some other minor differences between the RaspberryPi versions, which have no relevant influence with respect to HEH design. The RaspberryPi Foundation provides the following operating system images ready to run on raspberry: Raspbian (Debian-based), Pidora (Fedora-based), RaspBMC (XBMC), RISC OS, Arch Linux, and OpenELEC (XBMC). The main programming language for RaspberryPi is the Python which offers the use of various SW modules from the official repository. Additionally, there are other widely used programming languages supported. Rather than using one of the above operating systems, we prepared our own. We strippeddown version of Debian, which is well-known for its stability and long-term support. It also presents the basis for many other popular GNU/Linux distribution, such as Ubuntu and Mint. 3.1 Debian installation To prepare the SD card image for all the HEHs, first we prepared an environment on a development computer where Debian was installed from. This allowed us to make some system related changes and creation of a raw bootable disk image that was duplicated and deployed on all the HEHs. The image also includes the specific configuration of the LTE routers used in the project. The detailed image card preparation procedure is given in Section 1.1 of the Appendix. It results in an SW image file heh-image.raw available for deployment to all HEHs. The size of the image file is the same as the total size of the SD card used, which is 2 GB in our case. About 45 % of that space is used by the actual files. The remaining free space (over 1 GB) is more than enough for each HEH to store software updates and log files during its normal operation. 2 https://www.raspberrypi.org/ ebadge project Page 18 of 93

3.1.1 Image for RaspberryPi Version 2 For the newer RaspberryPi v2 a separate image must be prepared due to architectural changes to the main CPU. The process is otherwise the same. 3.1.2 Image deployment This is a straightforward procedure that can be done on any operating system and does not require special preparation of the environment. Of course, an SD card reader is required. For example, under Linux the following command can be used: dd bs=1m if=heh-image.raw of=/dev/<sd card disk device> 3.1.3 Overview of installation Finally, the SD card image is ready to boot the RaspberryPI. With the installation of the package ebadge from our custom repository we installed all the scripts and modules needed for communication with the ebadge cloud. At the first boot or when the SD card is inserted into another RaspberryPI the /etc/init.d/ebadge script : generates SSH RSA and DSA keys, sets hostname to heh-macaddress, where MACADDRESS is the MAC address of the RaspberryPi's integrated network interface, but without the : characters. This ensures that the HEH is unique and can be distinguished from all other HEHs that use the same SD card image. if the SD card is larger than the one the image was created for (2 GB), it expands the filesystem to fill the whole SD card. This allows the use any size of SD card rather than having to create a separate image for each card size. Set content of resolv.conf. Considering all above, Debian is installed on the RaspberryPI and configured to perform automatic upgrades form the ebadge cloud repository. ebadge project Page 19 of 93

4 Mobile 4G LTE communication Communication between HEH and the ebadge cloud is realised with an external 4G modem or router. In the field test the LTE router, known also as the mobile access point, was used to make connection to the ebadge cloud. Although the router is technically more complicated than the modem, the former is a commodity item while the latter is more of a speciality with often higher price. Compared to the use of modem, the use of router can be more demanding as it can introduce Network address translation issues. The HEH can be connected to the router in two ways. At first, an USB connection seems the natural choice because it requires no additional HEH hardware and takes care of supplying power to the router as well. However, it has two disadvantages: SW support for the router is required. This relies on the Linux driver availability which must usually be customized for each model of the router, it is difficult to tidily route the USB cable over long distances. Consequently, the router must be installed next to the HEH within the power cabinet, where mobile network signal can be weak. The alternative is to connect HEH with the router via Wi-Fi. This requires a Wi-Fi dongle to be added to the HEH. In such case, the router must be powered, either by connecting it to the HEH over USB only for power purposes, or by an additional power supply. In this scenario the router can be installed much farther from the HEH and the HEH does not need any customization of the drivers. In both cases, the router must be pre-configured to use the mobile network s APN (in our case named ebadge.ts.si ) and automatically connect to the internet on each boot. 4.1 USB connection During the ebadge project we provided USB drivers for the following routers: ZTE MF91, Huawei e5377t. In the following we describe only the procedure of connecting the HEH with the ZTE MF91 as similar procedure is used for the Huawei e5377t. Both modems work as a "flip-flop" USB device, which means that when first plugged in or after reboot, the router works as an USB thumb drive containing files irrelevant to the HEH (user's manual, MS Windows drivers, etc.). The HEH must then disconnect and reconnect (on the SW level) the USB port, after which the router starts functioning as a router. For example, on MS Windows environment, this is taken care of by the drivers. To overcome this "user friendliness", which is a hindrance rather than an advantage for use in the HEH, an initialization script had to be developed. Furthermore, the appropriate Linux drivers had to be installed on the HEH. The ZTE router has some problems making a successful connection. Once the router is powered on it stays disconnected from UMTS connection (PDP-context offline) for approximately 2 minutes. If we plug it into the USB port of the RaspberryPI in this state, or boot the RaspberryPI with the router plugged in in this state, the RaspberryPI will send the: --wds-start- qmicli -d /dev/cdc-wdm0 --client-no-release-cid network=internet command to the router. The command will activate the virtual Ethernet card in the router and also PDPcontext. However, the PDP-context is not activated as it should be because there is no connection to network. Probably this is due to a bug in ZTE router firmware. The above command cannot be omitted, ebadge project Page 20 of 93

otherwise there is no connection between the router and the RaspberryPI. As a workaround we implemented a connection checker in the HEH initialization scripts. This works in two stages: Stage 1: If the HEH cannot ping the router s IP it executes the following command: qmicli -d /dev/cdc-wdm0 --client-no-release-cid --wds-startnetwork=internet Disconnect: Stage 2: If stage 1 is successful, the HEH tries to connect to the MB. If it fails it will send two HTTP GET requests to modem: http://192.168.1.1/goform/manualdisconnect?manual_mode=disconnect Connect: http://192.168.1.1/goform/manualdisconnect?manual_mode=connect If the connection is still unsuccessful the HEH retries this procedure in an infinite loop. The Figure 4 depicts RaspberryPi connected to the ZTE modem over USB. Figure 4: RaspberryPi and LTE modem prototype setup. 4.2 Wi-Fi connection As already explained above, Wi-Fi connection allows the HEH to use various Wi-Fi routers. In ebadge, these models were tested and supported: ZTE MF91, ebadge project Page 21 of 93

Huawei e5377t, Teltonika RUT500. The latter is an industrial router which has been identified as the most stable and reliable of all three routers considered in the pilot. ebadge project Page 22 of 93

5 ebadge cloud services for HEH Once running, HEHs connect to the ebadge MB server (i.e. RabbitMQ server) to which the data collecting server must be connected as well. Furthermore, to deploy, update, configure, monitor, and maintain all the HEHs within the testbed, we have established additional services within the ebadge cloud which are presented in this section. 5.1 Debian SW repository The procedure for HEH SW installation described above includes the use of custom repository with Debian packages of standard SW, custom-developed HEH measurement SW, and SW of MB. The considered repository will be described in the following. 5.1.1 Apt-cacher Due to security reasons the HEHs do not have access to public internet and are rather locked down within the ebadge cloud. Therefore, the considered SW repositories must be hosted within the cloud as well (e.g. the repository with HEH s custom SW). On the other hand, the use of a proxy can enable HEHs connection to repositories outside the ebadge cloud. In particular, we have used the apt-cacher proxy, which not only acts as a gateway but also caches all the SW packages. Should there later be a need to use a custom repository also for the operating system packages (e.g. because the Debian operating system would no longer be maintained by its vendor), we could simply replace apt-cacher by a full mirror of the repository. Afterwards, we would be able to maintain the operating system by ourselves. The transition would be completely transparent to the HEHs. 5.1.2 Custom repository HEH custom packages are hosted in our Debian-compatible repository. To use the standard Debian update system for our custom packages, they must be packaged in the same way as the Debian packages. Debian packaging requires the following minimal folder structure: debian-minimal-tree/ DEBIAN control (Debian package control file: description, version, dependencies, etc.) This structure can also be created with the dh_make command. For the case of the package ebadge, which contains all the custom HEH SW, the tree contains these additional files and folders: pre- and post- (de)-installation scripts in the DEBIAN folder, /etc folder with configuration scripts for the SW repositories, USB router configurations, cronjobs, and the ebadge daemon, /opt with the executable code of the ebadge measurement/communication daemon, the MB library, and the measurement board library. All folders except the /DEBIAN contain files that have to be copied to the target system during the installation process. The entire tree structure is preserved. Inclusion of certain configuration files in the package allows us to change the configuration (e.g. to support a new router model) easily by providing an update to the package. The above tree can be transformed to a Debian package, signed, and added to the repository with the following commands: dpkg -b ebadge/ ebadge.deb dpkg-sig --sign builder ebadge.deb reprepro --ask-passphrase -Vb /opt/repo/ includedeb wheezy ebadge.deb ebadge project Page 23 of 93

Our custom repository stores the package ebadge in two architectures (i.e. for RaspberryPi v2 and the original RaspberryPi) and in two versions (the original data model/mb from the first year of the project and the updated final version). All the HEH SW released so far is being actively maintained. 5.2 Puppet provisioning As soon as the MB was first upgraded, it turned out that we need to divide the HEHs into multiple classes; some should be upgraded to test the new version while the other should continue sending measurements to the database until the new version was stable enough. Other configuration differences were added later (USB vs Wi-Fi router connection, RaspberryPi model B vs RaspberryPi v2, ebadge MB vs OpenADR, etc.). This required a new way to provision the HEHs, i.e. to transfer configuration files specific to the class the HEH belongs to. We considered the well-known Puppet 3 provisioning framework, widely used in cases of a large number of servers that have to be deployed and configured. The Figure 5 depicts the Puppet dashboard. In the left menu one can see the current count of changed, unchanged, unresponsive, etc. HEHs. The screenshot was taken at the time when many HEHs were being installed and no recent configuration changes were made, thus there are a lot of unresponsive and no changed HEHs. The main part of the dashboard on the right shows the history of statuses and details for individual HEHs. Figure 5: Puppet provisioning server dashboard. 5.3 Zabbix monitoring During debugging and maintenance of HEHs it is very useful to see the current status and history of each HEH. The variables such as online/offline status, CPU usage, RAM usage, running processes, and various log files are often required. To monitor and manage this information centrally, we set up a Zabbix 4 monitoring server in the ebadge cloud and connected all HEHs to it. The Figure 6 depicts its dashboard where a connection topology can be seen with all the HEHs in the lower part of the dashboard. The icons representing the HEHs also provide a quick status overview. Again, the screen shot was taken at the time of ongoing HEHs installations, thus many HEHs are shown in red circles. Figure 7 depicts the CPU load and network traffic of representative HEH. All monitoring data is stored in the Zabbix server, which is very useful for analysis and resolution of past problems. 3 https://puppetlabs.com/puppet/what-is-puppet 4 http://www.zabbix.com/ ebadge project Page 24 of 93

Figure 6: Zabbix monitoring server dashboard. Figure 7: Zabbix monitoring graph of CPU load (above) and network traffic (below) for one HEH. ebadge project Page 25 of 93

6 Measurement database For storing the data such as the HEH appliances data, one of the Database Management Systems (DBMS) is the best option. DBMS is a higher-level software application that interacts with the user, other applications, and the database itself to capture and analyse data. Through decades, different types of DBMS storage mechanisms have been developed (e.g. Relational and NoSQL) along with the applications implementing them (e.g. MySQL, PostgreSQL and MongoDB). Each database system implements a different database model to logically structure the data that is being managed. These models are the first step and the biggest determiner of how a database application will work and handle the information it deals with. There are quite a few different types of database models which clearly and strictly provide the means of structuring the data, with most popular being the relational model. Recently, a series of different systems and applications called NoSQL databases started to gain popularity, expeditiously. By eradicating the strictly structured data keeping style defined within the relational model, these DB systems work by offering a much more freely shaped way of working with information, thus providing a great deal of flexibility and ease. However, the NoSQL implementations (e.g. MongoDB) only recently started to grow in popularity and reliability, and were at a very early stage at the beginning of the ebadge project. However, for storing the HEH appliances data, reliability was the primary demand for the DBMS. Therefore, a relational DBMS mechanism was selected as the most appropriate. The additional demands for the DBMS system were popularity (large community and good support), industry-proven technology, security, speed, scalability, good documentation and it needed to be an open-source product. Among all the relational DBMS systems, MySQL 5 server was selected as the most appropriate, which positively addressed all the demands. The database was stored on a virtual machine with 8-core Intel Xeon processor (2.4 GHz), 16 GB RAM and Linux OS. The database was used for storing all the HEH appliances data received via the RMQ server, and querying this data for displaying it in the admin panel, user web application, and Android application. The data from HEH appliances has been stored at approximate rate 6 inserts per appliance every 5 second, which resulted in large amounts of data over a longer period of time. Using out-of-thebox MySQL server for storing large amount of data, resulted in a need for additional approaches, such as partitioning, splitting data into several tables, and creating procedures, which takes over some processing and calculations. Additionally, wise separation of data tables serving inbound (INSERT statements) and outbound flow (querying) was applied. The following subsections explain the methods which were used to implement efficient and responsive data store and also provide solutions to certain constrains that we encountered during the test trials on various layers of interaction. 6.1 Receiving data from RMQ Data received from RMQ endpoint was stored in two places: active data store (Figure 8 indicates the actual database implementation for storing received raw data, like measurements of power load (data table field mtx_p), frequency (data table field mtx_fi) and current (data table field mtx_i), and passive data store (Figure 9 indicates the actual database implementation). The purpose of active data store (indicated as the hot data store) is to provide fast response time for inserts and querying of recent data, e.g. when a request is made for all measurements for specific HEH for the last day. On the other hand, a passive data store provides all the historical data. Each HEH was comprised of six measuring points (i.e. measurement transformers - MTs) and measurements of corresponding appliances were performed for all the MTs at the same time. Therefore, we assumed and implemented two variants of receiving and inserting the data into the database: 1 measurement and 1 SQL row per appliance (6 rows for each HEH at the time of measurement), and 5 https://www.mysql.com/ ebadge project Page 26 of 93

1 measurement and 1 SQL row per HEH (all 6 measurements that were measured at the same time for specific HEH stored in one row). The advantage of the second variant is considerably smaller data rate, smaller number of inserts into the database and also smaller data table. On the other hand, possibility of greater measurement data loss exists in the second variant. For example, if one data packet is lost in the first variant, only 1 measurement is missing, but in the second variant all six measurements are missing. As for the need of controlling request and responses coming to/from RMQ MQ system, additional data tables were defined, where up to 9 arbitrary field:value pairs were stored, such as headers information (Figure 10). Also HEHs capabilities were conducted and stored into table TOTAL_CAPABILITIES. Figure 8: HOT data tables. ebadge project Page 27 of 93

Figure 9: COLD data tables. Figure 10: RMQ data tables. 6.1.1 Active data store The data received from the HEHs included measurements for every 5 seconds for each HEH (raw data). Additionally, aggregates of raw data were needed for responsive displaying in the user web and Android application. Since querying through these data needed to be very fast, two actions were used in MySQL: partitioning and limiting the time window of storing the data. As a result, four different hot tables in the database were established, as is presented in Table 1. ebadge project Page 28 of 93

Table 1: List of active data store tables and their characteristics. Table type Resolution Full data window Partition window Exp. Max. num. of rows per HEH for a) / b) RAW 5 sec 1 day 1 hour 103680 / 17280 MINUTE 1 minute 7 days 1 hour 60480 / 10080 15-MINUTE 15 minutes 30 days 1 day 17280 / 2880 HOUR 1 hour 1 year 7 days 52560 / 8760 DAY 1 day unlimited no partitions unlimited RAW table for the one-measurement-per-row variant contained the following columns: measurement_id, t (time of the data insert into database), from_time (time of measurement), mac (mac address of the HEH), device_id (MT number from 1 to 6), and p (average active electrical power consumption in 5-second window). Each of the aggregated active data store tables for the first variant, except the RAW table, contained the following columns: from_time (rounded time of measurement according to resolution of aggregated table), mac (mac address of the HEH), device_id (MT number from 1 to 6), p_avg (average active electrical power consumption in specified time window), p_max (maximal active electrical power consumption in specified time window), and p_count (number of measurements in specified time window). In the second variant (i.e. 6-measurements-per-row ) the column device_id was omitted and instead of column p in the RAW table and columns p_avg, p_max and p_count in the aggregated tables, columns p1 p6, p1_avg p6_avg, p1_max p6_max, and p1_count p6_count, were included. Actual database implementation is seen in Figure 8. Partitioning of the active data store tables was established to distribute portions of individual tables across the file system according to predetermined rules. Since most of the querying over the measurements in the database is limited to a certain time window, we partitioned the tables by the time of measurements. Sizes of partition windows for each table are also show in Table 1. Additionally, sizes of tables are limited with the time window (column Full data window in Table 1). This is handled by stored procedures that erase partitions older that the data window limitation and are called periodically. Using these actions, queries for supplying the data to web or Android application did not take more than 100 milliseconds. 6.1.2 Passive data store The passive data store contains all historical measurement data as it was already depicted in Figure 9. Such data are mainly used for data analytics (historical measurement statistics, electrical power predictions, etc.). For the purpose of data analytics outside SQL, exports of all historical data were performed periodically into text files. Prior the export, the data were also cleaned by: ebadge project Page 29 of 93

deleting of multiple identical rows in the RAW table (due to the failed reception of the acknowledgement message to HEH after sending the measurement data), handling of rows with null value for power (due to errors of measurement units), and excluding of test HEH data (HEHs placed in our laboratories). 6.2 MYSQL table entities Brief overview on architectural design of data store reveals the next entities: HEH measurements (described in previous subsections), HEH capabilities, HEH characteristics, HEH appliances and appliances operations, web/app user, and auxiliary data. 6.2.1 HEH capabilities HEH capabilities entity provides information for VPP regarding the load and generation capability and prediction models of HEH ( can predict profile, can predict curtailment ). These settings are set or unset in initialization procedure or when explicit request (i.e. from VPP) occur. These settings are populated when HEH initialization procedure is initiated (table TOTAL_CAPABILITIES in Figure 10). 6.2.2 HEH characteristics As can be seen in database implementation depicted in Figure 11, HEH characteristics entity provides HEH related information. This is further split into the following parts: HEH: information on the RaspberryPi-based measuring device, such as device MAC and local IP, number of connected phases (1-phase or 3-phase), device name, building ID and linear offset coefficients for power measurement calibration. Each HEH has a unique MAC, which is also used as HEH identifier in HEH measurement tables. MODEM: information on the LTE modem which serves as an access point to the ebadge cloud and is connected to HEH via Wi-Fi or USB cable. Columns in the table include modem IMEI, serial number, SSID and corresponding key, modem type and sim ID. SIM: network related information for identifying each HEH s communication channel inside ebadge cloud, such as GSM number, IMSI, PIN and PUK codes. BUILDING: geographical information of physical instalment location, namely building ID, address, building type, part of building (household, workshop, photovoltaics ), and longitude and latitude. ebadge project Page 30 of 93

Figure 11: HEH data tables. 6.2.3 HEH appliances HEH appliances entity describes MTs or user devices that are associated to measurement coils of each HEH s measuring device as depicted in Figure 12. MT s indices are associated to RMQ measurements in measurement data tables. Examples of appliances are household supply line, solar plant, electric heater, freezer, oven, etc. Data in this entity also include relay trigger information which is used control ON/OFF switching of selected appliances (table RMQ_RELAY). This data also includes status of bistable relay. ebadge project Page 31 of 93

Figure 12: HEH APPLIANCES data tables. 6.2.4 Web/app user Web/app user entity allows sessions or token based authentication for users to request and receive ebadge data as shown in Figure 13. Users can have different privileges ( admin, user-admin, user or guest ) and roles ( resident, commercial or VPP ), that define their permissions for interaction, e.g., guest can only observe public data, user can also control and monitor HEHs related to her user ID, and admin is granted full-access to add, modify or delete each HEHs data. User data also includes user residential (address) and contact (email, telephone number) information, and web/app access credentials (usernames, passwords, tokens). Figure 13: USER APP data table. 6.2.5 Auxiliary data Auxiliary data entity is composed of various tables with monitoring information (faults, server error, etc.), authorization attempts (user login errors, etc.), user support (recommendation capabilities), to keep the system properly managed and to ensure proper service availability and integrity, for instance. Examples of auxiliary data are power load recommendations (Figure 14) and login attempts (Figure 15). Recommendations are based on HEH historical data and suggest actions, a user should take to lower electricity costs. An example of such recommendation is: Set the heating device higher before and after peak and lower during the peak, when user behaviour should be stimulated towards more efficient heating usage. ebadge project Page 32 of 93

Figure 14: RECOMMENDATION data table. Login attempts (SQL table LOGIN_EVENTS) and various system events (table SYSLOG and SQL_ERROR) are used for web/app and Android app debugging purposes, monitoring of application usage, or even discovering possible server attacks. Figure 15: Various system data tables. 6.3 HEH server-side calibration With the aim of flexibility of the service, a server-side feature like post-processing of received measurements was conducted. Due to diversity of appliances connected to HEH, different responses in terms of electromagnetic characteristics can be observed. We had analysed them and established a calibration procedure based on found observations. The calibration was performed with a simple linear regression, on the 1-minute aggregated power load data measured with HEHs in comparison to the actual power load measured with the reference lower load meter. Although other fitting function could be applied, e.g. exponential, linear fit already presented satisfying results. An example of corrected measurements on the server side can be seen for the case of 3-phase heat pump, where the fitting with linear regression is presented in Figure 16 (correlation factor R square of 0.98). Additionally, a plot of measured, corrected, and true power load values is presented in Figure 17. ebadge project Page 33 of 93

Figure 16: HEH line fit plot for heat pump. Figure 17: Received measurement data ( HEH measurement ), reference power load meter ( Main mater ) and linear fitted data ( Fitted HEH data ) in 1-minute resolution. ebadge project Page 34 of 93

7 HEH administrator panel We developed a web-based GUI administration panel depicted in Figure 18 for managing ebadge entities and to monitor operation of HEH installations mounted on the field 6. It assists technical experts and technicians on the field to quickly overview HEH status, insert or edit new HEHs and their appliances, and manage new web or application users and their privileges. Figure 18: Admin panel menu. Web menu allows administrator to further access administration features: Manage USERs for adding, editing, deleting, activating and enrolling users. Also user access right to each HEH can be set or unset on proceeding screen (Figure 19), Manage HEHs for adding, editing and deleting HEHs. Also some digested information is available like recommendations, last response and historical data available for download in.csv file (Figure 20), Load reports with real-time data (AJAX call to API path), where last response of each HEH is listed (Figure 21), Load report map where geographical representation is used. We used Google API add-on for terrain modelling and JavaScript for drawing real-time data (Figure 22), Android app menu, where Android developer uploads new application releases (Figure 23), Send SMS to user where various notifications can be send to test users, like announcing new Android application (Figure 24), 6 Available at http://ebadge.si/admin. ebadge project Page 35 of 93

Get script status which populate area in the middle of the screen with underlying system process supervisor output, i.e. status of running Node.js scripts (Figure 25). Also possibility to start, stop or restart of script is present in case that unhandled errors during development stage occur (e.g. memory leak). Figure 19: Edit ebadge user. ebadge project Page 36 of 93

Figure 20: HEH info. Figure 21: Load reports. ebadge project Page 37 of 93

Figure 22: Load report on geo map. Figure 23: Android application related panel. ebadge project Page 38 of 93

Figure 24: SMS notification panel. Figure 25: Script status overview. ebadge project Page 39 of 93

8 Open access REST API API defines interfaces to various frameworks, like Android or web application, for accessing server-side functionalities. In ebadge we constructed HTTP API infrastructure with stateless existence (REST), where third party application can obtain a unique token (i.e. identified as application credential) to interact with API infrastructure. Due to JSON nativeness of application interaction to API call, we also decided to respond with a JSON object in the response. To obtain various data, the API caller can use following API calls: Service availability API to check the availability of service, User info API to check user credibility, Password change API to change user s password, Token acquisition API to obtain unique token, Token remove API to delete existing user token from token valid list, HEH list API to obtain information of the user corresponding HEHs and current status, HEH graph data API to obtain historical measurement data for all user s HEHs with from and to time parameters, Android app API to obtain various information regarding Android application (used for getting download link and check latest version). Available API JSON calls including required parameters and corresponding responses are further explained in more detailed manner in Section 1.4 of the Appendix. ebadge project Page 40 of 93

9 ebadge web application There are two parts of web application: the administrative portal and the user portal. Intention of administrative portal is to have a general overview of all ebadge HEH installations, users and status of HEH devices and their corresponding MT1-MT6 device names. User portal is intended for end users who have one or more HEH devices installed so they can have a general overview of power consumption in their premises. Since applications can be written in such manner that API functions can be called asynchronously we defined the message type numbers for server responses. Consequently, when applications parse answers to own requests they can easily match a particular message type with its respective API function that called. 9.1 User portal 9.1.1 Login page Login page shown in Figure 26 is a web form that takes username and password from the web GUI and calls token acquisition API. Username and password are encoded with base64 encoding algorithm. Server responds with a JSON which includes the token field and message type field is populated with the number 2. After the token is successfully retrieved the dashboard page is opened. In case of an error the token field is absent and the error field is populated instead. Figure 26: User portal login page. 9.1.2 Dashboard Dashboard page depicted in Figure 27 shows all HEH devices that are managed by the particular user. To retrieve that information from a server the HEH list API function is called. This provides all HEH devices with their respective serial numbers and their latest real-time data. Message type is numbered as 10. ebadge project Page 41 of 93

Figure 27: User portal dashboard. 9.1.3 Live view graph In this section of the dashboard on Figure 28 the user needs to select a HEH device ID of which he or she wants to obtain the measurements. After drop down item selection the HEH graph data API function is called. This retrieves all power measurements that are stored in the database for that particular HEH and for a given period of time as depicted in Figure 29. Message type is 7. Figure 28: User portal Live view graph section. ebadge project Page 42 of 93

The graph has a window of 60 minutes. By default, graph shows power consumption readings from last 60 minutes. To examine history of power consumption the user can hold the SHIFT key and, with left mouse button click, drag the graph left or right so the values are moved out of scope. After dragging event stops the API function is called again with updated from and to time stamp fields to retrieve values from database. After values are retrieved from server and parsed the graph is populated again with new values. User can also zoom in by selecting interested portion with left mouse button click. Zoom out to original view can be performed by double-clicking in graph area. Figure 29: User portal Live view graph in real-time. ebadge project Page 43 of 93

10 ebadge Android application In modern power consumption measuring scenarios it is very important to deliver information to heterogeneous user devices as fast as possible. In this respect, we developed a mobile application called My home ( Moj dom ), which logo is depicted in Figure 30. The application was designed to operate on various Android-based smartphones and tablet computers, though, it can be used also on Android based set top boxes to show power consumption on the big screens. In particular, it can be installed and run on all devices with the Android operating system version greater than the Ice Cream Sandwich (API level 15). Figure 30: My home application logo. The main part of the graphical user interface (GUI) of My home consists of three functional screens which show power consumption on the users, HEHs, and devices (i.e. power consumers) levels. However, the consumption information is shown to the users only after both, successful login and data retrieval from the server. Therefore, before more detailed representation of the GUI components, the one should be familiar with the application s basic program flows. The simplified login program flow is depicted in Figure 31 while the main program flow is in Figure 32, respectively. After My home is started it immediately checks for the internet connection and prompts the user to turn it on as it cannot operate without it. Next, it checks for previously logged in user and takes its last valid communication token to login on the ebadge server. If such user does not exist or if its communication token is invalid the application redirects the user to the login screen where it prompts him to enter the username and password. Based on both, a new communication token is obtained from the server. After having a valid communication token (i.e. user is successfully logged in) My home checks for the SW update and offers it to the users if available. Note that this step would be automatically handled by the Android system if the application was published in the Google Play store. If no SW update is available or when user declines to install it My home continues with the main program flow presented in the following. The logo splash screen is shown at the beginning of the main program flow, when measurements and other information are transferred from the server with the API messages of type 3 and 10. Here the one could argue about the splash screen or the progress bar screen necessity as the majority of users need information for only one or few HEHs. It is true that transferring information for a few HEHs can be fast however, when the user is logged into My home with the administrator account, he can view all HEHs in the monitoring system. In such case a considerable amount of information is transferred from the server. Another argument of using progress bar screen or splash screen is that they can be used to show various important notifications or errors at the start of application or within the login procedure. When all data is received from the server, the currently selected GUI screen is set accordingly, the splash screen is removed from the screen and the user can start using the application. In the Figure 33 we show two examples of a login screen, one with and the other without entered user password, and a splash screen with the wrong credentials login error. ebadge project Page 44 of 93

Figure 31: "My home" login program flow. ebadge project Page 45 of 93

Figure 32: "My home" main program flow. Figure 33: Example screens of "My home" two login screens and a splash screen with login error. ebadge project Page 46 of 93

After a successful login the user is redirected to the main application screen which shows current power consumption on the user s level. Several examples of this screen are depicted in Figure 34. Figure 34: "My home" main screen examples showing power consumption on a user's level. The user can select a HEH from the list of HEHs (i.e. by their unique identification number) in the spinner at the top of the screen. The selected HEH consumption is then shown in the gray/blue gauge in the predefined time intervals. For the time being a period for updating information is limited to be 5 seconds as this is the maximum time resolution of obtaining measurements in the database of the ebadge server. Below the gauge is a list of all HEHs of the user currently logged in, and some of the important HEH information. In particular, a unique identification number, mains power supply type (i.e. 1-phase or 3-phase 230 VAC), current power consumption and HEH operating state (i.e. green light for normal operation and red light for malfunction). At the bottom of the screen is place for user s personal recommendations which are produced with respect to his previous power consumption. The user can select a specific HEH from the list of shown HEHs and thus the application is redirected to the second GUI screen which shows information on the HEH s level. Several examples of this screen are depicted in Figure 35. Figure 35: "My home" screen examples showing power consumption on a HEH's level for 7 days, 24 hours, and last 31 days. ebadge project Page 47 of 93

From the top right spinner the user can select a period (i.e. last 7 days, last 24 hours, last 31 days, and last year) for which he wants to display the power consumption chart. The red bars on the chart are used to present peak power values in the aggregated time intervals while the blue bars represent the average power values respectively. From practical point of view the desired charts are produced from the measurements aggregated into: 15 minute time intervals for the last 7 days chart, 60 minute time intervals for the last 24 hours chart, 60 minute time intervals for the last 31 days chart, and 1440 minute (daily) time intervals for the last year chart. The information regarding the current status of the HEH, spinner for the selection of its operating regime (i.e. manual or automatic-controlled from the server side), mains power supply type (i.e. 1-phase or 3-phase 230 VAC), currently measured power consumption on the HEH s level and estimated monthly and daily costs of the consumed power measured by the HEH are available below the chart. Furthermore, the list of selected HEH s measurement transformers (MTs) and their measured power values (i.e. last measurements) is displayed at the bottom of the screen as shown in Figure 36. The generic names of the MTs can also be changed in the ebadge web administrator panel (Section 7) with respect to appliances names which power consumption they are measuring. For example, MT4 can be referred to as washing machine as shown in Figure 36. In this screen the user can select individual device to view its details, similarly as it selected the specific HEH in the main application screen. After this the user is redirected to the selected device screen. Figure 36: "My home" screen examples showing power consumption on default and changed MT names HEH level. The device screen is very similar to HEH related screen. At the top drop down menu the user can select the desired chart which shows the measured power consumption with the selected MT. Again, the red bars are used for the peak values and the blue bars for the average power consumption values of the time intervals aggregated as explained above. Beside the chart, this screen again depicts the current state of the considered HEH, current state of the considered device, currently measured power consumption on the device, and finally total as well as average power consumption measured by the device within the week. Examples of this screen are depicted in Figure 37. ebadge project Page 48 of 93

Figure 37:"My home" screen examples showing power consumption on the device s level. ebadge project Page 49 of 93

11 Fork of the original HEH SW design We forked a part of the original ebadge HEH SW design to: explore the possibilities of simplification, show the use of generalised Web application GUI, show how to customise and adapt the core HEH architecture, and use different type of information transport protocol. We realised that due to self-contained building block design we can fork large portions of the design that was conceptualised at the beginning of the project. We wanted to show that customisation can bring benefits and eventually enables selling the core design of HEH and its SW under different white labels, i.e. as original equipment designs. Furthermore, we show that protocols can be adapted too, as well as any user presentation devices and the GUI. The first thing that posed limitation is a MB that was designed and implemented in such manner that the user cannot control relays in real time and in a straight forward manner. This comes from the fact that primary goal was the integration with VPP for automatic power load control, on at most 15 min intervals. However, users want to have a real time interaction and control over their loads. The second thing is that MB defines 5 second interval between two consequent power measurements while we wanted to see how power consumption or currents are fluctuating in real time e.g. on 5 Hz frequency intervals. We really stretched the capabilities of the measurement board and smart meter chip itself and approached the issues by rewriting custom HEH firmware and utilizing the Websocket SW technology to send data from HEH to the database. The use of RabbitMQ seems fine, but, on the other hand, Websocket has an advantage of easily implementing its client directly in the browser using HTML5 and JavaScript. Since web browsers can run on many different devices, HEH measurements can also be viewed on different devices without developing apps for each of those platforms (e.g. Linux, Windows, OSX, Android, ios, Windows phone). 11.1 Data flow As shown in the forked applications data flow in Figure 38, HEH connects to Websocket_server.py and makes sure that measurements are sent from HEH to Websocket every 200 ms. At the same time heh_worker.js is connected to websocket_server.py and waits for measurements. Measurements are aggregated and stored into MySQL database every 3 seconds. websocket_server.py Port 8000 2. worker connects to websocket and reads measurement values heh_worker.js 3. values are aggregated and stored into database mysql database 1. measurements are sent to websocket server HEH def thread_loop(): x = get_measurements() websocket.send(x) time.sleep(0.2) 3. browser connects to websocket and receives measurements in realtime heh_api.js Port 8001 2. browser calls API function to retrieve measurements from database Nginx Port 80 1. browser connects to webserver, gets static files (html5, css, js) browser Figure 38: Forked applications data flow. ebadge project Page 50 of 93

On the other side the browser makes a connection with the HTTP server (i.e. nginx 7, a high-performance and low footprint web server) to receive HTML5 page, CSS, and JavaScript files. After that it calls appropriate API function to retrieve the measurements for the last 60 minutes. Request is proxied through nginx to heh_api.js (Node.js application). After measurements are retrieved the browser renders a graph and visualizes the data. Then it connects to the websocket_server.py to receive a stream of real time measurements. 11.2 HEH firmware To read measurement values from the measurement board it has to be initialized. After initializing the code spawns a thread and turns it into infinite loop to read measurement registers of the measurement board every 200 ms and send the values over the Websocket interface to the Websocket server immediately after. The code is written in Python and uses measurement board API library which is written in C. 11.3 Server side applications There are several components on the server side: Websocket daemon, MySQL daemon, aggregation worker, and web application server. 11.3.1 Websocket daemon The Websocket daemon is written in Python. It can handle multiple incoming connections and broadcasts received messages to all connected clients except to the one who sent it. 11.3.2 Aggregation worker The aggregation worker is written in JavaScript and run by Node.js daemon. It connects to the Websocket service and reads incoming messages which are relayed from the HEH. The purpose of aggregation worker is to sum all measurements from last 3 s and stores their aggregated values into MySQL database for later retrieval by the web application server. 11.3.3 Message format Messages with measurements are passed over Websocket connections in the following JSON format: { ua : 235.83, pe : 6, pd : 132, ia : 9.648, f : 49.99, did : 4, timestamp : 1443680647, pb : 10, pc : 2073, pa : 2274, pf : 9 } For the exact key-value pair descriptions please refer to Table 2. Table 2: Measurement table fields. The same fields are in JSON message except for id and tarifa. Field id timestamp did tarifa Description Unique among all rows in table, primary index Timestamp when aggregate values were calculated, indexed. In JSON message timestamp field represents point in time when measurement took place. HEH device id, indexed Tariff determined by calling IS_VTMT() user defined function, indexed 7 https://www.nginx.com/ ebadge project Page 51 of 93

f ua ia pa-pf Frequency (Hz) Voltage (V) Real current component (A) Active power component in Watts for MT1 MT6 coils 11.3.4 The database Measurements are stored in MySQL database in single table of the following structure: mysql> DESCRIBE meritve; +-----------+----------------------+------+-----+-------------------+----------------+ Field Type Null Key Default Extra +-----------+----------------------+------+-----+-------------------+----------------+ id bigint(20) unsigned NO PRI NULL auto_increment timestamp timestamp YES MUL CURRENT_TIMESTAMP did smallint(5) unsigned NO MUL NULL tarifa varchar(2) NO MUL NULL f float(4,2) NO NULL ua float(5,2) NO NULL ia float(6,4) NO NULL pa smallint(5) unsigned NO NULL pb smallint(5) unsigned NO NULL pc smallint(5) unsigned NO NULL pd smallint(5) unsigned NO NULL pe smallint(5) unsigned NO NULL pf smallint(5) unsigned NO NULL +-----------+----------------------+------+-----+-------------------+----------------+ 13 rows in set (0.03 sec) mysql> SELECT * FROM meritve ORDER BY timestamp DESC LIMIT 10; +---------+---------------------+-----+--------+-------+--------+--------+-----+----+----+-----+----+----+ id timestamp did tarifa f ua ia pa pb pc pd pe pf +---------+---------------------+-----+--------+-------+--------+--------+-----+----+----+-----+----+----+ 5464575 2015-09-10 12:24:34 4 VT 50.01 235.15 1.0030 195 4 6 125 7 6 5464574 2015-09-10 12:24:30 4 VT 50.01 235.35 1.0080 195 4 6 125 7 6 5464573 2015-09-10 12:24:27 4 VT 50.01 235.32 1.0050 195 4 6 125 7 6 5464572 2015-09-10 12:24:24 4 VT 50.02 234.87 1.0010 195 4 6 125 7 6 5464571 2015-09-10 12:24:21 4 VT 50.02 234.97 1.0000 195 4 6 125 7 6 5464570 2015-09-10 12:24:18 4 VT 50.02 234.85 1.0050 195 4 6 125 7 6 5464569 2015-09-10 12:24:15 4 VT 50.01 234.95 0.9990 195 4 6 125 7 7 5464568 2015-09-10 12:24:11 4 VT 50.00 234.61 1.0050 196 4 6 125 7 6 5464567 2015-09-10 12:24:08 4 VT 50.00 234.82 1.0090 195 4 6 125 7 6 5464566 2015-09-10 12:24:05 4 VT 50.00 235.14 1.0090 196 4 6 125 7 6 +---------+---------------------+-----+--------+-------+--------+--------+-----+----+----+-----+----+----+ 10 rows in set (0.00 sec) The tarifa field populates on INSERT trigger by calling IS_MTVT() function. USE `measurements`; DELIMITER $$ CREATE DEFINER=`marko`@`localhost` TRIGGER before_insert_meritve BEFORE INSERT ON meritve FOR EACH ROW SET new.tarifa = IS_MTVT() Function IS_MTVT() returns»mt«(low tariff) or»vt«(high tariff) string. It examines current timestamp and compares it against entries in the table delaprostidnevi which holds Slovenian holidays. If no entries are found then it examines whether it is weekend or not. If it is not weekend it determines in the final step whether the time is between 22:00 and 6:00. Function definition: DELIMITER $$ CREATE DEFINER=`marko`@`localhost` FUNCTION `is_mtvt`() RETURNS varchar(2) CHARSET latin1 BEGIN DECLARE tarifa VARCHAR(2); DECLARE tarifa1 VARCHAR(2); DECLARE tarifa2 VARCHAR(2); SET tarifa1 = IF ( EXISTS ( SELECT * FROM delaprostidnevi WHERE date=curdate() ),'MT', 'VT' ); SET tarifa2 = IF( HOUR(NOW())<6 OR HOUR(NOW())>=22,'MT', 'VT' ); ebadge project Page 52 of 93

IF tarifa1 = 'MT' OR WEEKDAY(NOW())>4 THEN SET tarifa='mt'; ELSE SET tarifa = tarifa2; END IF; RETURN tarifa; END In such way the current tariff is stored among the aggregated measurements so that it is possible to distinguish the power consumption proportion of each tariff period. Slovenian holidays are stored in the table delaprostidnevi: mysql> DESCRIBE delaprostidnevi; +-------------+--------------+------+-----+---------+-------+ Field Type Null Key Default Extra +-------------+--------------+------+-----+---------+-------+ date date NO NULL description varchar(255) YES NULL +-------------+--------------+------+-----+---------+-------+ 2 rows in set (0.00 sec) mysql> SELECT * FROM delaprostidnevi ORDER BY date; +------------+--------------------------------+ date description +------------+--------------------------------+ 2014-01-01 novo leto 2015-01-01 novo leto 2015-02-08 Presernov dan 2015-04-06 velika noc 2015-04-27 dan upora proti okupatorju 2015-05-01 praznik dela 2015-05-02 praznik dela 2015-06-25 dan drzavnosti 2015-08-15 marijino vnebovzetje 2015-10-31 dan reformacije 2015-11-01 dan spomina na mrtve 2015-12-25 bozic 2015-12-26 dan samostojnosti in enotnosti +------------+--------------------------------+ 13 rows in set (0.00 sec) For the purpose of web GUI graph display the user defined MT names are also stored in database: mysql> DESCRIBE coildescriptions2; +-----------+----------------------+------+-----+---------+-------+ Field Type Null Key Default Extra +-----------+----------------------+------+-----+---------+-------+ didnumber smallint(5) unsigned NO PRI NULL a varchar(32) YES NULL b varchar(32) YES NULL c varchar(32) YES NULL d varchar(32) YES NULL e varchar(32) YES NULL f varchar(32) YES NULL +-----------+----------------------+------+-----+---------+-------+ 7 rows in set (0.00 sec) mysql> SELECT * FROM coildescriptions2; +-----------+----------------+------------------------+--------+-----------+-----------------+----------------+ didnumber a b c d e f +-----------+----------------+------------------------+--------+-----------+-----------------+----------------+ 4 Dovodna linija Pralni + susilni stroj Bojler Hladilnik Pomivalni stroj Kuhalna plosca +-----------+----------------+------------------------+--------+-----------+-----------------+----------------+ 1 row in set (0.00 sec) We also implemented some stored procedures and views on the MySQL level to calculate the aggregated measurements values and display daily and monthly power consumption with respect to the tariff. Furthermore, the stored procedures and views enable also easy data mining support to drill down what causes high energy bills of the users. Implemented stored procedures are depicted in Figure 39 and Figure 40, while the views are depicted in Figure 41 and Figure 42. ebadge project Page 53 of 93

Figure 39: Stored procedure named get_watthours_today_total. Figure 40: Stored procedure named get_watthours_month_total. Figure 41: MySQL view named today_watthours_hourlyaggregated. ebadge project Page 54 of 93

Figure 42: MySQL view named month_watthours_hourlyaggregated. 11.4 Web application Web application consists of API which is implemented in JavaScript and HTML5/CSS/JavaScript code static files for browser side execution. Static files are served by nginx. API is handled in Node.js using express framework. We implemented the following API calls: // HTTP GET /rawdata/[didnumber]/[fromepoch]/[toepoch] app.get('/rawdata/:did(\\d+)/:a(\\d+)/:b(\\d+)', function(req,res) { }); // HTTP GET /rawdata/[didnumber]/[fromepochtime] // HTTP GET /rawdata/[didnumber]/-lastseconds app.get('/rawdata/:did(\\d+)/:a(-?\\d+)', function(req,res) { }); The purpose of API calls above is to retrieve the aggregated measurement values for specific period in time. Common parameter in all functions is a didnumber which describes the DeviceID of the HEH which is considered in the API calls. There is also an option to specify from-time and to-time values in the epoch format (number of seconds since 1 st of January 1970). The other option is to just specify from-time so we get all the measurements from specific point in time. Last option is to specify negative number of seconds which retrieves all measurements from the database for the lastseconds period. // HTTP GET /rawdata/coils/4 app.get('/rawdata/coils/:did(\\d+)', function(req,res) { }); The above function retrieves user defined names for MT1-MT6 measurement transformer coils (Rogowski) so when populating graph in the web GUI the names are natural to the user. Examples: Get data for the HEH DID = 4 for the last 10 seconds: vektor$ curl -s http://apiheh.dmz6.net/rawdata/4/-10 jq. [ { "timestamp": 1441880037, "pa": 77, "pb": 4, "pc": 6, "pd": 7, "pe": 7, "pf": 6 }, ebadge project Page 55 of 93

{ "timestamp": 1441880041, "pa": 76, "pb": 4, "pc": 6, "pd": 7, "pe": 7, "pf": 6 }, { "timestamp": 1441880044, "pa": 77, "pb": 4, "pc": 6, "pd": 7, "pe": 7, "pf": 6 } ] Get data for the HEH DID = 4 but from 1441880223 until now: vektor$ curl -s http://apiheh.dmz6.net/rawdata/4/1441880223 jq. [ { "timestamp": 1441880223, "pa": 210, "pb": 4, "pc": 6, "pd": 139, "pe": 7, "pf": 6 }, { "timestamp": 1441880226, "pa": 207, "pb": 4, "pc": 6, "pd": 137, "pe": 7, "pf": 6 }, { "timestamp": 1441880230, "pa": 204, "pb": 4, "pc": 6, "pd": 134, "pe": 7, "pf": 6 } ] Exactly the same data can be obtained by specifying from-time and to-time: vektor$ curl -s http://apiheh.dmz6.net/rawdata/4/1441880223/1441880230 jq. [ { "timestamp": 1441880223, "pa": 210, "pb": 4, "pc": 6, "pd": 139, "pe": 7, "pf": 6 }, { "timestamp": 1441880226, "pa": 207, "pb": 4, ebadge project Page 56 of 93

"pc": 6, "pd": 137, "pe": 7, "pf": 6 }, { "timestamp": 1441880230, "pa": 204, "pb": 4, "pc": 6, "pd": 134, "pe": 7, "pf": 6 } ] 11.5 User interface for data interpretation In the following we depict some representative examples of the power consumption measured by the HEH in a typical household. Please note the logarithmic scale and stack values check boxes in some of the Figures. Figure 43 shows typical situation when nobody is at home. There is a standby power consumption, while the one can easy notice the periodical refrigerator consumption spikes. Figure 43: Web application GUI for real time monitoring of power loads 1. ebadge project Page 57 of 93

Figure 44 shows the early morning events. Note the green spike of a microwave oven between 6:30 and 6:40 and the orange spike of the water heater between 7:30 and 7:50. Tumble dryer was started sometime after 6:20. Figure 44: Web application GUI for real time monitoring of power loads 2. The same events as in Figure 44, but without stacked graph values, are depicted in Figure 45. Figure 45: Web application GUI for real time monitoring of power loads 3. ebadge project Page 58 of 93

For example, the water heater event zoomed in Figure 46 can reveal the heater s interchanging consumption. Figure 46: Web application GUI for real time monitoring of power loads 4. Few other examples of early morning events, but with some data series disabled are depicted in Figure 47, Figure 48 and Figure 49. Figure 47: Web application GUI for real time monitoring of power loads 5. ebadge project Page 59 of 93

Figure 48: Web application GUI for real time monitoring of power loads 6. Figure 49: Web application GUI for real time monitoring of power loads 7. ebadge project Page 60 of 93

12 Field trial installation of HEHs The ebadge project field trial involved the installation of 120 HEHs at consumer and industrial/commercial premises. We obtained the consumer candidates via internal project campaign, whereas 22 HEHs were installed within the TS operator premises to demonstrate the suitability of design for industrial/commercial purposes. In particular, these HEHs were installed at: 6 PV power plants of the total installed power of 210 kwp, 11 mobile base stations, 5 electric car charging stations. 12.1 Customer introduction to HEH Before performing the HEH installations we organized the workshop about the field trial for all the consumer candidates. In the workshop we presented the ebadge project basics, HEHs, their operation, sensors and other equipment to be used. This included the demonstration of installation procedures and benefits of user engagement for conscious energy consumption. Additionally, participants were informed of all the data privacy issues of their concern, including handling of their personal data, security of the ebadge cloud and the data transmissions, and security of the HEHs themselves from the possibility of direct intrusions. For the demonstration purposes we prepared a demo board with two types of electrical power cabinets which are commonly installed in typical private households. It is depicted in Figure 50. The first type of electrical cabinet was an old type with porcelain fuse wedges, while the second, modern type of cabinet was with resettable automatic fuses and other components from renowned manufacturers. The HEH was installed in the modern cabinet with the help of terminal connectors so that its operation was successfully presented to the consumer candidates. ebadge project Page 61 of 93

Figure 50: A demo board with two types of electrical power cabinets which are commonly installed in typical private households. 12.2 Preparation for field trial All the consumer candidates which agreed to participate in the ebadge field trial had to go through the specific procedure prior the HEH installation in their premises. They had to sign a customer contract which revealed the basic user information such as type of electrical installation, its power rating, etc. If possible, we obtained also the photos of their existing electrical cabinets which enabled us to properly prepare the HEHs, basic wiring sets, fuses, and relays prior the installations. All the mounting material was selected from certified producers ETI Izlake 8 and Schneider 9 according to electro technical standards and technical guidelines. In particular, the TSG-N-003: 2013 for electrical installations and TSG-N-002: 2013 for fire protection were considered. 12.2.1 Laboratory tests Prior installations we tested all the equipment to be sure it is working properly. An example of parallel HEHs testing in a laboratory environment is shown in Figure 51. Up to 8 HEH were connected via Wi-Fi to the same LTE modem and three such configurations were tested with the same power load. Figure 51: Parallel testing of HEHs in a laboratory environment. Prior to assembly of the RaspberryPi inside the HEH enclosure, we had to remove video and audio connectors to get the proper form factor and carefully insert the SD card or adapter with the micro SD card to use the image file. Many of the original RaspberryPi SD cards were of inferior quality, so we replaced them with higher grade counterparts. 8 www.eti.si 9 www.schneider-electric.com ebadge project Page 62 of 93

Furthermore, during the field trial installations we have changed RaspberryPi with RaspberryPi Model B. Newer versions are preferred due to integrated microsd connector that has built-in latch by default. After successfully passing the laboratory test and prior the installation each HEH was labelled as depicted in Figure 52 and marked with the unique device identification number (DID). Figure 52: The HEH label of a specific customer. 12.3 HEH installations The installation of HEH at each location followed the following deployment steps: checking the existing situation and electrical devices, taking photos of existing electrical connections and documenting the installation work, deploying the HEH and its connectors into current wiring situation, installing of the Rogowski coils and bridging of inactive MT inputs to reduce the noise in measurements, connecting bi-stable pulse relays for loads switching, installing of the external modem, verifying HEH connectivity and its access to the ebadge cloud, testing the operation of all electrical devices connected to electrical cabinet, taking photos of a new wiring situation, fulfilling of the documentation. On potentially critical locations, e.g. old to new electrical distribution panel, we also checked the HEH and cabinet wiring with an IR camera FLIR e40, to make sure that there are no hot spots (literally). An example of such test is depicted in Figure 53. ebadge project Page 63 of 93

Figure 53: Checking electrical connections and proper dimensioning devices with IR camera. 12.3.1 Demonstration of various HEH installation possibilities With respect to consumers existing situation we implemented three types of HEH installations: HEH deployments in old electrical cabinets, HEH deployments in new electrical cabinets, HEH deployments next to old electrical cabinets. Examples of all three deployment types are depicted in Figure 54, Figure 55, and Figure 56. ebadge project Page 64 of 93

Figure 54: Example of HEH deployment in an old electrical cabinet. Figure 55: Example of HEH deployment in a new electrical cabinet. ebadge project Page 65 of 93

Figure 56: Example of HEH deployment next to an old electrical cabinet. 12.3.2 Specifics of HEH installation at PV power plants, mobile base stations and EV charging stations HEH installations at PV power plants or mobile base stations are not the same as in the households. Though, the HEHs are installed in the power cabinets in similar way they must incorporate more powerful PULSE PA3209NL Rogowski coils that can measure power consumption in the range up to 1000 A. Examples of HEH installations at PV plant, mobile base station and EV charging stations are depicted in Figure 57, Figure 58, Figure 59 and Figure 60. Figure 57: Electrical distribution board with HEH for 50 kwp PV plant. ebadge project Page 66 of 93

Figure 58: PV solar plant with HEH installation. Figure 59: Installation of HEH in the PV power plant AC distribution cabinet. ebadge project Page 67 of 93

Figure 60: Installation of HEH in the EV charging station. ebadge project Page 68 of 93

13 Conclusions The HEH is a platform for exchanging measurement data used to realise the ebadge field trial. This deliverable covers its building parts, features, and supporting infrastructure, ranging from measurement board and processor platforms on the HEH side, to cloud software and database on the side of Home Energy Cloud as well as user applications and HEH deployments on the consumer side. The HEH platform was designed by coupling a dedicated, custom made energy measurement board with singleboard computer, i.e. RaspberryPi running ARM-based Debian distribution. In the pilot HEH was connected with Ethernet or WiFi dongle to mobile modem, but theoretically also other connectivity options could be possible, e.g. serial interface like UART, I2C or SPI via on-board general purpose input/output (GPIO), ZigBee via external peripheral, or other. This makes it feasible to operate in various Internet of Things (IoT) environments. Mobile case uses a dedicated Access Point Name (APN) of the 4G LTE or 3G UMTS connection, which enables a reliable communication among the deployed HEHs and the ebadge cloud. Some contemporary security mechanisms were applied in order to support strict security restrictions and privacy for end-user data. To support upto-date long-term HEH operation data collecting server, database, MB server, and some Debian repository cache services in the ebadge cloud were deployed. These enable secure measurements collection, remote SW upgrades on the HEHs as well as their access to the most recent operation settings. On the other hand, the administration panel for managing ebadge entities and to monitor operation of the HEHs on the field was developed. This can assist technical experts and technicians on the field to quickly overview HEH statuses, insert or edit new HEHs and their appliances, manage new web or application users and properly assign their privileges. The entire infrastructure consist of private households, 6 PV power plants, 11 mobile base stations, and 5 electric car charging stations, where each type of prosumer has different characteristics in terms of amount of consumptions, generation and load capabilities and energy flow profile. Finally, to bring the field trial measurements to the consumers we developed the web-based user portal and Androidbased mobile application. Both applications allow end users who have one or more HEH devices installed so they can have a general overview of power consumption of their appliances and elaborate with additional graphical elements like real-time measurement graph. Furthermore, mobile application also supports push notifications, where management software are potentially able to engage user action by e.g. sending suggestions about most suitable electricity profile. This strongly contributes to whole consumers involvement towards more efficient energy consumption. Through the described and developed HEH platform, also some other novel contributions were presented. The HEH device itself was composed of low cost and accessible components, such as RaspberryPi and a home mobile router, which resulted in suitable and cost effective solution as compared to available smart metering devices currently on the market. Moreover, it is not only possible to monitor the power consumption of the end users at a higher resolution than the comparable, off-the-shelf devices, but also to actively operate (switch on/off) the end user appliances. This operation could not only be achieved by the end users themselves, but also directly by the VPPs, naturally with users consent, to optimise the behaviour of power grids and wise usage of energy. This also means that power grid providers, Distribution System Operators (DSOs) and power market operators are able to extend their interests to role of fine-graining of energy (electric, as well as the other) into more controllable, well balanced energy space on some larger geographic area. ebadge project Page 69 of 93

References [4noks 2013] http://www.zb-connection.com [AD 2013] http://www.analog.com/en/analog-to-digital-converters/energymeasurement/ade7880/products/product.html [ARM 2013] http://www.arm.com/products/processors/instruction-set-architectures/index.php [BBB 2013] http://beagleboard.org/products/beaglebone%20black [Cisco 2014] Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2014 2019, Cisco, 2014. [CSide 2013] http://www.cside.pt/p_energy_manager.asp [Euramet 2013] EMRP Call 2013 Energy and Environment, Selected Research Topic number: SRT-g18. [GWR 2013] http://www.greenwavereality.com/solutions/energymgmt/ [IJS 2013] http://sensorlab.ijs.si/hardware.html [Intel 2013] http://www.intel.com/content/www/us/en/processors/atom/atom-processor.html [LG 2013a] Landis technical paper for smart meters E850 and E650. [LG 2013b] Landis technical paper for communication units CU-P32, CU-E22 and CU-Q22. [MCP 2013] http://www.microchip.com/wwwproducts/devices.aspx?ddocname=en028189 [Munin 2013] http://munin-monitoring.org [OpenADR 2013] OpenADR 2.0 Profile Specification B Profile, Document Number: 20120912-1, OpenADR Alliance, 2013. [RFC5548] Routing Requirements for Urban Low-Power and Lossy Networks. [RFC6272] Internet Protocols for the Smart Grid. [RFC6282] Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. [RFC6550] RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. [RPi 2015] http://www.raspberrypi.org/ [TI 2013] http://www.ti.com/lsds/ti/microcontroller/16- bit_msp430/overview.page?dcmp=mcu_other&hqs=msp430 [Wattson 2013] http://www.diykyoto.com/uk/aboutus/wattson-solar-plus [WSK 2013] http://www.wireshark.org/ ebadge project Page 70 of 93

1 Appendix 1.1 Preparation of software image for HEH The steps described here provide us with a bootable SD card image that can then be duplicated and deployed on all the HEHs. Please note that the steps described are not the only possible, but rather present the particular option actually used for HEH SW image preparation. Requirements: PC with Debian or any derivative of Debian installed, SD card (min. 2GB), SD card reader, internet connection, connection to the ebadge cloud. We also considered the following tools: Dosfstools to format partitions with FAT filesystem, Debootstrap tool which will install base Debian system into folder. It requires access to Debian repository, qemu-user-static a processor emulator. It is needed because we are building an ARM system on a non- ARM (i386 or x64) platform, git-core tools for operations with git hub repository. Used for getting latest firmware version for RaspberryPi, binutils tools for building, assembling and linking binary and object files. The SD cards were formatted in the following way: partition 1: size: 100MB, type: W95, file system: FAT32, partition 2: size: minimum 1GB, type: Linux, file system: ext4. Partition 1 is used for HEH firmware and Linux kernel, a boot SW read immediately after HEH is powered on. This partition demands the FAT32 file system to boot the RaspberryPi successfully. Partition 2 is used for Debian operating system and the local measurements storage. Once created, the partitions should be mounted on the development machine to access them. We assumed that the mounting points for the boot (partition 1) and root (partition 2) are /mnt/raspberry_root and /mnt/raspberry_boot, respectively. The basic Debian system can be installed with Debootstrap. Internet connection is needed because Debootstrap downloads needed packages from Debian repository. The following command runs the first stage: debootstrap --foreign --arch=armel wheezy /mnt/raspberry_root/ http://ftp.si.debian.org/debian The installation process includes running executable programs compiled for the Raspberry Pi (ARM architecture) on a development PC (i386 or x64 architecture), so we need a suitable emulator. The widely used QEMU 10 proved adequate for our purposes. We need to copy the QEMU emulator binary into our working directory: cp /usr/bin/qemu-arm-static /mnt/raspberry_root/usr/bin/ Chroot operation is used to change apparent root directory for current running process and it children: 10 http://www.qemu.org ebadge project Page 71 of 93

chroot /mnt/raspberry_root/ If we had not copied the QEMU emulator here, it would not be accessible anymore. Now we can run the second Debootstrap stage to finish installing the base system: cd /debootstrap./debootstrap --second-stage The file /etc/apt/sources.list is used by the Debian packaging system apt and contains the list of SW repositories that the system can connect to and download the desired packages. To host all the HEH-specific SW we use our own Debian repository that is installed within the ebadge cloud. Thus, the entries for this repository have to be added: echo "APT::Default-Release "stable";" > /etc/apt/apt.conf.d/50aptpref echo "deb http://apt.ebadge.xlab.si:3142/eb-wheezy wheezy main non-free" > /etc/apt/sources.list echo "deb http://apt.ebadge.xlab.si:3142/eb-wheezy testing main " > /etc/apt/sources.list echo "deb http://apt.ebadge.xlab.si:3142/eb-wheezy-sec wheezy/updates main" >> /etc/apt/sources.list echo "deb http://apt.ebadge.xlab.si/ebadge wheezy main" >> /etc/apt/sources.list wget -O - http://apt.ebadge.xlab.si/ebadge/gpg.key apt-key add - && apt-get update Next, additional packages have to be installed. The following packages are required for regular operation of the HEH: locales files used by C library for localization (l10n) and internationalization (i18n), ntp program using Network Time Protocol protocol for clock synchronization, unattended-upgrades program for automatic upgrade from repository, psmisc package for process management, usb-modeswitch scripts for correctly recognize USB devices, libqmi-utils library for QMI communication with modem devices. This package is installed from testing debian repository, because it has not been ported to stable repository, and ebadge the package containing all custom HEH SW, including the daemon for collecting and reporting measurements, the client-side ebadge MB code, and various initialization and configuration scripts. The HEH is configured to use the en_us locale. The use of only one locale on all the HEHs avoids the issues with decimal commas vs points, date formats etc: locale-gen --purge en_us.utf-8 && echo -e 'LANG="en_US.UTF-8"\nLANGUAGE="en_US:en"\n' > /etc/default/locale Some helper packages are also installed on each HEH to help with troubleshooting, debugging etc. These could be left out for production use, but the space saved would not be significant: ssh remote terminal, nano text file editing program, tcpdump program for capturing network traffic. To correctly boot the system we need to create and populate the following system files: File /etc/fstab is file system table file and lists available file system devices. Content for /etc/fstab: proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults 0 2 /dev/mmcblk0p2 / ext4 defaults,noatime 0 1 File /etc/network/interfaces configures the network subsystem under Linux: ebadge project Page 72 of 93

auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp metric 20 allow-hotplug wwan0 iface wwan0 inet static address 192.168.1.2 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 up qmicli -d /dev/cdc-wdm0 --client-no-release-cid --wds-start-network=internet; Create file /etc/usb_modeswitch.d/zte91d.conf and insert next lines into file: DefaultVendor= 0x19d2 DefaultProduct= 0x0166 TargetVendor= 0x19d2 TargetProduct= 0x1426 Exit chroot with exit command: Exit Populate boot partition with RaspberryPI firmware and kernel modules: wget -O rpi-update https://raw.github.com/hexxeh/rpi-update/master/rpi-update chmod +x rpi-update mkdir /mnt/raspberry_root/lib/modules We need to create all files for firmware because rpi-update script will complain if no start.elf etc is found: for file in start.elf bootcode.elf loader.bin kernel.img ; do touch /mnt/raspberry_boot/$file; done Build firmware: ROOT_PATH=/mnt/raspberry_root BOOT_PATH=/mnt/raspberry_boot./rpi-update SD card is now ready to boot and we can create the RAW disk image that can be used for installations: dd bs=1m if=/dev/<sd card disk device> of=heh-image.raw When this command finishes we have the SW image file heh-image.raw available for deployment to all HEHs. 1.2 HEH customer information forms Information about the equipment, HEH deployment locations and subscribers is kept in a paper and electronic form. This is particularly important when introducing a customer support via phone or email. Note that we use the terms consumer, subscriber, customer and user interchangeably, but subscriber also signifies that he or she has the mobile contract with the TS. During the ebadge field trial we obtained the information outlined in the following subsections. 1.2.1 Subscriber information DID (HEH identification number), name of the contracting authority, surname of the contracting authority, type of the contracting authority (residence / business), ebadge project Page 73 of 93

e-mail, address of the contracting authority, location, postcode, signed contract (pdf. or jpg. Format) that also contains a questionnaire which displays the actual situation on the spot and the client's needs The questionnaire and an interview with the client is used for technical solutions, photos from locations before, during and after installations. 1.2.2 HEH information DID (identification number HEH-a), ID of the owner / user of HEH, stock number equipment, IP address, MAC address, phase system (1-phase or 3-phase), number of current transformers and consumers linked to the individual current transformers, the number of pulse relays and consumers linked to each pulse relays, and scheme for electrical connection HEH-a and equipment (.pdf format). 1.2.3 HEH installation information There are several documents which must be prepared prior, during and after HEH installation: Before installation order is created the document FIXED ASSED INVENTORY FOR THE CONTRACTING AUTHORITY is prepared. This precisely enumerates active equipment which will be installed. For each deployment site the contractors receive and sign the document INSTALLATION PROCEDURES, which precisely describes and defines the HEH installation steps. Before the installation work a photograph of the existing situation is taken and the control of existing electrical connections (working loads) is performed. The same procedure is repeated after HEH installation is completed. After installation begins operation tests must be performed and confirmed (connectivity, measurement results). Documents that are created after the HEH installation are EQUIPMENT AND INSTALLATION MATERIALS, FIXED ASSED INVENTORY AND ASSEMBLY MATERIAL, and HEH INSTALLATIONS SCHEME. By signing all these documents, the subscriber confirms the acceptance of all the equipment and services. 1.1.1 Customer contract form to join the ebadge project ebadge project Page 74 of 93

Figure 61: Example a signed declaration to join the project. ebadge project Page 75 of 93

1.2.4 Customer mobile subscriber form Figure 62: Mobile data subscriber information form. ebadge project Page 76 of 93

1.2.5 HEH installation procedure check list Figure 63: HEH installation check list. ebadge project Page 77 of 93

1.2.6 HEH wiring information form for Rogowski coils and relays This document is an inventory of installed equipment and the point of equipment connection. Based on the data of this document we produced Final assembly scheme. Figure 64: HEH wiring information form. ebadge project Page 78 of 93

1.2.7 HEH wiring scheme Figure 65: HEH wiring scheme at installation. ebadge project Page 79 of 93

1.2.8 HEH inventory of installed material This document is an inventory of spent materials and equipment. Used for financial evaluation of each project site. Figure 66: HEH installed materials form. ebadge project Page 80 of 93

1.2.9 HEH detailed final installation diagram Figure 67: HEH wiring scheme at installation. 1.3 Measurement of electrical loads and wiring In critical HEH deployment locations (e.g. where electrical power cabinets were changed with the new ones, in mobile base stations, etc.) we performed measurements with the Elspec 4500 power analyser. Some Figures of this step are depicted in the following. ebadge project Page 81 of 93

Figure 68: Measurement setup of power quality parameters. Figure 69: Measurement results of the power quality. ebadge project Page 82 of 93

Figure 70: Measurement results of the harmonics of the power quality. ebadge project Page 83 of 93

1.4 ebadge API API is designed to provide programming interface for various applications in defined way. In order to catch responses in synchronous clients (e.g. with receiving callback function), written in for example Javascript or Java (Android OS), the first object in response is message_type of requested call. Specific request also requires some parameters, which are validated during service request, e.g. ISO date format. In case of logical or syntax error, appropriate response is send, also describing type of error occurred. In the following lines, API calls are defined with corresponding bullets, where: a) is absolute path to HTTP call, b) is redirections in case of successful response, c) is successful returned JSON object, d) is unsuccessful redirection and e) is unsuccessful JSON object response. At the end of each call calling/returned API parameters are described. 1.4.1 Service availability API [ ] a) [full_http_path]/ b) None c) { }, { }, { }, { } "message_type": 0 "info":[info] "version": [version] "creator": [creator] d) / e) / Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [info] Raw text. info@ebadge.si [version] API version, of 3.0 type: X.Y, where X represents main version and Y represents minor version. [creator] API creator. Telekom Slovenije d.d. ebadge project Page 84 of 93

1.4.2 User info API [ ] a) [full_http_path]/info/[token] b) None c) { }, { }, { }, { }, { } "message_type": 1 "user_id": [user_id] "username": [username] "first_name": [first_name] "last_name": [last_name] [ ] d) None e) { }, { } "message_type": 1 "error": [error] Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [token] Raw text. E4IMTPOXCNM6P3AKL90TGSYZ1N2414QT55WY7A68OCBB 11VW [user_id] Unique user identifier 1 (for any purpose of user identification). [username] Raw text, username, Test.user@domain.com i.e. user s email address. [first_name] Raw text. TEST [last_name] Raw text. USER [error] Error response: invalid : user TOKEN is in database, but is not valid. Needs to re-authenticate using USERNAME/PASSW ORD pair. ebadge project Page 85 of 93

deny : TOKEN is not valid. Possible issues can be: wrong TOKEN, wrong CASE, incorrect LENGTH (48 bytes), etc. error : generalpurpose system error, e.g. MYSQL database cant not be reached. 1.4.3 Token acquisition API ] [ a) [full_http_path]/auth/[username_b64]/[password_b64] b) None c) { }, { }, { } d) None e) "message_type": 2 "username": [username] "token": [token] ] [ { }, { } "message_type": 2 "error": [error] Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [token] Raw text. E4IMTPOXCNM6P3AKL90TGSYZ1N2414QT5 5WY7A68OCBB11VW [username_b6 4] [password_b64 ] Base64 text. utf8tobase64( tomaz.lovren cic@ domena.si ): dg9tyxoubg92cmvu Y2ljQGRvbWVuYS5zaQ== Base64 text. utf8tobase64( AE0B9081AA23 EEF239987ACC ): QUUwQjkwODFBQTIzRUVGMj dg9tyxoubg92cmvuy2ljqgrvbwvuys5za Q== QUUwQjkwODFBQTIzRUVGMjM5OTg3QUND ebadge project Page 86 of 93

M5OTg3QUND [username] Raw text Test.user@domain.com [error] Error response: error : user USERNAME/PASSWORD pair is not correct. Or general-purpose system error. 1.4.4 Graph for all HEHs for single user with time interval and resolution [ a) [full_http_path]/graph/[from_b64]/[to_b64]/[resolution_b64]/[token] b) None c) { }, { }, { "message_type": [msg_type] "mac": [mac], "resolution": [resolution], "data": [ { "device": "MT1": { "load":[load_array], "time":[time_array] }, { "device": "MT2": { "load":[load_array], "time":[time_array] }, { "device": "MT3": { "load":[load_array], "time":[time_array] }, { "device": "MT4": { "load":[load_array], "time":[time_array] }, { "device": "MT5": { "load":[load_array], "time":[time_array] }, { "device": "MT6": { "load":[load_array], "time":[time_array] } "mac": [mac], "resolution": [resolution], "data": [ { "device": "MT1": { "load":[load_array], "time":[time_array] }, { "device": "MT2": { "load":[load_array], "time":[time_array] }, ebadge project Page 87 of 93

] ] [ d) None e) },... { }, { } { "device": "MT3": { "load":[load_array], "time":[time_array] }, { "device": "MT4": { "load":[load_array], "time":[time_array] }, { "device": "MT5": { "load":[load_array], "time":[time_array] }, { "device": "MT6": { "load":[load_array], "time":[time_array] } "message_type": [msg_type] "error": [error] Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [token] Raw text. E4IMTPOXCNM6P3AKL90TGSYZ1N2414QT55WY7A 68OCBB11VW [msg_type] msg_type determines the type 3 of graph: 3 : resolution of 1 minute, 4 : resolution of 15 minutes, 5 : resolution of 1 hour. [from_b64] Time interval: from. MjAxNC0wOS0zMCAwODowMDowMA== [to_b64] [resolution_b6 4] utf8tobase64( 2014-09- 30 8:00:00 ): MjAxNC0wOS0zMCAwODowM DowMA== Time interval: to. utf8tobase64( 2014-09- 30 09:00:00 ): MjAxNC0wOS0zMCAwOTowM DowMA== 1 minute ( 1 ), 15 minutes ( 15 ) or 1 hour ( 60 ) encoded in base64. MjAxNC0wOS0zMCAwOTowMDowMA== MTU= ebadge project Page 88 of 93

utf8tobase64( 1 ): MQ== [mac] b827eb8a5c43 [resolution] Raw text. 1 [load_array] Array of load samples for every input GPIO ( MT1 to 0.9464, 0.945, MT6 ) for time interval 0.945 specified by from_b64 and to_base64. [time_array] [error] Time for the load sample between from_b64 and to_base64. Error response: invalid : user TOKEN is in database, but is not valid. There is no need to remove this TOKEN. deny : TOKEN is not valid. Possible issues can be: wrong TOKEN, wrong CASE, incorrect LENGTH (48 bytes), etc. format : time format is not correct. It must be in exact MySQL notation, e.g.: 2014-10-01 10:00:00. time : time interval error, e.g. time interval to_base64 is after from_b64. resolution : resolution error, e.g. resolution is not one of the predefined (1, 15 or 60) or resolution is not a number. error : general-purpose system error, e.g. MYSQL database cant not be reached. ERRORS ARE NOT CONCATENATED! 2014-07-29 10:15:00, 2014-07-29 10:16:00, 2014-07-29 10:17:00 1.4.5 HEH list for single user with real-time data [ a) [full_http_path]/heh/list/[token] b) None c) { }, { "message_type": 10 "heh_id": [heh_id], "device_sn": [device_sn], "device_version": [device_version], "device_mac": [device_mac], "device_name": [device_name], "power_in": [power_in], ebadge project Page 89 of 93

"load_capability": [load_capability], "generation_capability": [generation_capability], "can_predict_profile": [can_predict_profile], "can_predict_curtailment_capability": [can_predict_curtailment_capability] "data": { { "MT": [load], "time": [time] }, { "MT1": [load1], "time": [time] }, { "MT2": [load2], "time": [time] }, { "MT3": [load3], "time": [time] }, { "MT4": [load4], "time": [time] }, { "MT5": [load5], "time": [time] }, { "MT6": [load6], "time": [time] }, { "MTO": [loado], "time": [time] } }, "status": [status] }, { "heh_id": [heh_id], "device_sn": [device_sn], "device_version": [device_version], "device_mac": [device_mac], "device_name": [device_name], "power_in": [power_in], "load_capability": [load_capability], "generation_capability": [generation_capability], "can_predict_profile": [can_predict_profile], "can_predict_curtailment_capability": [can_predict_curtailment_capability] "data": { { "MT": [load], "time": [time] }, { "MT1": [load1], "time": [time] }, { "MT2": [load2], "time": [time] }, { "MT3": [load3], "time": [time] }, { "MT4": [load4], "time": [time] }, { "MT5": [load5], "time": [time] }, { "MT6": [load6], "time": [time] }, { "MTO": [loado], "time": [time] } }, "status": [status] },... ] [ ] d) None e) { }, { } "message_type": 10 "error": [error] Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [token] Raw text. E4IMTPOXCNM6P3AKL90TGSYZ1N2414QT55WY7A68 OCBB11VW ebadge project Page 90 of 93

[heh_id] HEH id from the 64 database. [device_sn] DID number. 7 [device_version] HEH version. [device_mac] Raw text. b827eba0eace [device_name] String like: DID:0007 DID:XXXX, where XXXX represents device serial number. [power_in] Power supply: 1p 1p : 1 phase ( MT1 ), 3p : 3 phases ( MT1 + MT2 + ( MT3 ). It effects [load]. [load_capability] Boolean. 0 [generation_capability] Boolean. 0 [can_predict_profile] Boolean. 0 [can_predict_curtailme Boolean. 0 nt_ capability] [load] Float. 23.9 [status] Boolean. 1 [error] Error response: deny : TOKEN is not valid. Possible issues can be: wrong TOKEN, wrong CASE, incorrect LENGTH (48 bytes), etc. error : generalpurpose system error, e.g. MYSQL database cant not be reached. 1.4.6 Get last Android application info [ a) [full_http_path]/android/version/[token] b) None c) { }, { }, { }, "message_type": 100 "apk_name": [apk_name] "versiondate": [version_date] ebadge project Page 91 of 93

] { }, { }, { }, { "versionminsdk": [version_min_sdk] "versiontargetsdk": [version_target_sdk] "versioncode": [version_code] "versionname": [version_name] }, { "downloadurl": [download_url]http://ebadge.si/app/android/download/26/ppsr55yb7oarh4y8cp14iaathmtsbcg MXMZGW28K0NJWVB17 } d) None e) None (no input parameters to validate) Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [token] Raw text. E4IMTPOXCNM6P3AKL90TGSYZ1N2414QT55WY7A68 OCBB11VW [apk_name] Name of Android application. ebadgeapp_2015-07-14_15_21_026_0-9- 036.apk [version_date] Date of last 2015-08-04 version. [version_min_sdk] 15 [version_target_sdk] 21 [version_code] 26 [version_name] 0.9.36 [download_url] http://ebadge.si/app/android/download/26 /PPSR55YB7OARH4Y8CP14IAATHMTSBCGMXMZGW28 K0NJWVB17 [error] Error response: deny : TOKEN is not valid. Possible issues can be: wrong TOKEN, wrong CASE, incorrect LENGTH (48 bytes), etc. error : generalpurpose system error, e.g. MYSQL database cant not be reached. 1.4.7 Get last Android application a) [full_http_path]/public/android/download b) Latest.apk file download link c) None d) None ebadge project Page 92 of 93

[ ] e) { }, { } "message_type": 100 "error": [error] UNSUCESSFUL HTTP RESPONSE None Argument Comment Example [full_http_path] Base url. http:/ebadge.si/app [error] Error response: deny : TOKEN is not valid. Possible issues can be: wrong TOKEN, wrong CASE, incorrect LENGTH (48 bytes), etc. error : generalpurpose system error, e.g. MYSQL database cant not be reached. ebadge project Page 93 of 93