Request - Default OLA plugins to FTDI devices - Ability to Enable/Disable plugins through Rocket Show

[DavidOpgh]

IMO one the biggest challenges to getting RS up and running appears to be the OLA Plugins.

I request changing the default enabled OLA Plugins to support FTDI USB DMX interfaces.
Maybe have a radio button selector to choose between a handful of popular interfaces that would enable/disable the needed plugins.

I would also request the ability to show the list of loaded OLA plugins and their state with a selector to enable/disable them through RS.

Something like this would make it so much easier for users. There wouldn't be a big need to SSH or log in locally to the Pi.

[moritzvieli]

@DavidOpgh Agree. I assumed, requests like this will come in the future. We need to make sure to not duplicate the OLA interface in Rocket Show, because this would be too much. But the common use cases should be covered. I need to research deeper into this topic (I don't even know what FTDI is).

[DavidOpgh]

@moritzvieli
FTDI is nothing more than a chip made by Future Technology Devices International used in the inexpensive Open DMX interfaces including the ENTTEC Open DMX USB interface. Also might be referred to as a FT232 USB UART interface
https://opendmx.net/index.php/Open_DMX_USB

IMO new users should be able to plug in one of the these inexpensive FTDI Open DMX interfaces and have RS work, something it doesn't do now. To use a FTDI interface users not only need to understand how to enable/disable OLA plugins but also how the FTDI plugin conflicts with other plugins. What I found in the current OLA implementation used by RS the user needs to disable 3 OLA plugins (because of conflicts) and enable the FTDI plugin (which is currently disabled by default) to get a FTDI interface to work.

IMO this makes RS very difficult for a lot of potential users to implement when it doesn't have to be.

The main issue that needs to be addressed is making RS support FTDI interfaces by default.

To do that I found these 3 plugins need to be disabled
Plugin - StageProfi Id=8
Plugin - Enttec Open DMX Id=6 (Yes, I know it's surprising that this plugin doesn't work with the ENTTEC OPEN DMX USB interface)
Plugin - Serial USB Id=5

using these commands
ola_plugin_state -p8 -sdisable
ola_plugin_state -p6 -sdisable
ola_plugin_state -p5 -sdisable

And this FTDI plugin needs to be enabled
Plugin FTDI USB DMX Id=13
ola_plugin_state -p13 -senable

After giving it a little more thought this is how I might go about implementing it in RS
a) On initial startup RS would disable the Plugin StageProfi Id=8. This plugin was causing issues.
b) RS would have a check box on the Settings.Lighting page with the label FTDI Open DMX USB interface.
The default state would be checked.
When the box is checked RS would disable the Enttec Open DMX and Serial USB plugins and enable the FTDI plugin
c) When the user unchecks the box RS would disable the FTDI plugin and enable the Enttec Open DMX and Serial USB plugins

Users with FTDI interfaces would then be supported in RS by default. Users with interfaces requiring the Enttec Open DMX and Serial USB plugins would just need to uncheck the box and reboot. Users with StageProfi interfaces would have to enable the plugin manually.

After thinking about it more I agree there is no need to implement a more robust OLA interface at this time unless there are more issues with the OLA plugins and USB DMX interfaces. From what I've seen these are the only plugins that have conflicts.

[DavidOpgh]

After thinking about it more I believe the complete solution based on my findings would be:

A radio button control on the Settings.Lighting page with the label "DMX Interface" and 3 options.
FTDI Open DMX USB (default)
Enttec Open DMX and Serial USB
StageProfi and all others

Option FTDI Open DMX USB would
disable
Plugin - StageProfi Id=8
Plugin - Enttec Open DMX Id=6
Plugin - Serial USB Id=5
enable
Plugin FTDI USB DMX Id=13

Option Enttec Open DMX and Serial USB would
disable
Plugin - StageProfi Id=8
Plugin FTDI USB DMX Id=13
enable
Plugin - Enttec Open DMX Id=6
Plugin - Serial USB Id=5

Option StageProfi and all others would
disable
Plugin FTDI USB DMX Id=13
enable
Plugin - StageProfi Id=8
Plugin - Enttec Open DMX Id=6
Plugin - Serial USB Id=5

[moritzvieli]

Enhancement in OLA required: OpenLightingProject/ola#1979

[DavidOpgh]

Thanks for the update. The new OLA UI for Pi5 helps mitigate this issue.
The Startup Guide helps for the Pi4.

It would be helpful if the Settings.Lighting page would at least show you what Output port DMX device Rocket Show thinks is connected instead having to go to the OLA Settings.

[moritzvieli]

