enttec dmx usb pro mk2

[ssm Binder]

hello
i am a new happy owner of an Enttec dmx usb pro mk2.
this component is managing 1 input + 2 outputs.
both outputs can work at the same time.

i have tried to enable only the frti plugin and here is the answer :
Feb 13 15:20:55 raspberrypi olad: PluginManager.cpp:105: Trying to start FTDI USB DMX
Feb 13 15:20:55 raspberrypi olad: FtdiWidget-libftdi.cpp:292: Found FTDI device. Vendor: 'ENTTEC', Name: 'DMX USB PRO Mk2', Serial: 'ENVWHX4E'
Feb 13 15:20:55 raspberrypi olad: FtdiWidget-libftdi.cpp:299: Unknown FTDI device with vendor string: 'ENTTEC'
Feb 13 15:20:55 raspberrypi olad: PluginManager.cpp:109: Started FTDI USB DMX

and no port is appearing in the ola's web interface

then, i have enabled all the plugins to see what is happening :
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:105: Trying to start Enttec Open DMX
Feb 13 15:27:15 raspberrypi olad: OpenDmxPlugin.cpp:78: Could not open /dev/dmx0 No such file or directory
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:109: Started Enttec Open DMX
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:105: Trying to start Serial USB
Feb 13 15:27:15 raspberrypi olad: WidgetDetectorThread.cpp:202: Found potential USB Serial device at /dev/ttyUSB0
Feb 13 15:27:15 raspberrypi olad: WidgetDetectorThread.cpp:208: new descriptor @ 0x1f1af68 for /dev/ttyUSB0
Feb 13 15:27:15 raspberrypi olad: WidgetDetectorThread.cpp:393: trying stage 0 for 0x1f1af68
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:109: Started Serial USB
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:105: Trying to start USB
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:109: Started USB
Feb 13 15:27:15 raspberrypi olad: PluginManager.cpp:94: Skipping FTDI USB DMX because it conflicts with Serial USB which is also enabled
Feb 13 15:27:16 raspberrypi olad: UsbProWidgetDetector.cpp:347: Detected USB Device: ESTA Id: 0x0 (), device: 0 (), serial: 0x2123691
Feb 13 15:27:16 raspberrypi olad: WidgetDetectorThread.cpp:333: Defaulting to a Usb Pro device
Feb 13 15:27:16 raspberrypi olad: DeviceManager.cpp:111: Installed device: Enttec Usb Pro Device:5-02123691

then i can see a "Enttec Usb Pro Device" in the web interface that looks like working.

2 questions :
- what is the best plugin to enable for this component ? (it looks like ftdi driver can not find this new name and serial usb looks like working)
- how to set the dmx output to use ? (the component has 2 dmx outputs and i can not see how to select wich one i want to use)

[Simon Newton]

Read the plugin descriptions - they explain what devices are supported
by each plugin. That said, your observation & conclusion is correct
:).

> - how to set the dmx output to use ? (the component has 2 dmx outputs and i
> can not see how to select wich one i want to use)

As far as I know the extended API for the Mk II is not public. When I
chatted to Nic (the Enttec owner) at LDI last year he wanted me to
sign an NDA to access it. You could try emailing Enttec and saying
that you want to use both ports of the Mk II with OLA but can't find
the API reference. See what they say.


Simon


> --
> You received this message because you are subscribed to the Google Groups
> "open-lighting" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to open-lightin...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[ssm2017]

here it is :
http://www.enttec.com/support-center/history/RFJ-63414-489

in the hope that they will find a way to allow us to use this component at its full capabilities.

2013/2/13 Simon Newton <nom...@gmail.com>

[Simon Newton]

On Wed, Feb 13, 2013 at 9:25 AM, ssm2017 <ssm...@gmail.com> wrote:
> here it is :
> http://www.enttec.com/support-center/history/RFJ-63414-489
> in the hope that they will find a way to allow us to use this component at
> its full capabilities.

Did you open a ticket? That link just points to a stage of FAQ.

Simon

