wiki.openlighting.org - User contributions [en]

OLA Buildbot

2020-12-30T01:38:02Z

Peternewman: /* OpenBSD Instructions */ Add eg++ etc

We run a [http://buildbot.net/ Buildbot] instance for [[OLA]].

*Web UI: http://buildbot.openlighting.org
*IRC: OLA-buildbot-ch in #openlighting-build on irc.freenode.org

We're currently only building ola, but this could be extended to do other projects such as the QT GUI etc.

== Master Configuration ==
The buildbot master configuration is stored in git at https://github.com/OpenLightingProject/buildbot . It needs checking out, and symlinking to replace master.cfg in the buildbot master's config directory.

N.B. If the main open-lighting git repository (as opposed to buildbot config) is ever moved or changed, ensure the master's gitpoller-workdir folder is emptied out, or the poller won't work properly.

= Adding a Slave =

Buildbot documentation is at http://docs.buildbot.net/current/manual/installation.html#creating-a-buildslave . The steps below should cover everything you need though.

== Prerequisites & Warning ==

Slaves execute code directly from the git repo. Even though submits to the git repo are locked down, this is still a possible attack vector for your machine. For this reason it's best to run build slaves within a virtual machine. TODO: link to some VM solutions.

At the very least you should run the buildslave as a separate user (not root!). Slave passwords aren't stored in the git repo for security, you'll need to get Simon or Peter to add new ones.

The buildbot performs full build & test runs with all the options enabled. Please make sure you have all the necessary libraries installed on your system. You need to be able to complete a

<pre>
autoconf -i
./configure --enable-e133 --enable-rdm-tests --enable-python-libs --enable-ja-rule
make
make check
</pre>

cycle before proceeding. If you have trouble ask on the mailing list.

If you're running the lint check, you need cpplint.py in your path somewhere, see README.developer for info on how to obtain it.

Buildbot slaves need to connect to buildmaster.openlighting.org:9989 . Make sure your firewall allows this. No port forwarding for inbound connections is required.

== Debian / Ubuntu Instructions ==

This requires wheezy or later. For squeeze you can use the easy_install method below.

=== Build Slave Installation ===

<pre>
sudo apt-get install buildbot-slave
</pre>

=== Slave Configuration ===

Create the slave (the package creates the buildbot user automatically for you):

<pre>
sudo -u buildbot buildslave create-slave --usepty=0 /var/lib/buildbot/slaves/ola buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Update the slave info, edit the files in /var/lib/buildbot/slaves/ola/info to be relevant to you.

Add config for the slave into /etc/default/buildslave (you'll need to increase the array id if you've got more than one slave on the same host), e.g.:
<pre>
SLAVE_ENABLED[1]=1 # 1-enabled, 0-disabled
SLAVE_NAME[1]="ola" # short name printed on start/stop
SLAVE_USER[1]="buildbot" # user to run slave as
SLAVE_BASEDIR[1]="/var/lib/buildbot/slaves/ola" # basedir to slave (absolute path)
SLAVE_OPTIONS[1]="" # buildbot options
SLAVE_PREFIXCMD[1]="" # prefix command, i.e. nice, linux32, dchroot
</pre>

Start the slave
sudo /etc/init.d/buildslave start

Check the log if there are any issues, or confirm the slave is registered at http://buildbot.openlighting.org/buildslaves:
tail -f /var/lib/buildbot/slaves/ola/twistd.log

== FreeBSD Instructions ==

This was tested on FreeBSD 10.

=== Build Slave Installation ===
As root:
<pre>
pkg install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
adduser
</pre>
Username: ola-build-slave
Use password-based authentication? No

Setup the slave:

Switch to the slave user, I did:
<pre>
su - #To root
su - ola-build-slave #To slave user
cd ~
</pre>

Export the variables needed for configure on FreeBSD:
<pre>
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== NetBSD Instructions ==

This was tested on NetBSD 6.

=== Build Slave Installation ===
As root:
<pre>
pkgin install py27-buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>
Use password-based authentication? No

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for git and configure on NetBSD (add these to the .shrc or equivalent for next time):
<pre>
export CPPFLAGS="-I/usr/pkg/include/"
export LDFLAGS="-L/usr/pkg/lib/"
export GIT_SSL_NO_VERIFY=true
</pre>

Setup the slave itself:
<pre>
/usr/pkg/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/pkg/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/pkg/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== OpenBSD Instructions ==

This was tested on OpenBSD 5.4.

=== Build Slave Installation ===
As root:
<pre>
pkg_add py-buildslave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for autoconf and configure on OpenBSD (add these to the .profile or equivalent for next time), the eg++/egcc lines are needed if the installed gcc is too old to pass configure, install the eg++ one and then use that line:
<pre>
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.13
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
export CXX="eg++" CC="egcc"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== Other Platforms ==

=== Build Slave Installation ===

The easiest way to get started is by using easy_install. You need to have the Python headers available, so on Debian / Ubuntu run:

<pre>
sudo apt-get install python-dev
</pre>

Then install buildbot-slave:

<pre>
easy_install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
sudo -s
adduser ola-build-slave # use a temp password for now
vi /etc/shadow # delete the password entry
</pre>

Setup the slave:

<pre>
su ola-build-slave
cd ~
buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot buildbot start /home/ola-build-slave/ola-slave
</pre>

== Enabling the C++ Lint Checker ==

The lint checker enforces C++ style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Download the cpplint checker and put it in /usr/local/bin

<pre>
wget http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
sudo cp cpplint.py /usr/local/bin
sudo chmod a+x /usr/local/bin/cpplint.py
</pre>

Finally let Simon or Peter know, or raise an issue, asking them to enable C++ lint for your slave.

== Enabling the Javascript Lint Checker ==

The lint checker enforces Javascript style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Either:
*Install the closure-linter deb package if it's present on your OS
*Install the gjslint checker by following the relevant instructions here (you man need to install python-setuptools to get easy_install on Debian/Ubuntu) https://developers.google.com/closure/utilities/docs/linter_howto

Finally let Simon or Peter know, or raise an issue, asking them to enable Javascript lint for your slave.

== Enabling the heap checker ==

First we need libunwind:

<pre>
sudo apt-get install libunwind8-dev
</pre>

Then download the latest gperftools from https://code.google.com/p/gperftools/downloads/list .

<pre>
wget ....
tar -zxf gperftools-2.1.tar.gz
cd gperftools-2.1
./configure
make
sudo make install
sudo ldconfig
</pre>
Finally let Simon or Peter know, or raise an issue, asking them to enable the heap checker for your slave.

OLA Device Specific Configuration

2018-11-18T00:35:18Z

Peternewman: /* Linux */ Add a note about the GPIO group on later Pi builds

==Anyma uDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad"); on later Raspberry Pi builds, this may fail, instead just add the olad user to the gpio group.
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbserial.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==DMXter4 RDM and MiniDMXter 4==
Navigate to "RDM Controller" in the menu. Then press <LEFT> and <RIGHT> together, then also press <YES/Q>, then release <YES/Q>, finally release <LEFT> and <RIGHT>. It will then show USB DONGLE MODE and be discoverable in OLA.

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Raspberry Pi

2018-06-01T02:27:56Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/tutorials/ola-on-raspberry-pi/}}
[[Image:Raspi_Colour_R.png|right]]

