If you don't already have the Atmega I would suggest the Arduino compatible Teensy or Teensy++ boards. These also use Atmel micro controllers but have a much improved USB inteface compared to the "standard" Atmega boards.
http://www.pjrc.com/teensy/
Te Teensyduino software plugin for the Arduino IDE will provide you with many more examples, including some for a USB Joystick. The Teensys also have much smaller footprint comparable to a Arduino Nano for the Teensy++. For a joystick application the even smaller Teensy should be fine and only costs $16.

In general the inability to find  a data sheet would personally concern me, but I suppose that is normal for a lot of eBay stuff from ominous sources. Based on a recent post using that same sort of LED for Aquarium lighting, you should be able to find at least a data sheet for the single LED elements that they have assembled in this package.

Also make sure you have sufficient heat sinking, possibly using a fan if you intend to run these close to their max current. The 50000 h lifespan is likely not applicable if you run them at max current and will be definitely many magnitudes smaller if you don't heat sink properly.

A second suggestion is to use a switched constant-current power supply. Most high brightness LED drivers are switched constant-current power supplies for reasons of energy efficiency. Otherwise they would dissipate too much heat and also would need a lot of heat sinking. Energy efficiency is also the reason of a relatively low PWM frequency.

Perhaps if you post a little more about your project you'd also be rewarded with more pointed advice.

The circuit diagram shows two processors because the Atmega processor used on the Leonardo is available in different packages TQFP, VQFN etc. There is only one processor on the Leonardo board.

Well...as you've discovered yourself, you get what you pay for.
If you need a well made small Ardino compatible board I'd strongly suggest you check out the Teensy boards. All US made. Excellent support.
Even then smallest one is better than a Nano and at $16 priced very competitively. Not to speak about the newest Arm based Teensy 3, which is also Ardino compatible and vastly more performance than a nano.
http://www.pjrc.com/teensy/

Unfortunately that solution will not work for me, as the device is not designed to be used near a router.  I am just trying to find a way, other than BlueTooth (if possible) to create a connection between two devices, one being the Arduino.  I don't need internet access.  I guess WiFi is probably overkill for what I am trying to achieve.  Maybe I should just face the fact that I will need to stick with BlueTooth.

No, WiFi is not overkill. It may have much more data transfer rate than you need, however it is ubiquitous and nearly all mobile phones, tablets, laptops etc. can easily connect to it.
Bluetooth on the other hand is much less power hungry than WiFi.
If power in not a problem than you still should be able to connect the Ethernet card to a little Pocket router such as the TP- Link WR703n or WR702n. These accept 5V USB power and you can run them off of the Arduino. Not only is that likely less expensive than a WiFi shield but also probably works better. The TP link can work as its own AP, so you can connect directly to it without the use of another router.

I've done it in two projects and it works flawlessly.

The blink without delay sketch should fit the bill

http://arduino.cc/en/Tutorial/BlinkWithoutDelay

If one would look at the photo, which is incredibly easy to do, particularly by a poster with well over 30000 posts, in that case the UNO logo practically stares one in the face ;-)

The UNO has the The I2C pins on Analog Pins 4 & 5.

I2C problems are easiest to track down with an Oscilloscope. I have not looked and the spec sheet, however, are you sure you have pull-up resistors on the SCA and SCL lines ?

Edit:
Just could not shut my big mouth and missed the pull- up resistors also staring in my face ;-)

Edit2:
Bad contacts are a common issue with breadboards. If you have a multimeter, check at least that electrically everything is OK. 5V power at the sensor and signals at SCA and SCL. Then you can look at the software. Wiring looks OK to me and " should" work.

When I posted my reply we had been waiting almost a year since the official Arduino WiFi Shield was allowed at a Maker Faire in September the year before. There was not a single blog posting and requests on this and other forum as to when it might be available we're not answered. In essence the lines had gone dead.
In my own project I had gotten the CuHead to work but the library is not particularly intuitive, or easy to use for my limited programming expertise and I was not going to go into socket programming just to get the relatively simple UDP / ArdOSC functionality implemented. Also, due It's age and lack of continued development I was looking for a replacement.

Then in my research for an alternative solution I came across a blog post linking to a video showing a video of a person remote controlling a device per WiFi through an IPhone using  Recotanta's ArdOSC library. Exactly what I was hoping to achieve!

