Inter­faces

KNX

With KNX you can control building tech­no­logy — sockets, lamps, window blinds, and more!

KNX is a building auto­ma­tion system (form­erly known as EIB). Actua­tors and sensors are connected via a two-wire line over the bus.
Sensors include, for example, swit­ches, dimmers, motion detec­tors, and tempe­ra­ture sensors. Actua­tors can include, for example, lights, blinds, and dimming actua­tors. When a sensor sends a tele­gram over the bus, the appro­pria­tely “programmed” actuator reco­gnizes that it is the intended reci­pient and responds accordingly—for example, by turning on the light.
NeuroomNet is connected to the KNX bus via an IP bus coupler and can also place tele­grams on the bus or receive them.

KNX is very popular among all elec­trical manu­fac­tu­rers. All well-known manu­fac­tu­rers offer just about ever­y­thing in their product lines, from switch lines to DIN-rail actua­tors.
The advan­tages of KNX lie in its flexi­bi­lity; you can change at any time which light is controlled by which switch. One disad­van­tage is certainly that it can only be installed properly during the cons­truc­tion phase, meaning it’s quite labor-inten­sive to install in an exis­ting building.

PJLink

Control video projec­tors and screens in NeuroomNet — with the PJLink stan­dard!

Behind this stan­dard lies a network inter­face. This allows NeuroomNet to use a cross-vendor and cross-model inter­face for confi­gu­ring and monitoring video projec­tors, as PJLink is supported by more than 100 projector models from parti­ci­pa­ting manu­fac­tu­rers.
Features include, among other things, turning projec­tors on and off, reading lamp hours, switching sources, etc.
A list of manu­fac­tu­rers and supported devices can be found here.

In the mean­time, many manu­fac­tu­rers have started to use the PJLink protocol for commu­ni­ca­tion with moni­tors as well.

DMX / ArtNet

Show lighting and stage tech­no­logy is a real feast thanks to DMX in NeuroomNet!

DMX is a protocol tradi­tio­nally used in stage and event tech­no­logy. From small thea­ters to massive perfor­mance stages, lighting is controlled via DMX. Typi­cally, DMX is used to control light colors and the moto­rized axes of moving-head spot­lights.
But of course, there are many more devices and appli­ca­tions.
For example, from within NeuroomNet, you can also use DMX to lower the curtain or start the fog machine.
With the incre­asing use of LED lighting in perma­nent instal­la­tions, there are also more and more appli­ca­tions in the home and corpo­rate sectors. Consider, for example, indi­rect lighting in a confe­rence room.

NeuroomNet connects DMX via a network, so it uses the ArtNet protocol to commu­ni­cate directly with DMX devices that under­stand ArtNet. Alter­na­tively, one can use corre­spon­ding ArtNet DMX inter­faces.

Technical:

DMX can control up to 512 chan­nels (a universe) of lighting values over one cable. This worked well for many years but even­tually exceeded the 512-channel limit. In addi­tion, lighting consoles appeared that supported multiple DMX universes. Art-Net over­comes the channel limi­ta­tion of DMX while still using the struc­ture. It allows multiple DMX universes to be trans­ported over a Cat5 cable via Ethernet.

Exhi­bi­tion API

Monitoring and remote control of third-party soft­ware in your project!

The Exhi­bi­tion API is a proprie­tary NeuroomNet API. Programmers can use it to connect their soft­ware to the NeuroomNet ecosystem. The NeuroomNet monitoring inter­face can then directly visua­lize the status of the connected soft­ware.
For example, if there is no commu­ni­ca­tion between NeuroomNet and the third-party software—whether due to soft­ware issues or a faulty network cable—NeuroomNet can visua­lize this accor­dingly, just as it would for any other compo­nent.
In addi­tion, the soft­ware can register actions in the NeuroomNet system, which in turn are trig­gered by the NeuroomNet media control.

MQTT

Even more centra­lized commu­ni­ca­tion and auto­ma­tion in NeuroomNet!

