Cristian Vicente

Intentado resolver problemas de desconexión del sistema ambilight, gracias a un comentario de alguien en algún foro que hablaba sobre su necesidad de bajar el tamaño de las muestras de la capturadora para que el puerto USB 2.0 no se saturase, descubrí que mi caso era algo similar, la única diferencia es que mi información, a pesar de muy inferior, viajaba por Wifi, un medio muy problemático.

Así que, leyendo el post de Korbin Brown, descubrí que, a pesar de tener el punto de acceso al lado de la Raspberry PI, el cable LAN solucionó el problema por completo.

Con «iwconfig wlan0» detecté que la velocidad que alcanzaba era de 1Mb/s, totalmente insuficiente para transmitir los datos necesarios a Hyperion.

La idea es la de tener un HTPC funcionando con Kodi y una Raspberry Pi conectada a un sistema de luces led a través del puerto GPIO y con Hyperion funcionando.

• Por un lado, debemos instalar un addon para Kodi y configurarlo para que apunte a la IP de la Raspberry Pi, además de habilitar el control remoto.
• Por otro lado, configuraremos el fichero «/etc/hyerion.config.json» para definir la variable «xbmcAddress» con la IP de nuestro HTPC.

De esta forma podemos olvidarnos de difíciles configuraciones con capturadoras de pantalla externas y mucho cableado adicional.

Recientemente he migrado a la Raspberry Pi 2 y he tenido que realizar algunos cambios en cuanto al cableado del ambilight casero que tenía montado utilizando Hyperion.

En la siguiente imagen se puede observar la disposiciones de pines de la antigua Raspberry Pi, donde lo que nos interesaba era el pin GPIO 10 (MOSI), GPIO11 (CLK) y alguno de los GND (ground).

En cambio, se puede apreciar que la posición de dichos pines ha sigo ligeramente alterada en el modelo RaspPi2, donde necesitaremos hacer uso de los pines 9 (GND), 19 (MOSI) y 23 (CLK):

Aclarar también que necesitaremos activar el SPI en nuestro OSMC como ya describí en una entrada anterior.

Si tienes una Raspberry Pi, has actualizado el sistema operativo y te han dejado de funcionar las cosas que tenías conectadas en el GPIO es por una sencilla razón: en el kernel 3.18 se ha activado el soporte a Device Tree.

En mi caso me había dejado de funcionar el ambilight casero que tenía y, por ejemplo, boblight me lanzaba lo siguiente por el terminal:

SPI mapped from 0x0x20204000 to 0x0x16c5000

Boblightd 2.0 (optimized version for raspberry) (c) 2013 Speedy1985 and Heven)
(InitLog) start of log /root/.boblight/boblightd.log
(PrintFlags) starting boblightd
(CConfig::LoadConfigFromFile) opening /etc/boblight.conf
(CConfig::CheckConfig) checking config lines
(CConfig::CheckConfig) config lines valid
(CConfig::BuildConfig) building config
(CConfig::BuildConfig) built config successfully
(main) starting devices
(CClientsHandler::Process) opening listening TcpSocket on 127.0.0.1:19333
(CDevice::Process) AmbiLight: starting with output «/dev/spidev0.0»
(CDevice::Process) AmbiLight: setting up
(CDeviceSPI::SetupDevice) ERROR: AmbiLight: Unable to open /dev/spidev0.0: No such file or directory
(CDevice::Process) ERROR: AmbiLight: setting up failed, retrying in 10 seconds

Y efectivamente no existía ningún /dev/spidev0.0. Indagando encontré que en algunas distros (Raspbian) el módulo spidev o spi-bcm2708 no cargaban porque estaban en el fichero «/etc/modprobe.d/raspi-blacklist.conf» y había que comentar dichas líneas. En mi caso yo no tenía ningún módulo bajo el blacklist y me cercioré que mi kernel había sido compilado con las opciones correctas:

zcat /proc/config.gz  | grep -i SPIDEV

CONFIG_BCM2708_SPIDEV=y
CONFIG_SPI_SPIDEV=y

Pero la solución a mi problema fue añadir la siguiente línea al fichero «/boot/config.txt»:

dtparam=spi=on

Reiniciar y listo.