Running it

git clone https://github.com/pikesley/shedbot/
cd shedbot
bundle
bundle exec puma

Then go to localhost:9292

Configuration

There is a config/config.yml file (which should be overriden at ~/.shedbot/config.yml) which looks like

relays:
  spotlight:
    pin: 13
  striplight:
    pin: 6

This associates a light with a (logical) pin

Auto Pi Detection

If RUBY_PLATFORM matches /arm.*-linux/ then the assumption is made that this is running on a real Raspberry Pi, where PiPiper will work properly - if some other OS is identified then fake pins are used for testing

API

This is so, so Alpha, but:

Switching lights

PATCH /lights/:light

with a JSON payload like

{
  state: on
}

will (attempt to) set the light identified by :light to on. This is the method called by the controls in the HTML front-page

Reading state

GET /lights/:light

will return a JSON object describing the state of :light, thus:

{
  spotlight: "on"
}

Next steps

Because this is interacting with the Real World of Physical Things, we should not assume that setting state=on actually causes anything to happen. This all needs to happen asynchronously (via a Sheduler, thanks @floppy) and then the actual status can be reported back on a different endpoint

And it's important that this is all implemented correctly or the whole thing is rendered ludicrous

I gave a talk about this

I have spoken about this nonsense in public: at EMF Camp 2016, and at an ODI Friday Lecture. The latest iteration of the slides is here

Computers

Shedbot