MQTT (Message Queuing Tele­metry Trans­port) was deve­loped as a simple, resource-effi­cient, and reliable network protocol for exchan­ging information between devices (machine-to-machine communication—M2M). It ensures the reliable trans­mis­sion of states (measu­re­ment values), state changes (events), and commands (actions), even when the network connec­tion is slow or tempo­r­a­rily inter­rupted.
It has become highly signi­fi­cant in the “Internet of Things” (IoT). In this context, many small, low-perfor­mance, highly specia­lized end devices (sensors, actua­tors) are typi­cally inter­con­nected to form an auto­ma­tion solu­tion.
Messages are managed by a so-called “broker.” The broker receives and coll­ects data sent by MQTT parti­ci­pants and distri­butes it to regis­tered endpoints. NeuroomNet works with brokers starting with protocol version 3.1. Support for encryp­tion (TLS) and authen­ti­ca­tion is available, but it is only useful if your end devices also support these features.

SNMP

Inte­grate prin­ters, phones, and other network devices into your media control!

SNMP (Simple Network Management Protocol) allows network devices (such as servers, swit­ches, NAS devices, and prin­ters) to be centrally moni­tored and controlled. Information provided by your network compon­ents is recorded and processed in NeuroomNet.
The monitoring feature records para­me­ters and noti­fies you of any errors that occur. Depen­ding on the confi­gu­ra­tion, actions can also be trig­gered on the end devices. NeuroomNet curr­ently supports protocol versions 1 and 2c (commu­nity-based). In the future, it will also be possible to use version 3. Curr­ently, stan­dar­dized settings and para­me­ters are prima­rily used.

Serial / RS-232

Commu­ni­cate with AV devices and more!

When people talk about a serial inter­face in media tech­no­logy, they are usually refer­ring to an RS-232 inter­face. NeuroomNet commu­ni­cates via all common serial inter­faces, such as RS-485 or RS-422. Serial inter­faces have long been the stan­dard when it comes to control­ling AV devices such as projec­tors, video swit­chers, or audio/video players. Nowa­days, of course, these inter­faces are incre­asingly being replaced by network-based inter­faces and their proto­cols.
For many years, manu­fac­tu­rers have been provi­ding proto­cols for serial devices to control their products. Some of these proto­cols are also used for new devices with network inter­faces.

TCP

The Internet protocol TCP is a real all-rounder among the NeuroomNet inter­faces.

You can control many devices—such as MP3 players, video swit­ches, switchable power outlets, etc.—in NeuroomNet using TCP.
It’s important to know that TCP only handles data trans­port; a protocol descrip­tion is also required.
After all, TCP doesn’t inher­ently know what data the MP3 player under­stands or how it must be formatted.
In NeuromNet, you ther­e­fore create a network compo­nent of the TCP type and add the corre­spon­ding protocol descrip­tion from the NeuromNet data­base to it. And just like that, you can send a “Play” command to the MP3 player or query which track is curr­ently playing.

An advan­tage of TCP is the connec­tion orien­ta­tion. So there is a perma­nent connec­tion from NeuroomNet to the end device. If this connec­tion is lost (e.g. network plug is pulled, the device is defec­tive, etc.), NeuroomNet can register this and visua­lize it in the monitoring. This is diffe­rent from the UDP protocol, for example.

Inci­den­tally, NeuroomNet itself also commu­ni­cates intern­ally via TCP but is enhanced with SSL/TSL to ensure encryp­tion.

UDP

Use fast trans­fers with low admi­nis­tra­tion over UDP

UDP is used to send data directly to network parti­ci­pants without estab­li­shing a persis­tent connec­tion.
The UDP protocol has slightly less “over­head” than TCP. This means that not quite as much data is sent over the network. UDP is ther­e­fore very well suited for many small, fast queries—for example, when you want to check the position of a motor or similar device multiple times per second.
On the other hand, because of the connec­tion­less nature of the commu­ni­ca­tion, you won’t imme­dia­tely notice if the device on the other end is no longer there, unlike with the TCP protocol.

Like TCP, UDP initi­ally only knows “how” to transmit data, not “what.” Ther­e­fore, in NeuroomNet, you typi­cally add a protocol descrip­tion to a UDP-type network compo­nent in order to commu­ni­cate with a dedicated end device.
However, you can also send “raw data”—that is, simple strings (text)—from the NeuroomNet media control to an end device. To do this, you just need to know the device’s IP address and the port on which the end device is listening for inco­ming UDP messages. The port is speci­fied by the device manu­fac­turer and can usually be found in the manual.