Hi
Following on from this issue :- https://groups.google.com/forum/m/#!topic/openremotecommunity/m5oLWGeFdbM
I've got a situation where an ART-Net to DMX (or SPi) adapter has been given a new firmware to allow it to be controlled by simple HTTP commands.
http://m.ebay.co.uk/itm/DMX-512-controller-Art-Net-sACN-E1-31-6-output-input-ports-ArtNet-Ethernet-/321060993223?nav=WATCHING_ACTIVE
The http requests look like this :-
Http://ip_address:80/pixel.api?uni=0&oncolour=4488ff&start=1&end=170
This version of that request is used with the colour picker:-
Http://ip_address:80/pixel.api?uni=0&oncolour=${param}&start=2&end=7
When sent any number of HTTP requests from Simple HTTP request app on any of my Android devices, or from any web browser, the box responds perfectly, repeatedly.
https://play.google.com/store/apps/details?id=ch.rmy.android.http_shortcuts
(This app is fabulous at sending simple requests to an OpenRemote controller, I've got shortcuts that set dimmer levels or 'click' on macro buttons)
So my question is this...
Why...
When I use a colour picker in OpenRemote to send an RGB Pixel request to the DMX box does the box lock out after 2 requests?
FYI, because the box is primarily a dedicated ART-NET interface, it's restricted to a maximum of 2 simultaneous connections. (No authentication)
From an uneducated position, it would appear that the OpenRemote controller is attempting to create and maintain a fresh connection for each command.
Is this the case?
If so, how can I force OR to close each connection, or use only 1 connection?
Many thanks,
Stuart
It seems that the HTTP connection is not closed properly in the OpenRemote HTTP protocol implementation. I’ve fixed that in the GitHub repository. You could build the controller with the following commands :
Get code from GitHub:
git clone https://github.com/openremote/Controller.git
``
Build controller
./gradlew clean controller
``
If you have problems building the controller I’ll send you the controller executable for testing.
Hi,
I'm amazed that you've found an issue in the controller, I was convinced it was something I was doing wrong.
Could you email me a link to a downloadable ZIP of the controller please, I've tried compiling things before and it's beyond my skill set.
Many thanks,
Stuart
Hello
So, it tried to compile the new controller 
And once I'd found Gradlew, the machine seemed to do lots and lots of functions.
My newbie question is....
Where did it put the new controller?
I've ran a locate search for OpenRemote* and all it returned was the locations of the controller that was already on the machine.
/opt/OpenRemote-Controller-2.5.0
Thanks for your help.
If you’ve checked out the controller source from GitHub to the directory /Users/Stuart/Development/Controller (just an example - your directory differs) and the Gradle build was successful you’ll find the build result (OpenRemote-Controller-2.5.0.zip) in the directory /Users/Stuart/Development/Controller/controller/build/distributions. That means the Gradle build does not install the controller.
You can find a description of the build process in the file /Users/Stuart/Development/Controller/README.md
Excellent answer
Many thanks.
I'm in the process of loading it right now
I'm not in the office at the moment, so I can't check if it'll work, I'll do that when I'm next stood in front of the DMX lights.
A million thanks for your efforts
Hi
One small observation..
The velbus-1.2.1.jar file seems to be missing from the lib folder.
The velbus.properties file is present
I've dropped a copy of the jar file in with the others, is there anything else I need to do?
(I'll sync the controller with a Velbus OR design and give it a try)
Thanks,
Stuart
FYI
Adding the Velbus Jar file did the trick.
All I need to do now is stand in front of the DMX lights and check the HTTP commands
Thanks
Hi
I can confirm that I can now send endless colour picker and 0~255 commands to the HTTP controlled DMX or SPi boxes.
Thanks a million
All I have to do now is write up the how to 