[ssm2017]

yes, i have opened a ticket but it looks like they are moderated.

here is the text that i have posted :

"
hello
i have bought this wonderfull DMX USB PRO Mk2 component to be able to use dmx output on my linux machine.
as said on your product web page, it is using ftdi chipset but i need to use it with ola ( http://opendmx.net/index.php/OLA )

the problem im having now is that im not able to use the second port of the component.
when asking to the ola's developper why this port is not available, he's telling me that this is because the "extended mk2 api" is not public so people developping open source software are not able to go further.

you have made a very big step when developping and publishing the OpenDmx usb component so it proves that you are aware about the needs of the open source community.

im not asking you to publish the schematics and the source code of the mk2, but please can you find a way to allow us to use the mk2 second port using ola ?
"

[Simon Newton]

On Wed, Feb 13, 2013 at 9:45 AM, ssm2017 <ssm...@gmail.com> wrote:
> yes, i have opened a ticket but it looks like they are moderated.
> here is the text that i have posted :
>
> "
> hello
> i have bought this wonderfull DMX USB PRO Mk2 component to be able to use
> dmx output on my linux machine.
> as said on your product web page, it is using ftdi chipset but i need to use
> it with ola ( http://opendmx.net/index.php/OLA )
>
> the problem im having now is that im not able to use the second port of the
> component.
> when asking to the ola's developper why this port is not available, he's
> telling me that this is because the "extended mk2 api" is not public so
> people developping open source software are not able to go further.
>
> you have made a very big step when developping and publishing the OpenDmx
> usb component so it proves that you are aware about the needs of the open
> source community.
>
> im not asking you to publish the schematics and the source code of the mk2,
> but please can you find a way to allow us to use the mk2 second port using
> ola ?
> "

Thanks, if that doesn't work you may want to indicate you'll return
the Mk II, and get a http://dmxking.com/usbdmx/ultradmxpro instead :).

Let us know what they respond with.

[Jason Kyle]

I'll bite LOL

We're currently running some specials so now is a good time to buy an
ultraDMX Pro. You'll get 2 out and 1 in simultaneously (unlike Pro mk2 which
is 2 out or 1 out + 1 in) and a built in isolated DMX splitter too. We don't
offer a D15 connection option though but I see that as a good thing.

Also if you're wanting 2 universes and willing to pay around the price of a
pro mk2 then consider this http://shop.dmxking.com/eDMX2-TX_p_10.html

BTW the NDA thing is about Enttec trying to block DMXking from selling
compatible competing products even though we were actually first to market
with this kind of product (at a reasonable cost anyway). It's a real shame
they didn't just follow the existing 2U extensions we had already laid out
however popular rumour has it there's not that much difference....

Best Regards,

Jason Kyle
DMXking.com / JPK Systems Limited
+64(9)379 4836
+64(21)672535
j...@dmxking.com

[Douglas Heriot]

It’s interesting Simon got asked to sign an NDA. When I sent them an email just after the announcement saying I’d like to implement this in my Mac app, they just gave me the specification. There was also an update to it a few days ago they just sent out. (No mention of any NDAs or anything. They did name the pdf file with my app’s name – so it’s obvious if I share it without renaming it?)

I don’t have an actual device yet to test with (I’ve been too busy working on other things), but sometime soon I’ll get around to chasing it up and having a go at implementing it properly.

No, it doesn’t conform the the protocol extensions documented here:

http://www.opendmx.net/index.php/USB_Protocol_Extensions

You have to send it a specific message with a magic ‘API key’ value that’s documented to enable the new ‘API2’ features, otherwise it’ll only respond to the ‘API1’ messages.

It is kind of similar to what you’ve done with DMXKing, however more message labels now have a second counterpart label for operating on port 2 (not just for sending DMX) – you can set the DMX rate and other properties per port. It also does RDM on each port separately.

Also note you’re incorrect when you say the Pro mk2 is 2 out, or 1 out + 1 in (while DMXKing has simultaneous 2out + 1in). They say they’ve got “2 full universes”, which means it should be capable of 2 in + 0 out (which DMXKing currently can’t do).

It also supports MIDI, but that takes over the second DMX port. As MIDI data is still sent over the same USB serial protocol with everything else, it has no integration with standard USB MIDI or any OS or anything – it’ll only be useful with programs that specifically support the Pro Mk2. (And I can imagine it being a pain to implement, as I think you’ll have to split up all the MIDI messages yourself and handle all the edge cases, without Apple’s Core MIDI just doing it for you, at least on OS X)

I’ll say it again – I don’t have a device yet and haven’t verified any of this – this is just what their documentation says.

Since I’m not under any NDA, what happens when I eventually get around to implementing support for the protocol, and share it open source?

[Simon Newton]

On Wed, Feb 13, 2013 at 5:15 PM, Douglas Heriot <dougla...@gmail.com> wrote:
> It’s interesting Simon got asked to sign an NDA. When I sent them an email
> just after the announcement saying I’d like to implement this in my Mac app,
> they just gave me the specification. There was also an update to it a few
> days ago they just sent out. (No mention of any NDAs or anything. They did
> name the pdf file with my app’s name – so it’s obvious if I share it without
> renaming it?)

It may be watermarked. That said, if you're not under an NDA, they
can't really stop you sharing it. They could cut you off from future
updates I guess.

>
> I don’t have an actual device yet to test with (I’ve been too busy working
> on other things), but sometime soon I’ll get around to chasing it up and
> having a go at implementing it properly.
>
> No, it doesn’t conform the the protocol extensions documented here:
> http://www.opendmx.net/index.php/USB_Protocol_Extensions

That's not surprising, when asked Nic gave me the impression he
doesn't want to do anything that would make it easier for other
hardware to work.

>
> You have to send it a specific message with a magic ‘API key’ value that’s
> documented to enable the new ‘API2’ features, otherwise it’ll only respond
> to the ‘API1’ messages.

Does the key change (as part of a challenge - response sequence) or
is it constant? Do you know if the key is specific to your app?

>
> It is kind of similar to what you’ve done with DMXKing, however more message
> labels now have a second counterpart label for operating on port 2 (not just
> for sending DMX) – you can set the DMX rate and other properties per port.
> It also does RDM on each port separately.
>
> Also note you’re incorrect when you say the Pro mk2 is 2 out, or 1 out + 1
> in (while DMXKing has simultaneous 2out + 1in). They say they’ve got “2 full
> universes”, which means it should be capable of 2 in + 0 out (which DMXKing
> currently can’t do).
>
> It also supports MIDI, but that takes over the second DMX port. As MIDI data
> is still sent over the same USB serial protocol with everything else, it has
> no integration with standard USB MIDI or any OS or anything – it’ll only be
> useful with programs that specifically support the Pro Mk2. (And I can
> imagine it being a pain to implement, as I think you’ll have to split up all
> the MIDI messages yourself and handle all the edge cases, without Apple’s
> Core MIDI just doing it for you, at least on OS X)
>
> I’ll say it again – I don’t have a device yet and haven’t verified any of
> this – this is just what their documentation says.
>
>
> Since I’m not under any NDA, what happens when I eventually get around to
> implementing support for the protocol, and share it open source?

Nothing. You can either write code for OLA directly or you can release
your own code, I can read it and write the OLA version.

Thanks for the info though, it helps unlock part of the puzzle.


Simon

[Douglas Heriot]

It may be watermarked. That said, if you're not under an NDA, they
can't really stop you sharing it. They could cut you off from future
updates I guess.

That's not surprising, when asked Nic gave me the impression he
doesn't want to do anything that would make it easier for other
hardware to work.

All the new label ids appear almost randomly assigned – if other people want to continue their own extensions with more kinds of messages, I don’t know how you’ll choose more numbers without making a bigger mess.

 

Does the key change  (as part of a challenge - response sequence) or
is it constant? Do you know if the key is specific to your app?

No, there’s no challenge response sequence or anything – the 4-bye API key is just documented in bold in the pdf.

When I called them up and chatted with one of their engineers a few months ago, nothing was said about API keys and if they’re unique or anything. However, it would explain why my pdf was named specifically for me – they could just be sending out unique keys in different pdfs to everyone.

 

> Since I’m not under any NDA, what happens when I eventually get around to
> implementing support for the protocol, and share it open source?

Nothing. You can either write code for OLA directly or you can release
your own code, I can read it and write the OLA version.

That makes sense. I’ll probably just leave out the API key, in case that is supposed to be unique and kind of secret. It can’t be that secret though – surely there’s a few ways you’d be able to pull one out of software that contains it, or intercepting the serial data or something.

[Simon Newton]

On Wed, Feb 13, 2013 at 7:20 PM, Douglas Heriot <dougla...@gmail.com> wrote:
>> It may be watermarked. That said, if you're not under an NDA, they
>> can't really stop you sharing it. They could cut you off from future
>> updates I guess.
>>
>> That's not surprising, when asked Nic gave me the impression he
>> doesn't want to do anything that would make it easier for other
>> hardware to work.
>
>
> All the new label ids appear almost randomly assigned – if other people want
> to continue their own extensions with more kinds of messages, I don’t know
> how you’ll choose more numbers without making a bigger mess.

Maybe the labels are based on the key value. It would be interesting
to compare the labels give two different API keys.

Thankfully every other USB Pro clone I know of implements the Protocol
Extensions. From the manufacturer & product ID the software can tell
exactly what set of labels are supported and what the message types
are.

>
>>
>> Does the key change (as part of a challenge - response sequence) or
>> is it constant? Do you know if the key is specific to your app?
>
>
> No, there’s no challenge response sequence or anything – the 4-bye API key
> is just documented in bold in the pdf.
> When I called them up and chatted with one of their engineers a few months
> ago, nothing was said about API keys and if they’re unique or anything.
> However, it would explain why my pdf was named specifically for me – they
> could just be sending out unique keys in different pdfs to everyone.
>
>
>>
>> > Since I’m not under any NDA, what happens when I eventually get around
>> > to
>> > implementing support for the protocol, and share it open source?
>>
>> Nothing. You can either write code for OLA directly or you can release
>> your own code, I can read it and write the OLA version.
>
>
> That makes sense. I’ll probably just leave out the API key, in case that is
> supposed to be unique and kind of secret. It can’t be that secret though –
> surely there’s a few ways you’d be able to pull one out of software that
> contains it, or intercepting the serial data or something.
>

[Douglas Heriot]

Maybe the labels are based on the key value. It would be interesting
to compare the labels give two different API keys.

Given that the pdf spec says it was generated with Open Office, they’d have to have an impressive mail merge system to pull that off.

 

[Hippy]

I'd suggest you send it back, and demand a full refund.

Cheers,

 Hip

[Hippy]

Douglas, you are in a unique position - since having not signed a NDA, you are under no obligation in terms of that agreement.   

I would suggest copy and paste.... and pastebin.com

The API key is increadibly unlikely to be unique to each box, they would never be able to trace it...

I doubt it would ever change with firmware upgrades either, it would render new firmware useless without software updates as well...

 

or print it out, then burn it, and post the ashes back to spEnttec.

 

Or just email it to me, and I will read the fine print, just to make sure...

 

Plus, if your not in Australia, it's highly unlikely that there would be any recourse.  spEnttec would have to sell a million units just to get a lawyer on board - given the absenece of a NDA or even mention at the time, and the circumstances you've described - no lawyer would be interested in touching it because it's a no-brainer.

Really, it's just a matter of time... and the sooner the better......

[Douglas Heriot]

I could post the spec, but I don’t want to do wrong by anyone. I plan to continue my business selling OS X lighting control apps for the long term, so want to remain friends with Enttec, as well as everyone here…

Plus, if your not in Australia, it's highly unlikely that there would be any recourse.  spEnttec would have to sell a million units just to get a lawyer on board - given the absenece of a NDA or even mention at the time, and the circumstances you've described - no lawyer would be interested in touching it because it's a no-brainer.

Really, it's just a matter of time... and the sooner the better......

Well, I am actually in Australia (Wollongong, NSW), and want to avoid lawyers as much as possible…

The API key is increadibly unlikely to be unique to each box, they would never be able to trace it...

I doubt it would ever change with firmware upgrades either, it would render new firmware useless without software updates as well...

I’m guessing that if the keys are unique, it has a simple checksum or something so the Pro can check if it’s a valid key. Future software updates in theory could contain a blacklist. – I have no idea if that’s how it works, or if Enttec would ever blacklist a vendor, but they could if they wanted to.

[Simon Newton]

On Feb 13, 2013 9:25 PM, "Hippy" <dmx...@gmail.com> wrote:
>
> Douglas, you are in a unique position - since having not signed a NDA, you are under no obligation in terms of that agreement.   
> I would suggest copy and paste.... and pastebin.com
> The API key is increadibly unlikely to be unique to each box, they would never be able to trace it...
> I doubt it would ever change with firmware upgrades either, it would render new firmware useless without software updates as well...
>  
> or print it out, then burn it, and post the ashes back to spEnttec.
>  
> Or just email it to me, and I will read the fine print, just to make sure...
>  
> Plus, if your not in Australia, it's highly unlikely that there would be any recourse.  spEnttec would have to sell a million units just to get a lawyer on board - given the absenece of a NDA or even mention at the time, and the circumstances you've described - no lawyer would be interested in touching it because it's a no-brainer.
> Really, it's just a matter of time... and the sooner the better......

Hip, have you tried just emailing ENTTEC and asking for it? Maybe it's as easy as Douglas says.

[Jason Kyle]

If anything there’s a range of keys and what they’re doing is attempting to ID the source of a “leak”. Unfortunately for Enttec it’s not exactly hard to spy on USB messages so any software that actually supports the Mk2 Pro will need to send its assigned API key so it won’t take long to build a list.

 

So aside from D-Pro is there any software that actually supports the enhanced mode?

 

Hippy -

[dmx...@gmail.com]

Tbh, i have no interest in it whatsoever... 

I personally would never, ever purchase or recommend or use an enttec product ever again... But that's just me.

I just hate crippled hardware, with a passion akin to a jealous lover. 

Which bring me to brute force... Should be simple enough to brute the key if there is no significant time delay in responses... If anyone could be bothered. 

But that won't be me. 

I don't even have any DMXking hardware, but if I did, i would back it all the way, as JPK is a good bloke, and after a few tests id imagine id have nothing but nice things to say. 

Cheers, 

Hip 

Sent from Samsung Mobile

Simon Newton wrote:

On Feb 13, 2013 9:25 PM, "Hippy" <dmx...@gmail.com> wrote:
>

> Douglas, you are in a unique position - since having not signed a NDA, you are under no obligation in terms of that agreement.   
> I would suggest copy and paste.... and pastebin.com
> The API key is increadibly unlikely to be unique to each box, they would never be able to trace it...
> I doubt it would ever change with firmware upgrades either, it would render new firmware useless without software updates as well...
>  
> or print it out, then burn it, and post the ashes back to spEnttec.
>  
> Or just email it to me, and I will read the fine print, just to make sure...
>  
> Plus, if your not in Australia, it's highly unlikely that there would be any recourse.  spEnttec would have to sell a million units just to get a lawyer on board - given the absenece of a NDA or even mention at the time, and the circumstances you've described - no lawyer would be interested in touching it because it's a no-brainer.
> Really, it's just a matter of time... and the sooner the better......

Hip, have you tried just emailing ENTTEC and asking for it? Maybe it's as easy as Douglas says.
>
>  

[Simon Newton]

Just a reminder that the conversations we have here are archived and
public. You should assume that people from Enttec are reading this
thread.

Simon

[Jason Kyle]

Sorry that email wasn’t meant to end with Hippy –

[Hippy]

Hehehe....  Nice!

 

(The personal opinions expressed here by Hippy are posted under the WTFPL, and are voiced in the public interest, and should not be seen as in anyway related to, or associated with, or to be portraying the opinions of the open-lighting project or the awesome people who support it.)

Cheers,

  Hip

[Douglas Heriot]

If anything there’s a range of keys and what they’re doing is attempting to ID the source of a “leak”. Unfortunately for Enttec it’s not exactly hard to spy on USB messages so any software that actually supports the Mk2 Pro will need to send its assigned API key so it won’t take long to build a list.

Yep.

So aside from D-Pro is there any software that actually supports the enhanced mode?

Nope.

(at least none that I’ve found)

On the Enttec website they list both D-Pro and Martin M-PC in bold, but there’s no sign of M-PC supporting both universes (last release notes explicitly said free edition supports 1 universe with a PRO Mk2)

Just a reminder that the conversations we have here are archived and
public. You should assume that people from Enttec are reading this
thread.

Yep.

At this point in time, the best way for OLA to support Enttec’s PRO Mk2 devices is by someone just asking Enttec straight up.

Remember that we are still really just speculating at this point in time, and that usually doesn’t lead to good things.

Here’s an excerpt from the spec that explains it just a little bit, and contains what you need to detect the new Mk2 hardware:

Backward Compatibility

PC based application programs which were written to work with the DMX USB Pro1 should work without change with the DMX USB Pro2, with the following exceptions:

• The DMX USB Pro2 has a single firmware version to support DMX and RDM, whereas the DMX USB Pro1 had separate firmware versions for DMX and RDM support. This means that querying the firmware version of the DMX USB Pro2 no longer indicates whether RDM is supported or not.

• The second DMX port must be left disabled, to avoid the DMX USB Pro2 generating messages other than those which a DMX USB Pro1 would generate.

By default, apart from two new messages (Set API Key and Query Hardware Version), the DMX USB Pro2 only supports the same application messages as the USB Pro1. To enable support for all messages in this API document, an API key must be used to unlock the extended features of the DMX USB Pro2.

To detect if a DMX USB Pro1 or a DMX USB Pro2 is present, the Query Hardware Version message should be used. The DMX USB Pro1 will not reply to the Query Hardware Version request. 

13.Set API Key Request (Label = 13)

This message enables either the DMX USB Pro1 API (API1) messages or the DMX USB Pro2 API (API2) messages.

Labels in the range 1 to 12 inclusive, belong to API1. All labels in this document belong to API2. When the DMX USB Pro2 is powered on, only the API1 messages are enabled. To enable API2 messages a magic number must (REDACTED) be sent.

Each time the DMX USB Pro2 receives any message which is not enabled, the message will be discarded and the Red LED will blink to show that the message was rejected.

Size In Bytes	Description
4	API key, with LSB stored at lowest address. The API key value to enable API1 is hex 0. The API key value to enable API2 is hex REDACTED.

LSB Storage means the last byte of the key is sent FIRST and the first bytes sent LAST

14.Query Hardware Version Request (Label = 14, no data)

This message requests the hardware version number of the DMX USB Pro2. The request is supported whether or not the DMX USB Pro2 firmware is valid.

The DMX USB Pro1 will not reply to this request, since the DMX USB Pro1 does not support the request.

15.Query Hardware Version Reply (Label = 14)

The Widget sends this message to the PC in response to the Query Hardware Version request.

Size In Bytes	Description
1	Hardware version. Valid value is 2 for DMX USB Pro2.

 

[Hippy]

Oh don't worry JPK, most emails seem to end with hippy....

 

Just to be clear for everyone (and for the eternal record),  Hippy is in no way affiliated with, or exclusively endorses any specific company...  I'm not doing a Shihad/Pacifier style bigtime sell-out either...

 

But I will, and always will, support good people... even if from across the Tasman!

Cheers,

 Hip

[Jason Kyle]

Hi Nic! Nice D15 connector LOL

[Hippy]

+1  

[Hippy]

On Thu, Feb 14, 2013 at 4:14 PM, Douglas Heriot <dougla...@gmail.com> wrote:

 

Size In Bytes	Description
4	API key, with LSB stored at lowest address. The API key value to enable API1 is hex 0. The API key value to enable API2 is hex REDACTED.

 

Okay, now i'm a tiny bit interested...

 

4 Hex bytes aye....

 

i'm going to take a punt, I guess you could rule out $0000....

 

so it's gotta be either $dead or $f0cd... or possibly $abba.

[Brian]

Four bytes, it's probably 0xDEADBEEF  :-P

Brian

--

[Andrew Frazer]

Horrah for across the Tasman. We like the people in the west island.  I'm actually in Melbourne today and people are being nice. 

[ssm2017]

hello

i have juste received an answer from Enttec today.

they don't speak about NDA (i did not ask too) but you ca even try again to see what they will anser.

here is what they answered to my ticket :

"
Thanks for contacting us

Our PRO Mk2 API is accessible only on a request basis, and not publicly to ensure a better 3rd party support & development from developers.
Any developer that has approached us, has been sent the API, and we have had quite a few developers working on it too.

Maybe you need to ask the said developer to contact us to get a copy of API, unless they don't plan to support PRO MK2 specifically.
We have always believed that both open source & paid software can co-exist, and we encourage both

-=-=-=-=-=-
Manmeet
Tech Support
ENTTEC AU
"

2013/2/14 Andrew Frazer <andrew...@stellascapes.com>

[Simon Newton]

On Thu, Feb 14, 2013 at 4:37 AM, ssm2017 <ssm...@gmail.com> wrote:
> hello
> i have juste received an answer from Enttec today.
> they don't speak about NDA (i did not ask too) but you ca even try again to
> see what they will anser.
>
> here is what they answered to my ticket :
>
> "
> Thanks for contacting us
>
> Our PRO Mk2 API is accessible only on a request basis, and not publicly to
> ensure a better 3rd party support & development from developers.
> Any developer that has approached us, has been sent the API, and we have had
> quite a few developers working on it too.
>
> Maybe you need to ask the said developer to contact us to get a copy of API,
> unless they don't plan to support PRO MK2 specifically.
> We have always believed that both open source & paid software can co-exist,
> and we encourage both

I've sent an email. I'll report back when I get a reply.

Fingers crossed!

Simon

[Simon Newton]

Enttec emailed me the spec. I'll work on adding support for this next week.

Simon

[dmx...@gmail.com]

So we will all have the key shortly.... 

Sent from Samsung Mobile

Simon Newton wrote:

>>>> offer a D15 connection option though but I see that asa good thing.

[Andrew Frazer]

Was that a storm in a tea-cup?

[Jason Kyle]

After a little detective work I can  confirm each developer is given an API key so yes its “tracked” in a way. Sounds like Simon will be adding support for it so would assume he has been given a magic key for use with OLA.

 

 

If anything there’s a range of keys and what they’re doing is attempting to ID the source of a “leak”. Unfortunately for Enttec it’s not exactly hard to spy on USB messages so any software that actually supports the Mk2 Pro will need to send its assigned API key so it won’t take long to build a list.

 

So aside from D-Pro is there any software that actually supports the enhanced mode?

 

[Massimo Callegari]

Enttec sent me the new specs for the Mk2 device. Unfortunately I cannot share them.

If you want to help me with the integration in QLC+ I am happy to do so.

Afterward the OLA guys can grab the code. ;)

