Multicast routing and DMX (E1.31 / SACN)

cdosrun

Enlightened
Joined
Sep 22, 2006
Messages
369
Location
West Sussex - England
Apologies as this may be a long one.

I am setting up DMX controlled lighting at home using one of those cheap 4 universe eBay E1.31 gateways. The DMX then drives some LED multichannel drivers for LED strips on the wall (in some aluminium profile) so there is a CPF link somewhere.

Currently, the system is controlled by an openHAB server (running on a Raspberry PI temporarily but I will move this to a virtual server on the infrastructure in due course).

The network infrastructure comprises a Unifi wireless setup with a HP 3800 managed switch (j9575a) running firmware 16.01.0006. There are multiple VLANs in use on both the wifi and wired networks with assignment by RADIUS (albeit not necessarily relevant to the problem). I am segregating all devices (IOT) into different networks for security (I have separate VLANs for storage, servers, users, guests etc. and for network devices requiring internet such as the TV and Amazon Firestick and a separate VLAN for devices requiring only limited LAN access - such as for the squeezebox players and the home lighting). THe switch performs all inter-VLAN routing with ACLs setup to limit traffic between VLANs. All networks are dual-stacked with IPv4 and IPv6. There is then a separate VLAN from the switch into the virtual server running SophosUTM for the gateway firewall. Hopefully that makes sense but it is only to provide some background.

The E1.31 protocol uses multicast UDP port 5568 to address 239.255.x.x (x.x being the universe address, e.g. 0.2 in my current case).

I have enabled IGMP on the switch and when the gateway and controller are on the same VLAN, everything works. However, where the controller and gateway are on different VLANs (and subnets) nothing works. I have enabled PIM-Sparse mode on the switch and set up BSR and RP-Candidates to one of the VLANs but I cannot get any multicast traffic to route between the VLANs. I have included a static group (239.255.0.2) on both the controller and gateway VLANs. I have removed the ACLs but that does not seem to be the problem either.

Here is the output from the switch from command "show ip igmp"

This is the controller VLAN

VLAN ID : 87
VLAN Name : IOT-LAN
IGMP version : 2
Querier Address [this switch] : 172.27.87.254
Querier Port :
Querier UpTime : 4d 7h 10m 14s
Querier Expiration Time : 0h 0m 26s


Active Group Addresses Type Expires Ports Reports Queries
---------------------- ---------- --------------- ---------- ------- -------
239.255.0.2 Static 0h 0m 0s 0 0
239.255.255.250 Filter 0h 8m 57s 7 165 0



This is the gateway VLAN


VLAN ID : 89
VLAN Name : Devices
IGMP version : 2
Querier Address [this switch] : 172.27.89.254
Querier Port :
Querier UpTime : 4d 7h 5m 24s
Querier Expiration Time : 0h 1m 5s


Active Group Addresses Type Expires Ports Reports Queries
---------------------- ---------- --------------- ---------- ------- -------
239.255.0.2 Static 0h 0m 0s 0 0
239.255.255.250 Filter 0h 9m 58s Trk3 2949 0




There are not any queries so I think there must be something wrong but I cannot find any filtering going on.

The multicast routing table does not show any traffic for the multicast address: (show ip pim mroute)

IP Multicast Route Entries


Total number of entries : 1


Group Address Source Address Neighbor VLAN
--------------- --------------- --------------- ----
239.255.255.250 172.27.90.102 172.27.90.102 90



I have now exhausted everything I have read on multicast routing and would be really grateful for any thoughts anyone might have with this and apologies if I have missed something obvious - I just don't know anyone who knows much about this topic.


Thank you,

Andrew
 

HarryN

Flashlight Enthusiast
Joined
Jan 22, 2004
Messages
3,977
Location
Pleasanton (Bay Area), CA, USA
Hi, did you ever have any luck getting all of this to work?

The reason that I ask is that I am becoming increasingly involved in conversion van electrical projects.


These projects nearly always involve the need for LED light strips and dimming. Color / CCT changing would be a bonus.

