-
Notifications
You must be signed in to change notification settings - Fork 17
Museum and gallery implementation
When utilising Nodel as a control system for your museum or gallery, best practice imposes a pseudo-hierarchy on an otherwise independent series of nodes. This structure isn't made immediately apparent when browsing the web interface.
- At the top level, the scheduler or calendar is responsible for turning on or off galleries each day.
- The galleries are responsible for each of the exhibits associated with them.
- The next level down is the exhibits, which manage a series of network-ready devices, each with their own nodes.
In the below example, MM-FG Geological Landforms and MM-FG Firepole, both exhibit nodes, are associated with several device nodes. MM-FGSD01 refers to a solid-state playback device, waiting for network commands to play/pause content. MM-FGRP01 in this case is a remote-power device, waiting for commands to turn on or off power. MM-FGIO01 is an IO device translating physical button pushes into network signals for Nodel to interpret.
Each of these nodes works together, under the supervision of the exhibit node to control the behaviour of a multimedia interactive in the gallery.
Middle Nodes or Management Nodes refers to a specific group of nodes which form the structure of the network, and manage other nodes, but don't necessarily communicate directly with devices.
The most important of these nodes is the exhibit node, which differ widely in complexity depending on the recipes of the exhibit that they're managing.
These nodes are responsible for listening to device nodes, and performing actions when necessary, such as turning on and off power, or playing content when a button is pressed. This is achieved through bindings between device nodes and gallery nodes.
At the next level up, gallery nodes are responsible for a large cluster of exhibit nodes, each of which waits for the gallery to generate on or off signals according to the scheduler, or event tech control nodes. This is achieved through bindings each exhibit node to its corresponding gallery node.
Device nodes or end nodes refer to a very specific design of node, intended to communicate with network-ready hardware, and provide a way to interface with it through Nodel.
The recipes for devices will often attempt to replicate controls found within the web pages for devices which have them, but with the added benefit of integrating them into one central platform.
Recipes for these and other nodes can all be located on the Nodel Recipes repository.
Nodel can be a particularly useful tool in troubleshooting exhibit faults. The idea is to work-through device nodes associated with a faulty exhibit, and utilise their provided actions to eliminate possibilities in the search for the source of a fault.
It's important to acknowledge the possibility that Nodel itself can be at fault, this is most commonly due to incorrect bindings caused by human error, or offline nodes as a result of network failure across the decentralised platform.
Nodel: http://nodel.io/ | White Paper