Please contact me separately if you intend to contribute.

Thanks

[Simon Newton]

On Fri, Feb 15, 2013 at 8:19 PM, Jason Kyle <ja...@jpk.co.nz> wrote:
> After a little detective work I can confirm each developer is given an API
> key so yes its “tracked” in a way. Sounds like Simon will be adding support
> for it so would assume he has been given a magic key for use with OLA.
>
>
>
>
>
> If anything there’s a range of keys and what they’re doing is attempting to
> ID the source of a “leak”. Unfortunately for Enttec it’s not exactly hard to
> spy on USB messages so any software that actually supports the Mk2 Pro will
> need to send its assigned API key so it won’t take long to build a list.

The API key doesn't need to be secret, in fact, it wouldn't matter if
the key for each software was published.

That's because the 'secret' is in the label mappings, which are based
on the key. For example to send DMX to port 2, with the OLA key I use
label 135 but with Douglas's key he uses 202.

So you'd need to sniff the traffic for every software application out
there *or* figure out the label-assignment algorithm if order to build
a compatible device.

Quite clever really.

Simon

[Peter Stuge]

Simon Newton wrote:
> the 'secret' is in the label mappings, which are based on the key

How long is the key? I'm looking forward to seeing the OLA code.

> So you'd need to sniff the traffic for every software application
> out there *or* figure out the label-assignment algorithm if order
> to build a compatible device.