Right now we are hard wiring them in but it is honestly a pain and it seems like a WiFi based DMX setup that is not internet connected would be a potential solution.

I found some simple concepts on SuperBrightLEDs.com for wireless but durability in a mobile environment was not so clear.

LEDSupply.com for DMX but it was not wireless based.

Thanks.

Harry
 

cdosrun

Enlightened
Joined
Sep 22, 2006
Messages
369
Location
West Sussex - England
Hi Harry,

Yes everything works happily enough and has been for a while now. What I couldn't achieve was to have the multicast DMX signalling working across VLANs with that particular DMX gateway. Instead, the server just has another virtual interface on the VLAN with the DMX controller for now. I have bought another DMX gateway though and will try that out when I have a little time.

I have used a number of the cheap wireless DMX boards from eBay. I haven't found them to be especially long-lived and possibly a little sensitive to temperature and voltage spikes - a small separate regulator addressed the latter issue but they still seem to die at the rate of one per year for the unit in the garage. I had one indoors and it did not fail hence the assumption of temperature sensitivity.

Depending upon your requirements, perhaps a small Espressif based Wifi-DMX bridge would be the simplest approach, there is such a project here https://robertoostenveld.nl/art-net-to-dmx512-with-esp8266/ although I have not tried it. With this, a smartphone could control the DMX directly.

Otherwise, what are you using for control, a server-based approach?

Andrew
 

HarryN

Flashlight Enthusiast
Joined
Jan 22, 2004
Messages
3,977
Location
Pleasanton (Bay Area), CA, USA
Thanks for the information. That is a very helpful project.

I am slightly more familiar with the beagleboard but there are definitely plenty of aurdino users around. The nice thing about the beagle is that both analog and digital I/O are on board, maybe this has changed.

I am really hoping to be able to "buy" a solution vs having to build it up. It is easy to underestimate what can go wrong inside of a vehicle that is in the middle of nowhere in either freezing cold or super hot weather.

A long time ago, I did some hobby wiring around the house using the buckpucks


The same company makes this DMX controller based setup but I have not used it:


______

I build a modular power system for vans that come in either 48 or 24 volt and then use a DC - DC converter so that they have 12 volt for the appliances that need it. The 48 volt DC also feeds a 2 kW inverter for 120 vac for those loads.

Inverters tend to have some standby power draw so a lot of people turn these off when not actively in use and try to use only DC based items when possible.

The lighting has been a mix of overhead puck lights and LED strips that often the customers just pick themselves and I help them with the installation. These are kind of a pain though, because the typical request requires putting switches / dimmers / fuses all over the place and running 3 wires to each dimmer + wires to the lights. Getting all of these wires around the van and into tiny locations can be quite inconvenient. So far it has all been hard wired solutions.

_____

There are a few networked lighting solutions for tougher environments, such as these canbus based setups and I am looking into this as an option:


Very robust design, but again - at least some controls wiring. Might be acceptable though.
______________

I strongly prefer to avoid anything that requires a phone application to work, but might end up there.

Right now I provide a small android tablet to monitor the power system and it works via WiFi and any browser, so much more robust and less dependent on on any particular software supplier and it's OS / browser type agnostic. The monitor has a small embedded web server and broadcast via WiFi. Can tie into a router or direct.

I definitely do not want to use any products that only work with Apple and Google software. It is just a trap and I have seen how quickly customers start to call and ask with help to solve phone software problems.
_______
 
Last edited:

HarryN

Flashlight Enthusiast
Joined
Jan 22, 2004
Messages
3,977
Location
Pleasanton (Bay Area), CA, USA
I am really just in the "studying what is out there "stage for wireless control and avoiding as much wiring as possible.

I started looking at this outfit just because I purchased some strip lights from them in the past:



They also make some simple wireless setups that look like they are for in - home / teen use that provides RGB-W control for dimming, CCT, etc.


__________
More examples:

https://www.blizzardpro.com/collections/led-ribbon/products/komply-remote

But really still just controlling one light or strip.

It would be nice to be able to control 3 - 6 lights or light strips from 2 or 3 different locations. (so controller by rear door, side door, somewhere else) 12 / 24 / 48 volt would be nice, but if not, probably 12 volt only is good.


