Related: esphome/esphome-core#25

@OttoWinter
Just trying to understand if I should attempt to build this or if it would be a waste of my time:

• ESP8266 + MAX485 to control a string of DMX lights

• Create a custom component in ESPHome using the DMXSimple library as shown in this video @ 10:20

Does anything hardware or architecture wise that would prevent me from getting this to work?

Does anything hardware or architecture wise that would prevent me from getting this to work?

No, it should work.

The library you pointed to however does not seem to support ESP devices, you probably need to use another one.

Last couple of evenings I have been working on implementing support to DMX512 protocol.

Here is the code for further discussion and perhaps future merge request.
Implementation was inspired by modbus code. Since DMX512 differs from standard UART, this implementation requires some hardware hack which uses a port to ground the data signal for protocol start sequence.

Example YML:

uart:
  tx_pin: D0
  rx_pin: D1
  stop_bits: 2
  baud_rate: 250000
  id: uart1

dmx512:
  id: dmx
  start_tx_pin: D6
  uart_id: uart1
  # TODO: add a update_every X seconds just in case something resets.
  # TODO: Currently I am sending a packet only when an update happens.

output:
  - platform: dmx512
    channel: 1
    double_channel: False
    universe: dmx
    id: dmx_1

light:
  - platform: monochromatic
    name: "Test Lights"
    output: dmx_1
    id: light_test
    default_transition_length: 2s

Any news on this? I'd be interested in this feature as well. ESP8266 + MAX485 is exactly the setup I have. I'm using https://github.com/mtongnz/ESP8266_ArtNetNode_v2 at the moment, but it's not very reliable in my experience as I get frequent reboots of the esp with flickering of the lights included. Also I'm already using esphome and an integration into it would be awesome :-)

Also interested in DMX output support!

I'm also very much interested in DMX support and I had a look at the current solutions. All have their drawbacks:

• @cupertinomiranda's solution requires an additional transistor to generate the necessary break signal.
• @jakosek's solution does not require additional hardware but is limited to the ESP8266
• I have a working solution without additional hardware, but it is limited to the ESP32

For the software side, the additional transistor is by far the simplest solution. All other methods to generate the break signal (88us low on the Tx line) that I am aware of are more workarounds and would require some nasty changes to the UART component.

@OttoWinter I'd be interested in what you consider the simplest / cleanest solution, or in other words: How to best implement this?

@andyboeh I'm on ESP32 too, look at dmx_no_uart branch. It uses most common ESPDMX library with no UART component as dependency. It should work both ESP32/8266. But still generates some stability issues...

IMO brake signal isnt problem at all, but sending DMX frame on every loop.

Ah, thanks for the hint, I didn't see your other branch! I'll have a look at it next weekend.

For testing purposes, I created a custom component for DMX512. It uses the internal UART and generates the break signal by detaching and attaching the pin from/to the pin matrix. It is limited to the ESP32 using the Arduino framework (it should also work using IDF, but this is untested. Requires a change in the config validation if you would like to try it).

Code, README and example: https://github.com/andyboeh/esphome-dmx512

For now, I didn't want to change anything on the ESPHome code, thus the TX Pin needs to be configured twice and you need to figure out which hardware UART is used (it defaults to 1, which is usually the case if serial logging is enabled).

I only did limited testing using a Lite-Puter DMX dimmer pack, I can't say anything about the stability.

@andyboeh this looks really awesome. I will find some time to play around with it!

I built a DMX library for ESP32 that runs on ESP-IDF and Arduino. Some of the feedback I received included interest in porting it to ESPHome. The issue for me is that I am completely new to the ESPHome environment and I'm still wrapping my head around how to get a custom component running. My library doesn't depend on any existing UART code - I wrote a completely new UART driver for it that runs on the ESP32 hardware. So my library doesn't depend on any existing UART driver. Any chance that could be helpful here? It doesn't run on ESP8266, but maybe it would allow for DMX input/output on an ESPHome release branch?

@someweisguy I'm not too familiar with ESPHome either, so what I'm doing might be wrong as well. However, my assumption is that every component that uses a hardware UART needs to go through ESPHome's UART implementation. Otherwise, the UART assignment is going to be messed up in case the user configures an additional UART.

That said, the main problem with using the ESPHome UART component is that it doesn't have support for sending the break signal. That's the reason for the awkward double-configuration of the TX pin in my implementation.

Your library supports a lot more than what I wanted to achieve - my goal is to be able to dim the living room lights :)

Also interested in DMX output support!

For the record, this is what I'm hoping to be able to use:

• https://shop.m5stack.com/products/atom-tail485?variant=32169041559642 (another option here)
• https://shop.m5stack.com/products/atom-lite-esp32-development-kit

This makes for a very compact and simple setup that could be easily powered/embedded into a dmx fixture. The downside is I don't have any flexibility on the circuit. (no transistor)