Or build a simple jig to exhaustively search the mapping space.


//Peter

[Simon Newton]

On Sat, Feb 16, 2013 at 7:49 AM, Peter Stuge <pe...@stuge.se> wrote:
> Simon Newton wrote:
>> the 'secret' is in the label mappings, which are based on the key
>
> How long is the key? I'm looking forward to seeing the OLA code.

2^32.

>
>
>> So you'd need to sniff the traffic for every software application
>> out there *or* figure out the label-assignment algorithm if order
>> to build a compatible device.
>
> Or build a simple jig to exhaustively search the mapping space.

The problem with that is that many of the messages don't give replies
so you have to rely on manual validation.

Without knowing the algorithm, the complete set of mappings would
consume 64G of memory.

Simon

>
>
> //Peter

[Jason Kyle]

The key space can be reduced to 2^0 by just observing the plain text traffic
so initially seems clever but is actually a pointless exercise in reality.
Bruit force on this is actually well within reason these days although you'd
really need a room full of Pro Mk2's to actually achieve it within a
reasonable period of time since the turnaround time for each iteration is
significant.

-----Original Message-----
From: open-l...@googlegroups.com [mailto:open-l...@googlegroups.com]
On Behalf Of Simon Newton
Sent: Sunday, 17 February 2013 05:23
To: open-l...@googlegroups.com
Subject: Re: [open-lighting] enttec dmx usb pro mk2

