The Exhibits API was developed specifically for monitoring and controlling digital exhibits in exhibitions and museums.
Standard media controls can turn an exhibit’s PC on or off, but many museum operators want more control options, such as monitoring the software on the PC.
The exhibit does not work anymore!
NeuroomNet can distinguish if the PC or the software stops responding. In this case, you can restart the software from NeuroomNet Monitoring. This is faster than rebooting the whole PC.
It is also valuable for permanent error correction to know on which side the error was located.
How does it work?
The exhibit application connects to the NeuroomNet server via a network using the provided interface. Exhibits are uniquely identified via VendorIDs.
There are standard actions that NeuroomNet has implemented for this, for example:
- User login/logout
- Restart Exhibits Software
- Restart software
The developers of the exhibits can implement the functionality of these actions in their software. NeuroomNet only sends the trigger for this.
The server waits for connection requests via a predefined port. Applications must connect to the server as soon as they are ready.
The transmitted data packets consist of JSON strings.
It is recommended to store the IP address of the server, or rather its name to be resolved via a DNS, and the port in an application-specific configuration file to be able to use the server if necessary. to be able to carry out necessary adjustments 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 intervals to be able to visualize error states in the media control and thus allow the exhibition staff to correct the error. If the application hangs and does not respond or the WebSocket connection is disconnected, the exhibit is reported as “OFFLINE”. On the other hand, the application may only return an “Ok” if all components are working properly. However, exhibit software 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 credentials. Described here as an example of registration via RFID wristband.
The visitor logs on to an exhibition device (exhibit) by holding its RFID wristband to the RFID reader of the exhibit. The RFID reader transmits the captured ID of the wristband to the system, which communicates this via API to the assigned application of the exhibit manufacturer. The application will then start the visitor interaction with the exhibit (game, information, or similar). If this is finished (whether regularly by the end of all actions, by explicit, manual termination, or timeout), the corresponding information is sent to the system.
If, in the course of visitor interaction, it is necessary to confirm a transaction via RFID wristband, this information is transmitted to the application in the same way. The application must decide based on its status whether it is a confirmation, a new registration, or a change of visitor.
Implement visitor identification yourself
What is the advantage of using the NeuroomNet Exhibits API?
Finally, each application could also implement its own communication with an RFID or QR code reader.
- It is often the case that several companies write the exhibit software for an exhibition. So that would mean that each company would have to build the application once itself — so the same work would have to be done multiple times.
- There is no central authority to decide whether the ID is valid at all.
- Central statistics can be created through the use of exhibits.
- In the event of a device replacement (RFID defective) and changed hardware or firmware, all applications would have to be adapted.
- The same technology can be used in the building for other applications such as access control or to control visitor tours.
For more examples and explanations take a look at our documentation.