Skip to content

pikesley/shedbot

Repository files navigation

Build Status Dependency Status Coverage Status Code Climate License

Shedbot

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

Screenshot

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