DMX over TCP: Which and why?

Jay Ashworth

Well-Known Member
In furtherance of my Tampa refit project, I'm at the point of contemplating simply designing and building my own gateway to Zigbee/Z-wave (ZHA2.0/3/ZLL) from one of the streaming DMX over TCP protocols, for those not insignificant times when people need one of those.

Which version is the best place for me to start, and is there a good 101-level introduction to the protocols, from a network-guy viewpoint?

I know there are a couple versions of ArtNet, sACN, e1.31, and possibly some others; not sure which are multiple names for the same thing yet.
 
ArtNet is the one with the most traction for one-way applications.

sACN seems to differ little from ArtNet. If you implement an ArtNet gateway to zigbee, it looks like you are about five minutes work short of having sACN support.


...edit... I tried to paste in a code sample, but cloudflare blocked me.
 
Last edited:
Over IP, not TCP, yes; thanks.

Rob, I have the TCP side; been doing that for 20 years.

Lyle, that's about 60% of what I need, I think. :) Is it IP multicast, usually, or unicast and senders have a list of receiver addresses? Or do you just leverage multicast yourself, 'behind the sender's back'.

I'm looking into ZHA and ZLL and the other various middleware protocols used on the Z side.
 
Last edited:
Senders can broadcast or unicast. A unicast receiver will also receive broadcasts on the same subnet automatically.

In sACN, you can use unicast, but the default is multicast, NOT broadcast. The multicast address by default is determined by the universe number per the standard (which can be downloaded through the TSP: http://tsp.esta.org/tsp/documents/published_docs.php)

Depending on the installation environment, multicast can be a networking challenge - enterprise networks are often configured to block or severely limit it and implementation in such an environment is likely to require a discussion with the client's IT people...

If the network has IGMP properly configured, even on the same subnet, you won't get the multicast data unless you've sent the switch the relevant IGMP packets and asked for it...
Note that IGMP is a layer 2 protocol, not a layer 3+ protocol, which may affect the ease of implementation - there may however be existing mechanisms in place in the relevant ecosystem that reduce it to a call of some system function...

(Jay, as a network guy, I'm assuming you're all over this - but wanting to ensure a complete set of info for future readers...)
 
Last edited:
(The below is not relevant to ArtNet)

A multicast sender can just send multicast UDP packets blindly. There is no need to "warn" the network in any way.

A multicast receiver should send periodic IGMP Join messages to the network to inform it that reception of a particular multicast group is desired. IGMP is a protocol on top of IP.

Basic ethernet switches treat multicast frames as broadcast frames, sending them to everyone on the LAN segment. More advanced switches may perform a function called IGMP-snooping to try and limit the amount of unwanted traffic sent by listening to the IGMP joins to work out who really wants to hear each multicast group.
 
Not for the true geeks on this thread, but for those monitoring it, if you want an explanation of IGMP etc., check out the video I did here. The follow on video shows a real-world example of how this helps with large numbers of xDMX universes.
 
There's another stumbling block in this, as it turns out. The licensing for the Zigbee stack has a buy-in requirement to get the spec that's incompatible with the GPL, so there's no kernel drivers for ZHA, ZLL, and the like; you have to build them on top, or buy a dongle with the stack built in; I'm still trying to get a solid handle on the market and where the layer fences are.

But yes, such a gateway would have to send IGMP buy-in's back to the LAN.

Do switches propagate those back upstream automatically?
 
Yes, when properly setup, IGMP should traverse the tree back to the IGMP querier in the subnet, but as always, with managed switches along the way things are configurable and thus breakable...
 
I was wondering why the O.P. wanted zigbee support.

Also, an observation:

IP Multicast is generally broken (ie, not configured properly) within routers that make up networks if multicast support wasn't a requirement mandated during the original network build.
 
Lyle: I'll take any wireless protocol for which there are dimmers available which can fit in a 1-gang box and carry 1kw. Zigbee simply happened to be the protocol attached to the first ones I found.

You have other suggestions? :)
 

Users who are viewing this thread

Back