Things Bus

We want to make a super-easy-to-integrate-with way to handle sensors and actuators around the space.

Ideas

Message broker idea

Use a message broker such as ActiveMQ or RabbitMQ as the core of the system. Hef already has RabbitMQ in the space for ps1auth. This can be communicated with an an number of protocols but by far the simplest is STOMP. All messages passing through the broker should be JSON text messages well formed and documented.

Messages from devices such as arduinos could use MQTT protocol there is even an arduino lib: http://knolleary.net/arduino-client-for-mqtt/ Interesting article about bridging messages from a ZigBee mesh into MQTT: http://rijware.com/zigbee-and-mqtt/

References

The thread that started this off: https://groups.google.com/forum/#!topic/pumping-station-one/ogqSHK08DAI

Other Links

https://wiki.muc.ccc.de/uberbus:start?redirect=1

https://wiki.muc.ccc.de/uberbus:ubd

https://github.com/muccc/ubd

https://wiki.muc.ccc.de/uberbus:protocols

http://stackoverflow.com/questions/1534655/creating-a-program-to-be-broadcasted-by-avahi

http://www.avahi.org/wiki/Examples/PythonPublishAlias

Things We Want To Integrate

Status notices should be published so that consumers can subscribe to sections of the space that they are interested in for example:

• Workshop
  • AC
  • Extraction
  • ColdMetals
    • Bandsaw
    • Bridgeport
    • Lath
  • HotMetals
    • Forge
    • Lincoln100
    • Lincoln125
    • ArgonTank
  • WoodShop
    • Dustcollector
    • sawstop
    • bandsaw
  • CNC
    • Taz
    • AO-100
    • ShopBot
• Electronics
  • Projector
• Lounge
  • AC
  • Projector
  • Bar
• Kitchen
  • BrewFridge
  • Fridge
  • Stove
• General Area
  • Doors
    • Front
      • Front Doorbell
    • Rear
    • Lounge - Front and back
    • Starewell - Top and bottom
    • Bathrooms
  • Lights
  • A/C & Heat
• Workshop
  • Forge
  • Dust Collector
  • LN2 Scale
• Systems
  • Spacemon
  • Peoplemon
  • Chillmon
  • Schedmon
  • DHCP
  • Netlogon
  • Access control

Future Features

Issuing commands

Commands for items should be sent to a queue, the controller/interface for the time should be subscribed to the queue and process the commands, queues should be laid out in a similar way to topics. Messages should also be json and well formed and documented.

Examples

Dust collector status messages

Transmitted to: /topic/PS1/Workshop/WoodShop/DustCollector

On event:

{ "source": "DustCollection", "location": "workshop", "messageType": "status", "status": "Dust collector turned on", "transition": true }

Periodic status:

{ "source": "DustCollection", "location": "workshop", "messageType": "status", "status": "Dust collector active", "transition": false }

Off event:

{ "source": "DustCollection", "location": "workshop", "messageType": "status", "status": "Dust collector turned off", "transition": fase }

Dust collector commands

Transmitted to: /queue/PS1/Workshop/WoodShop/DustCollector

Turn system on:

{ "target": "DustCollection", "location": "workshop", "messageType": "command", "command": "on"}

Turn system off:

{ "target": "DustCollection", "location": "workshop", "messageType": "command", "command": "off"}