Interfaces – connection to the outside world.

KNX

KNX is a system for building automation (old designation EIB). Actuators and sensors are connected via the bus using a two-wire line.
Sensors are for example switches, dimmers, motion detectors or temperature sensors. Actuators can be lamps, blinds or dimming actuators, for example. If a sensor now sends a telegram to the bus, the appropriately ‘programmed’ actuator recognizes that it is meant and behaves accordingly, for example switches on the light.
NeuroomNet is connected to the KNX bus via an IP bus coupler and can also send telegrams to the bus or receive them.
KNX is very popular with all electrical manufacturers. All well-known manufacturers have just about everything in their range, from switches to top-hat rail actuators. The advantages of KNX lie in its flexibility, you can still change which lamp is to be switched by which switch at any time. A disadvantage can certainly be seen in the fact that it can only be properly installed during the construction phase, i.e. it can only be installed in an existing building with great effort.

PJLink

PJLink is a standard to configure video projectors and monitors via a network interface. With this standard, a manufacturer- and model-independent interface can be used for the configuration and monitoring of video projectors, because it is supported by more than 100 projector models from the manufacturers involved.
Functions include turning projectors on and off, reading lamp hours, switching sources, etc.
A list of manufacturers and supported devices can be found here. In the meantime, many manufacturers have started to use the PJLink protocol for communication with monitors as well.

DMX / ArtNet

DMX is a protocol traditionally used in stage and event technology. From small theaters to huge show stages, lighting is realized via DMX. Where mostly light colors and the motorized axes of the head-mounted fixtures are controlled via DMX.
But of course there are many more end devices and applications. For example, DMX-triggered, the curtain can fall or the fog machine can do its job. Due to the increasing spread of LED light in fixed installations, there are also more and more applications in the home or corporate sector. Think, for example, of the indirect lighting in the conference room.
NeuroomNet connects DMX via network, i.e. uses the ArtNet protocol to communicate directly with DMX devices that understand ArtNet, or you use the corresponding ArtNet-DMX interfaces.
Technical: DMX can control up to 512 channels (one universe) of lighting values over one cable. This worked well for many years, but eventually exceeded the 512-channel limit. In addition, lighting desks that support multiple DMX universes appeared. Art-Net overcomes DMX’s channel limitation while still using the structure. It enables the transport of multiple DMX universes over a Cat5 cable via Ethernet.

Exhibition API

The Exhibition API is a proprietary NeuroomNet API. Programmers can use it to connect their software to the NeuroomNet ecosystem, allowing the NeuroomNet monitoring interface to directly visualize the status of the connected software.
For example, if there is no communication between NeuroomNet and the third-party software, be it due to software problems or a defective network cable, NeuroomNet can visualize this accordingly, as it can for any other component. In addition, the software can then register actions in the NeuroomNet system, which in turn are triggered by the NeuroomNet media control.

MQTT

MQTT (Message Queuing Telemetry Transport) was developed as a simple, resource-saving and reliable network protocol for exchanging information between devices (machine-to-machine communication – M2M). It ensures the fail-safe transmission of statuses (measured values), status changes (events) and commands (actions), even with a slow or briefly interrupted network connection.
It has gained great importance in the “Internet of Things” (IOT). As a rule, many small and underperforming, highly specialized end devices (sensors, actuators) are linked to form an automation solution.
The messages are managed by a so-called “broker”. This receives and collects data sent by the MQTT participants and distributes them to registered endpoints. NeuroomNet works with brokers from protocol version 3.1. Support for encryption (TLS) and authentication is possible, but only makes sense if your end devices also work with it.

SNMP

With SNMP (Simple Network Management Protocol), network devices (e.g. servers, switches, NAS, printers) can be centrally monitored and controlled. Information provided by your network components is registered and processed in NeuroomNet.
Parameters are recorded in the monitoring and you are informed about errors that have occurred. Depending on the configuration, actions can also be triggered in the end devices. NeuroomNet currently supports protocol versions 1 and 2c (community based). In future it will also be possible to use version 3. Standardized settings and parameters are currently used for the most part.

Serial / RS-232

When media technology talks about a serial interface, in most cases an RS-232 interface is meant. NeuroomNet communicates via all common serial interfaces, e.g. RS-485 or RS-422. Serial interfaces have long been standard when it comes to controlling AV devices such as projectors, video routers or audio/video players. Nowadays, of course, these interfaces are increasingly being replaced by network-based interfaces with their protocols.
For many years, manufacturers have provided protocols for serial devices to control their products. These protocols are partly also used for new devices with network interface.

TCP

Commonly also called “Internet Protocol”. NeuroomNet itself also communicates internally via TCP, of course, but extended with SSL/TSL to ensure encryption. If you now want to control end devices like MP3 players, video switches, switchable sockets etc. via TCP, something is still missing. TCP only takes care of the transport of the data, but which data the MP3 player understands and how they have to be formatted, TCP does not know of course. For this you still need a protocol description. In NeuroomNet, therefore, a network component of type TCP is created and the corresponding protocol description is added to it from the NeuroomNet database. And you can send a “Play” to the MP3 player or query which title is currently being played. One advantage of TCP is the connection orientation. There is therefore a permanent connection from NeuroomNet to the end device. If this is lost (e.g. network plug pulled, device defective, etc.) NeuroomNet can visualize this. Unlike the UDP protocol, for example.

UDP

UDP is used to send data directly to network nodes without establishing a connection. Therefore you don’t notice if the device on the other side is no longer there, as e.g. with the TCP protocol. On the other hand, the UDP protocol has a little less ‘overhead’, i.e. not quite as much data is sent over the network. UDP is therefore very suitable, for example, if you want to query the position of a motor or similar x times per second. Like TCP, UDP only knows ‘how’ to transmit and not ‘what’. So in NeuroomNet you can also add a protocol description to a network component of type UDP to be able to communicate with a dedicated end device. However, it is also possible to send “raw data”, i.e. simple strings (texts), to a terminal device. To do this, you only need to know which IP address the device has and on which port the end device is waiting for UDP messages to arrive. The port is defined by the terminal manufacturer and can usually be found in the manual.