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.

Kosten en Baten van PV zonnepanelen

Bij deze een aangepaste versie van de excel-sheet met daarin een berekening van de kosten en baten van PV-zonnepanelen. De opgenomen berekeningen kunnen helpen bij het overwegen van de aanschaf van zonnepanelen en geven antwoord op de volgende vragen:

  • Wat is de gemiddelde stroomprijs voor stroom van zonnepanelen?
  • Wanneer is de aanschaf van zonnepanelen weer terugverdiend?

Voor het maken van een berekening, moeten een aantal gegevens in worden ingevuld:

  • Prijzen van aanschaf, plus installatie, minus subsidie van de zonnepanelen.
  • Verwachte opbrengst in kWh per jaar. Typisch 80% á 90% van het opgegeven vermogen, afhankelijk van de installatie en de ligging van de panelen.
  • Het rentepercentage in het geval dat het geld op de bank was gezet in plaats van zonnepanelen te kopen (bijvoorbeeld 4% voor een deposito van 10 jaar)
  • Stroomprijs, en de ontwikkeling daarvan (bijvoorbeeld 0.23 met een jaarlijkse groei van 2.5%)
  • Afschrijftermijn: de periode waarover de kosten van de zonnepanelen worden afgeschreven, en waarvan verwacht wordt dat de zonnepanelen het doen (bijvoorbeeld 25 jaar)

Download de excel-sheet, en pas de gegevens aan naar je eigen situatie.,

Download link: Kosten-Baten-Zonnepanelen

N.B. De ontwikkeling van de stroomprijs van de afgelopen jaren is ook ingevoegd.

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