This tutorial describes how to get [[OLA]] running on the [http://www.raspberrypi.org/ Raspberry Pi]. The procedure described here is designed to get OLA up and running as fast as possible. If you don't trust the images below, or want to build everything from scratch, you can install an image from the [http://www.raspberrypi.org/downloads Raspberry Pi Site] and use the generic instructions for [[Download & Install OLA|Installing OLA]] on Linux.

There is plenty of information at the [http://elinux.org/RaspberryPiBoard Raspberry Pi Wiki]. The [http://www.raspberrypi.org/phpBB3/ Raspberry Pi Forum] is a good place to ask for help on Raspberry Pi specific issues.

__TOC__

= Getting Started=

You'll need the following:
* A Raspberry Pi board. See the [http://elinux.org/Buying_RPi Buying Guide] for how to purchase one.
* An SD card, greater or equal to 4GB. Check the [http://elinux.org/RPi_Verified_Peripherals#SD_cards SD Card Compatibility List] but don't worry too much if your card isn't listed there.
* An SD card reader. Make sure it supports the SDHC (high capacity) cards.
* A microUSB cable to provide power
* A CAT5 network cable.
* A Composite or HDMI monitor / TV to debug if things go wrong.
* A computer with a SSH Client and (optionally) Web Browser. You can use the Pi locally with a USB keyboard, but many people find it easier to access it from another machine.
* A powered USB Hub, if you plan on using a USB DMX/RDM device. Many devices draw more current than the Raspberry Pi can support. See the [http://groups.google.com/forum/?fromgroups=#!searchin/open-lighting/usb$20hub/open-lighting/mJpgweztVdE/pXm5SOihjmAJ discussion] on the Open Lighting Group for more details.

= Select your Image =

At this point you need to decide what image you want to use. The ''GIT Repo Image'' allows you to track the latest changes, but requires you to build the software yourself, which takes time. The ''Binary Package Image'' uses the pre-built binary packages for each release. The images are can be found at http://dl.openlighting.org/.

We recommend the ''Binary Package Image'' if you're starting out.

New images are released every month or two, so remember to update to take advantage of new features and bug fixes.

==GIT Repo Image==

This tracks the [https://github.com/nomis52/ola Git Repo], which means you can always use the very latest version of the code. The downside of using this option is that you have the build the code yourself (which takes time) and configuration is left up to you. It's more flexible that the Binary Package version, but does require some extra work.

Download the latest ola-git-NNNNNNNN.zip image.

== Binary Package Image==

[http://www.raspbian.org/ Raspbian] is an armhf port of Debian specifically built for the Raspberry Pi. It offers slightly better performance than the stock Debian arm port.

Use this option if you prefer a more stable system. The pre-compiled packages are usually updated once a month and you don't need to spend time building OLA from source.

Download the latest raspbian-ola-X.Y.Z.zip image.

= Copying the Image =

Once you have selected an image, unzip it, and then you need to copy it to your SD card. The [http://elinux.org/RPi_Easy_SD_Card_Setup Raspberry Pi Wiki] page has detailed instructions for each platform.

This can take a while if you have a slow SD Card (see [http://en.wikipedia.org/wiki/Secure_Digital#Speed_Class_Rating SDHC Speeds]). On my Linux machine with a Class 2 card it took 14 minutes to write the 3.9G image, a Class 4 card took 11 minutes. On a Macbook Pro, using the onboard SD-Card slot it took 153 seconds to write the image using dd to a Class 4 card. Your speeds are likely to vary between machines.

= Starting Up =

Insert the card into the Raspberry Pi, make sure it's connected to a network which has a DHCP server running, and apply power. If you have a monitor attached you should see it booting. You'll then need to determine the IP address of your Pi. If you have a screen attached it should be shown just before the login prompt. Otherwise you can check your DHCP server logs and see which address was assigned. This example assumes an IP address of 192.168.1.200.

== Login using SSH ==

From your other machine, start your SSH client and SSH to your Pi. On Linux or Mac you can use the Terminal application and type:

<pre>
ssh pi@192.168.1.200
</pre>

The password is 'openlighting' (no quotes).

If you're on Windows you can download [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] and use that.

You should see the login message and get a shell prompt. If that doesn't work, you may need to restart (pull the power and plug it in again). Sometimes the Pi gets into a weird state on the first boot.

== Security ==

By default, the image comes with a SSH Key installed for Simon to access the system *only* if you configure your router and tell Simon what the address is. If you trust me (and your probably do since you're running my code) you can leave this on. Otherwise you can delete my key by running:

<pre>
rm .ssh/authorized_keys
</pre>

Next change the password:

<pre>
passwd
Changing password for ola.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
</pre>

== Enable Turbo Mode (Optional) ==

The Raspberry Pi supports overclocking, which can increase the performance of your system. You can configured this by running

<pre>
sudo raspi-config
</pre>

and then selecting the ''overclock'' option. I (Simon) normally run with the Turbo option and haven't experienced any problems.

== Expand the Root Partition (Optional) ==

If your SD card is larger than 4GB you can expand the root partition to use all of the available space. Again use

<pre>
sudo raspi-config
</pre>

and then choose the ''expand_rootfs'' option.

== Installing (git image only) ==

The git image is a pre-built clone of the git repo. The 'make install' step hasn't been run, so before you can use OLA you'll need to run the following:

<pre>
cd ~/open-lighting
sudo make install
sudo ldconfig
</pre>

Then you can launch olad with:

<pre>
olad -l 3
</pre>

= Updating =

It's best to always use the latest version of OLA. Even immediately after downloding an image there may be updates to apply so we recommend you do this before you start using the Pi. To update your install follow one of the methods below, depending on what image you used.

== Git Repo ==

Once you're logged in, run:

<pre>
cd open-lighting
git pull
autoreconf
./configure --enable-rdm-tests
make
sudo make install
sudo ldconfig
</pre>

The make step can take a few hours.

== Binary Package Image ==

Run this:

<pre>
sudo apt-get update
sudo apt-get upgrade
</pre>

= Connecting to OLA =

At this point everything should be running. You can access the OLA web UI by opening a web browser and typing:

http://192.168.1.200:9090

Of course you should replace 192.168.1.200 with the IP Address of your device.

= Config and Log files =

If you're using the pre-built image or Debian packages, the OLA config files are in <tt>/var/lib/ola/conf</tt>. The logs are written to <tt>/var/log/syslog</tt>.

= Related Information =

If you're interested in how these images differ from the image released by the Raspberry Pi Foundation, see [[Building a Custom Raspbian Image]]

OLA on Windows with VMWare

2018-06-01T02:27:20Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/tutorials/ola-on-windows-via-vmware/}}
This explains how to run [[OLA]] on a Windows system using VMWare. This uses virtualization so it's not recommended for real time lighting control. However it's useful if you want to experiment with OLA and perform tasks that aren't time sensitive like [[OLA RDM Responder Testing| Running RDM Responder Tests]]

<div style="border:1px solid red; background-color: #ffcccc; padding: 2px">Warning: There have been reports of the VMWare Player USB Stack dropping frames, which causing problems with the RDM Responder tests. The recommended way of running the tests is to use the [[OLA_Raspberry_Pi | Raspberry Pi]].</div>

== Prerequisites ==

* A Windows PC with a working internet connection.
* At least 20G of free hard disk space. Chance are you won't need that much.

== Setting up the Linux System ==

This tutorial is based on these [http://www.howtogeek.com/howto/11287/how-to-run-ubuntu-in-windows-7-with-vmware-player/ excellent instructions]. The instructions are for Windows 7, but works fine on XP as well.

=== Download & Install VMWare Player ===

Download the free [http://www.vmware.com/download/player/ VMWare Player]. You'll need to complete the survey and provide an email address. Install this on your windows machine. Reboot.

=== Download & Install Linux Distribution ===

I recommend Ubuntu. It's fairly easy to use and stays up to date. Get the latest version from [http://www.ubuntu.com/desktop/get-ubuntu/download here]. Once this is done you should have an .iso file which will be around 600MB.

=== Setup a New Virtual Machine ===

Open VMWare Player, select "Create New Virtual Machine". Choose "Installer Disk Image" and point to the Linux .iso file you downloaded.

On the next screen setup a username & password. You can then control where the VM image is stored and the size of the image. The defaults are fine.

Click Finish to setup the Linux image. Installation of Ubuntu then begins.

You'll be asked if you want to install VMWare tool for Linux. Say yes as we'll use them later. The download will continue along with the install. This stage can take quite a while.

Once complete, you'll be presented with a graphical login screen showing the username that you setup before. Login to the system and you'll be shown the desktop.

Next enter Unity mode. This seamlessly merges the Linux windows with the Windows desktop. You can also copy and paste between Windows and Linux at this point.

[[Image:Enter_unity.JPG| frameless]]

Finally open the Linux terminal application as shown below. You'll need to move your mouse to the Start button for the Unity menu to appear.

[[Image:Open_terminal.JPG| frameless]]

Now we'll confirm that the network is working. Type:

<pre>
ping www.google.com
</pre>

You should see responses like what's below. Hit Control-C to exit the ping program.

[[Image:Linux_terminal.JPG| frameless]]

At this point we have a working Linux system. Time to install [[OLA]]

== Installing OLA ==

These instructions closely follow [[OLA on Linux]].

=== Install the dependencies ===

<pre>
sudo apt-get install libcppunit-dev libcppunit-1.12-1 uuid-dev pkg-config libncurses5-dev git libtool autoconf automake g++ libmicrohttpd-dev libmicrohttpd5 protobuf-compiler libprotobuf-lite6 python-protobuf libprotobuf-dev libprotoc-dev zlib1g-dev bison flex make
</pre>

Note: More recent distributions may offer libprotobuf-lite7 instead of libprotobuf-lite6, which is an acceptable substitution.

Then run ldconfig:

<pre>
sudo ldconfig
</pre>

=== Checkout OLA ===

Run the following to clone the OLA code:

<pre>
git clone https://github.com/OpenLightingProject/ola.git ola
cd ola
</pre>

=== Configure, build and test OLA ===

Type these
<pre>
autoreconf -i
./configure --enable-rdm-tests
make
make check
sudo make install
sudo ldconfig
</pre>

If you want to do RDM responder testing you '''must''' add --enable-rdm-tests

== Using OLA ==

At this stage you can start OLA by running

<pre>
olad -l 3
</pre>

The -l flag controls the logging level from 0 (log nothing) to 4 (debug logs). 3 is log level info, which is usually enough for most people.

Now find the IP address of your Linux instance:

<pre>
/sbin/ifconfig eth0
</pre>

Look for a line that starts with ''inet addr:''.

[[Image:Linux_ip_address.JPG|frameless]]

Open up a browser on the Windows PC and type in the IP address followed by :9090. This will bring up the OLA web console.

[[Image:Windows_ola_webui.JPG|frameless]]

== USB Devices ==

When using OLA with VMWare you need to make sure that any DMX USB devices are correctly bound to the guest OS (Linux).

http://www.vmware.com/support/ws45/doc/devices_usb_ws.html describes how to set this up.

== Updating OLA ==

From time to time you may want to update the code. From within the existing ola directory run:

<pre>
git pull
autoreconf -i
./configure --enable-python-libs
make
make check
sudo make install
</pre>

Not all of these steps are required each time, but unless you have a good idea of what changed it's easier just to run everything.

==See Also==
*[[Building OLA for Windows]] - In the future this may provide a workable alternative

[[Category:Tutorials]]

OLA on Beaglebone

2018-06-01T02:26:52Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/tutorials/ola-on-beaglebone/}}
This describes how to get [[OLA]] working on a Beaglebone from strach. At the time of writing, an "image" does not exist for the beagle bone. This process is based on using the debian os. There certainly are other ways of bulding this, but this is a method that works for me.

=Preparing your debian based Beaglebone=

Get Robert C nelsons Netinstall scripts,

https://github.com/RobertCNelson/netinstall

cd /netinstall
./mk_mmc.sh --uboot bone --mmc /dev/sdX ( sdX ) is the card

this will build the boot loader onto the card. This is also based on debian Squeeze.

Once its done, put the card in your beagle, and start up. You'll need to connect the Beaglebone via USB, and talk to it via Screen. Follow the instructions for the debian install.. Select SSH server and System Ultiities for your build. It can take a while to finish a build, depending on how fast your internet connections are.

=Install dependencies =

You need a couple of libraries installed for everything to work correctly. Some of these are available as packages in distros but others need to be downloaded and built manually.

First you'll need at least the following:
* cppunit
* uuid or ossp uuid
* pkg-config
* curses
* lex (or flex)
* yacc (or bison)
* the protocol buffers library [http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/] (version 2.3.0 or later)
* microhttpd [ftp://ftp.gnu.org/gnu/libmicrohttpd/ ftp://ftp.gnu.org/gnu/libmicrohttpd/] (if you want the web UI). You need version >= 0.4.0 of microhttpd

If you're building from git you'll also need the following:

* libtool
* automake
* autoconf

sudo apt-get install libcppunit-dev libcppunit-1.12-1 uuid-dev pkg-config libncurses5-dev libtool autoconf automake g++ libmicrohttpd-dev libmicrohttpd5 protobuf-compiler libprotobuf-lite6 python-protobuf libprotobuf-dev libprotoc-dev zlib1g-dev bison flex make libftdi-dev libftdi1 libusb-1.0-0-dev liblo-dev git

Note, these dependencies are slightly different from the Debian build

= Install OLA =

Check out the git repo with the following command:

cd /usr/local/src ( not entirely nessary, but you will be able to find it later )
git clone https://github.com/OpenLightingProject/ola.git ola
cd ola

{{ MacOLABuild }}

Finally run ldconfig so you can use the new libraries.
sudo ldconfig

OLAGuruPlug

2018-06-01T02:21:34Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/tutorials/ola-on-guruplug/}}
[[Image:Guru-plug-setup.png|center]]

__TOC__

This describes how to setup [[OLA]] on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]. These devices make excellent low cost [[DMX512]] nodes.

Features of this system:
* Wifi access point with internet connectivity
* RDM control either over DMX or [[ArtNet]]
* Protocol conversion to/from: E1.31, DMX512, ArtNet, ShowNet, Pathport, SandNet, ESP Net

Costs involved:
* GuruPlug, $99 +shipping
* Ethernet Switch, from $30
* USB DMX/RDM Interface, chose from [[Open_Lighting_Architecture#Supported Devices|Support Devices]], usually around $100-$300
* Wireless Cell Card, shop around. Make sure it works with Linux.

== Prerequisites ==

This assumes you have a shell on the guru plug and that it can contact the internet to download the packages. Note that the default guru plug is insecure and comes with a lot of extras (samba, mysql, lighthttpd etc.) that aren't required. Removing these is outside the scope of this tutorial.

== Installation ==

Add the following line to /etc/apt/sources.list:

deb http://www.nomis52.net/data/ola-arm ./

Then apt-get install ola:

$ apt-get update
$ apt-get install olad

== Setup ==

Add a user ''ola'' for the daemon to run as:

$ adduser ola

If you intend to use USB devices, you need to add this user to the plugdev & dialout groups. Modify the lines in /etc/group:

dialout:x:20:ola
plugdev:x:46:ola

Finally add any udev rules that you'll need. See [[OLA Device Specific Configuration]]

== Running ==

Change to the ''ola'' user and the start the daemon:

$ su ola
$ olad -l 3

Now connect the the GuruPlug on port 9090 with your browser to configure it.

== Questions ==

Ask on the mailing list http://groups.google.com/group/open-lighting

OLA LED Pixels

2018-06-01T02:20:59Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/tutorials/ola-led-pixels/}}
[[Image:Lpd8806.jpeg|300px|right]]

Since March 2013, [[OLA]] contains an [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus SPI] plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the [[OLA_Raspberry_Pi | Raspberry Pi]], this allows one to build Pixel strings controllable via any of the [[OLA#Supported_Protocols|supported protocols]] ([[ArtNet]], [[E1.31]], [[OSC]] & more) for less than $100.

Alternatively if you don't want network control, you can send [[DMX512]] to the LEDs using the Python, C++ or Java client library running on the host itself.

This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see [[OLA_Raspberry_Pi| OLA on the Raspberry Pi]] for details.

== Host Hardware ==

The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.

The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a [https://github.com/hackerspaceshop/RaspberryPI_WS2801_Bridge schematic] available or you can buy a [http://www.hackerspaceshop.com/raspberrypi-ws2801.html kit].

Here are some timings stats collected from the Pi:

{| border=1 cellspacing="0"
! SPI Speed !! Number of bytes || time taken for write() !! Time on the wire
|-
|| 1MHz || 75 || 13.5ms || 11.1ms
|-
|| 2MHz || 75 || 8.1ms || 5.6ms
|-
|| 4MHz || 75 || 4.7 ms || 3.0 ms
|-
|| 8MHz || 75 || 3.7ms || 1.4ms
|-
|| 12MHz || 75 || 3.2ms || 0.75 ms
|-
|| 1MHz || 516 || 78.5 ms || 76.15 ms
|-
|| 2MHz || 516 || 40.2 ms || 38.2ms
|-
|| 4MHz || 516 || 21.5 ms || 19.1 ms
|-
|| 8MHz || 516 || 12.2ms || 9.6ms
|-
|| 12MHz || 516 || 7.4ms || 4.83 ms
|-
|}

It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute.

Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .

== Pixel Hardware ==

On the pixel side the following is supported:
* LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27
* WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28

Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.

== Hardware Setup ==

The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.

=== Multiplexer ===

If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.

There is a 8 way demultiplexer schematic [https://docs.google.com/file/d/0B7Z8oqKsoX5HWE1qV2hCeDNNOU0/edit?usp=sharing here].

== OLA SPI Plugin ==

The [[OLA]] SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types.

Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.

=== Timing ===

It all comes down to timing. Consider the following example:

* 170 LPD8806 pixels per string (results in 516 bytes written)
* Two strings using the built in CE lines to drive a hardware demultipliexer.
* SPI speed of 2Mhz

Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates.

If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:

* 32 WS2801 pixels per string (results in 75 bytes written)
* Four strings using two GPIO lines to drive a hardware demultipliexer.
* SPI speed of 2Mhz

Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.

== Software Setup ==
You'll need a suitable [[OLA_Device_Specific_Configuration#SPI|udev config]], so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.

If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.

<pre>
for pin in 17 21; do
echo $pin > /sys/class/gpio/export;
chmod a+w /sys/class/gpio/gpio${pin}/value;
chmod a+w /sys/class/gpio/gpio${pin}/direction;
done
</pre>

Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. This can be done from the OLA web UI or by using ola_patch
.
[[Image:Ola-spi-artnet.png| thumb|center |200px|Example of an ArtNet controlled LED String]]

== Configuration ==

The type of LED drivers, operating mode and DMX Start Address are configurable via [[RDM]]. Click on the RDM tab and you'll see the options.

[[Image:Ola-spi-rdm.png| thumb|center |200px|Using RDM to set the hardware type and DMX start address]]

The number of LEDs and SPI speed is set using the ola-spi.conf file.

<pre>
base_uid = 7a70:00000100
device_prefix = spidev
enabled = true
spidev0.0-dmx-address = 1
spidev0.0-personality = 1
spidev0.0-pixel-count = 25
spidev0.0-spi-speed = 100000
spidev0.1-dmx-address = 1
spidev0.1-personality = 2
spidev0.1-pixel-count = 25
spidev0.1-spi-speed = 1000000
</pre>

== Example Configs ==

=== Single Pixel String ===

For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.

<pre>
base_uid = 7a70:00000100
device_prefix = spidev
enabled = true
spidev0.0-0-dmx-address = 1
spidev0.0-0-pixel-count = 25
spidev0.0-0-personality = 1
spidev0.0-backend = software
spidev0.0-ports = 1
spidev0.0-spi-speed = 1000000
</pre>

=== Two Pixel Strings, using the CE lines ===

This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.

<pre>
base_uid = 7a70:00000100
device_prefix = spidev
enabled = true
spidev0.0-0-dmx-address = 1
spidev0.0-0-personality = 1
spidev0.0-0-pixel-count = 25
spidev0.0-backend = software
spidev0.0-ports = 1
spidev0.0-spi-ce-high = true
spidev0.0-spi-speed = 200000
spidev0.1-0-dmx-address = 1
spidev0.1-0-personality = 1
spidev0.1-0-pixel-count = 25
spidev0.1-backend = software
spidev0.1-ports = 1
spidev0.1-spi-ce-high = true
spidev0.1-spi-speed = 2000000
</pre>

=== Two Pixel Strings, using a single output ===

This example is a string of 300 WS2801 pixels. Since this is more than one universe of data, we need to use multiple ports.

<pre>
base_uid = 7a70:00000100
device_prefix = spidev
enabled = true
spidev0.0-0-dmx-address = 1
spidev0.0-0-personality = 1
spidev0.0-0-pixel-count = 150
spidev0.0-1-dmx-address = 1
spidev0.0-1-personality = 1
spidev0.0-1-pixel-count = 150
spidev0.0-backend = software
spidev0.0-ports = 2
spidev0.0-spi-speed = 1000000
spidev0.0-sync-port = -2
</pre>

SPI data is written when data arrives on the second port (sync-port = -2). See the plugin description for more info.

== Exported Variables ==

The SPI plugin exports a number of useful variables. These can be found at http://<ip>:9090/debug. Each is indexed by the device name e.g. /dev/spi0.0 .

;spi-writes
: Number of writes to each SPI device
; spi-write-errors
: Number of writes that resulted in an error
; spi-drops
: Number of DMX updates that were skipped. The happens if DMX data is arriving faster than it can be written to the SPI bus.

== Related Links ==

http://www.solderlab.de/index.php/software/glediator (Pixel Control Software that outputs ArtNet)

OLA Patch persistency

2018-06-01T02:20:32Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/advanced-topics/patch-%20persistency/}}
= Patch Persistency =
The patch persistency information is stored in plain text files inside your configuration folder (~/.ola by default, or/var/lib/ola/conf if you're using the Raspberry Pi image.)

The "universe" information is stored inside "ola-universe.conf"

The "patch" information is stored inside "ola-port.conf"

To start with something clean we can delete the "ola-universe.conf" and "ola-port.conf" files and ola will create them again when stopping ola.

Note : olad only writes it's patch files when it exists. That means that is the computer is crashing or if ola is crashing, the patch is not stored in files (see [[issue:125|Issue 125]] ).

== Example ==
We are going to patch an ArtNet universe as an input with a DmxKing ultraDMX Micro as an output.

On this example, I have enabled only the plugins :
* ArtNet
and
* Serial USB
setting all the plugins in the config folder with
enabled = false
except the 2 ones needed witch i have enabled using
enabled = true

=== Starting ola ===
We are starting olad using either the command
/etc/init.d/olad start
or
olad -l 3
-l 3 : means that we are starting olad with the login level 3

=== Getting devices info ===
To get the devices info we are using the command
ola_device_info
That is returning :
Device 1: ArtNet [10.0.0.2]
port 0, IN , priority 100, RDM supported
port 1, IN , priority 100, RDM supported
port 2, IN , priority 100, RDM supported
port 3, IN , priority 100, RDM supported
port 0, OUT , RDM supported
port 1, OUT , RDM supported
port 2, OUT , RDM supported
port 3, OUT , RDM supported
Device 2: DMXking.com - ultraDMX Micro
port 0, IN Serial #: 84000775, priority 100
port 0, OUT Serial #: 84000775, RDM supported

=== Patching the devices ===
First we are patching the ArtNet device using
ola_patch -d 1 -i -p 0 -u 0
That means :
patch device 1 (-d 1) input (-i) port 0 (-p 0) to the universe 0 (-u 0)
(ola is using the output port as the default one, this is why we need to tell it to use the input using -i.

Then we are patching the ultraDMX micro using
ola_patch -d 2 -p 0 -u 0

Now the device info is returning
Device 1: ArtNet [10.0.0.2]
port 0, IN ArtNet Universe 0:0:0, priority 100, patched to universe 0, RDM supported
port 1, IN , priority 100, RDM supported
port 2, IN , priority 100, RDM supported
port 3, IN , priority 100, RDM supported
port 0, OUT , RDM supported
port 1, OUT , RDM supported
port 2, OUT , RDM supported
port 3, OUT , RDM supported
Device 2: DMXking.com - ultraDMX Micro
port 0, IN Serial #: 84000775, priority 100
port 0, OUT Serial #: 84000775, patched to universe 0, RDM supported

=== Resulted files ===
After stopping ola (using "/etc/init.d/olad stop" or "ctrl+c" (if running it directly on the command line))

The ola-port.conf and ola-universe.conf are filled with the infos.

==== ola-universe.conf ====
Here is the content of this file
uni_0_merge = LTP
uni_0_name = Universe 0
LTP priority is set by default.

A default name "Universe 0" was given to the universe 0.

==== ola-port.conf ====
Here is the content of this file
2-1-I-0 = 0
2-1-I-0_priority_value = 100
2-1-I-1_priority_value = 100
2-1-I-2_priority_value = 100
2-1-I-3_priority_value = 100
5-84000775-I-0_priority_value = 100
5-84000775-O-0 = 0

What does it mean ?

First we need to know about the plugins ids.

To get the plugins infos, we are using
ola_plugin_info
That is returning
Id Plugin Name
--------------------------------------
1 Dummy
2 ArtNet
3 ShowNet
4 ESP Net
5 Serial USB
6 Enttec Open DMX
7 SandNet
8 StageProfi
9 Pathport
11 E1.31 (sACN)
12 USB
13 FTDI USB DMX
14 OSC
--------------------------------------
In this example, we are only using the ArtNet plugin and the Serial USB plugins.

We can see that the ArtNet has the id 2 and the Serial USB has the id 5.

The ola-port.conf file is storing the info as
<plugin-id>-<device-id>-<port-id>
We can translate the first line as :

The plugin 2, device 1 and input port 0 is patched to the universe 0.

The second line is defining the priority level.

Then we can see that other ports are not patched.

And then on the sixth line, we can translate it as :

The plugin 5, device 84000775 (remember ola_device_info values) Input port 0 is not patched.

And on the 7th line we can see translate it as :

The plugin 5, device 84000775 Output port 0 is patched to universe 0.

OLA DMX Trigger

2018-06-01T02:20:00Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/advanced-topics/ola-dmx-trigger/}}
ola_trigger executes programs based on the values of DMX512 data. This allows a lighting console to trigger events on a computer, like playing music samples, advancing slides in presentations etc. . ola_trigger supports variable assignment, which offers a flexible way to control the behavior of the programs with the DMX512 data.

= Config File Syntax =

The config file defines the mapping of slot values to actions. Each line is a directive and directives are either ''action definitions'' or ''variable assignment''. The order of directives within the config file doesn't matter - actions are triggered in the order of their slot numbers.

Any characters between a '#' and the end of the line are comments and are ignored.

== Action Definitions ==

Action definitions are specified one per line, in the following form:

<pre>
[Slot Number] [Slot Values] [Action]
</pre>

The columns must be separated by whitespace.

=== Slot Number ===

The first column, slot number, specifies the DMX512 slot the action is valid for. Slot numbers range from 0 to 511. Slot numbers may be offset by using the --offset option (see the Usage section below).

=== Slot Values ===

The second column controls which DMX512 values trigger the action. Slot values range from 0 to 255. Multiple values are separated by commas. Ranges can be specified with a hyphen.

<pre>
1,2,3,4 # Values 1 through to 4
1-4,10-14 # Values 1 to 4 and 10 to 14 (inclusive)
</pre>

The % character the is default match. It triggers for all values that don't have an explicit action configured

<pre>
0-100 # Values 0 to 100
% # Triggers for everything else (101 - 255)
</pre>

Actions are only triggered when the value changes. In the example above, if the value of slot 0 in the previous frame was 10, and a frame with slot 0 @ 10 arrived, the action will not be triggered. If a frame with slot 0 @ 5 arrives, the action will trigger again.

=== Actions ===

The third column specifies the action to run. Actions can be either variable assignments or commands and can trigger on rising values, falling values or both.

==== Variable Assignment ====

Variables can be assigned values which can then be used in later commands. Variable assignments are in the form

<pre>
variable=value
</pre>

The value must be quoted if it contains whitespace:

<pre>
variable="a quoted value"
</pre>

==== Commands ====

Commands are enclosed in back ticks (`). Command arguments are separated by whitespace, quotes can be used with arguments that contain whitespace.

<pre>
`echo hello world` # Execute the '''echo''' command with two arguments [hello, world]
`echo "hello world"` # Execute the '''echo''' command with single argument "hello world".
</pre>

Variables are specified with ${ }.

<pre>
`echo ${foo}` # Run echo with the value of the foo variable.
</pre>

Variables can be nested, which means you can do things like

<pre>
# if i=1 and count_1=foo
`echo ${count_${i}}` # runs echo foo
</pre>

==== Rising / Falling Triggering ====

Commands can be specified to trigger only if the value rises or falls. This is done with the + and - symbols:

<pre>
+`echo rising edge` -`echo falling edge`
</pre>

Either the rising or falling command can be omitted, in that case no action will be taken.

=== Full Action Definition Example ===

Putting everything together, the following will run `echo hello world` whenever the value of the first DMX slot changes to 0, 5 or 10.

<pre>
0 0,5,10 `echo hello world`
</pre>

== Variables ==

Variables can be assigned default values using the same syntax as variable assignment actions:

<pre>
# set the default value of foo
foo=bar
</pre>

=== Special Variables ===

The variables ${slot_offset} and ${slot_value} are available for use within commands. For example:

<pre>
0 % `echo "Slot ${slot_offset} is at ${slot_value}"`
</pre>

You should always use ${slot_offset} rather than hard coding slot numbers within command definitions, since the slot number may change with the --offset option.

= Usage =

Before running ola_trigger, make sure that olad is running and the universe has been configured with a DMX512 source. The config file is provided on the command line:

<pre>
ola_trigger example.conf
</pre>

Some useful options include:
; -l, --log-level <level>
: This change the logging level, valid values are 0 (minimum logging) to 4 (full logs). At log level 3 (INFO) and above, all actions (variable assignments and commands) will be logged.
;-o, --offset <slot_offset>
: This applies an offset to the configured slots. For example if the config file contains definitions for slots 0 and 1, if ola_trigger is run with -o 10 it will watch for values on slots 10 and 11. Defaults to 0.
; -u, --universe <universe>
: Specifies the universe to use. Defaults to 1.

= Sample Configs =

Sample configs are provided in the [https://github.com/OpenLightingProject/ola/tree/master/tools/ola_trigger/contrib tools/ola_trigger/contrib] directory.

A full example config is provided in the tools/ola_trigger directory. If you have configs that may be useful to others please submit them.

[[Raspberry Pi Media Player]] A combination of a Raspberry PI, ola_trigger and omxplayer

OLA Merging Algorithms

2018-06-01T02:19:19Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/advanced-topics/ola-merging-algorithms/}}

This document outlines the multi-source merging functionality in OLA.

== Problem Definition ==

The old version of OLA had two merge modes, [[HTP]] & [[LTP]]. This didn't allow for priority based merging of multiple [[DMX]] sources and in particular, didn't work well with automated lights.

A separate but related problem what that some devices (such as the [[E1.31]] device) support a priority field when sending [[DMX]] data. These fields should be customizable.

With the new merging features, a user can configure two input ports to be bound to the same universe, and set the priorities of the ports such that data on one is preferred over another. This can be used to implement backup controllers.

The protocols known to support priorities are:
* [[E1.31]]
* [[ETCNet2]] (no OLA plugin)

== Proposal ==

From the [[E1.31]] standard, we define a ''source priority'' which is an integer in the range 0 to 200 with 0 the lowest priority and 200 the highest. The default priority is 100.

Each universe will have an ''active priority'' which is the priority that data is being handled for. Data received with a lower priority will be ignored, while data received with a higher priority will raise the universe's ''active priority'' to match that of the new data.

=== Input ports ===

Input ports will be separated into two types, those that support priorities and those that don't.

Ports that support priorities will offer two modes, ''inherit'' and ''override''. ''Inherit'' mode will use the priority provided by the device/protocol. ''Override'' mode will allow the user to set a priority.

Ports that don't support priorities will allow the user to specify the priority, defaulting to 100.

=== Output ports ===

Output ports that support priorities will again provide ''inherit'' and ''override'' modes. ''Inherit'' mode will use the universe's ''active priority'', ports operating in ''override'' mode will allow the user to specify a priority.

Output ports that don't support priorities won't change.

=== Source Clients ===

Source clients will be able to set a source priority when sending DMX data, this will default to 100.

=== Sink Clients ===

No changes required. We may provide the universe's ''active priority'' in the data packet if required.

=== Resolution of Equal Priority Data ===

Universes will offer a choice of [[HTP]] and [[LTP]] merge modes for when data is received from multiple ports with the same priority.

=== Data Timeouts ===

When a data source doesn't receive data for a specified interval (known as the ''timeout interval'') it's considered disconnected. At this point the source is removed from the list of available sources and the universe's ''active priority'' may reduce. Different ports may have different ''timeout intervals''.

== Use Cases ==

Consider the following

* Input port A, supports priorities, operating in inherit mode.
* Input port B, doesn't support priorities, manually set to 120
* Source client without a priority (defaults to 100)
* Output port X, doesn't support priorities
* Output port Y, supports priorities

All ports are bound to the same universe. The cases described below are sequential (the events described in Case 2 assume the events of Case 1 have already occurred)

=== Case 1: No Merge ===

No data is received from either input port and the source client sends data. The ''active priority'' is 100. Output port X sends the data, output port Y sends the data with priority 100.

[[File:ola-merge-case-1.gif|center]]

=== Case 2: Simple Merge ===

Data is now also received on port B. The new ''active priority'' is 120. Output port X sends the data from port B, output port Y sends the data from port B with priority 120.

[[File:ola-merge-case2.gif|center]]

=== Case 3: Another Simple Merge ===

Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.

[[File:Ola-merge-case3.gif|center]]

=== Case 4: Conflict Merge ===

New data is received on port A with a priority of 120. With two data sources of the same priority, the merge mode setting of the universe kicks in and the data from ports A and B is [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.

[[File:ola-merge-case4.gif|center]]

=== Case 5: Priority Escalation ===

New data is received on Port A with a priority of 180. The new ''active priority'' is 180 and the conflict merge stops. Output port X sends the data from port A, output port Y sends the data from port A with priority 180.

[[File:ola-merge-case5.gif|center]]

=== Case 6: Overriding the Output Port Priority ===

The user changes the mode of Port Y from ''inherit'' to ''override'' and sets a value of 130. Output port X continues to send the data from port A, output port Y sends the data from port A but with a priority of 130.

[[File:ola-merge-case6.gif|center]]

=== Case 7: Source Removal ===

Port A stops receiving data and is considered disconnected. The ''active priority'' drops to 120 and both output ports use the data from port B. Port Y continues to send a priority of 130 because it's operating in ''override'' mode.

[[File:ola-merge-case7.gif|center]]

== Further Information ==

* [http://www.etcconnect.com/Community/wikis/products/etcnet2-products.aspx ETCNet2 Information]
* [[E1.31]] specification (purchase required)

Template:PageMigrated

2018-06-01T02:12:27Z

Peternewman: Tweak the template

<div id="siteNotice"><div id="localNotice" lang="en" dir="ltr">
<div style="background: #9999ff; border: 5px solid #9999ff; -moz-border-radius: 5px; border-radius: 5px;">This page has migrated This page has migrated to our new site, please see [{{{url}}} {{{text|{{{url}}}}}}]. 
This content will not be updated and is just left here for reference and will be removed at some point in the future, see the link above for the most up-to-date version.</div>
</div></div>

<noinclude>This template is for pages that have been migrated to the website. Remove page contents after some time.</noinclude>

OLA DiffServ support

2018-06-01T02:07:55Z

Peternewman: Add migrated template

{{PageMigrated|url=https://www.openlighting.org/ola/advanced-topics/ola-diffserv-support/}}

[http://en.wikipedia.org/wiki/Differentiated_services DiffServ] allows devices to mark network packets so that network devices can handle different types of traffic differently. This means that latency sensitive data such as VOIP or lighting control traffic can be prioritized on the network.

OLA supports DiffServ in some of the network plugins:

* [[E1.31]]
* [[:Category:Pathport|Pathport]]

If you'd like others just ask.

To enable DiffServ support add

<pre>
dscp = <value>
</pre>

to the plugin preference file. e.g. to mark packets as Expedited Forwarding, use

<pre>
dscp = 46
</pre>

== Future Work ==

Allow mappings of universe priorities -> DSCP values. This provides a flexible way of implementing backup controllers without provisioning extra network bandwidth. http://code.google.com/p/linux-lighting/issues/detail?id=76

OLA JSON API

2018-04-21T15:25:50Z

Peternewman: /* Examples */ Add a Get Perl example

Browse to /help on your OLA webserver to see the available commands (append ?help=1 to the end of a command for more info in newer versions of OLA)

==Examples==
===Set a universe of DMX===
====Perl====
<pre>#!/usr/bin/perl -w

use LWP::UserAgent;

my $ua = LWP::UserAgent->new;
$ua->timeout(5);

my $response = $ua->post('http://127.0.0.1:9090/set_dmx',
{u => 1, d => join(",",(0,10,20,30,40,50,60,255))}
);

if ($response->is_success) {
print $response->decoded_content;
} else {
die $response->status_line;
}</pre>

====curl====
<pre>curl -d u=1 -d d=0,10,20,30,40,50,60,255 http://localhost:9090/set_dmx</pre>

===Get a universe of DMX===
====Perl====
<pre>#!/usr/bin/perl -w

use JSON::XS;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new;
$ua->timeout(5);

my $url = "http://localhost:9090/get_dmx?u=1";

my $response = $ua->get($url);

if ($response->is_success) {
my $data = decode_json($response->decoded_content);

print "DMX Data: " . join(", ", @{$data->{dmx}}) . "\n";
} else {
die $response->status_line;
}</pre>

OLA JSON API

2018-03-17T18:33:35Z

Peternewman: /* Set a universe of DMX */ Add curl example, minor tweak of example values

OLA developer info

2017-12-31T12:55:11Z

Peternewman: /* Plugin System */ Fix the link

This attempts to describe the code structure of OLA, in particular the core C++ framework, the olad server and the plugins. Be sure to read [[Using OLA]] first to understand the Port, Device, Universe & Plugin terminology.

== A Brief Tour ==

Let's quickly cover the layout, you can [[code:|browse the code online]] to follow along.

: <tt>[[code:include|include]]</tt> - contains the header files (.h) that are installed on the system
:: <tt>[[code:include/ola|ola]]</tt> - headers for the OLA framework. If the header is used by both the client and server code it belongs here
:: <tt>[[code:include/olad|olad]]</tt> - headers specifically for the olad server
: <tt>[[code:common|common]]</tt> - code for the ola framework, contains the implementations of everything in include/ola/
: <tt>[[code:olad|olad]]</tt> - the olad server code
: <tt>[[code:ola|ola]]</tt> - the ola C++ client code
: <tt>[[code:plugins|plugins]]</tt> - headers and code for all the olad plugins
: <tt>[[code:javascript|javascript]]</tt> - the client side code used for the web UI
: <tt>[[code:java|java]]</tt> - the Java OLA client
: <tt>[[code:python|python]]</tt> - the Python OLA client
: <tt>[[code:tools|tools]]</tt> - Various utilities like the RDM sniffer, the [[RDM_Responder_Testing | RDM Responder Tests]], [[OLA_DMX_Trigger | DMX Trigger]] etc.

<tt>include/ola</tt> is further broken into modules. There are modules for RDM (<tt>include/ola/rdm</tt>), HTTP (<tt>include/ola</tt>), IO, Network etc.

== Core Framework Classes ==

The headers can all be found in <code>include/ola</code>, the implementations are in <tt>common/</tt>. While some of these just wrap the native library calls, we abstract them so that it's easier to port OLA to new platforms. Ideally there would be no platform-dependent code outside of common.

=== DmxBuffer ===
<tt>[[code:include/ola/DmxBuffer.h|include/ola/DmxBuffer.h]]</tt>

The DmxBuffer class allows DMX data to be passed around the code, while avoiding unnecessary copying.

<pre>
DmxBuffer data; // new empty buffer, starts with a size of 0
data.Size(); // size of the buffer, 0 to 512
data.Blackout(); // set all channels to 0
data.Set(data, length); // set the buffer from a uint8_t*
data.Get(data, &length); // copy the data buffer into the memory pointed to by data

Dmxbuffer data2 = data; // no copy
</pre>

DmxBuffers are very similar to the boost [http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/shared_ptr.htm shared_ptr]

=== Callbacks ===

Callbacks are used extensively throughout OLA. They provide asynchronous notification when an operation completes, and reduce the coupling between modules.

==== Basic Callbacks ====
<tt>[[code:include/ola/Callback.h|include/ola/Callback.h]]</tt>

Callbacks are similar to function pointers, they allow both functions and methods to be invoked at a later time with data from either / both the time the Callback is constructed and the time the Callback is executed.

All Callbacks have a Run() method, which is how the Callback is executed.

Callbacks come on two varieties, Persistent and SingleUse. SingleUse callbacks delete themselves after Run() is called so you don't have to.

<pre>
// wrap a function that takes no args and returns a bool
SingleUseCallback<bool> *callback1 = NewSingleCallback(&Function0);

// some time later
bool result = callback1->Run();
// callback1 has deleted itself at this point

// create a Callback for Method1 of the Object class and bind TEST_VALUE as the first arg
Callback<void> *callback2 = NewCallback(object, &Object::Method1, TEST_VALUE);

// this will call object->Method1(TEST_VALUE)
callback2->Run();
// this wasn't a SingleUse Callback, so callback is still around and needs to be deleted manually.
delete callback2;

// create a Callback for a method that takes 1 arg and returns void
BaseCallback1<void, unsigned int> *callback3 = NewCallback(object, &Object::Method1);

// Call object->Method1(TEST_VALUE)
callback3->Run(TEST_VALUE);
// callback3 is still around at this stage
delete callback3;

// create a callback for a method that takes 2 args and returns void
BaseCallback2<void, int, int> *callback4 = NewSingleCallback(
object,
&Object::Method2,
TEST_VALUE);

// This calls object->Method2(TEST_VALUE, TEST_VALUE2);
callback4->Run(TEST_VALUE2);
// callback4 is still around
delete callback4;
</pre>

==== CallbackRunner ====
<tt>[[code:include/ola/CallbackRunner.h|include/ola/CallbackRunner.h]]</tt>

Sometimes you need to ensure that a callback is always executed when a method returns.

<pre>
void Foo(MyCallback *on_complete) {
CallbackRunner runner(on_complete);
// do work here, which may contain return statements, on_complete will always be executed.
}
</pre>

==== MultiCallback ====
<tt>[[code:include/ola/MultiCallback.h|include/ola/MultiCallback.h]]</tt>

Multicallback is a callback that executes another callback after it has been called N times.

<pre>
/**
* Calls DoSomething() for each Port and runs the on_complete callback once each port's callback has run.
*/
void DoSomethingForAllPorts(const vector<OutputPort> &ports,
SomethingCalback *on_complete) {
// This will call on_complete once it itself has been Run ports.size() times.
BaseCallback0<void> *multi_callback = NewMultiCallback(
ports.size(),
NewSingleCallback(this, &SomethingComplete, on_complete));

vector<OutputPort*>::iterator iter;
for (iter = output_ports.begin(); iter != output_ports.end(); ++iter) {
(*iter)->DoSomething(multi_callback);
}
}
</pre>

=== Memory Buffers and Streams ===

OLA has a collection of classes for reading and writing data from memory. If you've used the C++ streams classes a lot of this will look familiar.

[[Image:Ola-io-classes.png]]

Abstract classes have dotted borders.

Of all the classes, the ones you probably care about are the IOQueue, BigEndianOutputStream & BigEndianInputStream. Skip down to those classes for an example.

==== Input & Output Buffers ====
<tt>[[code:include/ola/io/InputBuffer.h|include/ola/io/InputBuffer.h]]</tt> 
<tt>[[code:include/ola/io/OutputBuffer.h|include/ola/io/OutputBuffer.h]]</tt>

These define the abstract classes for reading and writing from/to memory buffers.

==== IOQueue ====
<tt>[[code:include/ola/io/IOQueue.h|include/ola/io/IOQueue.h]]</tt>

The IOQueue implements both the InputBuffer and OutputBuffer interfaces. They are used in all of the new network code to construct & parse packets.

IOQueues are nice because they grow as data is written. Normally you don't write to IOQueues directly but instead use an OutputStream.

IOQueues are also integrated with the Socket classes, so they avoid a memory copy. For instance when you call UDPSocket::SendTo() it uses [[wp:Vectored_I/O|Vector I/O]] to avoid a copy.

==== MemoryBuffer ====
<tt>[[code:include/ola/io/IOQueue.h|include/ola/io/MemoryBuffer.h]]</tt>

A MemoryBuffer is useful if you have a const block of memory, and want to extract typed data sequentially using an InputStream.

<pre>
void ExtractData(const uint8_t *data, unsigned int length) {
MemoryBuffer input(data, length);
// can now use input with an InputStream.
// ...
}
</pre>

==== Input & Output Streams ====
<tt>[[code:include/ola/io/InputStream.h|include/ola/io/InputStream.h]]</tt> 
<tt>[[code:include/ola/io/OutputStream.h|include/ola/io/OutputStream.h]]</tt>

These allow you to read / write typed data to Input/Output Buffers.

==== BigEndianInputStream & BigEndianOutputStream ====
<tt>[[code:include/ola/io/BigEndianStream.h|include/ola/io/BigEndianInputStream.h]]</tt> 
<tt>[[code:include/ola/io/BigEndianStream.h|include/ola/io/BigEndianOutputStream.h]]</tt>

Sending example:
<pre>
IOQueue packet;
BigEndianOutputStream output(&packet);

output << (int) 42; // automatically converts to big endian
output << true;
output.Write(raw_data, raw_data_size);

// now packet contains our binary data.
socket->SendTo(packet, target_address); // target_address is a IPV4SocketAddress.
</pre>

Receiving Example (we don't support IOQueues for input yet):
<pre>
bool HandlePacket(const uint_t *data, unsigned int length) {
MemoryBuffer packet(data, length);
BigEndianInputStream input(&packet);

int32_t foo;
if (!(input >> foo))
return false; // not enough data
bool bar;
if (!(input >> bar))
return false; // not enough data
// do something with foo and bar here
return true;
}
</pre>

=== Clock ===
<tt>[[code:include/ola/Clock.h|include/ola/Clock.h]]</tt>

Contains the TimeInterval, TimeStamp and Clock classes for managing time. It also defines a MockClock class which can be useful for testing.

<pre>
// get the current time
TimeStamp timestamp, timestamp2;
Clock::CurrentTime(&timestamp);

// sleep for a bit
usleep(10000);

// print the duration we slept for
Clock::CurrentTime(&timestamp2);
TimeInterval interval = timestamp2 - timestamp;
cout << interval << endl;
</pre>

=== Credentials ===
<tt>[[code:include/ola/base/Credentials.h|include/ola/base/Credentials.h]]</tt>

Functions to get user and group information.

<pre>
uid_t uid = GetUID();
PasswdEntry passwd;
if (!GetPasswdUID(uid, &passwd))
return;
cout << "Username is " << passwd.pw_name << endl;
</pre>

=== Initialization ===
<tt>[[code:include/ola/base/Init.h|include/ola/base/Init.h]]</tt>

Helper functions that should be called on startup. They do things like install SEGV stack trace handlers, initialize the random number generator etc.

<pre>
AppInit(argc, argv);
</pre>

=== HTTP Server ===
<tt>[[code:include/ola/http/HTTPServer.h|include/ola/HTTPServer.h]]</tt>

The HTTP server is provided by [http://www.gnu.org/software/libmicrohttpd/ microhttpd]. The HTTPServer class provides a C++ wrapper around the microhttpd code.

=== Logging ===
<tt>[[code:include/ola/Logging.h|include/ola/Logging.h]]</tt>

Contains logging macros which behave like streams:

<pre>
OLA_FATAL << "foo";
OLA_ERROR << "bar";
OLA_INFO << "baz";
OLA_DEBUG << "bat";
</pre>

Logging is initialized with a call to InitLogging(level, output). i.e.

<pre>
// Send INFO and above to STDERR
InitLogging(OLA_LOG_INFO, OLA_LOG_STDERR);

// or

// Send WARNING and above to SYSLOG
InitLogging(OLA_LOG_WARN, OLA_LOG_SYSLOG);
</pre>

Note you can't send different levels to different destinations (so you need one or the other of the above examples). Calls to InitLogging() overwrite the previous logging configuration.

=== String Utils ===
<tt>[[code:include/ola/StringUtils.h|include/ola/StringUtils.h]]</tt>

While not a class, this defines a number of helper functions for dealing with Strings. If you need to split strings, convert ints to strings and back, escape, trim or capitalize strings use these functions.

=== STL Utils ===
<tt>[[code:include/ola/StringUtils.h|include/stl/STLUtils.h]]</tt>

Various helper methods for dealing with [http://www.sgi.com/tech/stl/ STL] containers like [http://www.sgi.com/tech/stl/Vector.html vector] and [http://www.sgi.com/tech/stl/Map.html map]. Try to use this as much as possible to reduce code (and the change of introducing a bug!).

<pre>
vector<Foo*> foos;
STLDeleteValues(&foos); // delete all objects in foo

map<int, string> our_map;
vector<int> keys;
vector<string> values;
STLKeys(our_map, &keys);
STLValues(our_map, &values);
</pre>

=== Filesystem Utils ===
<tt>[[code:include/ola/file/Util.h|include/ola/file/Util.h]]</tt>

A collection of functions for working with files.

<pre>
vector<string> usb_devices;
// return all files that match /dev/ttyUSB*
FindMatchingFiles("/dev/", "ttyUSB", &files);
</pre>

=== Random Numbers ===
<tt>[[code:include/ola/math/Random.h|include/ola/math/Random.h]]</tt>

A simple uniform random number generator. You need to call InitRandom() before using this. Do not use for anything security related.

<pre>
InitRandom();
int r = Random(1, 10); // returns an int in the range 1 .. 10
</pre>

=== Backoff Policies ===
<tt>[[code:include/ola/util/Backoff.h|include/ola/util/Backoff.h]]</tt>

Backoffs are an important part of writing reliable software. <tt>Backoff.h</tt> defines various BackoffPolicies and a BackoffGenerator.

<pre>
BackoffGenerator generator(
new ola::ExponentialBackoffPolicy(TimeInterval(1, 0), TimeInterval(64, 0));

// when an event fails
TimeInterval backoff = generator.Next();
// schedule a retry...

// and when it fails a second time
TimeInterval backoff = generator.Next();
// schedule a retry...

// and when it succeeds
generator.Reset();
</pre>

=== Networking ===
==== Network Utils ====

include/ola/network/NetworkUtils.h has helper methods for converting between endian formats, and converting IPv4 addresses to strings and visa-versa.

==== IP Addresses & Socket Addresses ====

include/ola/network/IPV4Address.h include/ola/network/SocketAddress.h have classes used to represent IP Addresses and Socket Addresses.

==== SelectServer & Sockets ====

The SelectServer is the dispatcher at the core of OLA and is defined in include/ola/network/SelectServer.h. It waits for events, and when an action occurs calls the specified method. The SelectServer can also be used to register Timeouts (called every N ms) and Loop functions (shouldn't be used).

=== Threads and Locking ===

==== Threads ====
<tt>[[code:include/ola/thread/Thread.h|ola/include/thread/Thread.h]]</tt>

This works as you'd expect.

<pre>
class MyThread: public Thread {
protected:
void *Run() {
// write code for the new thread here
}
};

MyThread thread1;
thread1.Start(); // blocks until the thread is running
// continue, and later
thread1.Join();
</pre>

==== Mutexes & Condition Variables ====
<tt>[[code:include/ola/thread/Thread.h|ola/include/thread/Mutex.h]]</tt>

This provides [[wp:Mutual_exclusion|Mutexes]] (non-recursive) and [[wp:Monitor_(synchronization)|Condition Variables]] (Monitors).

<pre>
Mutex mu;
int counter;

void Foo() {
mu.Lock();
counter++;
mu.Unlock();
}
</pre>

While this works, it's not good coding practice. Consider what happens if someone later changes this to:

<pre>
Mutex mu;
int data_to_protect;

bool Foo() {
mu.Lock();
counter++;
if (counter % 10)
return true;
mu.Unlock();
return false
}
</pre>

Now the Mutex isn't unlocked when counter is a multiple of 10. On the next call the program will deadlock.

To avoid this, we use the MutexLocker class.

<pre>
void Foo() {
MutexLocker locker(&mu);
counter++;
}
</pre>

It saves a line of code, and unlocks the Mutex automatically when it goes out of scope.

=== RDM ===

Write me.

=== Timecode ===
<tt>[[code:include/ola/timecode/TimeCode.h|include/ola/timecode/TimeCode.h]]</tt>
<tt>include/ola/timecode/TimeEnums.h</tt>

A simple class for handling [[wp:Timecode|Timecode]] data. See [[OLA_TimeCode | OLA Timecode]] for more info.

=== JSON ===
<tt>[[code:include/ola/web/Json.h|include/ola/web/Json.h]]</tt>

A set of classes for constructing [[wp:JSON|JSON]] data structures and serializing them.

<pre>
JsonObject obj;
obj.Add("name", "simon");
obj.Add("Australian", true);
obj.Add("age", 21);

JsonArray *lucky_numbers = obj.AddArray("lucky_numbers");
lucky_numbers->Append(2);
lucky_numbers->Append(5);

// returns the above as JSON.
const string json_output = JsonWriter::AsString(obj);
</pre>

== OLAD ==

=== RPC System ===

The RPC system is what allows clients to communicate with the OLA Server. It uses [http://code.google.com/p/protobuf/ Protocol Buffers] as the data interchange format. You can see the message definitions in the [[code:common/protocol/Ola.proto|Ola.proto]] file.

Clients communicate with OLAD over a TCP socket connected to localhost::9010. The RPC port olad listens on can be changed with the <tt>--rpc-port</tt> command line option but this will require the clients to be updated as well. Because the communication is over localhost we don't need to worry about dropped messages causing the socket buffers to fill up. You can still exceed the socket buffers if the client sends faster than the server can receive, but this usually indicates a poorly written client.

[[Image:Ola-communication.png|center]]

=== Client Side ===

The code required on the client side is the similar irrespective of langage. All that's required to write an OLA client is an implementation of Protocol buffers. See the [http://developers.google.com/protocol-buffers/docs/reference/other Protocol Buffers, Other Languages] page.

Client code needs to:
* Open a TCP connection to localhost:9010
* Provide an API, which constructs protocol buffer objects, serializes them and writes them to the TCP socket.
* Read data from the TCP socket, de-serialize it into protocol buffer objects and deal with the response data.

The only tricky bit is matching the responses to the requests. This task is usually handled by a StreamRpcChannel class, see the [[code:python/ola/rpc/StreamRpcChannel.py|Python]] or [[code:common/rpc/StreamRpcChannel.h|C++]] code.

=== Server Side ===

On the server side, OLAD creates a listening socket and then calls [[code:olad/OlaServer.cpp#L427|InternalNewConnection]] each time a client connects. This sets up a OlaClientService object, which is what gets called when a new message is received. The OlaClientService objects call into [[code:olad/OlaServerServiceImpl.cpp|OlaServerServiceImpl.cpp]] which is where the message handling takes place.

=== HTTP Server ===

olad/OlaHttpServer.h implements the OLA specific behavior and runs as a separate thread. This uses the OlaCallbackClient which has a TCP connection open to the OLAD core, just like any normal client.

[[Image:Olad-http.png]]

== Plugin System ==
Read a walkthrough of the OSC plugin [[code:plugins/osc/README.developer.md|here]].

We'll use plugin to refer to the entire module (Plugin, Devices & Ports), and Plugin to refer to the class that inherits from Plugin.

Plugins create and register Devices, which each consist of 0 (obviously not useful) or more Ports. A Plugin generally does a bit of work when it starts to detect devices, then leaves all work to the individual Devices and Ports.

[[Image:ola_plugin_uml.png]]

Each plugin implements the classes in blue. Of course, you can choose not to inherit from the BasicPort / Device / Plugin classes and do everything yourself.

=== PluginAdaptor ===

The PluginAdaptor is the interface between plugin code and the core OLA objects. Each Plugin object has a pointer to a plugin adaptor in the instance variable m_plugin_adaptor.

=== Plugins ===

The AbstractPlugin interface is defined in include/olad/Plugin.h. The Plugin class implements most of this interface, and leaves Id(), PluginPrefix(), StartHook(), StopHook(), SetDefaultPreferences() and Description() to be implemented by the child classes.

The startup sequence for a Plugin object is:
* From within DynamicPluginLoader::LoadPlugins an instance of the plugin is created
* If the ShouldStart() method returns False, nothing else happens, otherwise the Start() method is called.
* The Start() method calls LoadPreferences() which in turn calls SetDefaultPreferences(), this last method gives the Plugin the opportunity to setup the Preferences object.
* if SetDefaultPreferences() doesn't fail, StartHook() is called where new Devices are created. m_plugin_adaptor->RegisterDevice() should be called to add new Devices.

During the shutdown sequence:
* Stop() is called, which in turn calls StopHook()
* StopHook should call m_plugin_adaptor->UnregisterDevice() for any devices registered during the start phase.
* delete is then called on the Plugin object

At any time a the following methods can be called:
* Id()
* Name()
* Description()

=== Devices ===

The interface to Devices is defined in include/olad/Device.h as AbstractDevice, again the Device class implements most of this interface, leaving the derived classes to fill in a couple of methods:
* DeviceId() - returns a unique persistent string identifying this device
* StartHook() - this should create the port objects for a device.

=== Ports ===

Ports are the objects that actually read/write DmxBuffers. Defined in include/olad/Port.h there is the base interface Port, and then two child interfaces, InputPort and OutputPort. The BasicInputPort and BasicOutputPort provide partial implementations for these two interfaces.

At a minimum , an OutputPort needs to provide the following methods:
* WriteDMX(const DmxBuffer &buffer, uint8_t priority)
* Description()

And an InputPort needs to provide:
* ReadDMX()
* Description()

A call to ReadDMX() is triggered by calling DmxChanged() on a InputPort object. This causes the universe the port is bound to to fetch the new DMX data. Both ReadDMX() and WriteDMX() must be non-blocking, blocking here will delay the main processing loop. To satisfy this, most ports use this sequence of events:

* register a Socket for reading with the SelectServer
// some time later
* receive notification that there is new data on the socket
* read the data and copy it to a buffer
* call DmxChanged() to notify the bound Universe we have new data
* the Universe then calls ReadDMX()

Often more than one port will use the same file descriptor. This means the device is responsible for reading the data and dispatching to the right port.

Here's an example of how dmx data is received from the UsbPro Device.

The UsbProDevice will have been registered using plugin_adaptor->RegisterSocket(). When input becomes available the following sequence happens:
device->action() // signals the device that new data is available
widget->recv() // tells the widget to read more data
widget->do_recv() // reads the data from the fd
widget->handle_cos() // handles the change-of-state message from the widget
device->new_dmx() // signal the device that new dmx data has arrived
port->DmxChanged() // signal the universe that new dmx data has arrived
// if this port is bound to a universe, the universe will then call
port->ReadDMX()
device->get_dmx()
widget->get_dmx()

Of course, the plugin authors are free to implement this however they like.

=== Config Messages ===

Config messages are handled a little differently for two reasons:
* The configure() method in a plugin has to return a response immediately. We don't want to block because we'll delay all lla processing. The new RPC subsystem removes this limitation.
* Sending a PARAMETER_REQUEST to the widget doesn't generate a response immediately (in fact it may not generate one at all).

To work around this, we send a parameter_request when we start the device, and then anytime we set parameters. In the meantime we store the parameters in the widget object and return those. The sequence looks like:

device->configure()
device->config_get_params()
widget->get_parms()

* What is the interface between the LLA core and LLA plugins?

See above and the files plugin.h, device.h and port.h. The create() call will be passed a PluginAdaptor object which can then be used to register/unregister file descriptors, loop functions, timeouts and devices.

* What is the interface between the LLA core and other apps/clients to LLA like QLC?

All clients should use the LlaClient library. This needs better documentation.

* How is functionality split between the usbpro plugin and the example program?

The example program constructs configuration request messages and sends them (using LlaClient) to the Lla Core. The core routes this message to the plugin, which then returns a response message. This response is passed back to the client.

== Ideas for easy configuration ==
For some users, it will be useful to have a "auto-connect" feature. When a attached device is discovered (either when LLA i started or when a new device is attached), the user could be asked if the available ports (input as well as output) should be patched to the lowest available universes.

* Enable auto-connect ( OFF|connect whatever comes first|connect by stored patch layout)
* Save a given combination of devices (just by type or with unique ID's from serial numbers, USB device ID's etc)

Which devices cannot be autodetected?

== About device config messages ==

We need a way to tune settings on a port/device that the LLA Core doesn't know about. To enable this, the LlaClient provides a method dev_config(unsigned int dev, LlaDevConfigMsg *msg)

The LlaDevConfigMsg is an interface which declares one method: pack(uint8_t buffer, unsigned int length).
On the device side, we declare a method configure(uint8_t *request, int length)

So to use this:

On the client

MyObserver::dev_config(unsigned int dev, uin8_t *res, unsigned int length) {
MyLlaDevConfigMsg msg = parse_message(data, length);
// do something with the result
}

int main() {
// all the setup code

MyObserver observer;
// the observer gets the dev_config() callback
lla_client->set_observer(&observer);

MyLlaDevConfigMsg msg;
// set some fields
msg.foo = 1
lla_client->dev_config(device_id, &msg); //calls pack() on the message
}

In the device:

MyDevice::configure(data, length) {
MyLlaDevConfigMsg msg = parse_message(data, length);
// do something with the message

MyLlaDevConfigMsg *response = new MyLlaDevConfigMsg();
// response is deleted by the lla core
return response;
}

== The tool app "lla-usbpro" ==

The purpose is to set and get the settings that reside in the ''USB Pro'' box.

The communication with ''USB Pro's'' seems to go via the LLA core, and lla-usbpro registers as a LLA client, and uses some event handlers.

As defined in the device spec. (PDF from Enttec):

label=3 response
*1. data byte= Firmware version LSB. Valid range is 0 to 255.
*2. data byte=Firmware version MSB. Valid range is 0 to 255.
*3. data byte=DMX output break time in 10.67 microsecond units. range=[9-127] (96.03 - 1355.09 micro seconds)
*4. data byte=DMX output Mark After Break time in 10.67 microsecond units. range=[1-127] (10.67 - 1355.09 micro seconds)
*5. data byte=DMX output rate in packets per second. range=[1-40]
*x. data byte= some user configuration of the requested size

The serial number is is decoded (from 4 bit Binary Coded Decimal) in lla-usbpro, not the plugin.

==Unsupported USB devices==

* [[Peperoni Light| Peperoni]] [[Rodin1]] (but this is supported directly by [[QLC]])
* [[Peperoni Light|Peperoni]] [[USBDMX21]]
* [[USB DMX]] from usbdmx.com
* [[Sandsys]] [[UMX2]]
* [[Sandsys]] [[UMX4]]
''Peperoni and usbdmx are probably easy to implement. The specs and source code examples are available.''

OLA Device Specific Configuration

2017-08-29T13:56:17Z

Peternewman: /* Anyma */ Add uDMX name

==Anyma uDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbserial.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==DMXter4 RDM and MiniDMXter 4==
Navigate to "RDM Controller" in the menu. Then press <LEFT> and <RIGHT> together, then also press <YES/Q>, then release <YES/Q>, finally release <LEFT> and <RIGHT>. It will then show USB DONGLE MODE and be discoverable in OLA.

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

Open Lighting PIDs

2017-08-13T02:48:00Z

Peternewman: Fix the link

This page documents [[RDM]] PIDs used by the Open Lighting project.

For the live list in use, visit the [http://rdm.openlighting.org/pid/manufacturer?manufacturer=31344 RDM Parameter Index].

===0x8000===
This sets the serial number of the device. The serial number is combined with the ESTA ID to create the UID.

===0x8001===
This just returns the current version of the OLA code that's running. It's a manufacturer specific PID used by the dummy responder, so that it provides a manufacturer specific PID for testing purposes.

===0x8002===
GETs / SETs the device model.

===0x8003===
GET a list of device models that can be used

===0x8004===
Reserved

===0x8005===
GET / SET the pixel type

===0x8006===
GET / SET the pixel count

OLA Device Specific Configuration

2017-04-28T19:10:47Z

Peternewman: Clarify and tidy

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbserial.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==DMXter4 RDM and MiniDMXter 4==
Navigate to "RDM Controller" in the menu. Then press <LEFT> and <RIGHT> together, then also press <YES/Q>, then release <YES/Q>, finally release <LEFT> and <RIGHT>. It will then show USB DONGLE MODE and be discoverable in OLA.

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2017-04-28T19:09:09Z

Peternewman: /* DMXter4 RDM */ Add the MiniDMXter 4

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbserial.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==DMXter4 RDM==
==MiniDMXter 4==
RDM Controller
Press <LEFT> and <RIGHT> together, then also press <YES/Q>, then release <YES/Q>, finally release <LEFT> and <RIGHT>. It will then show USB DONGLE MODE and be discoverable in OLA.

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2017-04-26T18:25:25Z

Peternewman: Add info on DMXter4

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbserial.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==DMXter4 RDM==
RDM Controller
Press <LEFT> and <RIGHT> together, then also press <YES/Q>, then release <YES/Q>, finally release <LEFT> and <RIGHT>. It will then show USB DONGLE MODE and be discoverable in OLA.

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2017-04-22T11:13:23Z

Peternewman: /* Mac */ Correct the config filename

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbserial.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2017-04-01T22:51:08Z

Peternewman: /* Raspberry Pi */ Add info on Pi 3 UART

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

=====Raspberry Pi 3=====
For the Raspberry Pi 3 you need to disable Bluetooth and reclaim the PL011 UART from it.

Add:
dtoverlay=pi3-disable-bt
to your config.txt file in the /boot directory.

According to this, you can also swap them, so Bluetooth uses the software UART:
[http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/ http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/]

If you use this instead:
dtoverlay=pi3-miniuart-bt

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2017-02-16T19:55:07Z

Peternewman: /* Open DMX USB / FTDI RS485 */

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux. See [https://www.openlighting.org/ola/get-help/ola-faq/#What_is_the_difference_between_the_different_USB_plugins here] for more info.

If you're having issues with the device failing to transmit DMX, these links might help:
*[http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/ http://stevenbreuls.com/2014/04/dmx-rs485-wrong-board-fix/]
*[http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877 http://falconchristmas.com/forum/index.php/topic,858.msg9877.html#msg9877]

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

Open Lighting Architecture

2016-03-24T22:10:03Z

Peternewman: /* Developer Documentation */ More APIs

[[Image:OLA-Logo-Fitted-48px.png|right]]
Link: http://www.openlighting.org/ola/ 
{{Features|free=yes|tx=yes|rx=yes|linux=yes|osx=yes|http=yes|rdm=yes|win=yes}}
[[Image:Ola-download.png |right|link=http://opendmx.net/index.php/Download_%26_Install_OLA]]
[[Image:Llad_home.png| thumb |200px|right|Universe Settings]]
[[Image:Ola-rdm.png|thumb|200px|right|RDM Devices Page]]
[[Image:OLA_patching.png|thumb|200px|right|Drag & Drop RDM Patching]]
[[Image:Ola-mobile.png|thumb|200px|right|Mobile UI]]

__NOTOC__
The Open Lighting Architecture (OLA) is part of the [[Open Lighting Project]] and provides applications with a mechanism to send and receive [[DMX512]] & [[RDM]] commands using hardware devices and DMX over IP protocols. This enables [[:Category:Controllers | software lighting controllers]] to communicate with hardware either via Ethernet or traditional DMX512 networks.

OLA can also convert DMX512 data sent using DMX over IP protocols from one format to another, allowing devices from different manufacturers to interact with one another. For example a [[Strand_Lighting|Strand]] Lighting Console using ShowNet can send DMX512 to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]. When combined with a physical DMX interface such as the [[DMX USB Pro]], OLA can send and receive data from wired DMX512 networks.

==Supported Protocols==

{| border=1 cellspacing="0"
! '''Protocol'''!! Linux !! '''Mac OS X''' || '''FreeBSD''' || '''Windows'''
|-
|| [[:Category:ArtNet|ArtNet, ArtNet 2, ArtNet 3]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]][[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]][[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]]
|-
|| [[E1.31]] / [[ACN]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || Not yet
|-
|| [[:Category:ESP Net|ESP Net]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[KiNET]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[OSC]] (Open Sound Control) || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || ? || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Pathport|Pathport]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Sandnet|Sandnet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ShowNet|ShowNet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|}

==Supported Devices==

{| border=1 cellspacing="0"
! '''Device'''!! Linux !! '''Mac OS X''' || '''FreeBSD''' || '''Windows'''
|-
|| [[Anyma uDMX]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|-
|| [[Arduino RGB Mixer]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || ? || no
|-
|| [[DMX 4 Linux]] || [[Image:Trans.gif|center]] || || ? || no
|-
|| [[DMX USB Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || no
|-
|| [[DMX USB Pro MkII]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || no
|-
|| [[DMX-TRI]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || no
|-
|| [[DMXking USB DMX512-A]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || ? || no
|-
|| [[DMXter4 RDM]] / [[MiniDMXter]] || [[Image:Rdm.gif|center]] || [[Image:Rdm.gif|center]] || ? || no
|-
|| [[Eurolite USB DMX512 PRO]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|-
|| [[KarateLight]] || [[Image:Trans.gif|center]] || || ? || no
|-
|| [http://kmtronic.com/kmtronic-dmx-adapter.html KMtronic DMX Adapter] || [[Image:Trans.gif|center]] || || ? || no
|-
|| [[Open DMX USB]] || [[Image:Trans.gif|center]] || || ? || no
|-
|| [[Milford Instruments 1-463]] || [[Image:Trans.gif|center]] || ? || ? || no
|-
|| [[Packetheads USB_DMX Dongle]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] || ? || no
|-
|| [[RDM USB Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || ? || no
|-
|| [[RDM-TRI]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || no
|-
|| [http://www.doityourselfchristmas.com/wiki/index.php?title=Renard Renard Serial Protocol (Renard SS24, SS8, etc)] || [[Image:Trans.gif|center]] || ? || ? || no
|-
|| [[Robe Universal Interface]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || ? || no
|-
|| [[RUNIT WTX]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] [[Image:Rdm.gif|center]] || ? || no
|-
|| [[OLA_LED_Pixels|SPI control of LED pixels]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || ? || ? || no
|-
|| [[StageProfi]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] (Ethernet version only) || ? || no
|-
|| [http://machosehead.wordpress.com/2010/06/12/udmx_asp/ uDMX_asp] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|-
|| [[ultraDMX Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || ? || no
|-
|| [[ultraDMX Micro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || ? || no
|-
|| [[USBDMX2]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|-
|| [http://www.soh.cz/produkty/modul-usb-dmx512 USB-DMX512] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|-
|| [[Velleman K8062]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|-
|| [[Velleman_K8062_Upgrade|VX8062]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] || ? || no
|}

==Getting Started==

Start here if you've never used OLA before and read these in order.
* [[Download & Install OLA]]
* [[Using OLA]] - A basic introduction
* [[OLA Command Line Tools]] - Documentation for the tools in ola-examples
* [[OLA Device Specific Configuration]]
* [[OLA Tips & Tricks]]
* [[RDM with OLA]]

===Tutorials===
* [[OLA on Windows with VMWare]]
* [[OLA Live CD]], instructions on how to use the Live CD
* [[OLA Raspberry Pi]]
* [[OLA on Beaglebone]]
* [[OLAGuruPlug]] - Running OLA on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]
* [[OLA RDM Responder Testing]]
* [[OLA LED Pixels]] - Using OLA and a Pi to drive SPI LED tape
* [[OlaOutput Max External]] - Setup OlaOutput on Mac OS X to send DMX messages from Max/MSP/Jitter
* [[OlaLED]] - control RGB LED via HTTP

===Advanced Topics===
* [[OLA Merging Algorithms]]
* [[OLA DiffServ support]] (QOS settings)
* [[OLA Thread Scheduling]] (Control latency)
* [[OLA DMX Trigger]] - Using OLA and DMX to trigger events on a computer
* [[OLA Patch persistency]]

===Developer Documentation===

The developer documentation is in the process of being re-written as doxygen comments in the src tarball. The latest generated copy of the docs is hosted at https://docs.openlighting.org/doc/latest/ versions for specific releases are hosted at https://docs.openlighting.org/doc/.

* [[OLA developer info]] - about the source code and structure
* [[doc:index|OLA Doxygen Docs]] - Generated Doxygen docs aimed at developers creating clients.
** See [[OLA_on_Linux#Doxygen_Documentation|here]] for info on generating Doxygen docs locally.
* [[code-raw:plugins/osc/README|Walkthrough of the OSC plugin code]] - good for people wanting to create new plugins
* OLA APIs - See also [https://www.openlighting.org/ola/apis/ https://www.openlighting.org/ola/apis/]
** Protobufs Based
*** [[doc:client_tutorial|OLA Client API]] - the C++ API, (also [[OLA Client API|older examples]])
*** [[OLA Python API]] - easy DMX programming
*** [[code:java|Java]] - currently a work in progress (see an example using it [https://github.com/neophob/ola-to-tpm2net here])
** Alternatives
*** [[OLA JSON API|JSON]] - Browse to /help on your OLA webserver to see the available commands (append ?help=1 to the end of a command for more info in newer versions of OLA)
*** [[OSC]] - Not technically an API, but not strictly a lighting protocol either, enable the OSC plugin and use it to communicate with OLA from a variety of software
* [[Build OLA Mac Packages]] - notes for building the .dmg images
* [[Building OLA for Windows]] - Notes on Windows support (in progress)
* [[OLA on Android]] - Notes on Android support (in progress)
* [[Cross Compiling OLA]]
* [[OLA Buildbot|Buildbot]] - For continuous build and testing
* [[Using OLA with Xcode]] - on a Mac, in Objective-C++
* [[Writing RDM Responder Tests]]
* [[Port Throttling]]
* [[RDM PID Definitions]]
* [[OLA Performance Stats]]
* [[OLA TimeCode]]
* [[doc:rpc_system|RPC Protocol]] (or "How do I talk to OLA in a different language")

===Old Tutorials===
These refer to the previous release but parts of them are still relevant.
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC
* [[LLA and Q Light Controller OSX Tutorial]] - Setup LLA on Mac OS X with QLC

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:E1.31]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]
[[Category:Pathport]]

OLP SOC Ideas Page

2016-02-18T14:50:59Z

Peternewman: OLE ideas

This page lists some ideas for [https://summerofcode.withgoogle.com/ Google Summer of Code 2016] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2016 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself. You can also see what projects [https://www.openlighting.org/openlightingproject/get-involved/gsoc/ past students] did.

Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].

=Open Lighting Architecture Ideas=
Ideas for [https://www.openlighting.org/ola/ OLA].
== Adding RDM support to the "new" Web UI ==

This project would include:
* Adding support for RDM discovery to list devices and sub-devices in the UI and extending the existing supporting code in the web server back-end where necessary
* Adding support to render the generic JSON returned by the back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter IDs or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Adding support for more RDM PIDS to the Web UI(s) ==

Our current "old" Web UI lacks support for a lot of the really cool parameters and features that RDM is capable of (our "new" Web UI currently lacks all RDM support, but see the idea above for that). The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web apps to use the new web API
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, AngularJS and JQuery or Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Continue Porting to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Hardware Programming 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See [[issue:280|issue 280]] for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard

=Open Lighting Embedded (OLE) Ideas=
Ideas for [https://www.openlighting.org/ole/ OLE].

== DMX in mode ==

OLE currently only supports DMX out from the ports, add support for DMX input too.
See [[ja-rule-issue:99|issue 99]] for some additional thoughts. You'd also need to make the additional changes to OLA to support DMX input via Ja Rule.

'''Skills Required''': Embedded C, C++ 
'''Estimated Difficulty''': Hard

== Second Port Support ==

OLE currently only supports DMX/RDM out from the first port, add support on the second too.
See [[ja-rule-issue:251|issue 251]] for some additional thoughts. You'd also need to make the additional changes to OLA to support the second port. [[ja-rule-issue:226|Issue 226]] details the plan to detect if the unit is a one or two port device. It would also be good to make use of DMX input on both ports as mentioned above.

'''Skills Required''': Embedded C, C++ 
'''Estimated Difficulty''': Medium

== Sniffer mode ==

It would be very useful to be able to use OLE as a DMX/RDM sniffer.
See [[ja-rule-issue:103|issue 103]] for some additional thoughts. You may also need to make additional changes to OLA to support the sniffer mode.

'''Skills Required''': Embedded C, C++ 
'''Estimated Difficulty''': Hard

OLP SOC Ideas Page

2016-02-18T14:38:34Z

Peternewman: Peternewman moved page OLA SOC Ideas Page to OLP SOC Ideas Page: Generalise to Open Lighting Project

This page lists some ideas for [https://summerofcode.withgoogle.com/ Google Summer of Code 2016] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2016 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself. You can also see what projects [https://www.openlighting.org/openlightingproject/get-involved/gsoc/ past students] did.

Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].

== Adding RDM support to the "new" Web UI ==

This project would include:
* Adding support for RDM discovery to list devices and sub-devices in the UI and extending the existing supporting code in the web server back-end where necessary
* Adding support to render the generic JSON returned by the back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter IDs or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Adding support for more RDM PIDS to the Web UI(s) ==

Our current "old" Web UI lacks support for a lot of the really cool parameters and features that RDM is capable of (our "new" Web UI currently lacks all RDM support, but see the idea above for that). The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web apps to use the new web API
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, AngularJS and JQuery or Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Continue Porting to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Hardware Programming 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See [[issue:280|issue 280]] for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard

OLA SOC Ideas Page

2016-02-18T14:38:34Z

Peternewman: Peternewman moved page OLA SOC Ideas Page to OLP SOC Ideas Page: Generalise to Open Lighting Project

#REDIRECT [[OLP SOC Ideas Page]]

OLP SOC Ideas Page

2016-02-18T00:52:26Z

Peternewman: Updates to 2016 and link to old projects

This page lists some ideas for [https://summerofcode.withgoogle.com/ Google Summer of Code 2016] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2016 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself. You can also see what projects [https://www.openlighting.org/openlightingproject/get-involved/gsoc/ past students] did.

Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].

== Adding RDM support to the "new" Web UI ==

This project would include:
* Adding support for RDM discovery to list devices and sub-devices in the UI and extending the existing supporting code in the web server back-end where necessary
* Adding support to render the generic JSON returned by the back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter IDs or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Adding support for more RDM PIDS to the Web UI(s) ==

Our current "old" Web UI lacks support for a lot of the really cool parameters and features that RDM is capable of (our "new" Web UI currently lacks all RDM support, but see the idea above for that). The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web apps to use the new web API
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, AngularJS and JQuery or Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Continue Porting to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Hardware Programming 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See [[issue:280|issue 280]] for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard

OLP SOC Ideas Page

2016-02-18T00:48:59Z

Peternewman: More ideas

This page lists some ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code 2014] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2014 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself.

Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].

== Adding RDM support to the "new" Web UI ==

This project would include:
* Adding support for RDM discovery to list devices and sub-devices in the UI and extending the existing supporting code in the web server back-end where necessary
* Adding support to render the generic JSON returned by the back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter IDs or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Adding support for more RDM PIDS to the Web UI(s) ==

Our current "old" Web UI lacks support for a lot of the really cool parameters and features that RDM is capable of (our "new" Web UI currently lacks all RDM support, but see the idea above for that). The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end
* Adding support for Ack Timer packets in the RDM flow
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web apps to use the new web API
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, AngularJS and JQuery or Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Continue Porting to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Hardware Programming 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See [[issue:280|issue 280]] for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard

OLA Device Specific Configuration

2016-02-17T00:36:12Z

Peternewman: More udev rule explanation

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

You need the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules
<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Buildbot

2016-02-14T21:15:17Z

Peternewman: /* Enabling the Javascript Lint Checker */ More ways to install the linter

We run a [http://buildbot.net/ Buildbot] instance for [[OLA]].

*Web UI: http://buildbot.openlighting.org
*IRC: OLA-buildbot-ch in #openlighting-build on irc.freenode.org

We're currently only building ola, but this could be extended to do other projects such as the QT GUI etc.

== Master Configuration ==
The buildbot master configuration is stored in git at https://github.com/OpenLightingProject/buildbot . It needs checking out, and symlinking to replace master.cfg in the buildbot master's config directory.

N.B. If the main open-lighting git repository (as opposed to buildbot config) is ever moved or changed, ensure the master's gitpoller-workdir folder is emptied out, or the poller won't work properly.

= Adding a Slave =

Buildbot documentation is at http://docs.buildbot.net/current/manual/installation.html#creating-a-buildslave . The steps below should cover everything you need though.

== Prerequisites & Warning ==

Slaves execute code directly from the git repo. Even though submits to the git repo are locked down, this is still a possible attack vector for your machine. For this reason it's best to run build slaves within a virtual machine. TODO: link to some VM solutions.

At the very least you should run the buildslave as a separate user (not root!). Slave passwords aren't stored in the git repo for security, you'll need to get Simon or Peter to add new ones.

The buildbot performs full build & test runs with all the options enabled. Please make sure you have all the necessary libraries installed on your system. You need to be able to complete a

<pre>
autoconf -i
./configure --enable-e133 --enable-rdm-tests --enable-python-libs --enable-ja-rule
make
make check
</pre>

cycle before proceeding. If you have trouble ask on the mailing list.

If you're running the lint check, you need cpplint.py in your path somewhere, see README.developer for info on how to obtain it.

Buildbot slaves need to connect to buildmaster.openlighting.org:9989 . Make sure your firewall allows this. No port forwarding for inbound connections is required.

== Debian / Ubuntu Instructions ==

This requires wheezy or later. For squeeze you can use the easy_install method below.

=== Build Slave Installation ===

<pre>
sudo apt-get install buildbot-slave
</pre>

=== Slave Configuration ===

Create the slave (the package creates the buildbot user automatically for you):

<pre>
sudo -u buildbot buildslave create-slave --usepty=0 /var/lib/buildbot/slaves/ola buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Update the slave info, edit the files in /var/lib/buildbot/slaves/ola/info to be relevant to you.

Add config for the slave into /etc/default/buildslave (you'll need to increase the array id if you've got more than one slave on the same host), e.g.:
<pre>
SLAVE_ENABLED[1]=1 # 1-enabled, 0-disabled
SLAVE_NAME[1]="ola" # short name printed on start/stop
SLAVE_USER[1]="buildbot" # user to run slave as
SLAVE_BASEDIR[1]="/var/lib/buildbot/slaves/ola" # basedir to slave (absolute path)
SLAVE_OPTIONS[1]="" # buildbot options
SLAVE_PREFIXCMD[1]="" # prefix command, i.e. nice, linux32, dchroot
</pre>

Start the slave
sudo /etc/init.d/buildslave start

Check the log if there are any issues, or confirm the slave is registered at http://buildbot.openlighting.org/buildslaves:
tail -f /var/lib/buildbot/slaves/ola/twistd.log

== FreeBSD Instructions ==

This was tested on FreeBSD 10.

=== Build Slave Installation ===
As root:
<pre>
pkg install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
adduser
</pre>
Username: ola-build-slave
Use password-based authentication? No

Setup the slave:

Switch to the slave user, I did:
<pre>
su - #To root
su - ola-build-slave #To slave user
cd ~
</pre>

Export the variables needed for configure on FreeBSD:
<pre>
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== NetBSD Instructions ==

This was tested on NetBSD 6.

=== Build Slave Installation ===
As root:
<pre>
pkgin install py27-buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>
Use password-based authentication? No

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for git and configure on NetBSD (add these to the .shrc or equivalent for next time):
<pre>
export CPPFLAGS="-I/usr/pkg/include/"
export LDFLAGS="-L/usr/pkg/lib/"
export GIT_SSL_NO_VERIFY=true
</pre>

Setup the slave itself:
<pre>
/usr/pkg/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/pkg/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/pkg/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== OpenBSD Instructions ==

This was tested on OpenBSD 5.4.

=== Build Slave Installation ===
As root:
<pre>
pkg_add py-buildslave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for autoconf and configure on OpenBSD (add these to the .profile or equivalent for next time):
<pre>
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.13
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== Other Platforms ==

=== Build Slave Installation ===

The easiest way to get started is by using easy_install. You need to have the Python headers available, so on Debian / Ubuntu run:

<pre>
sudo apt-get install python-dev
</pre>

Then install buildbot-slave:

<pre>
easy_install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
sudo -s
adduser ola-build-slave # use a temp password for now
vi /etc/shadow # delete the password entry
</pre>

Setup the slave:

<pre>
su ola-build-slave
cd ~
buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot buildbot start /home/ola-build-slave/ola-slave
</pre>

== Enabling the C++ Lint Checker ==

The lint checker enforces C++ style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Download the cpplint checker and put it in /usr/local/bin

<pre>
wget http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
sudo cp cpplint.py /usr/local/bin
sudo chmod a+x /usr/local/bin/cpplint.py
</pre>

Finally let Simon or Peter know, or raise an issue, asking them to enable C++ lint for your slave.

== Enabling the Javascript Lint Checker ==

The lint checker enforces Javascript style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Either:
*Install the closure-linter deb package if it's present on your OS
*Install the gjslint checker by following the relevant instructions here (you man need to install python-setuptools to get easy_install on Debian/Ubuntu) https://developers.google.com/closure/utilities/docs/linter_howto

Finally let Simon or Peter know, or raise an issue, asking them to enable Javascript lint for your slave.

== Enabling the heap checker ==

First we need libunwind:

<pre>
sudo apt-get install libunwind8-dev
</pre>

Then download the latest gperftools from https://code.google.com/p/gperftools/downloads/list .

<pre>
wget ....
tar -zxf gperftools-2.1.tar.gz
cd gperftools-2.1
./configure
make
sudo make install
sudo ldconfig
</pre>
Finally let Simon or Peter know, or raise an issue, asking them to enable the heap checker for your slave.

OLA Device Specific Configuration

2016-02-10T04:15:04Z

Peternewman: /* Linux */ Remove one note as confirmed working

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following:

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following udev rule:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
# After a short hang, the K8062 should come up as "Velleman Components, Inc."

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2016-02-10T01:39:59Z

Peternewman: /* Linux */ Tidy formatting

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following:

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following udev rule:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf, see [https://wiki.debian.org/KernelModuleBlacklisting https://wiki.debian.org/KernelModuleBlacklisting]
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
After a short hang, the K8062 should come up as "Velleman Components, Inc."
The K8062 has not been tested with any software after following this solution. It is only for the purpose of avoiding the Kernel Panic on Ubuntu.

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLA Device Specific Configuration

2016-02-10T01:39:25Z

Peternewman: /* Linux */ Add more info on kernel panics

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following:

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== Ja Rule ==

===Linux===

<pre>
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"
</pre>
== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following udev rule:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

Some people have reported issues with the K8062 on Ubuntu 14.04.
Symptoms: When you plug in your K8062, Ubuntu responds with Kernel Panic.
Problem: comedi and vmk60xx kernel modules are loaded and crash the kernel.
Solution: WARNING! Attempt at your own risk.
# Blacklist comedi and vmk60xx in /etc/modprobe.d/blacklist.conf
https://wiki.debian.org/KernelModuleBlacklisting
# Reboot and then run lsusb in the terminal. (Make sure K8062 is connected.)
After a short hang, the K8062 should come up as "Velleman Components, Inc."
The K8062 has not been tested with any software after following this solution. It is only for the purpose of avoiding the Kernel Panic on Ubuntu.

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

RDM PID Definitions

2015-11-03T00:54:33Z

Peternewman: Fix some links

== Parameter Definitions and OLA ==

[[OLA]] reads the structure of [[RDM]] parameter messages at runtime. This allows the users to update PID definitions without upgrading the binaries and also means we can add knowledge of new manufacturer PIDs to the RDM controller software very quickly.

To enable this, we've designed a parameter definition language which allows us to describe the structure of RDM parameter messages in a language-independent manner. This language has the following assumptions:

* The structure of a message (i.e. # of repeated values and the length of variable sized fields) must be able to be determined solely from the parameter definition and the length of the message. All parameters in E1.20 and E1.37-1 conform to this, as well as every manufacturer parameter I've encountered. This means that only one variable-sized field can be present in each message, and that [http://en.wikipedia.org/wiki/Type-length-value TLV] style messages aren't supported.

To get the full benefits of the definition language, the parameter definitions should also:

* Use big-endian for multi-byte fields
* When integer values are used, the values are stores as normal int values, not as ASCII.

The canonical parameter definitions are stored on the http://rdm.openlighting.org site. The data from the site is used to generate an ASCII [https://github.com/google/protobuf protocol buffer] which is then checked into the OLA codebase and distributed with the tarball. One day we may support automatic updating of the parameter definition files.

You can see the latest pid protobufs at <tt>[[code:data/rdm/pids.proto|pids.proto]]</tt> and <tt>[[code:data/rdm/manufacturer_pids.proto|manufacturer_pids.proto]]</tt>. In the tarball the files are in <tt>data/rdm/</tt> and they are usually installed into <tt>/usr/local/share/ola/pids/</tt>.

== Adding New Parameters ==

Parameters are added to the rdm.openlighting.org site by specifying the message structure, as well as properties like the parameter name and PID in a Python file. To get started, clone the rdm.openlighting.org code from https://github.com/OpenLightingProject/rdm-app. The definitions are found in <tt>data/pid_data.py</tt>. Once you have edited this file push the change to a public git repo and email the open-lighting list asking for a pull request. Simon will sanity check the new parameters and push them to the rdm.openlighting.org site.

You can use RDM Pid Builder to add your definitions:
http://imaginux.com/lighting/pids/addpids.php

Or use the tool locally:
https://github.com/RenZ0/rdm-pid-builder

== Structure ==

The section describes the syntax of the parameter definition language in the Python representation used by the rdm.openlighting.org site. The protobuf representation is very similar and the concepts are the same for both representations.

The parameter definitions file is just a Python data structure. At the top level there are two variables <tt>MANUFACTURER_PIDS</tt> and <tt>ESTA_PIDS</tt>.

<pre>
MANUFACTURER_PIDS = [
{'id': <int>, # the manufacturer ID, written in hex
'name': <string>, # the manufacturer name
'pids': [<parameter_definition>],
},
...
]

ESTA_PIDS = [
<parameter_definition>
]
</pre>

Each Parameter Definition takes the form:

<pre>
{
'get_request': {'items': [<item>]},
'get_response': {'items': [<item>]},
'get_sub_device_range': <int>,
'name': <string>,
'set_request': {'items': [<item>]},
'set_response': {'items': [<item>]},
'set_sub_device_range': <int>,
'link': <string>, # the URL for more information
'notes': <string>,
'value': <int>, # the PID
}
</pre>

; {get,set}_request
: The structure of the GET / SET request. This specifies a list of items which are the fields in the parameter message. See the section below for more details.
; {get,set}_response
: The structure of the GET / SET response, same structure as the _request fields.
; {get,set}_sub_device_range
: A value between 0 and 3 which places restrictions on the value of the SubDevice field in the RDM message.
; name
: The name of the PID, should be in CAPS like the names in E1.20
; link
: A URL pointing to where this information was obtained, set to the empty string is there isn't one
; notes
: A text description of what this parameter does. This should be explain to the user how to use the parameter.
; value
: The parameter ID (PID).

The allowed values for the sub_device_ranges are:

; 0
: ROOT_DEVICE, implies the subdevice field is 0x0000
; 1
: ROOT_OR_ALL_SUBDEVICE, the subdevice field is 0x0000 to 0x0200 or 0xffff
; 2
: ROOT_OR_SUBDEVICE, the subdevice field is 0x0000 to 0x0200
; 3
: ONLY_SUBDEVICES, the sub device field is 0x0001 to 0x0200

If a {get,set}_request field isn't present, this means the parameter doesn't support the GET / SET operation. In that case the corresponding _response field should also not be present. Note that this differs from a _request field which is present, but contains no items. The latter means that the parameter data length is 0.

== Items ==

Items represent the data fields within each message. An item can also be a group of items, which is how repeated fields are supported. There are only two required attributes for an item:

<pre>
{
'name': <string>,
'type': <string>',
}
</pre>

Item names should be all lower case, with spaces replaced by _ . In OLA, item names are run through CustomCapitalizeLabel() before being displayed to the user. This replaces '_' with ' ' and capitalizes words. For more details see the code in [[code:common/utils/StringUtils.cpp|StringUtils.cpp]].

The valid item types are:

* bool
* uint8
* uint16
* uint32
* int8
* int16
* int32
* string
* group, a group of items, see below for more details.
* ipv4, a 32 bit IP address
* mac, a 48 bit MAC address
* uid, a 48 bit UID.

All multi-byte items are big endian.

=== Optional Attributes ===

These are only defined for certain item types.

==== Labels ====

Labels can be used with int items (uint8, uint16, uint32, int8, int16, int32) to attach string descriptions to values.

Using DISPLAY_INVERT as an example:

<pre>
{'name': 'invert_status', 'type': 'uint8',
'labels': [(0, 'Off'), (1, 'On'), (2, 'Auto')],
}
</pre>

Labels implicitly restrict the values that the item can hold. In the example above, a value outside the range 0-2 will generate an exception.

==== Ranges ====

Ranges are used to limit the values for an int item. Using REAL_TIME_CLOCK as the example:

<pre>
{'name': 'month', 'type': 'uint8', 'range': [(1, 12)]}
</pre>

If both ranges and labels are specified, the union of values is used as the set of allowed values for the item.

==== Multiplier ====

This is used to shift the decimal point for int items. For example, in PRESET_INFO, the fade times are reported in 10ths of a second.

<pre>
{'name': 'max_preset_fade_time', 'type': 'uint16', 'multiplier': -1},
</pre>

==== Max Size ====

This limits the maximum size of a string, or the maximum allowed groups in a repeated item. From DEVICE_LABEL:

<pre>
{'name': 'label', 'max_size': 32, 'type': 'string'}
</pre>

==== Min Size ====

The opposite of max_size, used for strings and groups. From LANGUAGE_CAPABILITIES:

<pre>
{'name': 'language', 'max_size': 2, 'min_size': 2, 'type': 'string'}
</pre>

=== Item Groups ===

TODO: fill this in

== Examples ==

These examples show how parameters from E1.20 are described using the PID Definitions Syntax.

=== DEVICE_INFO ===

A simple example is DEVICE_INFO. This is only defined for GET commands, and returns a message with various mixed-type fields:

<pre>
{'get_request': {'items': []},
'get_response': {'items': [
{'name': 'protocol_major', 'type': 'uint8'},
{'name': 'protocol_minor', 'type': 'uint8'},
{'name': 'device_model', 'type': 'uint16'},
{'name': 'product_category', 'type': 'uint16'},
{'name': 'software_version','type': 'uint32'},
{'name': 'dmx_footprint', 'type': 'uint16'},
{'name': 'current_personality', 'type': 'uint8'},
{'name': 'personality_count','type': 'uint8'},
{'name': 'dmx_start_address', 'type': 'uint16'},
{'name': 'sub_device_count','type': 'uint16'},
{'name': 'sensor_count', 'type': 'uint8'}]},
'get_sub_device_range': 2,
'name': 'DEVICE_INFO',
'value': 96},
</pre>

=== DEVICE_LABEL ===

DEVICE_LABEL is defined for GET and SET. This example shows how to limit the length of a string.

<pre>
{'get_request': {'items': []},
'get_response': {'items': [
{'name': 'label', 'max_size': 32, 'type': 'string'}
]},
'get_sub_device_range': 2,
'name': 'DEVICE_LABEL',
'set_request': {'items': [
{'name': 'label','max_size': 32, 'type': 'string'}
]},
'set_response': {'items': []},
'set_sub_device_range': 1,
'value': 130},
}
</pre>

=== SLOT_INFO ===

This example shows how repeated fields work:

<pre>
{'get_request': {'items': []},
'get_response': {'items': [
{'name': 'slots',
'type': 'group',
'items': [
{'name': 'slot_offset', 'type': 'uint16'},
{'name': 'slot_type', 'type': 'uint8'},
{'name': 'slot_label_id', 'type': 'uint16'}
]},
]},
'get_sub_device_range': 2,
'name': 'SLOT_INFO',
'value': 288},
</pre>

Open Lighting Allocations

2015-10-12T01:48:28Z

Peternewman: /* UIDs */ SPaG and fix the link

== RDM Model Numbers ==
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].

{| border=1 cellspacing="0"
! '''Number'''!! '''Assigned To'''
|-
|| 0x0001 || Dummy Device
|-
|| 0x0002 || [[Arduino RGB Mixer]]
|-
|| 0x0003 || SPI Device
|-
|| 0x0004 || Dummy Dimmer
|-
|| 0x0005 || Dummy Moving Light
|-
|| 0x0006 || Dummy Ack Timer
|-
|| 0x0007 || Dummy Sensor Responder
|-
|| 0x0008 || Dummy E1.37-1 Dimmer
|-
|| 0x0009 || Dummy E1.37-2 Network Responder
|-
|| 0x0100 || Ja Rule LED Model
|-
|| 0x0101 || Ja Rule Proxy
|-
|| 0x0102 || Ja Rule Moving Light
|-
|| 0x0103 || Ja Rule Sensor Only
|-
|| 0x0104 || Ja Rule Network
|-
|| 0x0105 || Ja Rule Dimmer
|-
|| 0x0106 || Ja Rule Proxy Child Device
|}

== UIDs ==

The Open Lighting code is [http://rdm.openlighting.org/manufacturer/display?manufacturer=31344 0x7a70]

{| border=1 cellspacing="0"
! '''UID Range'''!! '''Assigned To'''
|-
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID
|-
|| 7a70:00000100 - 7a70:000001ff || SPI Devices
|-
|| 7a70:10000000 - 7a70:1fffffff || Microchip devices 00:1E:C0 OUI (Ja Rule)
|-
|| 7a70:20000000 - 7a70:2fffffff || Microchip devices D8:80:39 OUI (Ja Rule)
|-
|| 7a70:30000000 - 7a70:3fffffff || Reserved for Microchip devices 00:04:A3 OUI (Ja Rule)
|-
|| 7a70:fffffe00 - 7a70:fffffe0f || Ja Rule non-MAC Development UIDs
|-
|| 7a70:fffffe10 - 7a70:fffffefe || Development
|-
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices
|}

== Status Message Ids ==

Status Message ID Value Data Value 1 Data Value 2 Status ID Description

{| border=1 cellspacing="0"
! '''Status Message ID'''!! '''Value''' !! '''Data Value 1''' !! '''Data Value2 ''' !! '''Status ID Description'''
|-
|| STS_OLP_TESTING || 0x8000 || Cycle counter major || Cycle counter minor || Counter cycle %d.%d
|-
|| STS_OLP_SELFTEST_PASSED || 0x8001 || Self Test ID || N/A || Self test %d ok
|-
|| STS_OLP_SELFTEST_FAILED || 0x8002 || Self Test ID || N/A || Self test %d failed

|}

== Manufacturer Specific PIDs ==
{{:Open Lighting PIDs}}

Open Lighting Allocations

2015-10-12T01:26:25Z

Peternewman: /* UIDs */ More utilisation

== RDM Model Numbers ==
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].

{| border=1 cellspacing="0"
! '''Number'''!! '''Assigned To'''
|-
|| 0x0001 || Dummy Device
|-
|| 0x0002 || [[Arduino RGB Mixer]]
|-
|| 0x0003 || SPI Device
|-
|| 0x0004 || Dummy Dimmer
|-
|| 0x0005 || Dummy Moving Light
|-
|| 0x0006 || Dummy Ack Timer
|-
|| 0x0007 || Dummy Sensor Responder
|-
|| 0x0008 || Dummy E1.37-1 Dimmer
|-
|| 0x0009 || Dummy E1.37-2 Network Responder
|-
|| 0x0100 || Ja Rule LED Model
|-
|| 0x0101 || Ja Rule Proxy
|-
|| 0x0102 || Ja Rule Moving Light
|-
|| 0x0103 || Ja Rule Sensor Only
|-
|| 0x0104 || Ja Rule Network
|-
|| 0x0105 || Ja Rule Dimmer
|-
|| 0x0106 || Ja Rule Proxy Child Device
|}

== UIDs ==

The Open Lighting code is [http://rdm.openlighting.org/manufacturer/display?manufacturer=31344|0x7a70]

{| border=1 cellspacing="0"
! '''UID Range'''!! '''Assigned To'''
|-
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID
|-
|| 7a70:00000100 - 7a70:000001ff || SPI Devices
|-
|| 7a70:10000000 - 7a70:1fffffff || Microchip devices 00:1E:C0 OID (Ja Rule)
|-
|| 7a70:20000000 - 7a70:2fffffff || Microchip devices D8:80:39 OID (Ja Rule)
|-
|| 7a70:30000000 - 7a70:3fffffff || Reserved for Microchip devices 00:04:A3 OID (Ja Rule)
|-
|| 7a70:fffffe00 - 7a70:fffffe0f || Ja Rule non-MAC Development UIDs
|-
|| 7a70:fffffe10 - 7a70:fffffefe || Development
|-
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices
|}

== Status Message Ids ==

Status Message ID Value Data Value 1 Data Value 2 Status ID Description

{| border=1 cellspacing="0"
! '''Status Message ID'''!! '''Value''' !! '''Data Value 1''' !! '''Data Value2 ''' !! '''Status ID Description'''
|-
|| STS_OLP_TESTING || 0x8000 || Cycle counter major || Cycle counter minor || Counter cycle %d.%d
|-
|| STS_OLP_SELFTEST_PASSED || 0x8001 || Self Test ID || N/A || Self test %d ok
|-
|| STS_OLP_SELFTEST_FAILED || 0x8002 || Self Test ID || N/A || Self test %d failed

|}

== Manufacturer Specific PIDs ==
{{:Open Lighting PIDs}}

OlaOutput Build Intructions

2015-05-02T22:58:18Z

Peternewman: Peternewman moved page OlaOutput Build Intructions to OlaOutput Build Instructions: SPaG

#REDIRECT [[OlaOutput Build Instructions]]

OlaOutput Build Instructions

2015-05-02T22:58:17Z

Peternewman: Peternewman moved page OlaOutput Build Intructions to OlaOutput Build Instructions: SPaG

This describes how to build a 64bit version of the OlaOutput MAX/MSP plugin. Building a 32bit plugin is left as an exercise for the reader.

==Download the Max SDK ==

Download the MAX/MSP SDK from https://cycling74.com/downloads/sdk/. Extract the zip file.

== Install XCode ==

Download [https://developer.apple.com/xcode/ XCode]

== Install OLA ==

Follow the [https://www.openlighting.org/ola/mac-install/ instructions for installing OLA]. The easiest way is to install using MacPorts, which will install into the /opt/local path.

== Clone the OlaOutput Git Repo ==

Clone the [https://github.com/OpenLightingProject/olaoutput git repo].

Move the olaoutput directory under the Max SDK directory from the zip file. It should now look something like:

<pre>
simon:~/Downloads/max-sdk-7.0.3 $ ls -l
total 12016
-rwxr-xr-x@ 1 simon 5000 516 Apr 30 05:38 MaxAPI-7.0.3.html
-rwxr-xr-x@ 1 simon 5000 6137127 Apr 30 05:38 MaxAPI-7.0.3.pdf
-rwxr-xr-x@ 1 simon 5000 265 Apr 30 05:38 README.md
drwxr-xr-x@ 105 simon 5000 3570 Apr 30 05:38 help
drwxr-xr-x@ 831 simon 5000 28254 Apr 30 05:38 html
drwxr-xr-x 3 simon 5000 102 May 1 22:37 max_build
drwxr-xr-x 9 simon 5000 306 May 1 22:36 olaoutput
-rwxr-xr-x@ 1 simon 5000 214 Apr 30 05:38 package-info.json
drwxr-xr-x@ 15 simon 5000 510 Apr 30 05:38 source
</pre>

== Build ==

Start XCode and open the olaoutput/olaoutput/olaoutput.xcodeproj file. You should see something like the screenshot below.

[[File:Olaoutput-xcode1.png|thumb|center]]

Note that XCode can't find commonsyms.c or libprotobuf.8.dylib. Click on commonsyms.c on the left, then in the right panel click on the folder icon and navigate to source/c74support/max-includes/common/commonsyms.c .

For libprotobuf.8.dylib, it's a similar story, click on the folder icon and then select /opt/local/lib/libprotobuf.9.dylib. If you didn't use MacPorts to install OLA, the protobuf library may be in a different location.

Next you'll need to fix the C74SUPPORT path. Click on the 'olaoutput project' in the left pane, then choose 'Build Settings'. Set C74SUPPORT to the correct path (see screenshot).

[[File:Olaoutput-xcode2.png|thumb|center]]

Finally change the dropdown in the center pane from 'max-external' to olaoutput. Then under build settings remove i386 from the list of Valid Architectures.

[[File:Olaoutput-xcode3.png|thumb|center]]

At this point the build should succeed. The .mxo file will be in the max_build directory under the MAX SDK directory.

== Extra Info ==

The plugin will only work on machines where the OLA libraries are installed in the same paths. This means you can build a plugin on a machine where OLA was installed from a tarball and then expect it to work on a machine where OLA was installed using MacPorts.

If you want to build a 386 (32-bit) version, you'll need to build all the MacPorts software with i386 support. See the [https://guide.macports.org/chunked/internals.configuration-files.html build_arch] variable.

OLA Device Specific Configuration

2015-04-26T00:17:33Z

Peternewman: /* SPI */ Info on Device Tree

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following:

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following udev rule:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.

For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:
https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

In both cases, to allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

Open Lighting Allocations

2015-03-17T00:27:26Z

Peternewman: /* UIDs */ Add Arduino RGB mixer

Open Lighting Allocations

2015-03-17T00:14:27Z

Peternewman: /* RDM Model Numbers */ Update some more current model numbers

OLA Buildbot

2015-03-14T16:14:01Z

Peternewman: /* Prerequisites & Warning */ Update the configure options we run

We run a [http://buildbot.net/ Buildbot] instance for [[OLA]].

*Web UI: http://buildbot.openlighting.org
*IRC: OLA-buildbot-ch in #openlighting-build on irc.freenode.org

We're currently only building ola, but this could be extended to do other projects such as the QT GUI etc.

== Master Configuration ==
The buildbot master configuration is stored in git at https://github.com/OpenLightingProject/buildbot . It needs checking out, and symlinking to replace master.cfg in the buildbot master's config directory.

N.B. If the main open-lighting git repository (as opposed to buildbot config) is ever moved or changed, ensure the master's gitpoller-workdir folder is emptied out, or the poller won't work properly.

= Adding a Slave =

Buildbot documentation is at http://docs.buildbot.net/current/manual/installation.html#creating-a-buildslave . The steps below should cover everything you need though.

== Prerequisites & Warning ==

Slaves execute code directly from the git repo. Even though submits to the git repo are locked down, this is still a possible attack vector for your machine. For this reason it's best to run build slaves within a virtual machine. TODO: link to some VM solutions.

At the very least you should run the buildslave as a separate user (not root!). Slave passwords aren't stored in the git repo for security, you'll need to get Simon or Peter to add new ones.

The buildbot performs full build & test runs with all the options enabled. Please make sure you have all the necessary libraries installed on your system. You need to be able to complete a

<pre>
autoconf -i
./configure --enable-e133 --enable-rdm-tests --enable-python-libs --enable-ja-rule
make
make check
</pre>

cycle before proceeding. If you have trouble ask on the mailing list.

If you're running the lint check, you need cpplint.py in your path somewhere, see README.developer for info on how to obtain it.

Buildbot slaves need to connect to buildmaster.openlighting.org:9989 . Make sure your firewall allows this. No port forwarding for inbound connections is required.

== Debian / Ubuntu Instructions ==

This requires wheezy or later. For squeeze you can use the easy_install method below.

=== Build Slave Installation ===

<pre>
sudo apt-get install buildbot-slave
</pre>

=== Slave Configuration ===

Create the slave (the package creates the buildbot user automatically for you):

<pre>
sudo -u buildbot buildslave create-slave --usepty=0 /var/lib/buildbot/slaves/ola buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Update the slave info, edit the files in /var/lib/buildbot/slaves/ola/info to be relevant to you.

Add config for the slave into /etc/default/buildslave (you'll need to increase the array id if you've got more than one slave on the same host), e.g.:
<pre>
SLAVE_ENABLED[1]=1 # 1-enabled, 0-disabled
SLAVE_NAME[1]="ola" # short name printed on start/stop
SLAVE_USER[1]="buildbot" # user to run slave as
SLAVE_BASEDIR[1]="/var/lib/buildbot/slaves/ola" # basedir to slave (absolute path)
SLAVE_OPTIONS[1]="" # buildbot options
SLAVE_PREFIXCMD[1]="" # prefix command, i.e. nice, linux32, dchroot
</pre>

Start the slave
sudo /etc/init.d/buildslave start

Check the log if there are any issues, or confirm the slave is registered at http://buildbot.openlighting.org/buildslaves:
tail -f /var/lib/buildbot/slaves/ola/twistd.log

== FreeBSD Instructions ==

This was tested on FreeBSD 10.

=== Build Slave Installation ===
As root:
<pre>
pkg install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
adduser
</pre>
Username: ola-build-slave
Use password-based authentication? No

Setup the slave:

Switch to the slave user, I did:
<pre>
su - #To root
su - ola-build-slave #To slave user
cd ~
</pre>

Export the variables needed for configure on FreeBSD:
<pre>
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== NetBSD Instructions ==

This was tested on NetBSD 6.

=== Build Slave Installation ===
As root:
<pre>
pkgin install py27-buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>
Use password-based authentication? No

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for git and configure on NetBSD (add these to the .shrc or equivalent for next time):
<pre>
export CPPFLAGS="-I/usr/pkg/include/"
export LDFLAGS="-L/usr/pkg/lib/"
export GIT_SSL_NO_VERIFY=true
</pre>

Setup the slave itself:
<pre>
/usr/pkg/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/pkg/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/pkg/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== OpenBSD Instructions ==

This was tested on OpenBSD 5.4.

=== Build Slave Installation ===
As root:
<pre>
pkg_add py-buildslave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for autoconf and configure on OpenBSD (add these to the .profile or equivalent for next time):
<pre>
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.13
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== Other Platforms ==

=== Build Slave Installation ===

The easiest way to get started is by using easy_install. You need to have the Python headers available, so on Debian / Ubuntu run:

<pre>
sudo apt-get install python-dev
</pre>

Then install buildbot-slave:

<pre>
easy_install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
sudo -s
adduser ola-build-slave # use a temp password for now
vi /etc/shadow # delete the password entry
</pre>

Setup the slave:

<pre>
su ola-build-slave
cd ~
buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot buildbot start /home/ola-build-slave/ola-slave
</pre>

== Enabling the C++ Lint Checker ==

The lint checker enforces C++ style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Download the cpplint checker and put it in /usr/local/bin

<pre>
wget http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
sudo cp cpplint.py /usr/local/bin
sudo chmod a+x /usr/local/bin/cpplint.py
</pre>

Finally let Simon or Peter know, or raise an issue, asking them to enable C++ lint for your slave.

== Enabling the Javascript Lint Checker ==

The lint checker enforces Javascript style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Install the gjslint checker by following the relevant instructions here (you man need to install python-setuptools to get easy_install on Debian/Ubuntu):
https://developers.google.com/closure/utilities/docs/linter_howto

Finally let Simon or Peter know, or raise an issue, asking them to enable Javascript lint for your slave.

== Enabling the heap checker ==

First we need libunwind:

<pre>
sudo apt-get install libunwind8-dev
</pre>

Then download the latest gperftools from https://code.google.com/p/gperftools/downloads/list .

<pre>
wget ....
tar -zxf gperftools-2.1.tar.gz
cd gperftools-2.1
./configure
make
sudo make install
sudo ldconfig
</pre>
Finally let Simon or Peter know, or raise an issue, asking them to enable the heap checker for your slave.

OLA Buildbot

2015-03-14T16:11:25Z

Peternewman: /* Prerequisites & Warning */ More info on passwords

We run a [http://buildbot.net/ Buildbot] instance for [[OLA]].

*Web UI: http://buildbot.openlighting.org
*IRC: OLA-buildbot-ch in #openlighting-build on irc.freenode.org

We're currently only building ola, but this could be extended to do other projects such as the QT GUI etc.

== Master Configuration ==
The buildbot master configuration is stored in git at https://github.com/OpenLightingProject/buildbot . It needs checking out, and symlinking to replace master.cfg in the buildbot master's config directory.

N.B. If the main open-lighting git repository (as opposed to buildbot config) is ever moved or changed, ensure the master's gitpoller-workdir folder is emptied out, or the poller won't work properly.

= Adding a Slave =

Buildbot documentation is at http://docs.buildbot.net/current/manual/installation.html#creating-a-buildslave . The steps below should cover everything you need though.

== Prerequisites & Warning ==

Slaves execute code directly from the git repo. Even though submits to the git repo are locked down, this is still a possible attack vector for your machine. For this reason it's best to run build slaves within a virtual machine. TODO: link to some VM solutions.

At the very least you should run the buildslave as a separate user (not root!). Slave passwords aren't stored in the git repo for security, you'll need to get Simon or Peter to add new ones.

The buildbot performs full build & test runs with all the options enabled. Please make sure you have all the necessary libraries installed on your system. You need to be able to complete a

<pre>
autoconf -i
./configure --enable-e133 --enable-rdm-tests --enable-python-libs
make
make check
</pre>

cycle before proceeding. If you have trouble ask on the mailing list.

If you're running the lint check, you need ccplint.py in your path somewhere, see README.developer for info on how to obtain it.

Buildbot slaves need to connect to buildmaster.openlighting.org:9989 . Make sure your firewall allows this. No port forwarding for inbound connections is required.

== Debian / Ubuntu Instructions ==

This requires wheezy or later. For squeeze you can use the easy_install method below.

=== Build Slave Installation ===

<pre>
sudo apt-get install buildbot-slave
</pre>

=== Slave Configuration ===

Create the slave (the package creates the buildbot user automatically for you):

<pre>
sudo -u buildbot buildslave create-slave --usepty=0 /var/lib/buildbot/slaves/ola buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Update the slave info, edit the files in /var/lib/buildbot/slaves/ola/info to be relevant to you.

Add config for the slave into /etc/default/buildslave (you'll need to increase the array id if you've got more than one slave on the same host), e.g.:
<pre>
SLAVE_ENABLED[1]=1 # 1-enabled, 0-disabled
SLAVE_NAME[1]="ola" # short name printed on start/stop
SLAVE_USER[1]="buildbot" # user to run slave as
SLAVE_BASEDIR[1]="/var/lib/buildbot/slaves/ola" # basedir to slave (absolute path)
SLAVE_OPTIONS[1]="" # buildbot options
SLAVE_PREFIXCMD[1]="" # prefix command, i.e. nice, linux32, dchroot
</pre>

Start the slave
sudo /etc/init.d/buildslave start

Check the log if there are any issues, or confirm the slave is registered at http://buildbot.openlighting.org/buildslaves:
tail -f /var/lib/buildbot/slaves/ola/twistd.log

== FreeBSD Instructions ==

This was tested on FreeBSD 10.

=== Build Slave Installation ===
As root:
<pre>
pkg install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
adduser
</pre>
Username: ola-build-slave
Use password-based authentication? No

Setup the slave:

Switch to the slave user, I did:
<pre>
su - #To root
su - ola-build-slave #To slave user
cd ~
</pre>

Export the variables needed for configure on FreeBSD:
<pre>
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== NetBSD Instructions ==

This was tested on NetBSD 6.

=== Build Slave Installation ===
As root:
<pre>
pkgin install py27-buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>
Use password-based authentication? No

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for git and configure on NetBSD (add these to the .shrc or equivalent for next time):
<pre>
export CPPFLAGS="-I/usr/pkg/include/"
export LDFLAGS="-L/usr/pkg/lib/"
export GIT_SSL_NO_VERIFY=true
</pre>

Setup the slave itself:
<pre>
/usr/pkg/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/pkg/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/pkg/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== OpenBSD Instructions ==

This was tested on OpenBSD 5.4.

=== Build Slave Installation ===
As root:
<pre>
pkg_add py-buildslave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
su -
useradd -m ola-build-slave
</pre>

Setup the slave:

Switch to the slave user:
<pre>
su - ola-build-slave
cd ~
</pre>

Export the variables needed for autoconf and configure on OpenBSD (add these to the .profile or equivalent for next time):
<pre>
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.13
export CPPFLAGS="-I/usr/local/include/"
export LDFLAGS="-L/usr/local/lib/"
</pre>

Setup the slave itself:
<pre>
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
/usr/local/bin/buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave
</pre>

== Other Platforms ==

=== Build Slave Installation ===

The easiest way to get started is by using easy_install. You need to have the Python headers available, so on Debian / Ubuntu run:

<pre>
sudo apt-get install python-dev
</pre>

Then install buildbot-slave:

<pre>
easy_install buildbot-slave
</pre>

=== Slave Configuration ===

Setup a new user:

<pre>
sudo -s
adduser ola-build-slave # use a temp password for now
vi /etc/shadow # delete the password entry
</pre>

Setup the slave:

<pre>
su ola-build-slave
cd ~
buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password>
</pre>

Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.

Then start the slave:

<pre>
buildslave start ola-slave
</pre>

You can look at the logs by running

<pre>
tail -f ola-slave/twistd.log
</pre>

At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.

Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:

<pre>
@reboot buildbot start /home/ola-build-slave/ola-slave
</pre>

== Enabling the C++ Lint Checker ==

The lint checker enforces C++ style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Download the cpplint checker and put it in /usr/local/bin

<pre>
wget http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
sudo cp cpplint.py /usr/local/bin
sudo chmod a+x /usr/local/bin/cpplint.py
</pre>

Finally let Simon or Peter know, or raise an issue, asking them to enable C++ lint for your slave.

== Enabling the Javascript Lint Checker ==

The lint checker enforces Javascript style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.

Install the gjslint checker by following the relevant instructions here (you man need to install python-setuptools to get easy_install on Debian/Ubuntu):
https://developers.google.com/closure/utilities/docs/linter_howto

Finally let Simon or Peter know, or raise an issue, asking them to enable Javascript lint for your slave.

== Enabling the heap checker ==

First we need libunwind:

<pre>
sudo apt-get install libunwind8-dev
</pre>

Then download the latest gperftools from https://code.google.com/p/gperftools/downloads/list .

<pre>
wget ....
tar -zxf gperftools-2.1.tar.gz
cd gperftools-2.1
./configure
make
sudo make install
sudo ldconfig
</pre>
Finally let Simon or Peter know, or raise an issue, asking them to enable the heap checker for your slave.

OLA Device Specific Configuration

2015-03-12T11:35:31Z

Peternewman: /* Linux */ Detail how to make pins writable

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following:

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")
<pre>
chgrp plugdev /sys/class/gpio/gpio23/direction
chmod g+w /sys/class/gpio/gpio23/direction
chgrp plugdev /sys/class/gpio/gpio23/value
chmod g+w /sys/class/gpio/gpio23/value
</pre>

== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following udev rule:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, by editing /etc/modprobe.d/raspi-blacklist.conf and commenting out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

To allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

Building OLA

2015-02-27T01:18:19Z

Peternewman: Link to website

Please see [https://www.openlighting.org/ola/getting-started/downloads/ https://www.openlighting.org/ola/getting-started/downloads/]

OLA Device Specific Configuration

2015-02-06T19:44:30Z

Peternewman: /* Scanlime Fadecandy */

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true
==Streaming ACN / E1.31==

===All Platforms===
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line
<pre>
revision = 0.46
</pre>
to this line
<pre>
revision = 0.2
</pre>
Only do this if the older gear cannot accept the standardized version of E1.31.

===Linux===
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.
Use the following command:
<pre>
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

For example this command sets the maximum number of igmp memberships to 256:
<pre>
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships
</pre>

==Eurolite USB DMX512 PRO==

===Linux===

Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.

You may also need the following:

<pre>
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"
</pre>

===Mac===

Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].

== General Purpose I/O ==

This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]

===Linux===

You'll need to export the GPIO pins. For example, to use pin 23, as root run:

<pre>
$ echo 23 > /sys/class/gpio/export
</pre>

You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:

<pre>
/sys/class/gpio/gpio23/direction
/sys/class/gpio/gpio23/value
</pre>

== OSC ==

The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .

=== Receiving DMX ===

The OSC plugin accepts a number of message formats:

{| border=1 cellspacing="0"
! Path !! OSC Message Type !! Data !! Comments
|-
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512.
|-
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.
|-
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.
|}

=== Sending DMX ===

The following formats are available for sending data:

{| border=1 cellspacing="0"
! Config Option !! Path !! OSC Message Type !! Data !! Comments
|-
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.
|-
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.
|-
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.
|-
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|-
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this.
|}

==Open DMX USB / FTDI RS485 ==

There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.

The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.

=== Linux, Open DMX Kernel Module ===

Make sure the opendmx plugin is enabled.
Make sure the dmx_usb kernel module is loaded.

===Mac FTDI ===

You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins.

Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf)

=== Linux, FTDI ===

Same as Mac, but you also need to make sure that you add the following udev rule:

<pre>
# udev rules for ftdi devices
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"
</pre>

==Scanlime Fadecandy==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the Scanlime Fadecandy device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"
</pre>

== SPI ==

This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].

Enable the spi-bcm2708 module, by editing /etc/modprobe.d/raspi-blacklist.conf and commenting out the "blacklist spi-bcm2708" line. The file should look something like this:

<pre>
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
blacklist i2c-bcm2708
</pre>

To allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules

<pre>
SUBSYSTEM=="spidev", MODE="0666"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==UART native DMX==

===Linux===

====Raspberry Pi====

First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:

[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]

To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add

<pre>
init_uart_clock=16000000
</pre>

to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.

Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

==KarateLight, KarateDMX==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules

<pre>
# udev rules file for the karate-device
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"
</pre>
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.

OLP SOC Ideas Page

2015-01-11T23:20:40Z

Peternewman: /* Port to Windows */ Update the status of this idea

This page lists some ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code 2014] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2014 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself.

Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].

== Adding support for more RDM PIDS to the Web UI ==

Our current WebUI lacks support for a lot of the really cool parameters and features that RDM is capable of. The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end 
* Adding support for Ack Timer packets in the RDM flow 
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web app to use the new web api
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Continue Porting to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Hardware Programming 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See [[issue:280|issue 280]] for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard

OLP SOC Ideas Page

2015-01-11T12:57:32Z

Peternewman: /* Patcher v2 */ Switch to Interwiki links

This page lists some ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code 2014] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2014 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself.

Before asking questions on the list, please read ESR's [http://www.catb.org/esr/faqs/smart-questions.html How To Ask Questions The Smart Way]. Remember, when deciding who to select, we're looking for students who are self-starters and won't start asking questions the first time they run into something they don't understand. A quick Google search goes a long way.

If you'd like to apply, please complete the OLA [[GSOC Challenge]]. This is a prerequisite for being selected. We suggest you start it at least a week before, in case you need to ask questions.

== Adding support for more RDM PIDS to the Web UI ==

Our current WebUI lacks support for a lot of the really cool parameters and features that RDM is capable of. The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end 
* Adding support for Ack Timer packets in the RDM flow 
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web app to use the new web api
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Port to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

This project would include:
* Refactoring the base classes under [[code:common/network|common/network]] to use the Windows network & event management APIs and ensuring that all unit tests pass.
* Cleaning up various parts of the code which use POSIX APIs (see [[issue:140|issue 140]] for an example)

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Network Programming & Windows Event Handling 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See [[issue:280|issue 280]] for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard

OLP SOC Ideas Page

2015-01-11T12:56:44Z

Peternewman: /* Port to Windows */ Switch to interwiki links

This page lists some ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code 2014] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2014 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself.

Before asking questions on the list, please read ESR's [http://www.catb.org/esr/faqs/smart-questions.html How To Ask Questions The Smart Way]. Remember, when deciding who to select, we're looking for students who are self-starters and won't start asking questions the first time they run into something they don't understand. A quick Google search goes a long way.

If you'd like to apply, please complete the OLA [[GSOC Challenge]]. This is a prerequisite for being selected. We suggest you start it at least a week before, in case you need to ask questions.

== Adding support for more RDM PIDS to the Web UI ==

Our current WebUI lacks support for a lot of the really cool parameters and features that RDM is capable of. The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end 
* Adding support for Ack Timer packets in the RDM flow 
* Adding support for additional parameter ids or (PIDS).
'''Skills Required''': HTML, Javascript, C++ 
'''Estimated Difficulty''': Medium

== Raspberry Pi UI ==

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:
* Designing, writing and testing the new UI
 
'''Skills Required''': Python ? 
'''Estimated Difficulty''': Easy

== RESTful API ==

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:
* Writing and testing the new API
* Modifying our current Web app to use the new web api
 
'''Skills Required''': C++, Javascript, HTML, JSON 
'''Estimated Difficulty''': Easy

== Web Based Configuration of Preferences ==

User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Easy

== Asynchronous Web Notification of RDM Messages ==

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].

'''Skills Required''': C++, Network Programming, Javascript, HTML, Google Closure 
'''Estimated Difficulty''': Medium

==Port to Android==

Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.

This project would include:
* Building OLA as a Android Application
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
* Writing a frontend in Java to demonstrate the capabilities of OLA.

'''Skills Required''': C++, Java, Android 
'''Estimated Difficulty''': Hard

==Port to Windows ==

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.

This project would include:
* Refactoring the base classes under [[code:common/network|common/network]] to use the Windows network & event management APIs and ensuring that all unit tests pass.
* Cleaning up various parts of the code which use POSIX APIs (see [[issue:140|issue 140]] for an example)

A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.

 

'''Skills Required''': C++, Windows Network Programming & Windows Event Handling 
'''Estimated Difficulty''': Hard

== Patcher v2 ==

Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See https://github.com/OpenLightingProject/ola/issues/280 for some additional features and thoughts.

'''Skills Required''': C++, Javascript, HTML 
'''Estimated Difficulty''': Hard