Skip to content

# VeraController

VeraController is the interface to Vera hubs. Veras running firmware 7.0.27 and higher are supported (earlier versions may work fine but have never been tried).

Configuring a VeraController instance is straight-forward: the only required configuration key is `source`, to which you should assign the base URL to access the Vera system. For example:

    controllers:
    - id: vera
      enabled: true
      implementation: VeraController
      name: Vera System
      config:
        source: "http://192.168.0.20:3480"

openLuup Support

OpenLuup is an emulation of Vera Luup and is supported by VeraController to the degree that openLuup conforms with the behavior of Vera Luup in all respects necessary for VeraController to operate. There is no direct, official support for openLuup. Disparities in functionality between openLuup and Vera Luup should really be addressed in openLuup, as this improves that system for all of its current and future users. But it is up to the author of the openLuup project to decide if he wants to address these issues or not, but if he chooses not, it may leave the system unable to meet the needs of Reactor. As a result, support for openLuup is strictly as-is and as-available, and may not be possible in future versions of Reactor.

## How VeraController Maps Devices

As a controller, VeraController's primary duty is to collect data from the Vera system and publish it within Reactor as entities. It does this by mapping between the two systems. This mapping is principally done in a pair of configuration files: `server/lib/vera_devices.json` and `server/lib/vera_capabilities.json`. The latter defines any capabilities that are specific to Vera devices — those that are not generic enough to have been defined as system-wide capabilities shared by all controllers. The former is the real workhorse, containing the rules by which entities are assigned capabilities based on properties of their respective Vera devices. It's not important to know the details of this, but do know that because this process is driven largely by configuration files, it is possible for you to create additional user-space configuration to describe devices not yet included in the standard mapping — you don't need to wait for upgrades. More on that later.

Don't Edit the System Files!

Never modify the system-standard device mapping files. These will be overwritten on every upgrade. See TBD for instructions on the proper way to define your own device mappings.

As of build 26108, rooms known to the Vera hub will be mapped to room groups controlled by DynamicGroupController. Prior to this build, VeraController created and managed its own groups for rooms. The intent of the new behavior is that one group may serve all controllers having devices/entities in a same-named room. For example, if you have a Vera system with devices in the "Living Room" room and a Home Assistant hub with devices and entities in the "Living Room" area, a single group under DynamicGroupController will be created with the combined set of devices/entities as members. If you want or need the old pre-26108 behavior, add `rooms_as_local_groups: true` to your VeraController configuration. This old behavior is deprecated, however, so it will be removed from a future release and you should migrate to the new model.

## Special Configuration for VeraController

This section is informational only. It is not usually necessary to specify these values or modify their defaults.

- `PollTimeout` — Vera uses a technique called "long polling" for quick data access. When a request is made for data, the Vera can be told to pause until something has changed before it replies, and this value controls the length of that pause. The default value is 15000 (milliseconds), which is 15 seconds. It is not recommended that you change this value in most circumstances.
- `PollMinimumDelay` — a partner of `PollTimeout`, this value sets the minimum time that Vera must wait before responding. Often, when one thing changes in the system, other things quickly follow. This minimum delay causes the Vera to hold off responding to the query for the prescribed period (again in milliseconds), so that the response that it eventually makes can bundle several changes at once, rather than handing them over singly. This improves performance and responsiveness of the integration. Much testing has shown that the default 50 milliseconds is a good value.
- `ActionPace` — Controls the rate at which actions are sent to the Vera. Vera system stability demands that we don't throw too many things at it simultaneously, so all actions are pipelined. This value sets the minimum delay between action requests sent via that pipeline. The value is expressed in milliseconds, and is 25 by default. If you find that your Vera deadlocks and reloads while trying to execute long reactions, try increasing this value (some devices and plugins just need more time).

## Using the `x_vera_sys.runlua` action

The `x_vera_sys.runlua` action (on the system entity of each VeraController instance) can be used to run Lua code from Reactor on the Vera system. In order for this to work, the `UnsafeLua` flag in the Vera firmware must be enabled (i.e. set to 1). If this flag is not enabled, you will get errors trying to use the action, and also see errors in your Vera's log. You can check the state of the flag on your Vera by examining the `x_vera_sys.unsafelua` attribute on the VeraController instance's system entity.

To set the flag on your Vera system:

    luup.attr_set("UnsafeLua", 1, 0)
    luup.reload()

Updated: 2026-Apr-18