Home Automation in the UK Simplified, Part 1: Energenie MiHome

Join Shabaz as he works on his IoT home!

Learn about home automation using the Raspberry Pi, Energenie MiHome and Node Red.

Check out our other Raspberry Pi Projects on the projects homepage

Previous Part
All Raspberry Pi Projects
Next Part


Note: Although this blog post covers a UK home automation solution, a lot of the information is still relevant for other regions. The information here shows how to create software applications and graphical user interfaces using a block-based system called Node-RED and JavaScript, that can communicate with hardware and with cloud based services. The information here also shows how to convert the Raspberry Pi to run in a sort of 'kiosk mode' where the user interacts with the Pi as an end appliance with a graphical touch-screen interface. Finally, the information described here shows how to provide auto-dimming capability for the touchscreen display for suiting environments with varying light conditions.



A few months ago, the topic of home automation in the UK was explored, and how it could be achieved safely, at low cost. It turned out to be simple; attach radio-controlled mains sockets, mains adapters and light switches into your home, and connect a Mi|Home Gateway box into your existing home router. The gateway has a 433MHz radio to talk to the sockets and switches, and connects via the Internet to a free cloud service called Energenie Mi|Home.


This is sufficient to be able to control your home using the buttons on the sockets and switches, and using a web browser or mobile app downloadable from the Mi|Home website or iPhone/Android mobile app store.


The home automation was enhanced by purchasing a low-cost Amazon Echo box which connects to the home network wirelessly. It allows for voice control of your home appliances.


Not everyone wants voice control, although I prefer it. No need to touch and share the germs using a touch-screen : ) Nevertheless, many users still prefer touching buttons or a screen for control. There is also the desire to be able to programmatically control things using something like a Raspberry Pi, for more intelligent automation that just 'if this then that' style of encoding behaviour into your home. It would be perfectly feasible for the Pi to identify that a user has picked up a book, and automatically turn on the reading lamp. I decided to try to implement a large touchscreen on the wall to control the home in conjunction with retaining voice control and browser control. I also wanted to use a simple programming environment that could allow for more elaborate schemes in future.


This part 2 deals with how to go about this, using a Raspberry Pi 3Raspberry Pi 3 for the programming environment and for running a user interface, and a capacitive touch-screencapacitive touch-screen for monitoring and control.


The project is really easy from a hardware perspective, the Pi just needs connecting to the home network (either using the built-in wireless capability, or the Ethernet connection available on the Pi). Any display could be selected but the capacitive touch screen of course makes life easier because touch can be used! No keyboard required.


Further below in this blog post, the hardware design is extended slightly to provide auto-dimming capabilities to suit varying home lighting conditions.


To build the solution described here, the mandatory Energenie MiHome bits you need are the MiHome Gateway, and at least one MiHome control element such as a MiHome mains adapter.


An Amazon Echo, or Echo Dot device is optional but provides useful voice control as discussed in the earlier blog post.


The diagram here shows the approximate topology inside the home. It is really straightforward, difficult to go wrong!


Just to recap, the home devices such as lights and sockets are controlled via radio. These are shown at the top of the diagram. The hub that communicates over radio to them is the MiHome (also referred to as Mi|Home) Gateway. It connects to the Internet (for example using DSL) by plugging into your existing home Internet router. The user sets up an account at the Energenie MiHome website and downloads an app if desired. From here the user can control any device from anywhere with an Internet connection.


Voice commands are possible due to integration between Amazon’s Alexa service and the MiHome cloud service. All it requires is for the user to obtain an Amazon Echo or Echo Dot device as mentioned earlier, and run a small bit of configuration; all this was covered in Home Automation in the UK Simplified, Part 1: Energenie MiHome


This part 2 now covers the green portion in the diagram above. Basically it connects a Raspberry Pi to the solution. The Pi communicates to the MiHome service using an application programming interface (API). A user interface also runs on the Pi, so that a connected touchscreen can be used for controlling and monitoring the home. The typical flow of information is therefore:


  1. The user presses a selection on the touchscreen
  2. The Pi sends the command in a specific format (using the API) to the MiHome web service in the cloud
  3. The MiHome service looks up the pre-registered user, and sends commands to the MiHome Gateway
  4. The MiHome Gateway unwraps the command and converts it into a radio signal
  5. The radio signal is picked up by the appliance intelligent mains socket and switches on or off the connected appliance


