Episode 005 - ESP8266 webserver, new products, and more!


New format show today! We’ll be looking at what’s awesome in the Maker-sphere this week, answering your questions, and showing off some new products.

New Products


This bonkers low price Wifi-enabled micro has a compact web framework you can find here: https://github.com/solusipse/ureq

It’s as simple as:

ureq_serve("/", s_home, GET);

char *s_home() {
    return "<h1>Hello, World!</h1>";

This page breaks down how the live test performed: http://esp8266.solusipse.net/

Find the module on our shop here: https://shop.pimoroni.com/products/esp8266-smt-module-esp-12

Gpio Zero

You can find the GitHub repository here: https://github.com/RPi-Distro/python-gpiozero

Alex of Raspi.Tv has a great intro to GPIO Zero and an interview with Ben: http://raspi.tv/2015/gpio-zero-introduction


I really like the stuff you guys make, and I sometimes think I should contribute back. Have you thought about having the tutorials on learn.pimoroni.com open to submissions and/or available on github like with the code? Also, while we’re on the topic of code, why on EARTH would you use tabs in python source code?! ;-)

Episode 006 - Undefined

Whoops! Sorry we totally missed your question, but it’s a really good question so we’ll save it for a proper answer in BilgeTank 006!

On the subject of tabs… yeah… hides I’m currently going through our libraries and tidying them up to fix problems like this.


Hey, don’t worry about it!

I wouldn’t care so much about the tab issue if it weren’t for the fact that almost all other projects I’ve come across in the ten years I’ve been coding python use spaces. :) If you are working on a general overhaul of the code, why not create issues on github so the rest of us can pitch in?

In fact there’s a tool called reindent.py in the python source tree that might help you convert the source code.



Just a quick note to add that, at least from my perspective, gpiozero owes quite a bit to the Explorer HAT. Having used them extensively in picademy I was thoroughly impressed by the Explorer HAT API, and that design’s informed many of the decisions in my bits of gpiozero.

Oh, and there is a when_pressed in the Button class - when_activated is the generic name for the hook in the base InputDevice class which Button aliases to when_pressed (I confess to yelling at the monitor during that segment: “look to the right!” because the dir output shows it right next to when_activated ;)

I should add that I’ve recently patched the objects in gpiozero so they’re all using __slots__. That means if you try and assign to a non-existent property you’ll get an AttributeError. So if you ever think “why isn’t this when_pressed?” just try it: if it’s right, it’ll work, if it’s wrong it won’t silently make you think it’s right (not sure if that patch is in the current release, but it’ll be in the next). I must get around to doing something similar for picamera…

Anyway, off to hack on more gpiozero stuff (and buy a set of those lenses!)



Hahaha! You weren’t the only one. I got told

Our jokes about GPIO Zero being derivative are all in jest, of course, it’s a throughly brilliant library that we wholly support. The only reason I haven’t contributed beyond the odd comment/question is a mix of lack of time, and right now I think you guys have got it and there’s nothing I could add!

I’m not familiar with __slots__ but that’s something I’ll have to look into. Explorer HAT/Pibrella do a lot of weird, weird stuff which possibly should have me banned from Python forever.

I am definitely behind the idea of remixing our software libraries into GPIO Zero versions if it makes sense. It might, in fact, be a nice way to provide a minimal API for tinkerers.


Slots are … well, they’re a superficially simple concept but a horribly complicated one when you get under the covers (as I’m having to do at the moment in gpiozero). Anyway, they’re the sort of thing I’d normally avoid (because of the underlying complexity and the way it can bite you in the ass when you least expect it).

However, at a recent picademy I was having a chat with an Australian chap (James - if you’re reading this, my humble apologies - I can’t remember your last name!) who made a compelling case that one of the nastiest bits in Python for learners is the fact that you can set arbitrary attributes on instances without error. So, in his case he was playing around with picamera and wound up setting something incorrectly, let’s say resoluton instead of resolution (again, I can’t remember!) and of course the code didn’t complain at all when run, it just didn’t do the right thing.

Now, fixing the attributes of a class in an API (especially one like PiCamera) with __slots__ certainly complicates things for the hardened pro (there are certain sub-classing scenarios it can screw with, particularly if you get into multiple inheritance) but let’s face it: no newbie is going to care about that, and I doubt most advanced coders would be bothered either (very few people ever subclass PiCamera). But, it suddenly makes it throw an error every time you set an attribute with a spelling mistake instead of silently doing the wrong thing which is much better from a learning perspective.

So, I was utterly convinced, and set about applying this to the next project I was hacking on (gpiozero … sorry James, I’ll get around to picamera when I can!) and, lo and behold, the underlying complexities of slots have just bitten me in the ass. I’m not going to drop the idea of having it throw AttributeError when misspelt attributes are set, because I’m convinced it’s a good one, but I’m probably going to have to come up with another way of doing it!

Anyway, that’s quite enough rambling from me! On with the hacking…


P.S. Can’t say I’ve spotted any serious ugliness in Explorer HAT (except the help() mechanism, but then that’s deficient in gpiozero too because, so far, I’ve failed to convince Ben that reST is the only sane option for “proper” API docs ;). Haven’t looked under the hood of Pibrella yet though!