Home Automation Spaghetti

Lightweight message brokers like mosquitto, that makes use of the MQTT are of great use in the world of home automation and the Internet-of-Things. With MQTT, functionality like interfacing with specific hardware, interfacing with webservices, reading/writing databases can be dived into separate programs/scripts instead of putting everything together in a complex monolithic application. This provides flexibility, and a means to extend existing functionality by listening in on existing MQTT topics, that already being published.

What I like about a lightweight message bus is illustrated by the following example which I’m actually using at the moment. One program (a perl script) is connected to the OVMS webservice, where it listens to updates on the status of my electric vehicle, a Twizy, and publishes this data   (location, state of charge, speed, …) in the form of a JSON encoded object via MQTT. Another program, which is driving a LED matrix display (located in the kitchen), is subscribed to these MQTT messages, and uses them to display the actual charging state on the display.


UntitledWith this in place, It is possible to add a third program that writes all data to file, a fourth program that switches a wall outlet when the state-of-charge has reached 100%, a fifth program that plays an audible message when the Twizy is arriving home, a sixth .. etc. etc. While this setup is great, and is very, very flexible, the relation and dependencies between publishers and subscribers if written in program code, and therefore difficult to understand.

And that’s where Node-RED come into the picture. Node-RED is visual tool that displays the process flow between (the spaghetti) between a number of building blocks. With Node-RED it is possible to visually design a flow that, in the context of the previous example, trigger on messages from the Twizy, transform these in to readable text, and publish them to a LED matrix output. It is still spaghetti, but now it’s visible. A sample flow that I built recently is that where updates from the Twizy (received through MQTT, which is the block on the left), are routed based on changes in distance or charging state (blocks DISTANCE and STATE), transformed into a set of different messages, and then publised to a Text-to-speed engine (SONOS), or mobile phone (with Notify My Android).

















Twizy verkoopaantallen

Bij deze weer een update op een eerdere post van de verkoopaantallen van de Renault Twizy. Inmiddels lijkt de verkoop wel weer wat aangetrokken, maar niet zozeer als tijdens de eerste maanden van 2012. Het lijkt mij ook sterk als de verkoopaantallen de 10.000 gaan halen zoals tijdens het eerste jaar. In Nederland zijn er nu 267 Twizy’s verkocht, en wederom doet duitsland het beter dan Frankrijk zelf.

De Twizy, een smartphone op wielen?

Sommigen noemen de Tesla model S de ipad op wielen. Ik noem de Renault Twizy de smartphone op wielen.

Onder andere Maarten Steinbuch (professor autotechniek aan de TUE) noemde de auto van de toekomst een ipad op wielen. Een auto volgeladen met intelligente apps die zich zoveel mogelijk aan de bestuurder en zijn/haar wensen aanpast. Dan denk ik natuurlijk aan de Tesla model S met het grote touchscreen op de middenconsole.

Maar dan de Twizy, waar is die het beste mee vergelijken? Met behulp OVMS is de Twizy digitaal helemaal binnenste-buiten te keren. Als je wil weten hoe het met de Twizy gaat kijk je niet op het dashboard, maar op het scherm van je telefoon. Daarom is de Twizy voor mij een smartphone op wielen.


Range Anxiety

Through OVMS it is possible to log the status (range, location, battery condition) of an electric vehicle (in our case a Renault Twizy). With all this data at hand, it is possible to make all sorts of analysis, and as a result get more insight in all aspects of electric mobility.

To get more insight in the area that can be effectively reached with our Twizy, I made a contourplot where the SOC (state of charge, varies between 0% for empty and 100% for a full battery) is plotted as a function of geographical location. Source data is from three weeks Twizy driving. The plot below is a first result.

State of Charge contourplot (click to enlarge)

In the plot above the red areas are regions where more charge is available. The yellow areas are regions with less charge abailable. The small circles in the plot are popuplar charging locations (e.g. home, work).