________________

This whole search escalated into the RC4 world


and W-DMX



Which are really pro level concert systems so now I have a ton of reading to do and no idea what makes sense at the moment.

____

It takes a lot of time to wire all of this stuff up and finding qualified help is challenging. For that reason, even if the setup costs $1000 vs $100 for wired it is worth it if it is robust and easy.

So - at this stage - really just opening doors and looking around at what is on the market.
 
Last edited:

LEDphile

Enlightened
Joined
Mar 8, 2021
Messages
315
Have you considered Zigbee-based devices, e.g. from the Hue Ecosystem? The Hue strips, and some of the table lamps, run on low-voltage DC from a wall-wart, and should be easy enough to integrate. And while there are apps for Hue, the API is open if you'd rather roll your own interface.

DMX, sACN, and similar protocols are intended for running highly dynamic lighting content, where real-time control with updates at sub-second intervals is required. For simple "set the lights to this fixed color and intensity", there are other options, especially for wireless, where high speed is costly.
 
Last edited:

HarryN

Flashlight Enthusiast
Joined
Jan 22, 2004
Messages
3,977
Location
Pleasanton (Bay Area), CA, USA
Have you considered Zigbee-based devices (e.g. from the Hue Ecosystem? The Hue strips, and some of the table lamps, run on low-voltage DC from a wall-wart, and should be easy enough to integrate. And while there are apps for Hue, the API is open if you'd rather roll your own interface.

DMX, sACN, and similar protocols are intended for running highly dynamic lighting content, where real-time control with updates at sub-second intervals is required. For simple "set the lights to this fixed color and intensity", there are other options, especially for wireless, where high speed is costly.

Thanks - I will look into that system.

I need to make sure that it will work without an internet connection.

I am pretty against the entire concept of IOT and zigbee but sometimes a person has to flex a little bit to make things work.

The operating conditions specs (indoor and somewhat limited temperature range) make that aspect more difficult but it might work for at least some projects.

You are right that the more advanced, professional protocols are focused on achieving highly responsive results. I can just imagine getting the slower stuff to work and then someone will ask for a party van setup with pulsing lights and music.
 

cdosrun

Enlightened
Joined
Sep 22, 2006
Messages
369
Location
West Sussex - England
Hi Harry,

If you are after a complete solution without too much 'DIY', I wonder if a DALI based solution might be relatively efficient. Osram, for instance, make a range of DALI based interfaces and controllers. They are commercial, many seem to operate at 24v and should hopefully be sufficiently robust for automotive use. However, this is a building lighting protocol and is not designed for rapid updates. It is primarily designed for on/off and dimming in line with room usage rather than shows but the advantage is that it supports multiple sources of control. Dali is convenient in that it is a simple two-wire, low speed, system operating manchester coding so it relatively immune to interference over unshielded cable.

DMX is great as a simple higher-speed protocol where there is one source and multiple sinks. You could have the disco type lighting effects more easily but the trade-off is that some more DIY is likely to be required. If you want multiple sources/switches then they will have to be linked to the DMX master which then controls the DMX lines - DMX does offer a two-way system but it is relatively limited.

You will have a much better understanding of the quiescent current requirements but I would not underestimate the drain from a commercial DMX driver when it is awaiting instruction (lights off). I would certainly contemplate switching the power line with the controller as well so that drivers are not powered unless required. Something like a Raspberry PI Pico or Arduino is likely to be better here for the actual control and perhaps the Beaglebone or higher-draw board used to configure the low-level controller but otherwise powered down.

I am entirely on board with the idea of wired instead of wireless, I always prefer a hard connection where possible. With this in mind I would conceive more readily available solutions using either DMX, DALI or WS2811/2 type control. The latter might be quite interesting as it is only a single-wire along with the power and would provide the opportunity for finely-grained control over the lighting if you can find/produce some suitable luminaires. I also believe it to be relatively low-drain.

Apart from DALI though, there would be two control busses. One between the switches and the controller and the other between the controller and drivers (with the WS8211/2 drivers typically being built into the individual LEDs).

As always, there is a bit of a compromise and here I suspect it is largely between:

1. Degree of custom work required (in order DALI probably easiest, then DMX and finally WS2811)
2. Speed of updates (DMX, WS2811 and DALI)
3. Multiple points of control (Built into DALI, further work required with DMX and WS2811)
4. Cost (commercial DALI is probably the most expensive but I haven't looked at prices more recently).

Just some thoughts.

Andrew
 

HarryN

Flashlight Enthusiast
Joined
Jan 22, 2004
Messages
3,977
Location
Pleasanton (Bay Area), CA, USA
Thank you for the inputs and ideas.

As time progresses, I am starting to better understand the needs and limitations.

Multi location control:

- From an RV / conversion van perspective, imagine that you might enter from multiple doors (drivers door, side door, back door, or be sitting in the back.
- Customers would like to be easily able to control the lights (multiple) from each location, not because the distances are large, but because it is difficult to maneuver in between them.

Wireless vs wired
- In some ways it doesn't matter
- The big potential benefit is ease of wiring
- In theory connecting wires is pretty easy
- In reality, the bulk of the effort is pulling out panels and cabinets or drilling holes in the allowed steel rib locations to push wires through fairly tiny passageways.

Phone applications based
- People like phone applications and it can be fun, but it is a major problem for installers
- Google and Apple want a cut (sometimes 40%) of everything under the sun.
- Any time that an installer bases a installation on a phone application, it inevitably results in having to help support the phone and interactions with other software
- It is a major source of pain and after installation costs which occur even if you have nothing at all to do with the issue
- It is also a major security problem because phone applications are the ultimate privacy breach, going after contacts, web browsing history, location data, etc.
- There is also the risk that the entire van auxiliary electrical system can be hacked this way. The result could be minor, or it could also result in them doing things like changing the charging parameters of the batteries and causing extensive damage.

This security aspect is the reason that I don't want a "phone software" based wireless solution.

Wireless is fine - just not phone / tablet based.


Wire durability
- In a moving vehicle, any wire that is less than 14 awg is a liability to durability
- It does not matter at all what the currents are - small wires are difficult to install and difficult to make durable in a moving vehicle (boat waves pounding, bumps, off roading)
- Any system that is limited to 18 or 24 awg type wires is unfortunately pretty much useless in that environment
 

HarryN

Flashlight Enthusiast
Joined
Jan 22, 2004
Messages
3,977
Location
Pleasanton (Bay Area), CA, USA
Capability
- For some applications, all that is needed is dimming
- Most lighting is going to be LED strip lighting as the fixtures are too bulky for van use
- In more sophisticated applications, customers will want to have a (cool white) + (warm white) + (colors) + (dimming). My belief is that this level is really the baseline that is useful.
- If it can "pulse with the music" that is even better, but potentially not critical

LED "ballast" / controller
- Most of the ones that I have seen with much control are pretty bulky
- This means that it is more likely for these to be remote mounted with multi conductor cabling to each fixture rather than the controller mounted near the light.
- I hope that I am wrong, but that is what I am seeing so far.

Temperature range and vibration resistance
- Still looking at this aspect
- Most of what I find is designed for an indoor environment that is roughly shirt sleeves temperature conditions
- A vehicle experiences deep freezing winters and the harsh heat of being parked in AZ in the summer outside.
- Temperatures commonly range from (-40 / - 50 C) to (+ 50 - 60 C)

Support
- I really don't have time to do custom software on a hobby level control device that I need to support
- My preference is to find what can be purchased
- Failing that , then I need to find someone with the time and inclination to do some coding / support related stuff who can be hired part time to pull it off and knows what they are doing vs my hack job stuff.

I appreciate the ideas suggested and am very open to further suggestions / details, as it is a lot to go through and find viable devices that can work under these conditions.

Probably nothing on the market will cover every one of these specs - for instance most likely I will need to be more tolerant of the temperature range capabilities.

Feel free to be very specific with links - I don't mind at all.

Thanks

Harry
 
Last edited:
Top