I have some DMX lights I'd like to control through my hub. Currently they are interfaced through an ElectricIMP based setup I hacked together years ago. It works okay using a purpose built HTTP API but I'd rather have local control instead of cloud.
It looks like Art-Net would be the best way to interface these sorts of devices with HE. I haven't been able to find any discussion around this, but figured I'd see if there is any interest in an Art-Net app for HE. I'm still learning the HE APIs, but I think a reasonable architecture would be to create an App which could be used to register Art-Net nodes, the DMX universes controlled by them, etc. The app would then allow you to create child devices with different capabilities depending on how they were setup (e.g. simple dimmer for a single channel, RGB/W for 3,4 and 5 channel lights, etc).
I know people do all sorts of things with individually addressable segments of light strips, pixels, moving heads, and all the effects you can build around more sophisticated devices, but figured I'd start with simple light control and take it from there.
Does this sound useful to anyone? What features would you like to see in an Art-Net app? Are there apps/drivers already built around this that I've missed in my searches?
Alright, cool. I'm doing some initial proof-of-concept work on this now. It looks like the biggest challenge will be around timing and performance. Unlike other higher level control protocols, Art-Net needs the controller to send frames in real-time in order to get things like fades right. The target for DMX is 40 frames per second. Just blasting packets as fast as possible in a loop is giving me high enough frame rates up to about 128 channels, although I doubt this would "play nice" if other activity were going on in the hub.
Also, since multiple child devices will all be contributing to each frame, I'll need a parent device driver for each Art-Net DMX Universe with child devices for the HE exposed devices (supporting set level, color, etc).
Any good references on creating tight event loops for sending UDP packets? Since Art-Net nodes will "hold" the most recent values, this high rate sending will only be needed while one or more child devices are in progress of a transition.
I'm so delighted to discover this thread! I have an application to light a Living Wall. It is lit with some ETC Irideon fixtures, which are of course DMX controlled. I need to mimic the sun - come up slowly in the morning, and fade out at sunset. (And ideally throw in some random bad weather days). Being able to do DMX control from a Hubitat would be an extremely easy way to do this.
I got an initial proof-of-concept driver running that can send art-net frames to a static IP address from Hubitat. Art-net seemed like the best route to go since it is the de-facto standard for sending DMX over local networks. There are a number of commercial interfaces available, or you can go the DIY route with something like
github dot com /mtongnz/ESP8266_ArtNetNode_DMX
Where I ran into some challenges had to do with handling things like fades. Art-net is a fairly dumb protocol, you need to send each frame at the right time and have good control over timing in order to achieve smooth effects. Additionally, each art-net frame needs to contain the entire DMX universe, and although you can "stop early" if your universe doesn't have all 512 channels, I didn't find anything in the protocol that lets you skip lower addresses if, e.g. you only want to send changes to channel 100.
Essentially, the Hubitat network API seems a bit too high level to be able to generate a clean 24 fps across 512 devices. The amount of encoding/decoding I have to do just to send raw bytes to the network is causing performance issues. If I limit the universe size to something like the first 32 addresses, it seems to work okay, although again, since Hubitat isn't a real-time system, other system activity can interfere with frame rates. Additionally, blasting out network packets at the required rate is also somewhat taxing on the system. Finally, I don't see a good way to control the timing of these packets...in my proof-of-concept attempt, I tried using scheduling ( runInMillis ) for the "off" command and just blindly send as-fast-as-possible for the "on" command. It achieves a smooth fade, but controlling the rate of the fade is where things get tricky.
Since it seems like there is interest, I'll go ahead and post my code. At the very least it includes examples of how to send Art-Net packets using Hubitat. I hadn't bothered making a proper app-with-child-devices given the limitations I mentioned. For this thing to be useful, there would need to be an app where you could map DMX addresses into various hubitat devices (e.g. single channel for a light, 3 channel RGB, other combinations for color temp control, etc.). In order to work well with multiple channels, there would need to be one central app (or one per universe) generating frames, with multiple hubitat devices contributing "transitions" to that frame generator.
github dot com /supercargo/hubitat-artnet/blob/master/artnet-device-poc.groovy
Great! If you find some subset of the functionality I was going for to be useful, Iām happy to take PRs or try to make more of a proper app. Also, for testing and development, I found light jams useful...easier to debug with than live hardware.