Unfortunately, the program that created the contourplot from the raw data (latitude, longitude, SOC) made a cutt-off on the side (top, right and bottom left). This is probably caused by not enough data in these areas.

Connecting the Twizy

A post on the twizyowners forum about timed charging the Twizy triggered me to document me recent progress in Twizy and home automation hacking and write this post. In this post i’m trying to explain how I connected the Twizy to my home automation system, and controlled charging of the Twizy. Until recently we just plugged in the AC cable of the Twizy when arriving at home (in fact we still do). But what annoyed me was that a ventilator kept on running for hours and hours while Twizy charging was completed. What I wanted to do was disconnect the plug from the socket when charging was finished to avoid (from my perspective) unneeded energy consumption. The most simple and robust method for achieving this is walk to the garage and unplug the Twizy. I decided to do it automagically via home automation. A complete schematic of the whole setup is depicted below.

Connecting the Twizy to a home automation system can be approached from two perspectives: 1) receiving status updates from the Twizy and 2) controlling the Twizy

Receiving status updates from the Twizy

Our Twizy is extended with a so called OVMS Module. The OVMS module is a small device (with GPS and GPRS) that talks to the CAN-bus of the Twizy. OVMS stands for the openvehicle open source hardware/software project. Details on this project and how to get the OVMS module are available on the open vehicles website (http://www.openvehicles.com).

By default the OVMS module is configured to log status updates (GPS location, State of charge, Temperature, Speed, Odometer, and much more) over the Internet to a central server hosted by the open vehicles project. When communicating with the Twizy, you connect to the OVMS server instead of the car. A sample client application in Perl is provided on the github site of the project (client_app.pl). In order to get this client running you probably need a Linux compatible system, install the required perl modules, and create a small configuration file (ovms_client.conf) where you must enter the location of the OVMS server and your OVMS module credentials. The client_app program does not really ‘do’ something. When started, it connects to the OVMS server, decodes and prints out status update messages from the Twizy.

In order to connect the Twizy to my home automation system I modified the client_app.pl script so that the content of messages is decoded into understandable data (GPS location, charge status, speed, odometer, etc) and the the Twizy status is made available to other applications via an MQTT message broker (mosquitto). My modifications to the script can be downloaded here (client_app_mqtt.zip).

Control the Twizy

For now the only Twizy control I need is switching the AC socket for charging. For this purpose I make use of a Conrad/ELV FS20 wireless switching socket (link). This switch is triggered by an 868Mhz OOK encoded protocol. Luckily, the JeeLink is capable of transmitting this protocol.

The OVMS client application contains a rule that when the state of charge (SOC) reaches 100%, an MQTT message with the topic ‘FS20’ is being sent. The contents of the message is a JSON encoded structure with the details of the FS20 message (address of the socket and command 0 for off and 17 for on)

if ( $status->{soc} == 100 ) {
} else {

The JeeLink – MQTT bridge script (see this post)  subscribes to the ‘FS20’ MQTT messages and forwards them to the JeeLink. A modified version of the JeeLink-MQTT bridge which encodes FS20 messages is available here. The JeeLink then transmits a FS20 protocol message and the socket is switched.

A perl JeeNode MQTT bridge

This is a perl implementation of a bridge between the MQTT pub/sub message bus and the JeeNode wireless network. This MQTT bridge makes it a lot easier for me to implement home automation logic. Where device specific features (heating system, radiator valves,. washing machine, energy metering, electric vehicle, status display) are implemented most with JeeNodes, the logic that binds everything together (and makes home automation working) can be done in a higher level scripting or programming language.

An example of this logic i’m using is to switch off an AC wall outlet at the moment our electric vehicle reports that it is fully charged: Our EV is monitored through a client script watching the OVMS server (see my previous post). MQTT messages containing the battery status, car location, current speed, odometer are sent at regular intervals. At the moment the battery capacity reaches 100%, an MQTT message is sent which triggers the car charger AC outlet to be switched off.

The bridge implementation can be used to forward packets in both directions: MQTT messages of specific topics are forwarded as packets in the wireless JeeNode network. Packets received from other JeeNodes are forwarded as MQTT messages.

The MQTT bridge implementation is written in perl and should run on at least any Linux like server. makes use of two seperate threads, one for communicating with a JeeLink attached to a USB port. The JeeLink runs the standard RF12demo sketch. The second thread waits for subscribed MQTT messages sent by a MQTT server (in my case mosquitto) and forwards these via a queue to the first thread.

The perl script depends on several perl modules, most important are WebSphere::MQTT::Client, and Device::SerialPort. Both can be installed through the commands.

perl -MCPAN -e "install Device::SerialPort"
perl -MCPAN -e "install WebSphere::MQTT::Client"

The perl script can be downloaded here








Wat hebben de Tesla roadster en de Renault Twizy met elkaar gemeen?

De Tesla Roadster en de Renault Twizy zijn twee elektrische auto’s die op het eerste gezicht echt helemaal niets delen… behalve dan dat ze beide elektrisch zijn aangedreven. Toch is er iets wat beide auto’s met elkaar delen. Dat iets is het ‘Open Vehicle Monitoring System’ oftewel OVMS. OVMS is een systeem bestaande uit hardware en software waarmee het mogelijk is om op afstand met een auto te communiceren. OVMS is origineel ontwikkeld voor de Tesla roadster, en daarna ook geschikt gemaakt voor de Renault Twizy. Zo is het bijvoorbeeld mogelijk om met behulp van je smartphone (met een OVMS app) de actuele laadtoestand van de accu ,altijd handig bij een elektrische auto, inn te zien te zien. Het scherm voor de batterijstatus van onze Renault Twizy ziet er dan als volgt uit:

OVMS bestaat uit een module (een kastje met daarin een microcontroller, een GPS en een GPRS module) die in de auto wordt aangesloten op de OBDII diagnose interface. De OVMS module inclusief de benodige kabels (connector en antennes) kost ongeveer EUR 130 inclusief verzendkosten. Deze connector is aanwezig in veel auto’s, en ook de Tesla en de Twizy. De OVMS module leest via de diagnose interface wordt de actuele status van de auto uitgelezen en via de GPRS module doorgestuurd naar een centrale server op Internet. Vanaf dat moment is het mogelijk om met een smartphone app de toestand en locatie van je auto in te zien. OVMS is helemaal open source. Het is dus mogelijk om de firmware op de module aan te passen.

Voor meer informatie: http://www.openvehicles.com




Twizy verkoopaantallen

Dit weekend kwam in het nieuws dat de elektrische auto dreigt te floppen in duitsland (link). Voor mij de reden om eens naar de verkoopaantallen van elektrische auto’s te kijken, en wel de Renault Twizy (link) waar we recent een proefrit in hebben gemaakt (link).

Gelukkig heeft Renault de verkoopcijfers, waaronder de Twizy, netjes op haar website beschikbaar (link). Om een indruk te krijgen hoe goed het gaat met de verkoop zijn de maandelijkse verkoopaantallen tegen de tijd uitgezet. Voor de vergelijking heb ik de maandelijkse verkoopaantallen in Frankrijk en Duitsland er even naastgezet.

Wat me direct opvalt is dat de verkoop aan het eind van het jaar compleet is ingestort (is dat normaal voor autoverkopen?). De Twizy, met open ramen, zou naar verwachten het juist goed doen in de wat warmere landen. Maar Duitsland doet het qua verkoop zeker niet onder voor Frankrijk. In totaal zijn er in 2012 bijna 10.000 Twizy’s verkocht wat haar (voor 2012) de best verkopende elektrische auto heeft gemaakt.

Update Januari 2013: De verkoop van de Twizy is “geexplodeerd” in Nederland. Het aantal verkochte autos is bijna verdubbeld ten opzichte van december 2012. Het gaat echter nog steeds om zeer lage aantallen (22 tegen 13). De verkoop in Duitsland, Frankrijk en de rest van de wereld is verder gedaald (ruwweg gehalveerd).