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.

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: 2024-Feb-19