I see this in dmesg...
[ 43.990259] i2c-gpio i2c-gpio.0: using pins 1 (SDA) and 0 (SCL)
There does seem to be i2c traffic (verified with a scope) on two of the black wires leading to the led board. The other wires are all at GND, 3.3V, or 5V.
Actually, the SDA and SCL go to Test Points (TP3 and TP4) near the microprocessor on the LED board, respectively. I soldered wires to them, and fed them into A4 and A5 on an arduino, and ran this slave i2c code to spy on the data as I sent led_ctl commands from the luma: https://www.arduino.cc/en/Tutorial/MasterWriter
I could tell that the luma was addressing 0x48 by doing:
i2cdetect -y 0 (on the luma)
There also seems to be some devices at 0x50-0x57, but only 0x57 has any data, which you can see with e.g.:
i2cdump -y 0 0x57
It seems to be the default wifi ssid of the device, something I can't recognize, and the serial number. It's likely a flash nvram.
You can read/write from/to it with e.g.:
i2cset -y 0 0x56 0x40 0xef
i2cget -y 0 0x56 0x40
But I digress!
The LEDs can be controlled with i2cset commands just like they can from led_ctl. See the led_ctl commands below. Each command has up to four numbers. The first is the mode, the second is the color, and the third and forth depends on the command. For instance,
i2cset -y 0 0x48 3 1 9 0 i
would set it to solid red brightness=9 (and the fourth value is not used for that command).
The modes go from 3 to 8, for solid to pulsing.
The colors go from 1 to 7, for red to white (except blue and yellow are switched, so it really goes red, green, yellow, blue, purple, cyan, white).
Usage: led_ctl [status | upgrade | force_upgrade | version]
led_ctl solid COLOR
led_ctl single COLOR INDEX <brightness 0 - 15>
led_ctl spinning COLOR <period 1 - 16 (lower = faster)>
led_ctl fill COLOR <period 1 - 16 (lower = faster)>
( default is 5 )
led_ctl flashing COLOR <on dur 1 - 128> <off dur 1 - 128>
(default is 34) ( default is 34 )
led_ctl pulsing COLOR
COLOR: red, green, blue, yellow, purple, cyan, white