A presentation at IOT London, about http://exciting.io/printer, the IoT printer platform I built a few years ago

1. “An open-source
distributed platform
for IoT printers”
James Adam - @lazyatom - @freerange
If you’re bored:
bit.ly/printermail :: bit.ly/printerpaint
Text
My first time at an IoT meetup
I am not an expert
I don’t have any hardware expertise

2. Disclaimer:
I don’t know what I
am doing.
I don’t have any hardware expertise
last time I really worked with electronics was in school
really only here to get some help from you
all started with Timmy

3. Project Codename:
Timmy Printface
gofreerange.com/timmy
all started with Timmy
#blue, which included an API for accessing SMS messages
fun way to demonstrate the API
messages normally trapped on your phone

4. Timmy - April 2011
messages normally trapped on your phone
wrote a very simple script using the API, set up a webcam, and tweeted a phone number
quite a good response

5. quite a good response
lots of people seemed to enjoy having their message printed
not sure why - novelty of the physical?

6. some people did put in a lot of effort though
nice pieces of ASCII art
all very much inspired by Tom Taylor’s microprinter

7. Tom Taylor’s Microprinter, 2009
(photo by Tom Armitage)
all very much inspired by Tom Taylor’s microprinter
prints daily reports
if you look closely, it’s actually the same printer. I borrowed it from around the corner.
took Timmy to Interesting

8. Timmy at Interesting ’11
(Photo by Roo Reynolds)
took Timmy to Interesting
text messages, tried to read the messages (OCR) and print replies
also printed instagrams from attendees

9. ASCII, obviously
they look like nonsense unless you know what the picture is
anyway, people seemed to get the same kick out of it as earlier -- still not sure why
but the problem is that it was a hack

10. The problem with
hacks is that they are
hacky.
but the problem is that it was a hack
I’m a developer, I like things that are simple, clean, elegant, reliable
I have a learned aversion to things that are unreliable
Timmy was very unreliable

11. Timmy was very unreliable
bugs in the code to say the least
also, Timmy was a bit of a lie

12. also, Timmy was a bit of a lie, because he was really just tethered to a computer
and computers aren’t cool.
also, look at all the wires! jammed into a breadboard
just waiting to be accidentally pulled out

13. Timmy at Interesting ’11
(Photo by Roo Reynolds)
even at interesting, look, a computer behind the scenes
To do anything else with Timmy, it would always just be a hack on top of a hack
dusting off scripts and trying to figure out how they all fit together
so Timmy went on a shelf

14. so Timmy went on a shelf
It still bothered me that it was so hacky.
spent months idly wondering how to “finish it”.
anyway, that’s a long story

15. gofreerange.com/hello-printer
anyway, quite a long story
if you’re interested how I got from there to here, there’s a blog post
The only real motivation here was to try and assuage my developer guilt

16. The Goal:
Make it less of a
giant ugly hack.
The only real motivation here was to try and assuage my developer guilt
However, over the past few months, a few happy accidents happened
found myself with something maybe a bit interesting.
Beyond Timmy.

17. Printer.
gofreerange.com/printer
“An open source toolkit of exploring the possibilities of internet-of-things printing”
project page, best place to start reading about it.
in a nutshell:
very simple printer that anyone can put together

18. Cheap printer
Ethernet shield
Arduino
Ethernet shield
Some LEDs, etc
A very simple printer that anyone can put together themselves
buy everything here from sparkfun or adafruit or cool components
follow the online instructions

19. follow the online instructions
very simple to put together
guide with lots of pictures
very simple Arduino sketch too

20. Poll a special URL
Emit data via serial
Manage some LEDs
and maybe a
button?
a very simple sketch
only does three things
it’s polling a backend server

21. arduino is polling a backend server
acts as the glue between content and the printers
real job is to turn content into something the printer can understand

22. the server’s real job is to turn content into data the printer can use
can transform pretty much any appropriately-formatted HTML page into data that the printer can directly use
so there are three basic components to the system

23. three basic components to the system
the content service only cares about the content itself

