Is there any standard lighting controlling protocol over USB?

[technix]

I have submitted my USB lighting controller to manufacturer, and now it is up to the software.

Is there any standard lighting controlling protocol based on USB, like some kind of DMX512- or DALI-over-USB? Or it is up to myself to create a HID-compatible protocol for this?

[mrpackethead]

I have submitted my USB lighting controller to manufacturer, and now it is up to the software.

Is there any standard lighting controlling protocol based on USB, like some kind of DMX512- or DALI-over-USB? Or it is up to myself to create a HID-compatible protocol for this?

No DMX over USB standard.

[jav]

Is there any standard lighting controlling protocol based on USB, like some kind of DMX512- or DALI-over-USB? Or it is up to myself to create a HID-compatible protocol for this?

You can start on the Power Device HID and build on top of it.

[dmills]

Given a suitable HID->RS485 UART USB->Serial type thing you can do DMX directly over the virtual serial port....

You need to be able to select 250KBaud, 8N1 and having a better way to generate a break then changing the baud rate and sending a 0 is helpful, but that does work (Watch the mark after break timing specification).

Other then that I am not aware of anything particularly standard for USB, but I suppose if your device pretended to be an ethernet port you could fire art-net or even s-ACN at it, and most modern controllers will talk art-net.

Regards, Dan.

[ajb]

What sort of "lighting controller" is it?

Basically, if there's not a USB class for it, you're on your own.  It doesn't make a lot of sense to standardize things like lighting control protocols at the USB link because no one's running USB to link up hundreds of fixtures through a whole building.  They're using DALI, or something over RS-485 (like DMX, or one of the building automation systems), or something over Ethernet (ArtNet, E1.31).

Enttec's DMX USB interface is documented--they use an FTDI chip (a FIFO, I think?) that shows up as a virtual COM port, and the command set for it is described in their developer documentation.  I wouldn't be surprised if DMXKing et al used compatible interfaces, but I haven't looked into it.  That's probably the closest thing to a "standard" USB interface for lighting.  The really cheap USB DMX interfaces are usually just a USB-UART bridge IC and an RS485 transceiver, with the host handling the break/MAB timing.  If you wanted your device to be able to be controlled by existing lighting control software, your best bet is probably to go the USB CDC route, and be prepared for the software to send raw DMX through it.  Or you could emulate an Enttec or other device, but you'd probably also have to spoof their VID/PID to get the software to work with it.  Much of the free/cheap lighting control software will work with the Enttec or direct UART interfaces, but the professional level stuff usually only works with manufacturer-specific interfaces, as the interface also serves as a de facto license dongle for the software.

[Rasz]

the small matter of USB cable length consideration makes any DMX aspirations rather pointless.

[technix]

What sort of "lighting controller" is it?

Basically, if there's not a USB class for it, you're on your own.  It doesn't make a lot of sense to standardize things like lighting control protocols at the USB link because no one's running USB to link up hundreds of fixtures through a whole building.  They're using DALI, or something over RS-485 (like DMX, or one of the building automation systems), or something over Ethernet (ArtNet, E1.31).

Enttec's DMX USB interface is documented--they use an FTDI chip (a FIFO, I think?) that shows up as a virtual COM port, and the command set for it is described in their developer documentation.  I wouldn't be surprised if DMXKing et al used compatible interfaces, but I haven't looked into it.  That's probably the closest thing to a "standard" USB interface for lighting.  The really cheap USB DMX interfaces are usually just a USB-UART bridge IC and an RS485 transceiver, with the host handling the break/MAB timing.  If you wanted your device to be able to be controlled by existing lighting control software, your best bet is probably to go the USB CDC route, and be prepared for the software to send raw DMX through it.  Or you could emulate an Enttec or other device, but you'd probably also have to spoof their VID/PID to get the software to work with it.  Much of the free/cheap lighting control software will work with the Enttec or direct UART interfaces, but the professional level stuff usually only works with manufacturer-specific interfaces, as the interface also serves as a de facto license dongle for the software.

The lighting controller switches an IKEA USB lamp (or PWM dim it...)

I do need proper in-microcontroller USB as it is part of my USB KVMP switch tree. Both the host software and the device need to be aware when the KVM switch button is pressed, disconnecting my monitor and all USB peripherals attached on it from one computer and connecting those to another. The lamp is clipped on the corner of the monitor, so it do need to be synchronized with the rest of the monitor.

[funkathustra]

The lighting controller switches an IKEA USB lamp (or PWM dim it...)

There isn't a class-compliant protocol specific to this. This is a perfect candidate for an "HID Generic" device.

Though, honestly, these days I prefer doing vendor class, instead of HID class, for these sorts of devices (as we were discussing in your USB MCU thread). Vendor class gets you access to bulk IO (which is exactly the sort of transfer you want for your device), and works well across operating systems.