@andyboeh

I only did limited testing using a Lite-Puter DMX dimmer pack, I can't say anything about the stability.

I tried your external component against a chain of "4PCS DJ PAR Can 36 LED RGB Bühnenlicht DMX512 Disco Show Bühnenbeleuchtung DHL" (totally white label par lights) over about 25m and it works flawlessly, provided one terminates the DMX line.
The component itself is really easy to use, and mapping dmx channels to light components is fairly easy. It could use a dedicated dmx light component that takes the channels directly, but it's not really needed to get a few lights to work.

@andyboeh
Great work! On my setup I use 128 GPIO from i2c mcp expanders + about 40 dmx channels. On my code ESP32 sometimes crash. After exception decode, problem is HardwareSerial.end() and begin().
With Your code so far no errors have occurred, but I modified max channel. With full 512ch frame, on my setup as above, there was API reconnections loop. Probably full frame takes too much time blocking main loop.
Please consider adding setting for max channels, as DMX don't need full universe at once.

I have some kind of "throttling" functionality in the pipeline where it sends full frames only twice a second and not as fast as possible - I just haven't had the chance to test it (I'll push it afterwards). That would probably solve the problem as the .flush() calls are most of the time not needed. I'll try to make the "refresh rate" configurable.

Further, if I understood the protocol correctly, for new values it would be sufficient to only send the bytes up to the changed channel. That should improve the situation as well.

only twice a second and not as fast as possible

no, no - it should be as fast as possible - You could try add some transition to light - higher fps is better.
According to dmx timing, full 512 channel frame "takes approximately 23 ms to send, corresponding to a maximum refresh rate of about 44 Hz", but from esphome docs there is info that loop() shouldn't block longer than 20ms. In theory nothing happens if take some longer, but in practice I have API reconnections.

no, no - it should be as fast as possible - You could try add some transition to light - higher fps is better.

Maybe I wasn't clear enough about that: Changed values, i.e. transitions, are of course sent as fast as possible! But refreshing old / already set values can be slower.

@jakosek I just pushed the promised update:

• If values are unchanged, updates are sent roughly every 500ms
• Changed values are pushed immediately (transitions etc.)
• The message sizes is automatically adapted to the number of channels in use: If you only have one channel, the DMX messages are only 2 bytes long. That should improve performance!
• Tested with a meanLED S1-DR two-channel DMX dimmer

@andyboeh
Could you add an example board layout?
I have been having trouble getting this to work.

Could you add an example board layout? I have been having trouble getting this to work.

If it helps you, that's what is running well on my end: https://github.com/klaernie/esphome-configs/blob/main/dmx01.yaml

Could you add an example board layout?

What exactly do you mean, a schematic diagram? Or the configuration file? An example configuration file is provided in the github repository.

Could you add an example board layout?

What exactly do you mean, a schematic diagram? Or the configuration file? An example configuration file is provided in the github repository.

I’d love a schematic if you got one

I’d love a schematic if you got one

Please find attached the very simple schematic for the RS485 adapter that I'm using. A bit more background info: I use a WT32-ETH01 board that is plugged into a base board. On the base board is a 12-pin header where the RS485 adapter board is plugged into. The adapter board provides a RJ45 socket with the DMX signal. On the PCB, I also added a simple 3-pin screw terminal as an alternative.
I went for a SP3485 because it was in stock at the fab. If I'm not mistaken, it is pin-compatible with a MAX3485.

rs485_adapter.pdf