In the event of network failure, the local controls on each mains socket will continue to function. The touchscreen controls can also continue to function since the Pi can switch to radio mode, sending commands directly to the IoT devices, using a radio module plugged on top of the Pi. This last capability is outside the scope of this blog post and may be covered in a later article if there is interest.


In summary, the Energenie + Raspberry Pi + Capacitive Display + Amazon Echo forms a fairly comprehensive solution, little effort is required to build it, and all code for this project is published and is easy to customise.


The diagram below shows the complete path of information between the home and the cloud services. This is not necessary to know, it is just background information for those that are curious.


How do I do it? - Brief Overview

Firstly, get a Pi 3 and the correct power supplycorrect power supply (the Pi 3 along with the display uses a lot of power - most USB chargers and associated USB cables will not be sufficient) and do the usual basic configuration (install the latest software image, create a password, and get it connected to your home network using either wireless or the Ethernet connection). The steps for this are covered in many blog posts. Next, attach the display to the Pi.


The next step (described further below) is to enable the software development environment called Node-RED and copy across the example Energenie MiHome code (all links are further below) that was developed as part of this blog post. Configure it to suit your home appliances. This entails storing an 'API Key' that is unique to anyone who registers their MiHome Gateway on the Energenie MiHome website, and also obtaining and entering in the device identifiers so that the Pi knows which adapter you wish to control when you press particular buttons on the touchscreen. Finally, you can customize the touchscreen and make it auto-dimming when the room is dark with a small add-on circuit. The majority of this blog post will cover all these topics in detail.



The security of the base solution was covered in part 1, see the section there titled ‘Protocols and Examining the Risks’. The extra functionality in this part 2 has no known data security issue. No password is stored on the Raspberry Pi and no inbound ports are required to be opened on the router beyond those that would ordinarily be dynamically opened for web browsing responses. All communication between the Pi and the MiHome cloud service is encrypted. The Raspberry Pi stores just an ‘API key’ and the e-mail address that was used to register the MiHome service (use a throwaway e-mail account if you wish). The API key provides control of the home appliances until the user deactivates them from the MiHome cloud service, in the event that someone hacks into the Pi. With sensible precautions (no ports opened up on the router) and user access restricted to the Pi, the risk of this occurring is low.


Depending on the desired level of trust/mistrust, one could modify the touchscreen interface to prompt for the MiHome password always; this would eliminate the need to locally store an API key but would increase the inconvenience. It is an option nevertheless.


What is an API?

An Application Programming Interface is a type of machine-to-machine communication method that is (often) made public. It isn’t necessarily designed for any one particular purpose. The reason is, often the creators of a service are not sure of how all their customers will use the service. By having an API, unexpected solutions can be created, adding value for the user. Whole businesses have been created on the backs of APIs; for example, Uber may not have known what else could be done by ordering a taxi with an API, however it is possible to automate deliveries by using such an API to automatically request a nearby driver as soon as someone places an order for your product. A taxi service that works like DHL is definitely unexpected, and would be harder to create without APIs. It has allowed businesses to have delivery staff on-demand.


Modern APIs frequently rely on HTTP and REST techniques. These techniques ultimately allow for efficient communication in a consistent manner. They nearly all result in the communicating device sending a HTTP request to a web address over the network with any data sent as plain text often in parameter and value pairs (known as JSON format) and the HTTP response looks like a what a web browser might receive, with a response code and text content. It actually means that such APIs can often be tested with any web browser like Chrome or Internet Explorer.


In the case of MiHome, Energenie have created an API that allows one to do things like send instructions to turn on and off devices. Once the MiHome server in the cloud determines that the request was a valid and authenticated use of the API, it will send a message to the MiHome Gateway in your home. From there, a radio signal is used to control the end device. The system can work in the other direction too; end devices can send information via radio, such as power consumption. This information is stored in the Cloud, at the MiHome service database in the cloud. When a request arrives using the API, the MiHome service will look up the data in the database and send it as part of the HTTP response.


For this project, the API will be invoked by the Raspberry Pi whenever a button is pressed on the touchscreen. This is just an example. With some coding effort it is also possible to instruct the Pi to (say) send on/off commands at certain times; this would implement a service to make the home appear occupied when the home is actually empty for instance.


Building the Graphical User Interface (GUI)

There are many ways to achieve a nice user interface with modern Linux based systems. One popular way uses an existing application called OpenHAB which is intended for easy home automation deployments. There are many blog posts which describe how to install it and use the OpenHAB software application. I couldn’t find a working Energenie MiHome plugin however (perhaps it exists or will exist one day).