[Andrew Frazer]

It seems to me that if you were smart enough to do that, you'll probably have built your own interface anyway.

[Simon Newton]

On Sat, Feb 16, 2013 at 4:09 PM, Jason Kyle <ja...@jpk.co.nz> wrote:
> The key space can be reduced to 2^0 by just observing the plain text traffic
> so initially seems clever but is actually a pointless exercise in reality.

That only gives you the label mappings for one software product.

[dmx...@gmail.com]

This makes no sense, since OLA is open source, everyone will just copy your keys and labels... I would.

 Unless you undertake some intensive obfuscation, it'll be pretty much copy/paste? 

But I would say I would know better than to spend money on crippled hardware like this... There should be a public api for the second universe, and a private api for those using it as a 'copy protection' dongle... Keeping everyone happy. 

As for the midi side of things, $12 gets you a pnp usb midi interface, works out of the bubble wrap on Win/Lin... for which you can write your own software to control, or use the millions of existing midi softwares. 

Sent from Samsung Mobile

[Jason Kyle]

Yes but there are only N software products and each has exactly 2^0
permutations so just observe [plain text] each one and you're done. For
purely academic reasons it would be fun to deduce the algorithm used
assuming there's some correlation between API key and label IDs.

[Simon Newton]

On Sat, Feb 16, 2013 at 7:42 PM, Jason Kyle <ja...@jpk.co.nz> wrote:
> Yes but there are only N software products and each has exactly 2^0
> permutations so just observe [plain text] each one and you're done.

That solves the problem today for N software products, but then you're
constantly having to play catch up. The more keys Enttec hands out the
stronger the protection becomes.

[Jason Kyle]

N isn't large so moot point in reality.