Author: Wido den Hollander

How I built my 3-phase Open EVSE

Ever since I posted on my blog that I built my own Open EVSE for my future Tesla Model S I’m getting a lot of e-mails from people asking how I build it.

A couple of notes to everybody who wants to build one:

I’m using a Open EVSE board with a modified firmware
I modified the firmware so that with the Advanced Power Supply it will switch to level 2 charging when it senses 230V on L1.

The source code can be found on my Github account.

I also have two compiled versions (with LCD support) available (both from 01-09-2012):

You can program the EVSE using ‘avrdude’ and the right programmer.

The relais I’m using is a 40A 4p
I’m using a Hager ESL440S relais.

This relais has 4 poles and works on 12V AC or DC.

There is a second relais which switches on my main relais
The main relais (Hager ESL440S) works on 12V DC, but pulls about 1000mA to switch on.

That is a bit to much for the Open EVSE board, so I had to buy a 12V DC transformer and a second smaller relais. When Open EVSE board switches on the small relais, it switches on the main relais by using the external 12V transformer.

If you go to page 8 of the PDF I wrote you can see these components.

In the casing where the Open EVSE board is you can see the small relais on the left.

The external 12V DC power supply is in the distribution panel on the right and is on the left of the main relais. You can see the green and red LED on it.

I limited my EVSE to 30A
I limited the pilot signal to 30A. 32A would stress some fuses in the distribution panel in my house, since that 32A relais also provides power to the TL-lights in my shed. So I turned the EVSE down to 30A instead of 32A. Technically I could use 32A, but 30A was a safe bet in this case.

1-phase of 3-phase doesn’t matter
The EVSE itself doesn’t know anything about 1-phase or 3-phase. When a car connects and talks to the EVSE it requests power, when all the criteria match the EVSE turns on the relais.

The car then senses 3-phases and will use them if the charger supports it. The EVSE has nothing to do with that.

To conclude:

  • Read the PDF I wrote.
  • For the EVSE 3-phase or 1-phase doesn’t matter. It just switches on a relais.
  • Read the Open EVSE website about J1772, programming, etc, etc

Redundant Ceph monitors with Round Robin DNS

One of the unique features of Ceph is that it can be build without any Single Point of Failure. No single machine will take your cluster down when designed properly.

Ceph’s monitors play a crucial part in this. To make them redundant you want a odd number of monitors, where 3 is more then sufficient for most clusters.

When librados (The RADOS client) reads the ceph.conf it can read something like:

[mon.a]
  mon addr = 192.168.0.1:6789

[mon.b]
  mon addr = 192.168.0.2:6789

[mon.c]
  mon addr = 192.168.0.3:6789

The problem is that when working with for example Apache CloudStack you can’t have it read a ceph.conf nor does CloudStack support multiple Ceph monitors.

The reason behind this is that CloudStack passes storage pools in the form or URIs internally, for example: rbd://1.2.3.4:6789/mypool

So you’d be stuck with a single monitor in CloudStack. It’s not a disaster, since when a client successfully connects to the Ceph cluster it will receive a monitor map which tells it which other monitors are available should the one he’s connected to fail. But when you want to connect when that specific monitor is down you have a problem.

A solution to this is to create a Round Robin DNS record with all your monitors in it:

monitor.ceph.lan. A 192.168.0.1
monitor.ceph.lan. A 192.168.0.2
monitor.ceph.lan. A 192.168.0.3

You can have your librados client connect to “monitor.ceph.lan” and it will connect to one of the monitors listed in that A record. Is one of the monitors down? It will connect to another one.

This doesn’t only work with CloudStack, but it works with any RADOS client like Qemu, libvirt, phprados, rados-java, python-rados, etc, etc. Anything that connects via librados.

P.S.: Ceph fully (!) supports IPv6, so you can also create a Round Robin AAAA-record 🙂

CloudStack: Zone X is is not ready to launch console proxy yet

As you might know, I’m a committer in the Apache CloudStack project and I work on it on a daily basis.

I have a couple of development setups running and I upgraded one of them (where I do all my Ceph development) from 4.0 to 4.1 (isn’t out yet) and suddenly I got this message in my logs:

Zone 1 is not ready to launch console proxy yet

That log line didn’t tell me that much, so I started digging through the code as of WHY my Zone wasn’t ready, since it was working under 4.0.

It turns out that my global setting “secondary.storage.vm” wasn’t set to true and that caused my KVM zone not to work.

This setting can’t be changed through the Web UI (not sure why) and I had to change it in the database instead. After setting it to “true” my System VMs began to start again and all worked just fine.

It seems this was legacy on my end since the upgrade process doesn’t touch this setting at all. I’m adding some extra debugging to the code to make it a bit more clear as of WHY your zone isn’t ready.

Should you ever encounter this one, verify this setting.