24. Content Services
produce HTML
pages, and post
URLs for those
pages to Backend
Servers.
content services are only concerned with specific content. Doesn’t care about printers.
could be static, could be dynamic, could be user-specific or generic
just HTML, reachable via URLs
when service has some new content, it should POST a URL to the backend server

25. Backend
Servers
expect
URLs to
HTML
pages...
... and
converts
them into
1-bit
images,
then serial
commands
backend server then retrieves that page
turns it into an image using headless browser (PhantomJS)
turns that into a 1-bit image -- array of bits
and knows how to translate that into a stream of serial commands for the printer

26. Printers download
serial commands
and send them
directly to printer
peripherals.
the printer polls the backend server
when some content is available, it downloads it
caches it on an SD card (could be >100k)
streams bytes to the printer via serial
might seem complicated, but there are three things that make this work really well. first is that HTML is easy

27. Content generation is easy in HTML
most printers support ASCII bold, inverse, underline, some graphical characters
quite hard to program them to print custom graphics
it’s relatively easy to use HTML to make something that looks great
much more flexible with how information is presented
the novelty of printing ASCII wears off; maybe the novelty of cute graphics will last longer?
second is that responsibility for making content doesn’t all fall to me

28. Content can come from many places
there’s no need for centralised content.
as long as its reachable via a URL, it can be sent to any printer.
content production is distributed
more than one independent content service

29. http://backend1/print/abc123
Content service A - TODOs
Content service B - weather
Don’t need to know anything about each other
As long as they both know the URL for a printer, they can both produce output on it
to try and demonstrate, I wrote a few simple content services

30. bit.ly/printermail
first sample content service
sending simple messages
it’s simple, really just to demonstrate the principle
anyone with a printer can register one it and people can send them content

31. bit.ly/printerpaint
second content service lets you draw pictures
completely separate application from the messages one
uses HTML5 canvas to let people draw a picture
backend server takes care of turning the HTML into something the printer can understand
tweeted the URLs for these services

32. tweeted the URLs
now have metres of pictures and messages from people
(mostly nice; only a few drawings of genitalia)
built a third example service

33. built a third content service that gets the weather using Wunderground
example of automated content (no human triggering it)
sends the forecast for printing at 8am every morning
Icons drawing using HTML5 canvas, but could as easily be images
third interesting aspect of the system is not only is the content decentralised

34. No central server either
there doesn’t need to be a central responsibility for keeping the system running
just like there can be multiple independent content services...

35. Two Backend
Servers using
the same
Content Service
... there can be multiple independent backend servers too.
If you’re paranoid, you can run your own;
If we shut down the one running this printer, another one can replace it and run as many printers as it likes
completely decentralised.
So, what’s the plan?

36. •Other people are better at design
than I am;
•Other people have better ideas for
content that I have;
•So: make it easy for them to produce
and print content, from which
everyone benefits.
The Plan:
Just a software developer, I don’t have a lot of design talent
I probably don’t have the best ideas for what would be useful to print
But maybe you do.
Anything you make, you can potentially share (deploy to heroku, let other people add their printer URLs)
I am really excited to see what other people might make (that I can then use!)
Some people already have

37. Some other people have already been experimenting
Really interesting looking weather forecast from Denmark

38. Another guy is printing out stats from their existing graphing system
(needs to tweak his printer a bit)
What’s really exciting is seeing what other people produce.

39. •HTTP Header parsing
•Running out of space on Arduino
•Reliable networking is hard
•Programming in C is a pain in the
fucking ass.
TODO
Plenty still to do
Make the Arduino slightly smarter (print now header, status codes)
Sketch size has almost reached 32k capacity of the Arduino
Really hard to make Arduino networking reliable when you’re downloading more than a few kilboytes
Programming in Ruby is much easier than this :-/

40. More information
gofreerange.com/printer
gofreerange.com/hello-printer
github.com/freerange/printer
.../wiki
.../issues
Anyway, if you’d like to know more
- project page
- introductory blog post
- also the source code for everything
- lots of documentation, making a printer guides on the wiki
- list of known bugs and planned enhancements on github
Thanks!

41. one of the first graphics tests
“an homage.”

42. somebody sent this on Thursday