Home » Deve­lo­p­ment » Exhi­bits API

Exhibits API

The Exhibits API was deve­loped speci­fi­cally for monitoring and control­ling digital exhibits in exhi­bi­tions and museums.

Stan­dard media controls can turn an exhi­bit’s PC on or off, but many museum opera­tors want more control options, such as monitoring the soft­ware on the PC.

The exhibit does not work anymore!

NeuroomNet can distin­guish if the PC or the soft­ware stops respon­ding. In this case, you can restart the soft­ware from NeuroomNet Monitoring. This is faster than rebooting the whole PC.
It is also valuable for perma­nent error correc­tion to know on which side the error was located.

How does it work?

The exhibit appli­ca­tion connects to the NeuroomNet server via a network using the provided inter­face. Exhibits are uniquely iden­ti­fied via Vend­orIDs.

There are stan­dard actions that NeuroomNet has imple­mented for this, for example:

  • User login/logout
  • Restart Exhibits Soft­ware
  • Restart soft­ware

The deve­lo­pers of the exhibits can imple­ment the func­tion­a­lity of these actions in their soft­ware. NeuroomNet only sends the trigger for this.

In addi­tion, individual events and actions can be regis­tered. These then become visible and execu­table in the NeuroomNet monitoring and NeuroomNet script blocks.

Notice.

Here is the distinc­tion from soft­ware API. The soft­ware API also offers on a low-level protocol the possibility to log events and actions, but just that and no prede­fined proto­cols for user logins, etc.

Technical details

The API is imple­mented on the NeuroomNet server, to which the appli­ca­tions of the exhibit manu­fac­tu­rers connect. The WebSo­cket protocol (ws:// accor­ding to RFC 6455) is used for commu­ni­ca­tion, which offers several advan­tages: The protocol is built on TCP (connec­tion-oriented) and ensures the bidi­rec­tional exch­ange of message packets. In addi­tion, ready-made libra­ries already exist for very many runtime envi­ron­ments (opera­ting systems and programming languages).
The server waits for connec­tion requests via a prede­fined port. Appli­ca­tions must connect to the server as soon as they are ready.
The trans­mitted data packets consist of JSON strings.
It is recom­mended to store the IP address of the server, or rather its name to be resolved via a DNS, and the port in an appli­ca­tion-specific confi­gu­ra­tion file to be able to use the server if neces­sary. to be able to carry out neces­sary adjus­t­ments easily.

PING — Are you still there?

After connecting/logging in an exhibit to the server, the server will query the status of the application/exhibit at regular inter­vals to be able to visua­lize error states in the media control and thus allow the exhi­bi­tion staff to correct the error. If the appli­ca­tion hangs and does not respond or the WebSo­cket connec­tion is discon­nected, the exhibit is reported as “OFFLINE”. On the other hand, the appli­ca­tion may only return an “Ok” if all compon­ents are working properly. However, exhibit soft­ware can also report individual errors such as “No more paper” or “Connected camera not working”.

Visitor identification via RFID or QR code

The system is equipped to manage visitor creden­tials. Described here as an example of regis­tra­tion via RFID wrist­band.
The visitor logs on to an exhi­bi­tion device (exhibit) by holding its RFID wrist­band to the RFID reader of the exhibit. The RFID reader trans­mits the captured ID of the wrist­band to the system, which commu­ni­cates this via API to the assi­gned appli­ca­tion of the exhibit manu­fac­turer. The appli­ca­tion will then start the visitor inter­ac­tion with the exhibit (game, information, or similar). If this is finished (whether regu­larly by the end of all actions, by explicit, manual termi­na­tion, or timeout), the corre­spon­ding information is sent to the system.

If, in the course of visitor inter­ac­tion, it is neces­sary to confirm a tran­sac­tion via RFID wrist­band, this information is trans­mitted to the appli­ca­tion in the same way. The appli­ca­tion must decide based on its status whether it is a confir­ma­tion, a new regis­tra­tion, or a change of visitor.

Imple­ment visitor identification yourself

What is the advan­tage of using the NeuroomNet Exhibits API?

Finally, each appli­ca­tion could also imple­ment its own commu­ni­ca­tion with an RFID or QR code reader.

  • It is often the case that several compa­nies write the exhibit soft­ware for an exhi­bi­tion. So that would mean that each company would have to build the appli­ca­tion once itself — so the same work would have to be done multiple times.
  • There is no central autho­rity to decide whether the ID is valid at all.
  • Central statis­tics can be created through the use of exhibits.
  • In the event of a device repla­ce­ment (RFID defec­tive) and changed hard­ware or firm­ware, all appli­ca­tions would have to be adapted.
  • The same tech­no­logy can be used in the building for other appli­ca­tions such as access control or to control visitor tours.

For more examples and expl­ana­tions take a look at our documentation.