LARA key info

WHAT is LARA? WHY do users need it?

Future-proof It helps integrators with simplified automation setup in meeting
room automation platform rooms. Also allows corporate employees to focus on their
by Lightware meetings instead of managing the practicalities in the room.

HOW does LARA achieve this? HOW MUCH

Through a user-friendly, easily parametrizable modular software solution does it cost?
that eliminates the need to have deep programming knowledge, while keeping Initially free of charge. Advanced
the possibility for advanced programmers to write their own modules. features might be priced.

WHERE can you find it?

Runs integrated in Taurus and MMX2, configurable via a browser.
Meeting participants can control the devices in the room through a touch panel.

2
Overview

Lightware Advanced Room Automation (LARA) is a Because of the modular design, the integrators can build
future-proof room automation platform which enables their system based on existing modules (drivers, touch
to control both Lightware and 3rd party devices in a screens, services and more) or create their own.
meeting room area and also to access remote services
over the network. Thanks to the approach of open source modules, the
integrators can easily modify or extend the existing
LARA has an easy-to-use graphical user interface which modules or use them as a base for their new solutions.
lets the integrators set up and deploy their system and
also helps the technicians and IT people to check the However, LARA was designed to have an intuitive user
actual system status and diagnose possible errors. interface where integrators can set up the behavior of the
meeting room by creating rules and setting various
For end users LARA comes with built-in touchscreen parameters, there is an option to write codes.
support where a fully customizable graphical interface
can be provided to literally any modern touchscreen JavaScript is one of the most widespread languages
devices. today, which has an easy learning curve and huge online
community. By using the popular NodeJS engine under
LARA eliminates the need for an external controller unit or the hood, the integrators can rely on the 1.3 million JS
PC as it is embedded into the Taurus UCX and MMX2 packages available freely today.
family.

3
Why LARA?
Readiness to use
• Pre-written driver modules eliminate the need of complex programming skills
• Possibility for advanced programmers to write their own modules in JavaScript
• Reusable elements with easy parametrization

Open integration
• Can control any device which supports open protocols: LW, 3rd party, remote services
• Generic pre-written modules for the most common protocols (REST, TCPIP, LW3, etc)
• No need for certificated trainings

No need for external controller

• LARA is in Lightware products (for now in Taurus and MMX2 only)
• No need for external controller unit
• Updates come with firmware upgrade

4
 What Can LARA Do at 1st Release?

• Room automation from GUI with Event-Action setup • Replace user scripts with LARA script module:
Integrators are able to code their own room automation in LARA script module.
• Wizard instead of coding:
Integrators can set up automation with the pre-written modules without/with • Convert user scripts to LARA script modules:
minimal coding. LW to make the existing LW user scripts compatible with LARA so end-users don’t
experience any change and the integrators only have to upload and run the new
• Pre-written driver modules: LARA script modul.
Integrators can set up device control without/with minimal coding. • Upload, download backup configuration:
Taurus / TCPIP / REST / LW3 modules are in LARA by default at launch Integrators do not lose the configuration when upgrading firmware.
Integrators can keep a backup of their configurations.
• Room control from user panel with customizable layout:
So end-users can control the room during a meeting. Integrators can duplicate the configuration of a room to another room.

• Factory reset:
• Status board: Integrators can always get back to the default version of LARA: default modules with
Integrators/maintenance teams can easily get a visual status overview of the default (for now empty) configuration.
running modules and quickly do a health-check to spot bugs.
Helps integrators/maintenance teams with debugging. • Script module templates from user scripts:
Integrators have to set only the parameters for the 3 most common meeting room
• Real-time log: operations including Cisco (these can cover the functionality of most of the already
For integrators/maintenance teams to see the status of the running modules. existing user scripts)

• Help functionality:
Built-in manual to guide the integrators how to use LARA.

5
Example
Someone connects a laptop to Taurus input 1
Event1  Taurus reports signal present on input 1.

Monitor 1 driver turns on and sets its volume

