Add Protocol and Network information to Fixtures in MVR

[Bartel-C8]

Is your feature request related to a problem? Please describe. New feature: It would be great if a MVR could contain more info about the used protocol and optional network information for used fixtures.

Describe the solution you'd like Add to a Fixture definition these (or more/less) tags:

• Protocol:
  • Selected protocol: DMX / sACN / Art-Net / ...
• Network:
  • Selected routing: Unicast / Broadcast (Art-Net) or Multicast (sACN)
  • Configured IPv4 address + netmask
  • Configured IPv6 address + prefix
  • Configured VLAN id ?
  • Configured IP stack: 4 or 6 ?

Describe alternatives you've considered Custom user variables in MVR?

Additional context This way consoles/media-servers can automatically select/enable the right protocol (for each fixture) on import. Especially useful in the case of using Art-Net with unicast. The IP info is critical there...

[Bartel-C8]

@moritzstaffel @klinzey : If I am allowed to "ping" you after the monthly meeting.

Roel Apers first posed this question in the monthly meeting of 26/04 and Moritz said it was "a good one". Happy to contribute/discuss this further.

[moritzstaffel]

This is part of the Proposal for Electrical and Data Components in GDTF.https://github.com/mvrdevelopment/gdtf-din-spec/pull/3 There was some presentation in the monthly meeting here. The work on MVR here is still due.

[Bartel-C8]

Yes, I saw that part. But this configuration above is setup/project specific so, therefore should reside in MVR, no?

[moritzstaffel]

Yes, this is currently not done. But the option on how the device can connect comes from GDTF.

[moritzstaffel]

So when the device has two connection options, you can define two IP dresses and that part...

[Bartel-C8]

@moritzstaffel : Any chance this will land in the next MVR version (soon)? Would be awesome! I saw this issue mentioned in https://github.com/mvrdevelopment/spec/pull/108 , but I see no reference fitting this issue (yet).

Thanks!

[reneberhorst]

https://github.com/mvrdevelopment/spec/blob/Network_protocols_proposal/mvr-spec.md addresses the suggestion. Hopefully everything is covered.

[Bartel-C8]

@reneberhorst , thank you very much!

A thing that we would like to be seen added is to specify whether unicast or broadcast/multicast data is expected.

Suggestion: Add a unicast field to the (Art-Net / sACN / ...) protocols: https://github.com/mvrdevelopment/spec/blob/Network_protocols_proposal/mvr-spec.md#node-definition-protocols

unicast : true -> unicasted (both valid for e.g. Art-Net and sACN) unicast: false -> which means: broadcast for Art-Net and multicast for sACN

With this, a complete (basic) lighting setup can be fully made reproducible (import/export). E.g. a MVR could be used as a "project file" for a lighting console containing all needed/required settings.

Other observation : Table numbers are not unique anymore: Table 17 — Protocols Node Children VS Table 17 — Adresses Node Children (+typo in 'Adresses') Table 18 — Network Node Attributes VS Table 18 — Address Node Attributes (even same name)

Other question: How RDM will fit in this protocols list, as it mostly is done over DMX.

RDM over Art-Net is supported, via ArtRdm packets, so is this why it's added? Or RDMnet even? Should the RDM node explain which sub-protocol it uses to communicate?

[moritzstaffel]

@Bartel-C8 https://github.com/mvrdevelopment/spec/pull/162/files

We have added this via the transmission attribute. What do you thing?

Yes the RDM will be the RDM-Net, we need to change this.

[Bartel-C8]

Thanks for the changes (especially the transmission field).

One thing from my previous comment (typo) that is still there: Table numbers are not unique anymore: Table 17 — Protocols Node Children VS Table 17 — Adresses Node Children (+typo in 'Adresses') Table 18 — Network Node Attributes VS Table 18 — Address Node Attributes (even same name)

Other question:

Is the description still valid with the changed type/default?:

Default Value when Optional     |   Description
NetworkInOut                    |   This is the interface name.Typically used "ethernet_x", "wireless_x", "loopback_x" (x starting at 1 and incrementing)

Other question I have now is the meaning of NetworkInOut_1. Is this the physical connector on the fixture? Where is this described, in the GDTF then?

Because, what would be the MVR for a fixture having 2 ethernet ports (internal unmanaged switch)? The fixture probably will have 1 IP address (of each type, IPv4 of IPv6), available on the 2 physical network ports.

But how should you describe then that both ports support a specific protocol? As only 0 or 1 times a protocol can be defined...

Actually more IP addresses should be no problem at all, on the same interface. This is especially the case on a IPv6 network where both a global (routed) and link-local (fe80::...) IPv6 address is available. But this is allowed, right? Or not?

        <Network geometry="NetworkInOut_1" IPv4="192.168.11.5" SubnetMask="255.255.0.0" />
        <Network geometry="NetworkInOut_1" IPv4="2.1.2.3" SubnetMask="255.0.0.0" />

Thanks

[Bartel-C8]

I was AFK unfortunately for 15 mins on the call today, and just at that time I think this was discussed. I will watch back the recording. But may I ping you in the meantime about my question above? @moritzstaffel @reneberhorst

[moritzstaffel]

Sure any time. We also can have a call :)

[Bartel-C8]

But maybe @reneberhorst can already answers some questions?

When is the DIN handover planned? Should we schedule a call this week?