@DavidOpgh Not sure, whether those 3 options would cover all use cases/devices properly. I'm currently thinking about an approach where only one plugin would be activated at a time and you'd have to select the most suitable option (or even get assisted by being able to select the device used, if it's a well-known one). Because currently there's no use case for rocket show to have more than one plugin activated imo.

What do you think?

[DavidOpgh]

I don't know if those 3 option would cover all the use cases.
All I can say is those 3 options covered all the interfaces I tested.
(And in the case of the DMXking UltraDMX Max it took an additional change to the ola-usbserial.conf file).

I agree there is no reason to have more than one plugin activated. Although having more than one active appears to cause no harm accept in the one case of FTDI devices (unless you have experience with other DMX interfaces?). The only instance having one plugin active at a time might be if you were testing out different interfaces, which would make you enable/disable different plugins.

The end result is to make it as easy as possible for a new user to connect a DMX interface. I would give the user the option to select from a well known interface or manually enable/disable plugins for a DMX interface that is not well known.

[moritzvieli]

@DavidOpgh Just implemented a simple select now on the test channel. Maybe you can check it. I found it difficult to add supported devices, because each one would be needed to test. So maybe, the users just need to try it out a little bit. But the switch is quite fast at least. Let me know, what you think.

[DavidOpgh]

OK - thanks! I'll check it out.

[DavidOpgh]

Checked it out the latest beta.

1. It would be helpful to have RS notify the user to reboot after making a change.

2. Looks to be an issue when RS needs to access the DMX device.
   Playing a composition without DMX lighting works fine.
   But RS throws an exception when trying to play a composition with DMX lighting. Here is the relevant portion of the log file.

FYI - The OLA server seems to be working fine. I can use the Console web page to send DMX signals manually to the device.

2024-11-11 11:37:54.227 INFO c.a.r.a.TransportController : Received API request for transport/play
2024-11-11 11:37:54.259 INFO c.a.r.p.CompositionPlayer : Designer project found. Load it...
2024-11-11 11:37:54.260 ERROR c.a.r.a.DefaultControllerService : An exception has been thrown in the controller

java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because "repeatFor" is null
at com.ascargon.rocketshow.lighting.designer.DefaultDesignerService.getPixelKeysInOrder(DefaultDesignerService.java:1137)
at com.ascargon.rocketshow.lighting.designer.DefaultDesignerService.fixtureHasGeneralChannel(DefaultDesignerService.java:1324)
at com.ascargon.rocketshow.lighting.designer.DefaultDesignerService.updateCachedFixtures(DefaultDesignerService.java:1340)
at com.ascargon.rocketshow.lighting.designer.DefaultDesignerService.load(DefaultDesignerService.java:1378)
at com.ascargon.rocketshow.play.CompositionPlayer.play(CompositionPlayer.java:643)
at com.ascargon.rocketshow.play.DefaultPlayerService.play(DefaultPlayerService.java:229)
at com.ascargon.rocketshow.api.TransportController.play(TransportController.java:48)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1071)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:964)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:696)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:779)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:177)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:840)

2024-11-11 11:37:54.273 INFO c.a.r.a.TransportController : Received API request for transport/stop
2024-11-11 11:37:54.278 INFO c.a.r.p.CompositionPlayer : Stopping composition 'Don't Let The Sun'
2024-11-11 11:37:54.426 INFO c.a.r.p.CompositionPlayer : Composition 'Don't Let The Sun' stopped

[peternewman]

Just to say, OLA provides the conflicts field in PluginStateReply to let you know what plugins you need to disable to enable the one you want to:
https://github.com/OpenLightingProject/ola/blob/c4adb5034feddeaea32cb4554ef00837dbbcbec9/common/protocol/Ola.proto#L197

I'm currently thinking about an approach where only one plugin would be activated at a time and you'd have to select the most suitable option (or even get assisted by being able to select the device used, if it's a well-known one). Because currently there's no use case for rocket show to have more than one plugin activated imo.

If your software only handles one universe, or your users are only likely to need it, that should be fine.

(And in the case of the DMXking UltraDMX Max it took an additional change to the ola-usbserial.conf file).

You could leave that option permanently enabled, but USB Serial will then conflict with FTDI (which is fine if you only ever enable one plugin at a time).

It may be worth a forth option where Rocket Show doesn't touch the OLA config at all and just sends on a universe of the users choice, for more advanced users who want to do something more complicated with the OLA backend (e.g. DMX over IP or multiple interfaces etc).

P.S. Your visualiser/designer is very impressive and it's great to see the Open Fixture Library data being used too!

[moritzvieli]

@DavidOpgh Thanks for testing! Can you export the designer project for me? Seems like there's an issue with a fixture.

@peternewman Thanks a lot for your input! Highly appreciated!

[DavidOpgh]

@moritzvieli - Never mind. It is working correctly. It was an issue with the PI5 I set up for testing.

Once I opened the Designer project I got the notification about it being migrated. I just saved the project and the composition played without issues.