The equipment was a " standard" Ethernet shield connected by a short cable to a pocket WiFi router. I have this solution implemented in my projects and it works absolutely flawlessly. The beauty is that the full functionality of the mature Ethernet library is at hand, including the ArdOsc and Bonjour.
Not only is it a highly functional solution but it is also less expensive that any of the more recent WiFi shields.

If you ask me, the Arduino WiFi shield is a bit too late and too expensive and lacks some basic things that many users seem to look for. The library for is has currently no UDP support. So even if you want to play with ArdOSC you're out of luck! Also at $80+ it is very expensive.

The spec sheet is only for a single of the chips on this mosnter. No dimensions etc.
Given the color temperatuerr this LED is very BLUE or so it seems. Not sure how you want to simulate dusk/dawn with it.

Usual daylight conditions are a mixture of direct sunlight around 5000K and blue sky background 15000 - 20000K+.
A color temperature as this LED has with 20 X 20000K and 30x royal blue is going to appear VERY cold blue and not like natural sunny daylight whatsoever. More like an extremely bright icy cold moon  night!

60W  How are you going to heatsink this monster beause this will require serious, perhaps even active (Fan) heatsinking. Also this is rather a point lightsource and a more distributed area light source employing several smaller LEDs may be more appropriate for this case. There are several threads on this forums in respect to Aquarium lighting and I've seem it mentioned at LEDsupply.com.

I don't think that you can drive this unit with a ESC. This likely requires a purpose build constant current switched power supply, which is what most hight efficiency LED drivers are, otherwise not only the LED will need heat sinking but the LED driver as well.

Interesting thread and a very good example why accidental success does not result in true knowledge.

An LED needs a constant current supply, there is no way around that. Thats based on not too complicated and widely published physics. Perhaps that currnt limit can be achieved by some implicit resistance of the components involves, e.g the internal resistance of a battery etc.

However, the question is whether one would want to base a sound design on something that is more a byproduct of a statistically distributed manufacturing process thats only monitored within rlatively wide limits or a design goal kept within close tolerance. A battery for example is a supplier of electrical energy with the usual design goals  being a stable voltage over time and mAh etc. The internel resiststance is what you get with it and it may not even be stated on a data sheet.

A resistors design goal, however, is to have a specified resistance and can be bought at different tolerance ratings. Using components for their intended purpose is obviously more a sound approach. That does not mean that you can't get away with not using that approach occasionally. Using that approach, however for a reliable solution is dangerous.

Cool! Thanks for posting the openFrameworks part of it too. It's often ant these software interfaces where one gets stuck.

Or in Obi Wan's words "Be mindful of the Interface Luke'" 

What Arduino board are you using ?

I am asking because my sample code specifies :

Code:

Serial.begin(115200);

On an Arduino Uno for example that would not work and I'd start with :

Code:

Serial.begin(9600);

And don't forget to change that in the serial monitor as well ;-)

Also, perhaps, if your board has an LED pin you may want to start getting to turn the LED on and off. Then at least you know that you can send an receive a value.

replace the :

Code:

  wert=value;
  Serial.println(wert);

with:

Code:

  Serial.print("Value = : ");
  Serial.println(value);

And see what that does. That works in the example code I wrote. It's a bit shooting in the dark, however, if that works you've accomplished 2 things.

1. You know your openFrameworks code sends a valid float.
2. You know where the problem is in the Arduino code.

I am not sure that is the entire solution to the problem, but I believe that the format of what you want to send in the open frameworks code is:

 

Code:

m.addFloatArg(3.0f);

rather than the

Code:

m.addFloatArg(3.0);

The "f" behind the "3.0"  designates that it is actually a float value.

Also my gut feeling is that you'd be better off putting the :

Code:

Serial.println(wert);

Into the callback function right after you've assigned value to wert.

That depends ;-)

The pull-up resistors in the set- up your setup  are basically arranged on the bus in parallel configuration so 2x 10k and one 4.7 k comes out to 2.42 Ohm. That should still be ok.

Usually you only need one pair of pull-up resistors on the I2C bus.

There are a couple of excellent resources that explain things in more detail:

http://gammon.com.au/i2c
http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors.html