Perl OpenSSL on OS X

Note to self for later reference: I regularly update my Dist::Zilla install on my computer (running OS X 10.9 Maverick). After the last update suddenly the [GitHub::Meta] plugin failed with the following error:


[GitHub::Meta] Getting GitHub repository info
[GitHub::Meta] Err: SSL connection failed for api.github.com: Client side SNI not supported for this openssl

The reason this fails is because the system-provided openssl < 1.0 does not support the client side SNI. Upgrading OpenSSL to a more recent version easily fixes this:


brew install openssl

Fixing SSL problems with Dist::Zilla and github

I’m using Dist::Zilla extensively to test/release the Perl code I write.

I had to fix a bug on one of the modules I wrote and I ran into this error when I tried ‘dist test’ on the freshly checked out repo:

[GitHub::Meta] Getting GitHub repository info
[GitHub::Meta] Err:  SSL connection failed for api.github.com: Client side SNI not supported for this openssl

After some searching I found that IO::Socket::SSL throws this error when it tries to use openssl releases from before the 1.0 release. I’m on OS X 10.9 so this makes sense as it comes with openssl v0.9.8.

Onto homebrew to install openssl, then link it so it appears in /usr/local/bin

$ which openssl
/usr/local/bin/openssl
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

But alas, ‘dzil test’ is still not working.

Looking into the Dist::Zilla::Plugins::GitHub::Meta code I see this error originates from a HTTP::Tiny call. Now, how to tell HTTP::Tiny to use the recent openssl?

I did

cpanm IO::Socket::SSL
cpanm Net::SSLeay
cpanm Net::HTTP
cpanm HTTP::Tiny

And after the last module install all is working fine again.

I have no time to investigate this further currently, but maybe it is of use to somebody else when the same error pops up.

Ultracapacitor capacity verification over time

A few years ago I installed a wireless, self-powered light sensor in my garden to determine when it is time to close down our electric blinds. It uses ultracapacitors to store energy during the day to be able to continue transmitting sensor status at night.

I monitored the capacitor voltage to be able to track the performance of the ultracap over time. The question was how it would behave during cold winter nights and hot summer days, and also if and how much the capacity of the component would be influenced by aging.

The first months the system worked fine, the ultracap got charged by the solar panel when the sun was shining, and the sensor node would happily bridge the night until sunrise, with even some juice left in the ultracap (the capacitor voltage never went below 3V). Over the time of a few months, the voltage was dropping further and further every night. A sign that the capacity of the ultracap was decreasing, as I assumed that the power consumption of the electronics would not change (the electronics are mounted in a water/airtight enclosure and were not touched).

After a year, I decided to add a second ultracap to help bridging nights. This helped temporarily, but after a few months the system voltage reached the minimum working voltage (2.5V) again every night.

After three years and after posting a message on jeelabs.org on the influence of aging on an ultracapacitor, I decided to dismantle the sensor node to actually measure the remaining capacitance of the ultracap.

Continue reading Ultracapacitor capacity verification over time