I'm pretty sure it's my electric skills that are failing me now :(
I am trying to use one of these max485 boards: https://protosupplies.com/product/max485-ttl-to-rs-485-interface-module/
I hooked up the DI to the tx_pin and the DE to the enable_pin. I'm leaving the RE and RO floating.
Unfortunately nothing happens. GND is connected to RJ45 pins 7 and 8, and A is pin 1, B is pin 2 (according to ESTA standard).
I hope someone here knows this particular max485 TTL board and can give some pointers on how to use it. I don't have a scope unfortunately, so cannot debug further.

I do appreciate your work with this module! Me failing is obviously a problem from my end.

only problem is that the dmx address is hard coded, so maybe its possible to change that too

Seems like channel calculation based on address is not supported but can be worked around with manual calculation. You jut have to keep in mind when you set up your light fixtures that the next free address number on the bus can be the address of the previous light + the last channel number of that light. This way you can daisy chain them with XLR cables and use one single ESP to control them all.

So for example the ADJ VBar Pak can be used in various modes, if you set them up to 8-channel mode (to access all the effects) you can set the address of the first one 1, the next one to 9, the third one to 17, fourth one to 25, using the buttons on each fixture.

Then in the config you'd have channels for the first one from 1 to 8, the second one from 9 to 16, third one from 17 to 24, forth one from 25 to 32.

According to @nagyrobi my DMX component also works on the ESP8266. I pushed support for it to to the main branch and I'd be happy to hear your feedback!

DMX with ESP8266:

daisy chained 4 fixtures, 8 DMX channels each

@nagyrobi fyi: The 120 Ohm resistor is already on the board (R7), at least according to the schematic (https://protosupplies.com/product/max485-ttl-to-rs-485-interface-module/). And there are pull-ups on RE and DE, so no need to connect anything unless you want to be able to disable the output.

Maybe also interesting to know for some people, there is also a 3v3 version of the max485 called max3485, so that one would be better for esp, also if you want to use the esp as slave for example then over time you won’t blow out the esp pins with 5V.

Yes, very true! I use the SP3485 which is the equivalent of Sipex.

I use the MAX485-M at 3.3V only and it works (on another modbus device too).

The 120 Ohm resistor is already on the board (R7)

Hm indeed. My previous experience a few weeks ago showed though that MODBUS communication CRC errors happen if I don't add the 120 Ohm resistor myself in parrallel with the connector.

I use the MAX485-M at 3.3V only and it works (on another modbus device too).

It's specified at 5V, so there is no guarantee that it works on 3.3V. Use the 3485 to be on the safe side.

Hm indeed. My previous experience a few weeks ago showed though that MODBUS communication CRC errors happen if I don't add the 120 Ohm resistor myself in parrallel with the connector.

Yeah, the exact value depends on your cables and your environment.

@andyboeh this works so well.
It's even possible to combine the various lights into partitions as single_light_ids and use them in sync, even on an 8266.

It's worth making this component as part of ESPHome @jesserockz

@nagyrobi if you have it running you should PR that component into ESPHome. I have no objections (unless the code is not up to scratch)

@nagyrobi @jesserockz I consider my DMX implementation a hack. The user has to configure the TX GPIO a second time and needs to know which UART number is in use. To implement that properly, changes to the Arduino libraries are necessary (see #1494).

It's a nice workaround and does nothing illegal IMHO.

@jesserockz I am considering creating a PR myself. Do you think it's worth creating one even though the UART number and TX pin have to be configured twice?

@nagyrobi I removed the picture of the module you are using from my Github as it contains some sort of watermark which led me to believe that there might be copyright issues with using that image. Do you have one where you're sure about the rights?

I'll make one

Here you go:

Hi guys I have an entire house with lighting based on DMX512, and I know my way around Arduino, C++ and Python. I'm also a programmer of many years experience. I'm fairly new to Home Assistant (just moved over from LinuxMCE), but I'm keen to help get this Esphome solution working, if I can. It seems to have stalled, because @andyboeh doesn't want to support what he considers a hack - fair enough. What can I do?

@Ajwardxxx Please read my comment just 3 posts above yours: I wanted feedback whether it would make sense to create a PR myself, but @jesserockz didn't find the time to reply. The component itself is working fine and all issues from March until now could be fixed by a proper configuration.

jesserockz, as one of the main devs from ESPHome is way too overwhelmed. He won't answer to such direct pings from anyone. The proper way to get stuff to his table is to prepare a normal PR (eventually marked as draft) + docs (there are many of us who can help with that). Development related questions can be asked on Discord where several dev contributors can offer support. When done with all of this, and tests run etc., PR can be marked for review and Jesse will put it on his todo list. Which, often is about several months long, but it's worth the patience.

The community, (including me) stated clearly that yes, this component definitely deserves to be part of ESPHome, and we are all appreciating you took the time to make it. I'm also actively using it.

Please come to Discord support chat and create a new thread with any direct questions you may have and you will get competent answers if uncertain about anything.

Submit your work as a PR and we'll all do our best together to make it into a release.

any progress on this project?? I have a fairly straightforward DMX setup (lights, lasers & dimmers) and want to go wireless. this seems like it would fit the bill perfectly.

Works perfectly as external component:

external_components:
- source: github://andyboeh/esphome-dmx512
  refresh: 300s

@andyboeh this is not a hack anymore, starting with 2023.12 ESPHome officially supports sharing GPIO pins between components. allow_other_uses: true is needed from now on, like:

uart:
  id: uart_bus
  baud_rate: 250000
  tx_pin: 
    number: GPIO2 #ESP8266, Wemos D1 Mini D4
    allow_other_uses: true
  stop_bits: 2

dmx512:
  id: dmx
  uart_id: uart_bus
  tx_pin: 
    number: GPIO2 #ESP8266, Wemos D1 Mini D4
    allow_other_uses: true
  uart_num: 1

Submitted PR to your external component repo.
I guess it's worth to submit this whole component to main ESPHome project, it's perfect...!

Thanks for the PR. Nevertheless, I won't submit - I don't have the resources to maintain it. Feel free to take over.