Difference between revisions of "Things Bus"

From Pumping Station One
Jump to navigation Jump to search
(Created page with "We want to make a super-easy-to-integrate-with way to handle sensors and actuators around the space. Here's a link dump. The thread that started this off: https://groups.goog...")
 
Line 4: Line 4:
  
 
https://wiki.muc.ccc.de/uberbus:start?redirect=1
 
https://wiki.muc.ccc.de/uberbus:start?redirect=1
 +
 
https://wiki.muc.ccc.de/uberbus:ubd
 
https://wiki.muc.ccc.de/uberbus:ubd
 +
 
https://github.com/muccc/ubd
 
https://github.com/muccc/ubd
 +
 
https://wiki.muc.ccc.de/uberbus:protocols
 
https://wiki.muc.ccc.de/uberbus:protocols
 +
 
http://stackoverflow.com/questions/1534655/creating-a-program-to-be-broadcasted-by-avahi
 
http://stackoverflow.com/questions/1534655/creating-a-program-to-be-broadcasted-by-avahi
 +
 
http://www.avahi.org/wiki/Examples/PythonPublishAlias
 
http://www.avahi.org/wiki/Examples/PythonPublishAlias
 +
 +
 +
== Message broker idea ==
 +
 +
Use a message broker such as [http://activemq.apache.org ActiveMQ] as the core of the system. 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.
 +
 +
=== Status notices ===
 +
 +
Status notices should be published to topics so that they are multicast, topics should be hierarchical so that consumers can subscribe to sections of the space that they are interested in for example
 +
 +
* PS1
 +
** Workshop
 +
*** AC
 +
*** Extraction
 +
*** ColdMetals
 +
**** Bandsaw
 +
**** Bridgeport
 +
**** Lath
 +
*** HotMetals
 +
**** Forge
 +
**** Lincoln100
 +
**** Lincoln125
 +
**** ArgonTank
 +
*** WoodShop
 +
**** Dustcollector
 +
**** sawstop
 +
**** bandsaw
 +
*** C&C
 +
**** Taz
 +
**** AO-100
 +
**** ShopBot
 +
** Electronics
 +
*** Projector
 +
** Lounge
 +
*** AC
 +
*** Projector
 +
*** Bar
 +
** Kitchen
 +
*** BrewFridge
 +
*** Fridge
 +
*** Stove
 +
 +
 +
=== 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 ====
 +
 +
On event:
 +
<pre>
 +
{ "source": "DustCollection", "location": "workshop", "messageType": "status", "status": "Dust collector turned on", "transition": true }
 +
</pre>
 +
 +
Periodic status:
 +
<pre>
 +
{ "source": "DustCollection", "location": "workshop", "messageType": "status", "status": "Dust collector active", "transition": false }
 +
</pre>
 +
 +
Off event:
 +
<pre>
 +
{ "source": "DustCollection", "location": "workshop", "messageType": "status", "status": "Dust collector turned off", "transition": fase }
 +
</pre>
 +
 +
 +
==== Dust collector commands ====
 +
 +
Turn system on:
 +
<pre>
 +
{ "target": "DustCollection", "location": "workshop", "messageType": "command", "command": "on"}
 +
</pre>
 +
 +
Turn system off:
 +
<pre>
 +
{ "target": "DustCollection", "location": "workshop", "messageType": "command", "command": "off"}
 +
</pre>

Revision as of 18:42, 7 October 2014

We want to make a super-easy-to-integrate-with way to handle sensors and actuators around the space. Here's a link dump.

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

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


Message broker idea

Use a message broker such as ActiveMQ as the core of the system. 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.

Status notices

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

  • PS1
    • Workshop
      • AC
      • Extraction
      • ColdMetals
        • Bandsaw
        • Bridgeport
        • Lath
      • HotMetals
        • Forge
        • Lincoln100
        • Lincoln125
        • ArgonTank
      • WoodShop
        • Dustcollector
        • sawstop
        • bandsaw
      • C&C
        • Taz
        • AO-100
        • ShopBot
    • Electronics
      • Projector
    • Lounge
      • AC
      • Projector
      • Bar
    • Kitchen
      • BrewFridge
      • Fridge
      • Stove


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

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

Turn system on:

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

Turn system off:

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