Skip to main content

Best Practice: Implementation of master / master or bilateral value synchronization between external devices and NeuroomNet [Dashboards]

note

This page has been automatically translated and has not been reviewed in detail yet. Therefore, the translation might not be completely accurate.

Description scenario​

Preliminary note: This chapter / best practice primarily concerns the control of external devices with NeuroomNet dashboards, but is not limited to dashboards per se.

If NeuroomNet remotely controls other devices in a NeuroomNet installation, this usually happens in such a way that only NeuroomNet controls these other devices and the devices are not controlled from another side (at least with regard to the functionality of these devices, which is also controlled by NeuroomNet). This is then a so-called master/slave setup.

Note: The terms “Master / Slave” (and the “Master / Master”), which were very well known from computer science from the 1980s to 2000s, were chosen in this chapter due to the lack of alternative, concise and suitable terms. This only means the technical meaning, similar to “Client / Server”, “Primary / Replica” or “Server”. The authors do not intend any connection, connotation or denotation to terms from other contexts (such as slavery in human history).

But there are also cases - and this is what this best practice is about - where both NeuroomNet and another instance control the same values of the same external device. This is where NeuroomNet has to be

  • report both value changes that come from NeuroomNet to the external device,
  • Update value changes received from the external device (especially in the dashboard).

We refer to these cases as bilateral synchronization of value changes or synonymously as master / master setups.

Example:

In a lecture hall, a tablet is installed in the podium that displays an NrN dashboard. On the dashboard you can control the volume in an audio DSP using a slider and toggle mute on and off using a button:

Screenshot Dashboard for Audio DSP

There are 2 variables in NeuroomNet, the values of which can be changed using the above slider or button:

  • AudioDSP_Lautstaerke1: Integer
  • AudioDSP_Mute1: Boolean

Assuming that this volume and / or mute can still be controlled directly in the AudioDSP / its software, then there is such a required bilateral value synchronization or master / master setup.

Wrong solution (Don't)​

The following solution is only intended as an explanation and is NOT a good solution to the problem of "two-sided value synchronization or master / master":

You create triggers for the two variables "Value changed" in the script blocks, so that when the variables change, the new value is sent to the audio DSP:

Screenshot Don't (1): Variable Changed trigger / script in the Script Blocks module

This actually works very well in the master / slave setup and is also relatively elegant there, as there is only one central point per variable that ensures that new values are sent to the hardware.

With a master / master setup, an event handler must also be added here for incoming value changes from the audio DSP:

Screenshot Don't (2): Event trigger / script in the Script Blocks module

However, this can then lead to problems such as "flutter effects" and overall poor performance, because incoming new values cause a variable change again, so that the new values (in fact the same values that had just come in) are sent out again. For binary values like mute this is probably less critical, but for number ranges where many small changes are often sent across the network in a short period of time (because a human moves a slider more or less quickly), this can lead to "fluttering effects". . A possible keyword here would be "throttling", but in this context it would be more of a workaround than a real solution to the core problem.

Below is the proposed solution for the bilateral synchronization of a variable X using the previous example:

The crucial point here is that you do NOT have a "Value changed" trigger for the variable

Instead, a custom event including a corresponding action is introduced for each affected variable, which sends the current variable values to the external system:

Screenshot Do (1): Custom event trigger / script in the Script Blocks module

(if necessary, these can also be bundled)

This custom action is then also configured in the dashboard for the corresponding controls (e.g., as here with a slider on the sub-control knob as an onChange event):

Screenshot Do (2): Calling the custom event via onChange in the dashboard

(and possibly also in the script blocks, if variable values change there via other script logic and should be sent to the external device).

As a result, this custom action and thus the sending of variable values to the external device is only carried out when values are changed manually on the controls in the dashboard (only then are the custom actions triggered and not when the variable values change and the controls automatically display the new values).

Recommended solution (Do) - short version​

  1. No Variable Changed Trigger in the script blocks for variables that represent values in external devices and which then send changed values to the external devices
  2. Instead, define custom actions, which are solely responsible for sending new variable values to external devices
  3. Configure the custom actions accordingly in the dashboard and, if necessary, in the script blocks where necessary