Which host operating systems do you have to support? You mentioned KVM, so I assume there's multiple.

HID in Linux is a little clunkier than vendor classes, as you have to load udev rules for assigning the "hidraw" driver to the device, otherwise the kernel gobbles it up, if I remember correctly. Vendor-class devices can be opened directly by LibUSB (only subject to typical device permission issues... bah).

In Windows, it's the other way around: HID devices will instantiate without issues, but vendor-class devices need drivers. The best way is to add the WinUSB descriptors to the firmware to get WinUSB.sys to load without having to screw around with INFs / code signing certificates (though it's really not the end of the world to self-sign a certificate for use on your local machine, and programs like Zadig will do this whole process for you).

In macOS, IOKit is fairly easy to make work with either device class.

While both HID Generic and Vendor-class devices let you send and receive arrays of bytes up through userspace, they have very different APIs across the operating systems, so you may want to do a bit of research before committing!

[technix]

The lighting controller switches an IKEA USB lamp (or PWM dim it...)

There isn't a class-compliant protocol specific to this. This is a perfect candidate for an "HID Generic" device.

Though, honestly, these days I prefer doing vendor class, instead of HID class, for these sorts of devices (as we were discussing in your USB MCU thread). Vendor class gets you access to bulk IO (which is exactly the sort of transfer you want for your device), and works well across operating systems.

Which host operating systems do you have to support? You mentioned KVM, so I assume there's multiple.

HID in Linux is a little clunkier than vendor classes, as you have to load udev rules for assigning the "hidraw" driver to the device, otherwise the kernel gobbles it up, if I remember correctly. Vendor-class devices can be opened directly by LibUSB (only subject to typical device permission issues... bah).

In Windows, it's the other way around: HID devices will instantiate without issues, but vendor-class devices need drivers. The best way is to add the WinUSB descriptors to the firmware to get WinUSB.sys to load without having to screw around with INFs / code signing certificates (though it's really not the end of the world to self-sign a certificate for use on your local machine, and programs like Zadig will do this whole process for you).

In macOS, IOKit is fairly easy to make work with either device class.

While both HID Generic and Vendor-class devices let you send and receive arrays of bytes up through userspace, they have very different APIs across the operating systems, so you may want to do a bit of research before committing!

I am going to use libusb regardless (since it works under all three OS with the same API) so is vendor class with WinUSB descriptor the best choice?

[funkathustra]

I am going to use libusb regardless (since it works under all three OS with the same API) so is vendor class with WinUSB descriptor the best choice?

Yes. Which microcontroller did you settle on? Some of them have out-of-the-box demos with built-in WinUSB descriptors you can copy.

[technix]

I am going to use libusb regardless (since it works under all three OS with the same API) so is vendor class with WinUSB descriptor the best choice?

Yes. Which microcontroller did you settle on? Some of them have out-of-the-box demos with built-in WinUSB descriptors you can copy.

STM32F042F4P6. Are there any WinUSB demo that does not involve Keil and hopefully not Cube? (My dev tools are based on GCC, Eclipse CDT and GNU MCU Eclipse.)

[funkathustra]

STM32F042F4P6. Are there any WinUSB demo that does not involve Keil and hopefully not Cube? (My dev tools are based on GCC, Eclipse CDT and GNU MCU Eclipse.)

Check this out: https://code.google.com/archive/p/found-bits/wikis/STM32F4WinUSBComm.wiki
Blog post: http://searchingforbit.blogspot.com/2014/05/winusb-communication-with-stm32-round-2.html

TLDR: you have to add a few extra descriptors to your device that Windows can sniff to learn that it needs to load winusb.sys without user intervention. These extra descriptors have nothing to do with the actual USB bulk I/O endpoint operation --- it's just to tell Windows to automagically load winusb.sys for the device.

It's a bit convoluted and totally optional if you have administrative access of the computer, in which case, you can just use Zadig to load the WinUSB driver (or the old-school libusb-0.1 or new libusbk driver). But the WinUSB descriptors-in-firmware route is far superior, as your driver will always load (even if you switch ports, which can confuse Zadig). It's also one less step you have to do on the host.

When I build products, they use WinUSB descriptors, because I don't want my customers to have to fuck around with that stuff.

By the way, you probably noticed I mentioned Zadig can load both winusb.sys and libusb.sys. Any libusb-win32 / libusb-0.1 thing you see is for the *old* version of libusb. Modern versions of LibUSB use WinUSB as a backend on Win32 platforms, so I recommend using the WinUSB driver. You should know the existence of the libusbk project, which provides a high-performance USB driver for userspace access. It's another driver option, but not really necessary for your project.