Action2 for a predefined volume level

Monitor 2 driver also turns on and sets its

Action3 volume for a predefined volume level

Taurus driver sets GPIO on output 6 to Low ~

Action4 it turns off the light

All relevant changes are reported to the UI

Action1 panel instance

Someone pushes a button on touch panel 

Event2 UI panel reports user touch interaction

Taurus driver to set GPIO in output 6 to Low

Action4 ~ it turns off the light

Action3 Taurus driver sets crosspoint switch to input 1

6
 Why is LARA Important Now?

It overcomes the difficulties of user script-based room automation and will provide a future-proof solution.

User scripts LARA goals

Programming Complex programming skills are needed. Need Fit for integrators with no/limited/advanced
skills to modify the code for every small change. coding skills

Status board with actual device statuses, manually

Debugging No option to find feedback about errors. trigger events and invoke methods, console log for
viewing device communication

Compatibility No guarantee for future compatibility with new

Compatibility with new firmware guaranteed
with host device Taurus firmware versions.

Structure One large complex script, hard to modify for AV Modular, easily parametrizable, reusable setup.
integrators User-friendly GUI interface

7
How Does LARA Work?
LARA’s automation is based on rules that consist of three elements: Event - Condition(s) - Action(s).

Event: this is the rule trigger, we

can set only one event for one rule

Condition(s): status criteria, if the

rule is triggered by the event and
the condition(s) are met, the
action(s) will run

Action(s): this will happen when

the event triggers the rule and the
conditions are met

We can create the driver’s own

rules in the driver module.

We can create the room’s logic

(~the interaction of different
drivers) within the business logic
module.

See more details on the coming

slides.

8
What Are Modules in LARA?

Modules are software pieces which can be freely distributed, modified, uploaded / deleted from
LARA. A module can be downloaded as a ZIP file from the graphical user interface or uploaded back.

There are five different types of modules:

• Logic module – Describes the business logic of the room / interactions between other modules
• User panel module – Provides a user interface for the end-users, eg. tabletop control /
interaction between other modules
• Driver module – Connects to a device in the room
• Service module – Connects to a service on the network (eg. calendar services)
• Script module – Any custom software for a specific purpose
Driver, service and script modules are intended to be reusable between projects. For example if
you have a driver module for a specific television brand and model, you can re-use it in other rooms
with different setup.
However, logic and user panel modules are different – they create the connection between
other modules, by defining rules. Therefore logic and user panel modules are tied to the current
configuration and they might be modified if moved to another project.

9
What Are Instances in LARA?

If we speak about modules as

independent programs, you can run
them in one or more instances.
With a simple analogy: if you have an
executable file on your computer, it is a
module. When you run it in one or
multiple times, the windows are the
instances.
The software pieces are identical
behind the running instances, however
you can give them different parameters
when starting them, modifying their
behaviour.
Parameter for a driver module can be
for example the IP address of the device
or the unique ID of the television. When
you have multiple instances, all of them
can have different kind of parameter set.

