Inter­faces

KNX

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

KNX is a system for building auto­ma­tion (old name EIB). Actua­tors and sensors are connected via the bus using a two-wire line.
Sensors are for example swit­ches, dimmers, motion detec­tors, or tempe­ra­ture sensors. Actua­tors can be, for example, lamps, blinds, or dimming actua­tors. If a sensor now sends a tele­gram to the bus, the corre­spon­dingly ‘programmed’ actuator reco­gnizes what it is meant and behaves accor­dingly, for example switching 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 with all elec­trical manu­fac­tu­rers. All well-known manu­fac­tu­rers have pretty much ever­y­thing in their program, from switch programs to DIN rail actua­tors.
The advan­tages of KNX lie in its flexi­bi­lity, you can still change at any time, which lamp should be swit­ched by which switch. As a disad­van­tage you can certainly see that it can only be installed reason­ably during the cons­truc­tion phase, so can only be installed elabo­ra­tely in an exis­ting building.

PJLink

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

Behind this stan­dard is a network inter­face. This allows NeuroomNet to use a cross-manu­fac­turer and cross-model inter­face for confi­gu­ring and monitoring video projec­tors because PJLink is supported by more than 100 projector models from the parti­ci­pa­ting manu­fac­tu­rers.
Func­tions include turning projec­tors on and off, reading lamp hours, switching sources, etc.
A list of manu­fac­tu­rers or 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 that is tradi­tio­nally used in stage and event tech­no­logy. From small thea­ters to huge show stages, lighting is realized via DMX. Whereby mostly light colors and the moto­rized axes of the head-moving spot­lights are controlled via DMX.
But of course, there are many more end devices and purposes.
For example, from NeuroomNet you can also DMX-trig­gered drop the curtain or start the fog machine.
Due to the incre­asing use of LED light in fixed instal­la­tions, there are also more and more appli­ca­tions in the home or corpo­rate sector. Think, for example, of indi­rect lighting in confe­rence rooms.

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 thus 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 soft­ware, either due to soft­ware problems or a defec­tive network cable, NeuroomNet can visua­lize this accor­dingly, just as 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-saving, and reliable network protocol for the exch­ange of information between devices (machine-to-machine commu­ni­ca­tion — M2M). It ensures the inter­fe­rence-free trans­mis­sion of states (measured values), state changes (events), and commands (actions), even if the network connec­tion is slow or briefly inter­rupted.
It has gained great importance in the “Internet of Things” (IOT). Here, many small and inef­fi­cient highly specia­lized end devices (sensors, actua­tors) are usually linked toge­ther to form an auto­ma­tion solu­tion.
The messages are managed by a so-called “broker”. This broker receives and coll­ects data sent by the MQTT parti­ci­pants and distri­butes it to regis­tered endpoints. NeuroomNet works with brokers from protocol version 3.1. Support for encryp­tion (TLS) and authen­ti­ca­tion is possible but only makes sense if your end devices also work with it.

SNMP

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

With SNMP (Simple Network Management Protocol), network devices (e.g. servers, swit­ches, NAS, prin­ters) can be centrally moni­tored and controlled. Information provided by your network compon­ents is regis­tered and processed in NeuroomNet.
In monitoring, para­me­ters are recorded and you are informed about errors that have occurred. Depen­ding on the confi­gu­ra­tion, actions can also be trig­gered in 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 or para­me­ters are essen­ti­ally used.

Serial / RS-232

Commu­ni­cate with AV devices and more!

When people in media tech­no­logy talk about a serial inter­face, in most cases they mean an RS-232 inter­face. NeuroomNet commu­ni­cates via all common serial inter­faces, e.g. RS-485 or RS-422. Serial inter­faces have long been stan­dard when it comes to control­ling AV devices such as projec­tors, video routers, or audio/video players. Nowa­days, of course, these inter­faces are incre­asingly being replaced by network-based inter­faces with their proto­cols.
For many years, manu­fac­tu­rers have provided proto­cols for serial devices to control their products. These proto­cols are partly 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 end devices such as MP3 players, video swit­ches, switchable sockets, etc. in NeuroomNet using TCP.
It is important to know that TCP only takes care of the trans­port of the data, but that a protocol descrip­tion is also required.
Because TCP does not know what data the MP3 player under­stands and how it has to be formatted.
A network compo­nent of the type TCP is ther­e­fore created in NeuromNet and the corre­spon­ding protocol descrip­tion from the NeuroomNet data­base is added to it. And you can send a “play” to the MP3 player or ask 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

Using UDP, data is sent directly to network parti­ci­pants without estab­li­shing a perma­nent 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 if you want to query the position of an engine or similar several times per second.
On the other hand, due to the connec­tion­less commu­ni­ca­tion, you don’t imme­dia­tely notice if the device on the other side is no longer there, unlike with the TCP protocol.

Like TCP, UDP only knows ‘how’ to transmit and not ‘what’. So in NeuroomNet you usually add a protocol descrip­tion to a network compo­nent of type UDP to commu­ni­cate with a dedicated end device.
But you can also send “raw data” i.e. simple strings (texts) from the NeuroomNet media control to an end 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 end device manu­fac­turer and can usually be found in the manual.