I decided to take a more general approach and create a lightweight custom application. After all, coding is part of the fun when developing your own home automation system. The custom application is not a large amount of code. In fact it is tiny. This has the benefit of being really easy to follow and modify, allowing people to heavily customize it because everyone's home and needs are unique. For instance, some users may not want a touchscreen. They could easily modify the code to instead take push-button input and show indications with LEDs. This is really easy to do by tweaking the custom app.


For this project, I decided to use JavaScript (one of the most popular languages for web development), and an environment or graphical programming add-on called Node-RED. When this environment is run on the Pi, the software creation is done (mostly) in a web browser using graphical blocks. With Node-RED, user interfaces and program behaviour is implemented by dragging blocks (called 'nodes' onto a blank canvas) and literally 'joining the dots' between nodes. Each node can be customised by double-clicking on it. Once the design is complete, the user interface is automatically made available at a URL such as http://xx.xx.xx.xx:8080/ui where xx.xx.xx.xx is the IP address of the Pi that is running Node-RED.


It is then a straightforward task to automatically start up a web browser on the Pi in full-screen mode, so that the user interface is the only thing visible. In other words, the Pi and touchscreen become a dedicated user interface device. Since web technologies are used, it means a mobile phone can also be used if you're not near the touchscreen.


In brief, Node-RED has nodes (blocks) for doing all sorts of things that are useful for a user interface. There are nodes for buttons and sliders and graphs that can be used to construct up the desired result. There are many nodes for application creation too. However Node-RED does not have an off-the-shelf node object that can control Energenie MiHome devices.


So, my first step was to design such a block and store it online so that anyone is free to use it. The instructions to install it are further below, in the 'Installing Node-RED' section. This means that when Node-RED is started and the web page for development is accessed, the left side blocks palette will contain a mihome node. It will automatically communicate using the Energenie Mihome API to the cloud service.


A one-time thing that needs to be done is to retrieve a key from the mihome cloud service. To do that, a special command called get_api_key is sent to the mihome node, along with the username and password that was used to register to the mihome service. The code does not store the password; just the username (i.e. e-mail address) and the returned API key is stored to a local file. If the Pi crashes or is powered off, the user does not need to re-enter the username and password; the key will be re-read from the file. For those that require a different strategy, it should be straightforward to modify the code.


The next section describes all these steps in detail.


Installing Node-RED

As root user (i.e. prepend sudo to the beginning of each command line, or follow the information at Accessing and Controlling the Pi in the section titled 'Enabling the root user account (superuser)' and then type su to become the root user, and type exit to revert to the previous 'pi' user if you originally logged in as the 'pi' user):


apt-get update
apt-get install npm
npm install node-red-dashboard


exit out of root user, and update node-red by typing:


