# Shedbot

RESTful API for the Internet of Sheds. You’ll also want the Arduino stuff

# 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