10
Events and Methods: How do Instances Communicate with Each Other?
Running modules as independent instances is great, but how
can they cooperate to realize a real meeting room control?
Of course, the instances need to communicate with each
other. The basic primitives for this communication are
events and methods.
Every instance can dispatch Events when something
happens. An event has a source (which instance has
dispatched it), a name (like ‘GpioChange’) and optionally has
one or more parameters (like ‘gpioNumber’=1, ‘state’=1).
An event is always momentary, it will be dispatched
immediately when something triggers it and it has no length,
continuous existence in time. An event can be used by other
logic or user panel instances (explained later), or even can be
used by the same instance itself.
Methods are software pieces, which can be invoked by using
their name and passing the optional parameters. By defining
methods in modules, the running instances can provide
services for external logic and user panel instances.
For example if your sony_bravia_professional driver
module has a setVolume method with a volume parameter,
then the logic instance can invoke this method on the instances
of the driver module and pass the requested volume level.
*UI panel (user panel) modul can also manage interaction of the driver modules, like the logic 11
modul can.
How Do LARA Automation Rules Work?
Every module might have unlimited number of rules. However, instances of driver, service and script
modules cannot communicate with other instances, like receiving events or invoking methods.
This limitation ensures that driver, service and script modules are easily re-usable in other
projects and doesn’t depend on other instances, however they still can use rules to define their own
internal logic.
A rule consists three integral parts: Event, Condition and Action.
When defining a new rule, we have to set up the event which will trigger the rule. To do that, first
the source of the event has to be selected, where from the event shall be originated. With logic and
user panel modules any existing instance can be selected, other modules can use only their own
dispatched events. After that the name of the event has to be picked.
The rule will be triggered when the event with this name from the selected source has been
dispatched.
After triggering the rule, LARA will check all of the conditions set up. A rule can have multiple
conditions where optional event parameters and also state variables can be compared. Similar as
above, only logic and user panel modules can use state variables from other instances. When
multiple conditions are defined, they can be in AND or OR connection with each other. When
conditions are in AND connection, both of them shall be fulfilled to continue. When conditions are in
OR connection, it is enough if one condition evaluating as true.*
The action part defines what to do when conditions are met. The action can be set up by a
wizard holding unlimited number of steps or can be written in javascript if preferred.
*Note: In the first LARA release, conditions cannot be used

12
LARA’s Development Approach
• At 1st launch we deliver a solution fast (MVP*), that can already solve the user’s problem.
• To be able to deliver the solution fast, we consciously cut functionalities and comfort enhancements
to minimum, we don’t deliver a “skyrocket” product just yet.

Instead, we do it
gradually, by adding new
functionalities regularly
in small product
increments, prioritizing
them by user value.


• Delivering in small increments enables us to put the customer in the center of product development
 we continuously iterate based on feedbacks and market changes, we keep close contact with customers.
*MVP=Minimum Viable Product  the first delivered product increment that is able to give value to the user
13
LARA’s Development Approach

Why and how does this approach benefit LARA?

• We can react to user feedback and market changes
fast without re-work and deliver user-validated solutions
• Quick time-to-market, user problems solved fast, no
need to wait years for a whole perfect product to be
developed
• The user gets a basic, but viable and constantly improving
solution when s/he needs it.
If we developed with the traditional approach it’s possible
that by the time we enter the market, the market need is
not valid anymore.

14
LARA’s Development Approach

What does it mean for the LARA functionalities for the 1st launch?
We will have limited number of driver
modules  We regularly add more and more modules

For the user panel control the HTML Later we will have what-you-see-is-what-you-get
content has to be uploaded manually  user panel design editor

By developing more and more modules,

Due to the few driver modules, some
technical/coding skills are required  functionalities, the need for technical skills will
decrease

Gradually we will automatically populate the cells

In multiple places we expect the user to
type in data, eg. Action name  and make the interface more and more
convenient to save time and effort for the users

15
Agile Sandcastles

How
traditional
development
is done

How we do
development
now Release 1 Release 2 Release 3 Release 4

Picture souce: https://medium.com/the-pinch/you-cant-make-a-skateboard-into-a-car-259b28c1b1b9

16
 What Future Ideas Are on the LARA Roadmap?
Condition management
Include conditions in rule management to 1
complement events and actions. Offline configuration
2 Run on PC so integrators can configure
What-you-see-is-what-you-get user panel design without internet and without Taurus.
Create user panel design without HTML content 3
coding.
Parametrized bulk configurations
New pre-written driver modules 4 Add and run one config for multiple identical
5 rooms.
Shure microphone, PJLink projector, Sony Bravia TV,
LG-Signage TV, etc.
Wizard at first login and factory reset
Open community platform Help user experience at 1st login and after
6
Online platform where integrators can share the factory reset: default config/upload config or
driver modules they wrote and the user panel 7 start with empty configuration
designs they prepared and also download
Lightware’s driver modules.
…etc.
17