bash <(curl -sL https://raw.githubusercontent.com/node-red/raspbian-deb-package/master/resources/update-nodejs-and-nodered)


It takes a long time (perhaps 15 minutes) to uninstall the earlier version and upgrade it, so take a break!

Afterwards, in the home user folder (/home/pi) become root user and then type:


npm install -g git+https://github.com/shabaz123/node-red-contrib-mihome.git


Exit out of root user and type:




After about ten seconds, you should see “Server now running at”.


Now in a browser, open up the web page http://xx.xx.xx.xx:1880 where xx.xx.xx.xx is the IP address of the Pi. You should see a Node-RED web page appear!


Using Node-RED

The CLI command node-red-start will have resulted in a web server running on the Pi at port 1880. Code is written (actually, mainly drawn graphically with a bit of configuration) in a web browser. The editor view is shown when any web browser (e.g. Chrome or Internet Explorer) is used to see the page at http://xx.xx.xx.xx:1880 where xx.xx.xx.xx is the IP address of the Pi.

Here is what it looks like:


In the left pane, (known as the palette), scroll down and confirm that you can see a node called mihome in the group under the title 'function' and a whole set of nodes suitable for user interfaces under the title ‘dashboard’. To save time finding a node in the palette, you could just type the name, e.g. mihome in the search bar as shown here.


What does this mean? Basically, it means that ‘mihome’ functionality is available for you to use in your graphically designed programs which are known as ‘flows’ in Node-RED. The flows will be created in the centre pane, known as the Flow Pane. It is tabbed and by default the blank canvass for the first flow (Flow 1) is presented. When creating programs, nodes would be dragged from the palette onto the flow pane. Then, connections would be made between nodes. Each node would be configured by clicking on it; a node configuration parameter window then appears, and help on the node appears in the tab marked Info. The program is run (or ‘deployed’) by clicking on a button marked Deploy shown in red on the top-right of the web page when a flow is created (by default it is grayed out).


An Example Home Automation Program

To help get started, I’ve created an example program sufficient to control home appliances with the MiHome solution. To obtain it, click to access the example code on github and then copy the program (press ctrl-A and then ctrl-C to copy the entire code into the clipboard). Next, go to the Node-Red web page and click on the menu on the top-right, and select Import->Clipboard. Click in the window and press ctrl-V to past it in there, and click Import. The code will appear graphically, attached to the mouse pointer! Click anywhere inside the web page to place it.

This is what the demo program looks like:


As you can see, it is split into three main parts; the top, the middle one and the bottom one. The middle part is used to control a fan.


The light-blue nodes on the left represent buttons (the actual buttons will look nicer; this is just a view of the graphical code). When a ‘Fan On’ or ‘Fan Off’ button is pressed, some signal or message is sent into the yellow mihome node. The mihome node is responsible for communicating to the Energenie MiHome cloud (which in turn will send a message to your MiHome Gateway box, which will then send a radio signal to the end appliance mains socket). The green node on the right doesn’t do much; it is used for debugging and will dump text into the ‘Debug’ tab in the editor.


The top flow looks near-identical, except that the buttons do not control a fan, but rather control a group of appliances. For example, you may have several lamps in a room and you may wish to define a group to control them all simultaneously.


In summary, the mihome node will recognize various commands and will make the appropriate API call to the cloud, to invoke the appropriate real-world action like switching on appliances.


The bottom flow is a bit different:


It doesn’t have a light-blue button node on the left. Instead it has a darker blue node which is known as an Inject node. It has the characteristic that it can repeatedly do something at regular intervals. It has been configured (by double-clicking on it) to send a message to the yellow mihome node every minute. Every minute it instructs the mihome node to query the Energenie MiHome cloud and find out how much power is being consumed by the fan appliance. When the cloud receives the request, it will send the request to the Energenie MiHome Gateway box which will transmit a radio signal to the fan mains socket, which will respond back with the result.


The pink/orange get real power node is a function node. By double-clicking on it within Node-RED, you’ll see that all it does is extract the ‘real power’ value out of all the information that is returned and discards the rest. The final node in the chain, the fan-power-history node is a chart node. It is responsible for graphing all the information it receives. The end result would be a chart that updates every minute.


To explore the yellow mihome node in a bit more detail, double-click on any preceeding node, to see what information is sent to the mihome node. For example, if you double-click on ‘Fan On’, you’ll see this information appear:


You can see that this is a button node (or more specifically ui_button), which is part of the dashboard collection of nodes in the palette. It basically will display a button on the screen. The button will be labelled “Fan On” and if the user clicks it, then a message or payload will be sent into the mihome node. The payload is partially shown on the screen, but click on the button marked ‘’ to see it fully. When you do that, you’ll see this text:


    "command": "subdevice_on",
    "objid": "65479"


The command indicates that this is something to be powered up, and the objid identifies what device should be powered up. That objid value 65479 happens to be an Energenie mains socket that I own, connected to a fan. In your home, every Energenie device will have its own unique ID, and they are very likely to be different to mine, although there could be overlap. So how does the mihome node know which device should be controlled, yours or mine?


The answer is, the mihome node uses an API key. This is unique and assigned whenever anyone creates an Energenie MiHome account. The API key can be obtained using the username and password that was used to set up the account. Code can be created to do that automatically, and then save it so that the Pi always uses the API key. For security reasons, I wanted it to prompt for the password, but not store the password. Only the e-mail address and API key are stored. To do that, I wanted an ‘admin’ screen on the user interface to allow the user to type in their credentials. This needs some additional code, which is explored next.


Building an Admin View

The Admin view is used to initially configure the Pi so that it has the API key to control your home. I created it as a separate program (flow) that happens to appear in the same user interface. You can obtain the code by clicking on the Menu button (top right) and selecting Flows->Add. You’ll see a Flow 2 tab appear with a blank canvass for your new flow. Then, click here to access the admin view code on github and select all (ctrl-A) and copy (ctrl-C)  the entire program there. Import it into the Node-RED editor as before (click on the Menu icon and then Import->Clipboard and paste it there using ctrl-V) and then click on Deploy.


Here is how it works; the top-left shows four user interface objects; the PIN, email and password nodes will be text boxes where the user can type in these parameters, and then click the OK box. All the information will have been collected up by the next node in the chain, called invoke_get_key which checks that all the text fields have been populated and that the PIN number is correct (the PIN is not used for security; it is just used to prevent young children in the home from accidentally wiping the API key, since the code will not perform a request to obtain an API key until the PIN is correctly entered; it needs the correct username and password to get the API key, but if the incorrect username and password was used then the API key would be wiped out, so the PIN prevents that from accidentally occurring if babies/young children start playing with the touchscreen). Since the PIN doesn’t play a security role, it is just hard-coded; you can edit it by double-clicking on the ‘invoke_get_key’ node. I won’t explain the rest of the flow, but it is simple and straightforward to explore by double-clicking on nodes.


The end result is that the flow will allow the API key to be retrieved and stored permanently on the Pi in a file in plain text format. The password is not stored as mentioned earlier. Since the API key is stored, if the Pi reboots, the user will not have to add the API key again.


When we examined the ‘Fan On’ node earlier, we saw that an identifier is used for the mains socket and in my case it happened to be 65479. To obtain such identifiers, we need to use the API to ask the Energenie MiHome cloud what devices exist in the home. The Scan Devices button is used to do that. It will make the appropriate API call and then show the list on the screen.


Working with the User Interface

So far, we have examined the flows for the example home automation system, and the Admin view. Once you’ve clicked Deploy, the code will be running. The user interface can be accessed by opening up a browser to

http://xx.xx.xx.xx:1880/ui and you’ll see this:


The buttons can be tapped to switch things on and off, and the chart shows the power consumption of the fan over time, allowing you to see when the fan was used (it was not used; it is cold here!).


The menu is the result of the code in Flow 1. But the system won’t work until it has been configured as in Flow 2. To do that, click on the menu icon (the three bars on the top-left, next to where it says “HAL 9000” and in the drop-down, select ‘Admin’, and you’ll see the code from Flow 2 executed:


Once you’ve entered the PIN (it is 1234 unless you edited the code as mentioned earlier) and e-mail address and password as used on the Energenie MiHome cloud service, click on OK and the system will retrieve the API key from the cloud service and store it locally.


You can’t control the fan, because it is set up for my fan mains socket identifier; you’d need to change it to suit your own device. To do that, click on Scan Devices and the system will show in a pop-up window a list of all Energenie devices you own, and their associated identifiers. Take a screen print of that, and you can use it for editing the flow to add buttons and groups for those devices. Once you’ve done that, click on Deploy again.


Theme Customizations

I didn’t like the color scheme, but thankfully it is possible to choose your own. To do that, go back into the editor view at http://xx.xx.xx.xx:1880 and then click on the Dashboard tab on the right as shown here:


You’ll see lots of options to adjust the ordering of buttons in the Layout sub-tab. Click on the Theme sub-tab and then set Style to custom and you’ll see all the elements that can have different colors. Once they have been adjusted to suit preferences, they can be saved under a custom name. I didn’t want the touchscreen to be entirely lit up brightly at night-time, so I chose a dark background for example.


Building a ‘kiosk mode’ for the Pi and Display

For practicality, the Pi needs to be set up so that Node-RED executes automatically when the Pi is powered up, and the web browser must be set up to auto-start too, set to fill the entire touch display with no border or URL/website address visible. In other words, we want a type of kiosk mode much like the interactive help/information screens in shopping centres/malls.


The steps to implement this on the Pi are scattered all over the Internet and a bit outdated; I had to spend some time working out the customisation that would suit the Pi and Capacitive Display, for implementing such a system.


First, stop Node-RED by issuing the command node-red-stop and then as root user, type the following:


systemctl enable nodered.service
systemctl start nodered.service


Now Node-RED will automatically start whenever the Pi is rebooted.


The next step is to invoke a browser whenever the Pi starts up.

To do this, as root user type raspi-config and then select Boot Options and then choose to auto-boot into text console as ‘pi’ user. Then at the main menu press the tab key until Finish is highlighted to save it, and select to reboot the box. When the Pi comes up, you should see the text-based command shell/prompt on the touchscreen display, and the user already logged in.


Also as root user, type the following:


apt-get install matchbox-keyboard


This will install a virtual keyboard for the times you may need to tap text on the display; it isn't used for this project but could be useful in future.


Also type:


apt-get install matchbox-window-manager


You’ll also need a better web browser than the default. I installed two more, so that there was some choice. Still as root user, type:


apt-get install midori
apt-get install chromium-browser


(If you test it from the command line and chromium-browser has an error concerning mmal_vc_init_fd, then you will need to issue rpi-update and then reboot the Pi).


As normal ‘pi’ user, create a file in the /home/pi folder called midori_start.sh containing the following:


matchbox-window-manager -use_cursor no&
echo "10" ; sleep 1
echo "20" ; sleep 1
echo "50" ; sleep 3
echo "80" ; sleep 3
echo "100" ; sleep 2
) |
zenity --progress \
  --title="Starting up" \
  --text="Please wait..." \
  --auto-close \

if [ "$?" = -1 ] ; then
        zenity --error \
          --text="Startup canceled."
midori -e Fullscreen -a


Create another file called chromium_start.sh with the same content, but replace the last line with:


chromium-browser --incognito --kiosk


Edit the /home/pi/.bashrc file and append the following:


if [ $(tty) == /dev/tty1 ]; then
  xinit ./domidori.sh


The result of all this is that when rebooted, the Pi will display a progress bar for ten seconds (allowing sufficient time for the Node-RED server to start up) and will then display a full-screen browser opened up at the correct URL for the user interface ( which is the local host address of the Pi).


Reboot the Pi (i.e. type reboot as root user) and the user interface should appear!


Preventing Display Blanking

After some minutes of inactivity, the display will blank by default. Depending on requirements this may be undesirable. To prevent the screen from blanking, issue the following commands.


Edit the midori_start.sh and chromium_start.sh files, and insert the following lines after the first line:


xset -dpms
xset s off



Auto-Blanking the Mouse Pointer

It could also be desirable to make the mouse pointer/cursor disappear from the screen. Type the following as root user:


apt-get install unclutter


Then, as the ‘pi’ user, edit the midori_start.sh and chromium_start.sh files and insert this just above the line containing the matchbox-window-manager text:


unclutter &


Reboot the Pi for these to take effect.


Auto Brightness for the Capacitive Touch Display

Although the kiosk mode implementation works fine, there is a lot that could be improved. For starters, the display is too bright in the evening. It would be possible to adjust the brightness level based on time, but I felt it may be better to just measure the brightness using a light dependent resistor (LDR).


The capacitive touch display brightness level is controlled using the following command line as root user:


echo xxx > /sys/class/backlight/rpi_backlight/brightness


where xxx is a number between 0 and 255 (a value of about 20 is suitable for night-time use, and 255 can be used for a bright screen during the day).


To automate this, a couple of scripts were created in the /home/pi folder. As the ‘pi’ user, create a file called set_bright.sh containing the following:


sudo echo 255 | sudo tee /sys/class/backlight/rpi_backlight/brightness > /dev/null


Do the same for a file called set_dim.sh but set the value to 20.


Next, type:


chmod 755 set_bright.sh
chmod 755 set_dim.sh


In order to invoke these scripts, a new flow is created in Node-RED. Click here to access the auto brightness source code on github.


Once it has been added to Node-RED, click on Deploy to activate it.

The flow looks like this:


The left node, called dark_detect, is configured as shown below (double-click on it within Node-RED to see this):


The dark_detect node will generate a message of value 1 whenever the Raspberry Pi’s 40-way header pin 7 (GPIO 4) goes high.

A small circuit was constructed to generate a logic level ‘1’ whenever it goes dark:


The circuit consists of a Schmitt trigger inverter integrated circuitSchmitt trigger inverter integrated circuit, a light dependent resistorlight dependent resistor, a 50k trimmer variable resistor50k trimmer variable resistor and a 100nF capacitor100nF capacitor. The trimmer resistor can be adjusted to suit the home lighting level.


It worked well. When the room lighting is reduced, the display automatically dims to a very comfortable level.



It is possible to create a nice touchscreen based user interface for home automation with the Pi. The programming effort is low using Node-RED. It is possible to create code ‘flows’ with graphical ‘node’ objects that can represent buttons on the screen. The functionality that interacts with the Energenie MiHome service is contained in a ‘mihome node’ graphical object that is inserted into the code flow. It will automatically send the appropriate commands to the Energenie MiHome cloud service, which will in turn send a message to the MiHome Gateway that will issue a radio message to control the desired home appliance. Monitoring capability is possible too; an example showing appliance energy consumption over time is contained in the code.


The solution with the Pi is reasonably secure; no password is stored on the Pi, the system stores an API key instead.


Finally a small circuit was constructed and an additional code flow was created that would automatically dim the display backlight when the home lighting is reduced.


I hope the information was useful; these two blog post were rather long, but I wanted it to be detailed so that anyone can implement a home automation solution.