MiOS - User contributions [en]

Luup Lua extensions

2014-02-26T20:08:42Z

Guessed: /* function: variable_get */ Change example to show that it returns a timestamp result in addition to the value.

In addition to the [[http://lua.org Lua]] commands described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]], you can also reference in your Lua code variables and functions from modules which the Luup engine provides as follows:

== Module: luup ==

These are general purpose functions and variables. Call them by using the luup. module, such as: 

<source lang="lua">luup.log('Now running version: ' .. luup.version)</source>

=== variable: device ===

The ID of this device instance, if it's running as part of a device

=== variable: version, version_branch, version_major, version_minor ===

''version'' contains the version of the luup engine, such as "1.0.843", as a string. The version consists of 3 numbers separated by a period: the branch, the major version, and the minor version. To make it easier to compare against a minimum acceptable version, ''version_branch, version_major and version_minor'' return each component as a number. You can put a comparison in the startup function in your Luup plugin and return false if the minimum version isn't met. The user will then see that the Luup device's startup check failed: 

<source lang="lua">if( version_branch ~= 1 or version_major ~= 0 or version_minor < 843 ) then
luup.log("I need version 1.0.843 minimum to run")
return false
end</source>

=== variable: longitude ===

Contains the longitude as a number, as found on the location tab in the setup UI.

=== variable: latitude ===

Contains the latitude as a number, as found on the location tab in the setup UI.

=== variable: timezone ===

Contains the timezone as a number of hours offset from UTC, as found on the location tab in the setup UI. It accounts for DST, so, for example, Pacific Standard time will be -8 or -9 depending on DST.

'''Note:''' Contains 0 for MiOS < 1.5.250 (Vera V2) / < 1.5.249 (Vera V3).

=== variable: city ===

Contains the city as a string, as found on the location tab in the setup UI.

=== variable: devices ===

Contains all the devices in the system as a table indexed by the device number.

The members are:
* '''room_num''': (number) This is the number of the room the device is in.
* '''device_type''': (string) This is a string representing the type of the device.
* '''category_num''': (number) This is a category for the device. See: [[Luup_Device_Categories]] for a list.
* '''subcategory_num''': (number) This is a sub category for the device.
* '''device_num_parent''': (number) This is the number of the parent device. See: [[Lua Device Structure]] for details.
* '''ip''': (string) If this device is IP based, this is the IP address.
* '''mac''': (string) If this device is IP based, this is the MAC address.
* '''user''': (string) If this device is IP based and requires http authentication, this is the username
* '''pass''': (string) If this device is IP based and requires http authentication, this is the password
* '''id''': (string) If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.
* '''embedded''': (boolean) If this device is embedded, it means that it doesn't have its own room or exist as a separate device. It should be considered part of its parent. Like a 3-in-1 sensor is a device with 3 embedded child devices.
* '''hidden''': (boolean) If true the user checked the 'hidden' box and doesn't want to see the device on the dashboard.
* '''invisible''': (boolean) If true the device is 'for internal use only' and shouldn't be presented to the user.
* '''description''': (string) This is the text description for the device as supplied by the user in the web UI.
* '''udn''': (string) This is the UDN for the UPnP device.

Example to log device #5's IP address and its internal ID:
<source lang="lua">luup.log('Device #5 ip: ' .. luup.devices[5].ip .. ' id: ' .. luup.devices[5].id)</source>

This code will log all the attributes from all the devices:
<source lang="lua">for k, v in pairs(luup.devices) do
for k2, v2 in pairs(v) do
luup.log("Device #" .. k .. ":" .. k2 .. "=" .. tostring(v2))
end
end

return true</source>

=== variable: rooms ===

Contains all the rooms as a table of strings indexed by the room number. Example: 

<source lang="lua">luup.log('Room #1 is called: ' .. luup.rooms[1])</source>

=== variable: scenes ===

Contains all the scenes in the system as a table indexed by the scene number. The members are: room_num (number), description(string), hidden(boolean)

=== variable: remotes ===

Contains all the remotes in the system as a table indexed by the remote id. The members are: remote_file (string), room_num (number), description(string)

=== variable: event_server ===

type: string

Contains the notification/event server. On UI5 it can be either ''cms1.mios.com'' or ''cms2.mios.com''.

=== variable: ra_server ===

type: string

Contains the remote access server. Can be either ''fwd1.mios.com'' or ''fwd2.mios.com''.

=== variable: pk_accesspoint ===

type: number

Contains the serial number of this Vera.

=== variable: hw_key ===

type: string

Contains the Vera hardware key.

=== function: log ===

parameters: what_to_log (string), log_level (optional, number)

return: nothing

Writes what_to_log to the log, /var/log/cmh/LuaUPnP.log, with the given log_level, which is 50 by default. See: [[Luup Loglevels]]

=== function: task ===

parameters: message (string), status (number), description (string), handle (number)

return: handle (number)

When the Luup engine is starting status messages are displayed for the various modules as they're initialized. Normally each device, including Luup devices, automatically log their status and the user is shown an error if the device doesn't start, such as if the 'startup' function returns an error.

If you have other startup sequences which you want the user to see to know that startup hasn't finished yet, call this function passing in a handle of -1 for the first call. The status should be: 1=Busy, 2=Error, 4=Successful. Message is the current state, such as 'downloading', and description describes the module, like 'Smartphone UI'. After the first call, store the handle and pass it on future calls to update the status rather than add a new one.

=== function: call_delay ===

parameters: function_name (string), seconds (number), data (string), thread (bool)

returns: result (number)

The function ''function_name'' (the first parameter), which must be passed as a string, will be called in ''seconds'' seconds (the second parameter), and will be passed the string ''data''. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name. function_name will only be called once and you must call call_delay again if you want it called again, or use call_timer instead.

If thread is specified and is true or 1, the call back will be made in it's own thread and can block if needed. Normally it is called by a worker thread and is expected to return immediately.

As of December 19, 2011, for all builds after 1.5.237, the 'thread' will be ignored. Each Lua state has its own worker thread now, so all calls to call_delay and call_timer will occur in a separate thread.

=== function: call_timer ===

parameters: function_name (string), type (number), time (string), days (string), data (string)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called when the timer is triggered, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name.

Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer. For an interval timer, days is not used, and Time should be a number of seconds, minutes, or hours using an optional 'h' or 'm' suffix. Example: 30=call in 30 seconds, 5m=call in 5 minutes, 2h=call in 2 hours. For a day of week timer, Days is a comma separated list with the days of the week where 1=Monday and 7=Sunday. Time is the time of day in hh:mm:ss format. Time can also include an 'r' at the end for Sunrise or a 't' for Sunset and the time is relative to sunrise/sunset. For example: Days="3,5" Time="20:30:00" means your function will be called on the next Wed or Fri at 8:30pm. Days="1,7" Time="-3:00:00r" means your function will be called on the next Monday or Sunday 3 hours before sunrise. Day of month works the same way except Days is a comma separated list of days of the month, such as "15,20,30". For an absolute timer, Days is not used, and Time should be in the format: "yyyy-mm-dd hh:mm:ss"

Data can be a string passed back to the function. The function should be declared so it takes a single argument, which is this data. 

<source lang="lua">function refreshCache(stuff)
....
end

function startup()
--
-- Setup an interval-based timer to call refreshCache after 30 minutes.
-- Note that if you want it to "recur" then you need to call this function again
-- at the end of the refreshCache() implementation.
--
luup.call_timer("refreshCache", 1, "30m", "", "SomeStuff")
end</source>

=== function: is_ready ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: ready (boolean)

version: UI5 and above

Checks whether a device has successfully completed it's startup sequence. If so, is_ready returns true. If your device shouldn't process incoming data until the startup sequence is finished, you may want to add a condition to the <incoming> block that only processes data if is_ready(lul_device) is true.

<source lang="lua"><incoming>
if (luup.is_ready(lul_device) == false) then
return
end

doSomething(lul_device)
</incoming></source>

=== function: call_action ===

parameters: service (string), action (string), arguments (table), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: error (number), error_msg (string), job (number), arguments (table)

Invokes the UPnP service + action, passing in the arguments (table of string->string pairs) to the device. If the invocation could not be made, only error will be returned with a value of -1. Otherwise, all 4 values are returned. error is 0 if the UPnP device reported the action was successful. arguments is a table of string->string pairs with the return arguments from the action. If the action is handled asynchronously by a Luup job, then the job number will be returned as a positive integer.

Example to dim device #5 to 50%: 

<source lang="lua">local lul_arguments = {}
lul_arguments["newLoadlevelTarget"] = 50
lul_resultcode, lul_resultstring, lul_job, lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:Dimming1",
"SetLoadLevelTarget", lul_arguments,
5)</source>

=== function: variable_set ===

parameters: service (string), variable (string), value (string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]], [startup (bool)]

returns: nothing

The UPnP 'service' + 'variable' will be set to the 'value' for this device. If there are events or notifications tied to the variable they will be fired.

The device parameter: if it's a string, is interpreted as a udn. If it's a number, it's interpreted as a device number.

Optionally, you can add an argument 'startup'. If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will ''not'' be fired.

=== function: variable_get ===

parameters: service (string), variable (string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: value (string) and Unix time stamp (number) of when the variable last changed

Returns the value of the UPnP service + variable and the time when the variable was last modified, as a unix time stamp (number of seconds since 1/1/1970). If the service+variable or device does not exist, it returns nothing. 

[[Example usage]]
<source lang="lua">local value, tstamp = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5)
luup.log("Dim level for device #5 is: " .. value .. " last changed (Epoch): " .. tstamp)</source>

The device parameter: if it's a string, is interpreted as a udn. If it's a number, it's interpreted as a device number.

[[Caution - Incorrect usages]]
<source lang="lua">local value = tonumber(luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5))
</source>

<code>luup.variable_get</code> returns two parameters and <code>tonumber</code> also accepts two parameters. However the parameters are incompatible: the Unix timestamp returned by <code>luup.variable_get</code> is being used as a number base in the function <code>tonumber</code>. The number base is limited to a power of 36 or less and the current timestamps are in the range of thousands of millions.

<source lang="lua">local value = tostring(luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5))
</source>

<code>luup.variable_get</code> returns two parameters and <code>tostring</code> only expects one

=== function: attr_set ===

parameters: attribute (string), value(string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: none

Sets the top level attribute for the device to value. Examples of attributes are 'mac', 'name', 'id', etc.

=== function: attr_get ===

parameters: attribute (string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: string or none (note: none means nothing at all. It does not mean 'nil')

Gets the top level attribute for the device. Examples of attributes are 'mac', 'name', 'id', etc. If the attribute doesn't exist, it returns nothing. If nothing is passed in for device, it gets the top level attribute from the master userdata, like firmware_version.

<source lang="lua">-- This code logs nil if theDeviceNumber is invalid.
local theName = luup.attr_get ('name', theDeviceNumber)
luup.log(theName)
return true
</source>

<source lang="lua">-- This code fails if theDeviceNumber is invalid.
luup.log(luup.attr_get ('name', theDeviceNumber))
return true
</source>

=== function: ip_set ===

''Not available in UI5 or lower''

parameters: value (string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: none

Sets the IP address for a device. This is better than setting the "ip" attribute using attr_set because it updates internal values additionally, so a reload isn't required.

=== function: mac_set ===

''Not available in UI5 or lower''

parameters: value (string), device (string or number)

returns: none

Sets the mac address for a device. This is better than setting the "mac" attribute using attr_set because it updates internal values additionally, so a reload isn't required.

=== function: reload ===

''Not available in UI5 or lower''

parameters: none

returns: none

Reloads the Luup engine.

=== function: create_device ===

''Not available in UI5 or lower''

parameters:
* device_type (string)
* internal_id (string)
* description (string)
* upnp_file (string)
* upnp_impl (string)
* ip (string)
* mac (string)
* hidden (boolean)
* invisible (boolean)
* parent (number)
* room (number)
* pluginnum (number)
* statevariables (string)
* pnpid (number)
* nochildsync (string)
* aeskey (string)
* reload (boolean)
* nodupid (boolean)

returns: the device ID

This creates the device with the parameters given, and returns the device ID.

=== function: register_handler ===

parameters: function_name (string), request_name (string)

returns: nothing

When a certain URL is requested from a web browser or other HTTP get, function_name will be called and whatever string and content_type it returns will be returned.

See the Smartphone Web Interface plugin as an example: 

<source lang="lua">luup.register_handler("lug_WapRequest","wap")

function lug_WapRequest (lul_request, lul_parameters, lul_outputformat)
local lul_html = "<head>\n" ..
"<title>Main</title>\n" ..
"</head>\n" ..
"<body>\n" ..
"Choose a room: \n"
local lul_content_type = "text/html"
return lul_html, lul_content_type
end</source>

The request is made with the URL: data_request?id=lr_[the registered name] on port 49451. So: http://192.168.1.1:49451/data_request?id=lr_wap will return the web page defined in the function lug_WapRequest in the example above.

=== function: variable_watch ===

parameters: function_name (string), service (string), variable (string or nil), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: nothing

Whenever the UPnP variable is changed for the specified device, which if a string is interpreted as a UDN and if a number as a device ID, ''function_name'' will be called. See [[Luup Declarations#watch_callback]] for the values that will be passed to ''function_name''. If variable is nil, ''function_name'' will be called whenever any variable in the service is changed.

=== function: devices_by_service ===

parameters:

returns:

=== function: device_supports_service ===

parameters: service ID (string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: ''true'' if the device supports the service, ''false'' otherwise

A device supports a service if there is at least a command or state variable defined for that device using that service. Setting UPnP variables is unrestricted and free form, and the engine doesn't really know if a device actually uses it or does anything with it. So this function isn't really definitive.

=== function: set_failure ===

parameters: value (int), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns:

Luup maintains a 'failure' flag for every device to indicate if it is not functioning. You can set the flag to 1 if the device is failing, 0 if it's working, and 2 if the device is reachable but there's an authentication error. If device is a string it is interpreted as a udn, if it's a number, as a device id. The lu_status URL will show for the device: <tooltip display="1" tag2="Lua Failure"/> and Lua Failure is shown in red in UI5 for the device.

=== function: is_night ===

parameters: none

returns: ''true'' if it's past sunset and before sunrise, ''false'' otherwise.

=== function: sleep ===

parameters: number of milliseconds

returns: none

Sleeps a certain number of milliseconds

=== function: sunset / sunrise ===

parameters: none

returns: The next sunset / sunrise in a Unix timestamp (i.e. the number of seconds since 1/1/1970 in UTC time). You can do a diff with os.time to see how long it will be for the next event. luup.sunset-os.time is the number of seconds before the next sunset. Be sure the location and timezone are properly set or the sunset/sunrise will be wrong.

required firmware: 1.5.353

== Module: luup.inet ==

=== function: wget ===

parameters: URL (String), Timeout (Number), Username (String), Password (String)

returns httpStatusCode (Number), content (String)

This reads the URL and returns 2 variables: the first is a numeric error code which is 0 if successful, and the second is a string containing the contents of the page. If '''Timeout''' is specified, the function will timeout after that many seconds. The default value for '''Timeout''' is 5 seconds. If '''Username''' and '''Password''' are specified, they will be used for HTTP Basic Authentication.

 

== Module: luup.chdev ==

Contains functions for a parent to synchronize its child devices. Whenever a device has multiple end-points, the devices are represented in a parent/child fashion where the parent device is responsible for reporting what child devices it has and giving each one a unique id. For example in the sample [[Luup Somfy Walkthrough]] there is a parent device, which is the interface module that controls up to 16 blinds, and up to 16 child devices, one for each blind. As shown in that sample, the parent calls start, then enumerates each child device with append, and finally calls sync. You will need to pass the same value for device to append and sync that you passed to start.

=== function: start ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: ptr (binary object)

Tells Luup you will start enumerating the children of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. The return value is a binary object which you cannot do anything with in Lua, but you do pass it to the append and sync functions.

=== function: append ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]], ptr (binary object), id (string), description (string), device_type (string), device_filename (string), implementation_filename (string), parameters (string), embedded (boolean) [, invisible (boolean)]

returns: nothing

Adds one child to device.

Pass in the ptr which you received from the luup.chdev.start call. Give each child a unique id so you can keep track of which is which. You can optionally provide a description which the user sees in the user interface.

device_type is the UPnP device type, such as urn:schemas-upnp-org:device:BinaryLight:1.

If device_filename is specified, that is the name of the XML file with the UPnP device specification. The deviceType from the filename will override any device_type you set manually. If the device_file contains the implementation file for this child device you do not need to specify it in implementation_filename. Otherwise, if there is a Luup implementation for this child device and it's not being handled by the parent device, you can specify it in implementation_filename.

If embedded is true, the 'embedded' flag is set for the device which generally means that the parent and all the children will be displayed as one compound device, or group, rather than as separate devices which you can put in their own rooms.

The parameters are UPnP service,variables you want set when the device is created. You can specify multiple variables by separating them with a line feed (\n) and use a, and = to separate service, variable and value, like this: service,variable=value\nservice...

<source lang="lua">
luup.chdev.append(device, children,
string.format("Input-%d", i), string.format("Input %d", i),
"urn:schemas-micasaverde-com:device:TemperatureSensor:1", "D_TemperatureSensor1.xml",
"", "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=50", true)
</source>

=== function: sync ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]], ptr (binary object),

returns: nothing

Pass in the ptr which you received from the start function. Tells the Luup engine you have finished enumerating the child devices. If the child devices have changed in any way, the new device tree will be written to the configuration file and the Luup engine is reset.

== Module: io ==
io.open 
io.write 
io.intercept 
io.read 
io.is_connected

=== function: open ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]], ip (string), port (number),

returns: nothing

This opens a socket on 'port' to 'ip' and stores the handle to the socket in 'device'. The opening of a socket can take time depending on the network, and a Luup function should return quickly whenever possible because each top-level device's Lua implementation runs in a single thread. So the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.

Generally you do not need to call the open function because the socket is usually started automatically when the Luup engine starts. This is because the user typically either (a) associates a device with the destination io device, such as selecting an RS232 port for an alarm panel, where the RS232 is proxied by a socket, or (b) because the configuration settings for the device already include an IP address and port.

=== function: write ===

parameters: data (string), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: result (boolean)

In Lua a string can contain binary data, so data may be a binary block. This sends data on the socket that was opened automatically or with the open function above, and associated to 'device'. If the socket is not already open, write will wait up to 5 seconds for the socket before it returns an error. Result is 'true' if the data was sent successfully, and is 'false' or nill if an error occurred.

The written data is modified depending upon the value of the [[Luup_Plugins_ByHand#<protocol>|<protocol> tag]].

=== function: intercept ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: nothing

Normally when data comes in on a socket (I/O Port), the block of data is first passed to any pending jobs that are running for the device and are marked as 'waiting for data'. If there are none, or if none of the jobs' incoming data handlers report that they consumed (i.e. processed) the data, then the block of data is passed to the general 'incoming' function handler for the device. If you want to bypass this normal mechanism and read data directly from the socket, call intercept first to tell Luup you want to read incoming data with the read function. This is generally used during the initialization or startup sequences for devices. For example, you may need to send some data (a), receive some response (b), send some more data (c), receive another response (d), etc. In this case you would call 'intercept' first, then send a, then call read and confirm you got b, then call intercept again, then send c, then read d, and so on.

You can call the read function without calling intercept and any incoming data will be returned by that function after it's called. The reason why you generally must call intercept is because normally you want to send some data and get a response. If you write the code like this ''send(data) data=read()'' then it's possible the response will arrive in the brief moment between the execution of send() and read(), and therefore get sent to the incoming data handler for the device. Intercept tells Luup to buffer any incoming data until the next read, bypassing the normal incoming data handler. So ''intercept() send(data) data=read()'' ensures that read will always get the response. If the device you're communicating with sends unsolicited data then there's the risk that the data you read is not the response you're looking for. If so, you can manually pass the response packet to the incoming data handler.

**TBD: Add a function to do this**

=== function: read ===

parameters: timeout (number), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: data (string)

This reads a block of data from the socket. You must have called ''intercept'' previously so the data is passed. The time unit for ''timeout'' is seconds. 

=== function: is_connected ===

parameters: [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: connected (boolean)

This function returns true if there is a valid IO port connected, otherwise returns false

== Module: luup.job ==

=== function: status ===

parameters: job_number (number), [[Luup_Lua_extensions#device:_string_or_number|device (string or number)]]

returns: job_status (number), notes (string)

If '''job_number''' is invalid the function returns ''-1''. If '''device''' is a string it is interpreted as an UDN, if it's a number, as a device ID.

This is the list with all job statuses and their meaning:
* '''-1''': No job, i.e. job doesn't exist.
* '''0''': Job waiting to start.
* '''1''': Job in progress.
* '''2''': Job error.
* '''3''': Job aborted.
* '''4''': Job done.
* '''5''': Job waiting for callback. Used in special cases.
* '''6''': Job requeue. If the job was aborted and needs to be started, use this special value.
* '''7''': Job in progress with pending data. This means the job is waiting for data, but can't take it now.

=== function: set ===

parameters: job (userdata), setting (string), value (string)

returns: nothing

This stores a setting for a job.

<source lang="lua"><job>
luup.job.set(lul_job, "comments", "In progress...")
local comments = luup.job.setting(lul_job, "comments")
luup.log("job comments = " .. comments)
</job></source>

=== function: setting ===

parameters: job (userdata), setting (string)

returns: value (string)

This returns a setting for a job.

== Notes ==
=== device: string or number ===
*If a number, it is the device ID
*If a string, it is the UDN for the UPnP device
Both of these can be found in the User Interface (UI5) under the advanced Tab as "id" and "local_udn" respectively.

Examples:

<source lang="lua">
local update_frequency = luup.variable_get("S_WebcamDropboxUploaderSettings1.xml","SendFrequency",87)
local update_frequency = luup.variable_get("S_WebcamDropboxUploaderSettings1.xml","SendFrequency","uuid:4d494342-5342-5645-0057-000001c9d682")
</source>

[[Category:Development]]

Luup plugins and Luup code

2012-09-26T15:38:45Z

Guessed: /* Alphabetical list of all Luup plugins, Luup code fragments and Vera clients */ Obsolete HDMI-CEC Plugin

= '''All Luup plugins, Luup code fragments and Vera clients by category''' =

== '''Alarm System integration''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Ademco Honeywell Vista 20P Alarm Plugin
| 
| plugin
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4531.0]
| 
| N/A
| 
|-
| DSC Alarm Panel
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| GE Caddx Networx NX-584 NX-8E Alarm Plugin
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
|-
| Paradox Alarm Plugin
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
|}

 

== '''Development''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
|}

 

== '''Energy management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
|-
| Trane Thermostats
| 
| plugin
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
|}

 

== '''Home Entertainment management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Denon Receiver Control Plugin
| 
| plugin
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
|-
| Learning IR codes
| 
| Windows application
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| MCV
| 
| 
| 
| 
| 
| N/A
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
|-
| Sending IR codes
| 
| code
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
|-
| TiVo
| 
| 
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
|}

 

== '''Interfacing''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| [http://forum.micasaverde.com/index.php?topic=6007.0]
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
|}

 

== '''Monitoring''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| MCV
| 
| IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| [http://wiki.micasaverde.com/index.php/ICamView]
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|}

 

== '''Notifications''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=1412.0]
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
|}

 

== '''System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ADD
| Alerter for Drowsy Devices
| code
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| cf. Battery low notification
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| cf. ADD
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| based on 'Z-Wave routing matrix' by Ap15e
|-
| LSI
| Luup System Information
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
|-
| Z-Wave routing matrix
| 
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
|}

 

== '''Temperature or Weather measurement''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
|}

 

== '''UI''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled rece
| client
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| MCV
| 
| 
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Elisa
| Control device locally and remote
| client
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
|}

 

== '''Utility''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
|-
| Closing a window shutter partially
| 
| code
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| TedStriker
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| 
| Working
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| [http://forum.micasaverde.com/index.php?topic=5609.0]
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
|-
| Slowly dim your lights
| 
| code
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| cf. WakeupRamp
|-
| Sunrise/sunset
| 
| code
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| cf. Slowly dim your lights
|-
| Wavemaking
| 
| code
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
|}

 

== '''Watering System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
|}

 

= '''Alphabetical list of all Luup plugins, Luup code fragments and Vera clients''' =

{| border="1" cellpadding="2"
|-
! Name
! Description
! Type
! Category
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Unique MCVID
! Remarks
! Screenshot
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| Interfacing
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
| 
| 
|-
| ADD
| Alerter for Drowsy Devices
| code
| System management
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| 
| cf. Battery low notification
| 
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| UI
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled receivers.
| client
| UI
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
| 
| 
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| Energy management
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| UI
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| UI
| MCV
| 
| 
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| System management
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| 
| cf. ADD
| 
|-
| Brultech Power Monitor
| Energy Monitoring integration for Brultech ECM-1240 devices.
| plugin
| Energy management
| guessed
| 
| Brultech ECM-1240
| 
| [http://forum.micasaverde.com/index.php?topic=7589.0]
| [http://code.mios.com/trac/mios_brultech-power-monitor]
| Working
| 
| 
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
| 
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| Utility
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
| 
| 
|-
| Closing a window shutter partially
| 
| code
| Utility
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Interfacing
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
| 
| 
|-
| dataMine Graphing Plugin
| Records and graphs variables. A GUI is provided to select any MIOS variable and graphs are presented in real-time with zoom/scroll capability.
| plugin
| Utility
| Chris Jackson
| 
| 
| 
| [http://forum.micasaverde.com/index.php/topic,7750.0]
| [http://code.mios.com/trac/mios_datamine]
| Working
| 
| 
| 
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Utility
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| 
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
| 
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| System management
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| 
| based on 'Z-Wave routing matrix' by Ap15e
| 
|-
| Denon Receiver Control Plugin
| 
| plugin
| Home Entertainment management
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
| 
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| Home Entertainment management
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#DSC_PowerSeries_Panels|DSC Alarm Panel]]
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Alarm System integration
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Elisa
| Control device locally and remote
| client
| UI
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
| 
| 
|-
| Elk M1 Family Panels 
| Integration with the Elk M1 alarm panels via the RS232 port.
| plugin 
| Alarm System integration
| mcvflorin 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6916.0] 
| [http://code.mios.com/trac/mios_elk-alarm-panel] 
| Working 
| 
| 
| 
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| Notifications
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
| 
| 
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| Utility
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Energy management
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| Interfacing
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
| 
| 
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| Watering System management
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
| 
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Utility
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| 
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
| 
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| Monitoring
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
| 
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Monitoring
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
| 
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| Utility
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#GE.2FCaddx_NetworX_Panels|GE Caddx NetworX NX-584 NX-8E Alarm Plugin]]
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| Alarm System integration
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
| 
| 
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| Monitoring
| MCV
| 
| IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
| 
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Development
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| Interfacing
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| Utility
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| UI
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
| 
| 
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Temperature or Weather measurement
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| Utility
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
| 
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| UI
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
| 
| 
|-
| Honeywell Ademco Vista Panels via AD2USB
| Integration with Honeywell's Ademco Vista panels via the AD2USB adapter.
| plugin
| Alarm System integration
| mcvflorin 
| 
| AD2USB Adapter 
| 
| [http://forum.micasaverde.com/index.php?topic=7266.0]
| [http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb] 
| Beta
| 
| 
| 
|-
| Honeywell Ademco Vista Panels with RS232 
| Integration with Honeywell's Ademco Vista panels with a RS232 interface.
| plugin
| Alarm System integration
| dfad1469
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6626.0]
| [http://code.mios.com/trac/mios_ademco-panels-plugin]
| Working
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| UI
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
| 
| 
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| Monitoring
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/ICamView]
| 
|-
| IO Relay Plugin
| This component permits the control of Relay and Analog IO boards from IORelay.com (National Control Devices). Controls up to 8 Relays and 8 Analog inputs.
| plugin
| Interfacing
| guessed
| 
| ProXR, ProXR Lite, Reactor Relay board from iorelay.com
| 
| [http://forum.micasaverde.com/index.php?topic=7589.0]
| [http://code.mios.com/trac/mios_iorelay]
| Working
| 
| 
| 
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| Interfacing
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
| 
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Home Entertainment management
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
| 
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| UI
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| UI
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
| 
| 
|-
| Learning IR codes
| 
| Windows application
| Home Entertainment management
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
| 
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Interfacing
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Home Entertainment management
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
| 
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| Home Entertainment management
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
| 
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Utility
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
| 
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| UI
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
| 
| 
|-
| LSI
| Luup System Information
| plugin
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
| 
| 
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Interfacing
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| Development
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
| 
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| 
| 
| N/A
| 
| 
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| Interfacing
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| 
| [http://forum.micasaverde.com/index.php?topic=6007.0]
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| System management
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
| 
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| Home Entertainment management
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
| 
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| Home Entertainment management
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
| 
| 
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| Monitoring
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| Home Entertainment management
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#Paradox_EVO_Panels|Paradox Alarm Plugin]]
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| Alarm System integration
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
| 
| 
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| Interfacing
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| Utility
| TedStriker
| guessed, Henk
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| [http://code.mios.com/trac/mios_ping-sensor]
| Working
| 
| 
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| Notifications
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
| 
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| Utility
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
| 
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| 
| [http://forum.micasaverde.com/index.php?topic=5609.0]
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| System management
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
| 
| 
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| Interfacing
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Interfacing
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
| 
| 
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Utility
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
| 
| 
|-
| Sending IR codes
| 
| code
| Home Entertainment management
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| 
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
| 
|-
| Slowly dim your lights
| 
| code
| Utility
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| 
| cf. WakeupRamp
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| UI
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Notifications
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
| 
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| Interfacing
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| UI
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
| 
| 
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| Home Entertainment management
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
| 
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| Home Entertainment management
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Home Entertainment management
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
| 
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| Home Entertainment management
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
| 
| 
|-
| Sunrise/sunset
| 
| code
| Utility
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
| 
| 
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| Energy management
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
| 
| 
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| Interfacing
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
| 
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| Utility
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
| 
| 
|-
| TiVo
| 
| 
| Home Entertainment management
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
| 
|-
| Trane Thermostats
| 
| plugin
| Energy management
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
| 
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| Notifications
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=1412.0]
| 
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| Notifications
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
| 
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| Notifications
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
| 
| 
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
| 
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Utility
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| UI
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
| 
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| Notifications
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
| 
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| Utility
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
| 
| 
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
| 
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| Utility
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
| 
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| Utility
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| 
| cf. Slowly dim your lights
| 
|-
| Wavemaking
| 
| code
| Utility
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
| 
| [http://forum.micasaverde.com/index.php?action=dlattach;topic=5865.0;attach=1826;image]
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| Temperature or Weather measurement
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
| 
| 
|-
| Z-Wave routing matrix
| 
| code
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
| 
|}

 

= '''Sources''' =

Sources: http://forum.micasaverde.com/ http://code.mios.com/ http://wiki.micasaverde.com/index.php/Luup_Projects http://forum.micasaverde.com/index.php?topic=6280.msg40147#msg40147 http://www.micasaverde.com/list-of-apps.php 

 

= '''Todo''' =

[[Category:Development]] [[Category:Plugins]]

Luup Variables

2012-09-26T15:34:44Z

Guessed: /* Weather Plugin */ Example now moved to the Wiki for the Weather plugin, since that Wiki is maintained, and secured correctly.

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

=On/Off Switch=

==Device category==
Device Category 3,
UPnP device id: ''urn:schemas-upnp-org:device:BinaryLight:1''

==Variables==
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left" width="30%"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:SwitchPower1''||''Status''||If the device is on, the value is ''1'', otherwise it's ''0''.
|}

==Examples==
* Getting whether the Switch/Light is on or off
<source lang="lua">
local switchOnOff = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 37)
if (switchOnOff == "1") then
-- Switch is on
...
end if
</source>

* Request that the Switch be turned on. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 37)
</source>

=Dimmable Light=

==Device category==
Device category 2,
UPnP device id: ''urn:schemas-upnp-org:device:DimmableLight:1''

==Variables==
Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, ''LoadLevelStatus'' indicates the dim level.

{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left" width="30%"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:Dimming1''||''LoadLevelStatus''||If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from ''0-100'' indicating a percentage of brightness.
|}

==Examples==
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

=Thermostat=

==Device category==
Device category 5,
UPnP device id: ''urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1''

==Variables==
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left" width="30%"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:HVAC_UserOperatingMode1''||''ModeStatus''||This indicates the current operating mode and will be one of the following basic values:
* ''Off''
* ''HeatOn''
* ''CoolOn''
* ''AutoChangeOver''

In addition to the basic modes, some thermostats may also support the following modes:
* ''InDeadBand''
* ''AuxHeatOn''
* ''EconomyHeatOn''
* ''EmergencyHeatOn''
* ''AuxCoolOn''
* ''EconomyCoolOn''
* ''BuildingProtection''
* ''EnergySavingsHeating''
* ''EnergySavingsCooling''
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat''||''CurrentSetpoint''||This indicates the current heat set point.
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool''||''CurrentSetpoint''||This indicatea the current cool set point.
|-
|''urn:upnp-org:serviceId:TemperatureSensor1''||''CurrentTemperature''||This indicates the current ambient temperature.
|}

==Examples==
* Getting the current temperature
<source lang="lua">
local outsideTemp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 5)
</source>

=Other Devices or Services=
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "rain")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "ConditionGroup",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather ConditionGroup using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''ConditionGroup''

All we have to add is the device ID that Vera creates. In my case #''37''

Luup Variables

2012-09-26T15:33:21Z

Guessed: /* Other Devices or Services */

Luup Somfy Walkthrough

2012-05-30T05:49:04Z

Guessed: /* Step 5: Create the child devices for the blinds */ Add the other reference to D_BinaryLight1.xml

[[Category:Development]]
This page is for developers wanting to learn how to write a plugin. If you simply want to use the Somfy plugin see: [[Somfy_Plugin]]

This page walks through in detail the process of creating a Luup plugin to control the Somfy RS232 interface for motorized blinds as a sample. The Somfy documentation (see: [http://www.blindshademotors.com/documents/accessories-special-applications/rs232-to-rts-compatability.pdf]) explains that you talk to the controller using RS232 9600 Baud, 8 Data Bits, 1 Stop Bit, No Parity. The interface supports up to 16 blinds. The communication is one-way only; there are no response codes or incoming data from the blinds when they change manually. Here is the relevant section from the manual.

RS232 Operation
1. Set RS232 communication settings to: 9600 Baud, 8 Data Bits, 1 Stop Bit, No Parity
2. Use the ASCII protocol command string syntax: <!> <2 digit channel number> <Directional Command>
3. The directional commands must be capital letters and are as follows:
U: UP
D: DOWN
S: STOP
4. Examples: Motor 2 Up: !02U
Motor 5 Down: !05D
Motor 1 Stop: !01S

==Step 1: SSH into Vera==

Since this device is so simple it may not be necessary to debug anything. But we'll do this anyway. You need to give Vera a root password, which is the administrator password to login directly. Do this by either: a) from a command prompt in Windows, Linux or Mac type telnet [ip address of vera] and when you see the ''root@HomeControl:~#'' prompt enter: ''passwd'' and type in a password twice. Then type exit. Or b) In Vera's web ui click Advanced, Net & Wi-fi and the 'Advanced Configuration' link, and supply the password there. Note, sometimes Windows Vista doesn't have the telnet utility installed, so you have to use step b.

Once you have a root password set, you will no longer be able to use telnet to login to Vera, you must use ssh. The reason you should use ssh to login for debugging, and not telnet, is because some of the useful key sequences, like Ctrl+C, don't work in telnet.

Once you've setup a root password, from a Mac or Linux console type: ''ssh [ip of vera]'' From a Windows PC, download putty.exe here: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html]. You don't need to install putty, just put the .exe on your desktop or in a folder. When you run putty.exe, type in Vera's IP address and click 'open'. If you don't see the root password or need help logging in see [[Logon_Vera_SSH#Can.27t_find_the_root_password.3F|Logon # Can't find the root password?]].

When you see ''login as:'', enter: ''root'' and then enter your password. Now from the ''root@HomeControl:#'' prompt type:

cd /var/log/cmh
tail -f LuaUPnP.log

Do something in Vera's web ui and you'll see the logs go. Whenever the system rotates the logs, meaning purges the log files because Vera's memory is limited for storing logs, your tail will end. Press the 'up' arrow and hit 'enter' to display the tail command again and restart it. Press Ctrl + c when you've confirm the logs are working ok.

In Vera's web ui, choose Advanced, Logs, and check 'Verbose logging'. This option will create large logs that have lots of information we may need for debugging. It will stay checked for 24 hours and then automatically turn itself off so you're not creating unnecessarily large log files.

==Step 2a: Add your device with the web generator tool==

--coming soon. for now use step 2b.

== Step 2b: Add your device by building the XML files by hand ==

To do this you'll want a good text editor. I'm using, such as Notepad++ available here: [http://notepad-plus.sourceforge.net/uk/site.htm] by clicking Download, Download Notepad++ executable files, download and run the npp....Installer.exe file, and you may also want to download the 'XML plugin' from the download page, and unzip it putting the file \Program Files\Notepad++\plugins.

In Vera's setup UI, go to Devices, Luup plugins, click 'Luup files' and download the files:

''D_BinaryLight1.xml'' since there is no UPnP device specification for blinds, and blinds are essentially binary devices that are either up/down, we can implement the up/down using the same service that a light switch uses, and that way any UPnP control point that can control a light switch, will also be able to control blinds.

''S_SwitchPower1.xml'' because when you open D_BinaryLight1.xml, you'll see that in the 'services' section, this is the filename (SCPDURL) for the SwitchPower service.

[[Media:D_TestSerial.zip | ''D_TestSerial.xml'']] because this is a sample serial device we can use as a template.

[[Media:I_TestSerial.zip | ''I_TestSerial.xml'']] because this is a sample implementation for our serial device.

Open D_TestSerial.xml in your text editor and re-save it as a different name, such as D_SomfyBlinds.xml. Change the xml field deviceType to "urn:somfy-com:device:blinds:1" or use your own domain name instead of somfy-com. Change friendlyName to "Somfy Blind Controller", manufacturer to "Somfy", manufacturerURL to "somfy.com", modelDescription to "16 port RS232 to Somfy blind interface", modelName to "1810686" (the Somfy part number). modelURL and serialNumber and UPC aren't really important so you can just remove them. Add in their place a protocol tag with the value 'raw', and handlechildren (we'll explain this one later) with the value 1, like this:

<source lang="xml">
<protocol>raw</protocol>
<handleChildren>1</handleChildren>
</source>

The 'raw' protocol is because the Somfy device doesn't have any particular low level protocol, like terminating blocks of data with a carriage return, etc. Remove all the tags in 'servicelist'.

Change the filename in the ''implementationFile'' tag from I_TestSerial.xml to I_SomfyBlinds.xml.

Open I_TestSerial.xml and delete the sample Lua code within the 'actionList' tag. We have to put some Lua code in the implementation file for the Luup engine to start it, so for now just put a placeholder in the 'functions' xml tag:

<source lang="lua">
function lug_startup(lul_device)
luup.log("Somfy blind #" .. lul_device .. " starting up with ID " .. lug_device[lul_device].ID)
end
</source>

and in the 'startup' xml tag, put: ''lug_startup'', like this:

<source lang="xml">
<startup>lug_startup</startup>
</source>

So we've created a Lua function, lug_startup, told the Luup engine to call it when the engine is starting up. The name lug_startup is arbitrary, it can be anything you want. Save the file as I_SomfyBlinds.xml.

Back on Vera's setup ui under 'Luup files' you the first 'upload' button to upload D_SomfyBlinds.xml and the 2nd to upload I_SomfyBlinds.xml. Check ''Restart Luup after upload'' because the files won't be processed unless we restart the Luup engine, and click 'go'. Now leave your browser tab open at this page so that as we change the implementation file we can just click 'go' without having to select the files again.

In another browser tab go to Vera's device page again and under 'Add device' put the new device filename ''D_SomfyBlinds.xml'' in the input box, and choose the room where the blind controller is located, click 'Add device'. You'll have a new, blank device in that room, so give it a description "Somfy Blind Controller", then click 'save'.

Note that if the Somfy device was bi-direction we should attempt to communicate with it during the startup sequence and the startup function should return false if the sequence failed, or true if it succeeded, followed by some comments and the name of the module, which information is shown to the user in the info panel. So: return false,'Interface not responding','Somfy Blind' or return true,'Initialized OK','Somfy Blind'

==Step 3: Setup the port==

Vera talks to serial devices using a serial port proxy that turns the serial port into a network port. This way the serial port can reside anywhere on the network. Here are 3 ways to connect Vera to the Somfy device:

1. Get the UC232R-10 usb->serial adapter here: [http://www.futureelectronics.com/en/Pages/index.aspx] Connect it to one of Vera's USB ports. In Vera's web ui, click the 'save' button, which, even if the 'save' button is grayed out, causes the Luup engine to re-initialize and scan for new serial ports. Wait 30 seconds.

2. Use any Windows COM port or USB->serial port device. Download [[Windows_Serial_Proxy]] and run it as explained there. Wait 30 seconds after running it and it will exit after it has reported the port to the Luup engine.

3. Connect a Global Cache GC-100 to your network. Wait 30 seconds or so for the Luup engine to find it. This should happen automatically. Bring up the GC100's setup page in your web browser; you can find the IP address in Vera's device page under the + sign, and set the baud/parity/etc. for the port to match. In the case of the GC-100, this information is supplied to the GC-100 itself and the values in the Serial Port Configuration page have no effect.

After you've done 1, 2 or 3, go to Devices, Luup plugins and click "Serial port configuration". The serial port should be on the list. Use the pull-down's to set the serial port options: baud=9600, Data Bits=8, Stop Bits=1, Parity=none. For the 'Use with device', select your Somfy Blind controller. Choose 'Save'.

==Step 4: Test the port==

First, make note of the device id for your Somfy blinds by clicking '+' next to the device in the device list. Next, go to Devices, Luup Plugins, Test Luup code. In the 'Device number' input box put the device number for the Somfy blinds. This way whatever code we test uses the Lua instance for the Somfy blinds, which will be configured already to use the serial port.

In the 'Code' input box, type: ''luup.io.write('!01U')'' and click 'Go'. That is a command according to the Somfy specs, which should make motor #1 go up. You can try other commands and click 'Go' each time. If everything is working ok, skip to step 6. If it's not working, you will want to do some debugging. Here's some debug things to try:

1. Be sure you checked 'Verbose logging' in Step 1. In your ssh console (ie putty if you're using windows) enter ''tail -f LuaUPnP.log | grep '^5\|^01' '' where the | means to send the output through the grep utility, which will filter out only certain lines. The ^ means 'lines that start with'. Line that start with 5 are logs related to Lua, and lines that start with 01 are critical errors. The \| means 'or' for grep. Now go back and click 'go' again in the Test Luup window. Return to the ssh console and you should see a line that starts with 51, which means data sent within Luup, that shows !01U, in this format: ''51 06/29/09 17:19:53.453 0x21 0x30 0x31 0x55 0xd 0xa (!01U\r\n)'', where the human-readable ascii text is in () at the end, following the binary/hex. If you're going to be switching back and forth between the ssh console and web ui to do tests, then before you switch to the web ui, you can either hit 'enter' a few times in the ssh console to add some blank space, or press Ctrl+c and then 'up' followed by 'enter' to restart tail. That way you've created some separation between existing log entries and new ones so you can clearly see what is happening when you click 'go'. If you're not seeing anything, in the Test Luup window add the line ''lu_log('test somfy')'' above the luup.io.write. You should see 'test somfy' get logged when you press 'go'.

2. Assuming you do see the line '51' log entry showing that the Luup engine is trying to send data, you may want to check the serial port itself. You can go back to the 'serial port configuration' and remove the 'Somfy blind' device from the serial port so the Luup engine won't open the port. Make a note of the network ip and port for the serial port. Click 'Save' to save your changes. Now from a command prompt run: ''telnet [ip] [port]''. If you don't have telnet, open another putty session and click the 'telnet' radio box, put in the ip address and port and click 'open'. You should now be able to type the commands in the telnet session: ''!01U'' and see the blinds work. If it still doesn't work, try connecting the blinds directly to your PC and using a terminal program, like Hyperterminal, to talk directly to the serial port and confirm the connections are ok.

==Step 5: Create the child devices for the blinds ==

In Luup, when you have an interface device which is able to control multiple devices this is represented as a tree where the interface is a 'virtual' device, that probably doesn't implement any actions itself, and multiple 'child devices' under the interface device for each device the interface can control. The Somfy Blind controller is such a device because the 1 interface can control 16 blinds. If it only controlled 1 blind, we wouldn't need to implement the parent/multiple child architecture, because we would have just 1 device which implemented the blind functions. We also wouldn't need to create any functions in Lua and we'd simply have put the control protocol in the 'action' tags in the implementation XML. But we want a parent 'Somfy interface' with up to 16 different child devices for each of the 16 blinds the device can control. This means it's a bit more complicated, so we'll want to use Lua functions, like 'lug_startup'.

The way to implement multiple children is with the 'Reporting child devices' commands documented in [[Luup_Lua_extensions]]. This is how a parent device, in this case the Somfy blind interface, reports to the Luup engine what child devices it has and what ID number it will use internally to keep track of each one. Every device in Luup has an "ID" value which has no meaning to the Luup engine itself, but which is used by parent devices to keep track of the children. Many interface devices have a way to get from them the list of child devices so the parent can manage the children automatically. The Somfy doesn't. So we have 2 choices: 1) Just automatically report 16 child devices since the interface supports 16 devices, or 2) Let the user indicate which Somfy blind numbers he has and report just those child devices. The advantage of #1 is that it's very simple, but the drawback is that the user will see 16 blinds in his home, even if he only has 1. So, we will do it with #2. The first question is where to let the user store the list of blind numbers that are active. The usual way to store this information is to create a UPnP service which contains variables for all the various parameters the user should specify to configure the device. Creating a UPnP service description document and adding it to the device description is a lot of work to get only 1 parameter: a list of device numbers. But, what we can do is instead just create a variable in Lua using some service id/variable we made up, like this:

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
</source>

This won't be an 'official' UPnP variable and won't show up in a UPnP scanner. But, it does show up in Vera's user interface as a variable the user can edit the value. We want to be sure we set this to a default value if it's not already there so the user sees it in the UI and can change it.

Now we'll add the Lua code to iterate through all the blinds and create the devices, which will go in the lug_startup function we created earlier. We could put the code directly in the XML implementation file. But that means saving/uploading the file each time, and is a bit more tedious. It's often easier to debug it first in the 'Test Luup code' window. So we'll this to test first. First, put in the code box: ''lug_startup(123)'' but change the 123 to the actual device number of the Somfy blind, and click 'go'. Switch back to the ssh console that is tail'ing the LuaUPnP.log. You'll see that it logged ''Somfy blind #... starting up with ID''. This is because we already created the lug_startup function in the implementation file, and in the code box we just called that function. Now put this in the code box:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID="01,02"

luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1","BlindIds", lul_ID, lul_device)
luup.log("test2--Somfy blind #" .. lul_device .. " starting up with ID " .. lul_ID)
end

lug_startup(123)
</source>

where 123 should be your actual device number for the device. The Lua code in ''function lug_startup'' will cause the lug_startup function that was already in the implementation file to be replaced with this version, without actually executing the function (just updating it), so afterward we also have lug_startup(123) to actually run the new version we updated. When you click 'go' you'll see in the ssh log that the it now says ''test2--Somfy blind'', so you can see the lug_startup function was replaced. Note that any functions you create in the 'Test Luup Code' window will still stay in the Luup engine until you reload the Luup engine. So if you type in the code box:

<source lang="lua">
function some_test()
luup.log("some_test")
end
</source>

click 'go', nothing will get logged. If you then erase the code box and type: ''some_test()'' when you click 'go', you'll see "some_test" in the log. If you want to update the some_test function, and run it at the same time, do:

<source lang="lua">
function some_test()
luup.log("some_test2")
end

some_test()
</source>

Now when you click 'go', you'll see "some_test2" be logged. So we'll create a simple startup that creates all 16 blinds by putting this in the Test Luup code window:

<source lang="lua">
function lug_startup(lul_device)
child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-upnp-org:device:BinaryLight:1", "D_BinaryLight1.xml", "", "", true)
end

luup.chdev.sync(lul_device, child_devices)
end

lug_startup(123)
</source>

The ''for i=1,16'' is runs the block before 'end' 16 times, assigning the variable 'i' to 1 to 16 each time. We want the devices to be 0 padded to 2 digits, so 1 should be "01". This is because the ID which the Somfy needs is a zero-padded 2 digit number. It also will make it easier to filter just the blinds we want to control as explained later. The statement ''s = string.format("%02d", i)'' converts the numeric value 'i' to a string that is padded to decimal places. This is documented in Lua (see [http://www.lua.org/pil/20.html#StringLib]).

luup.chdev.start() takes as a parameter our device id (ie the parent device) and it tells the Luup engine we're going to start listing all our children. It returns a handle which we pass in to to the other chdev_ functions. luup.chdev.append() adds each child and it takes the parent device number, the handle from lu_chdev_start, the id the parent will use to identify the device (s=01, 02, etc.), and the device type. This is a UPnP device. We'll use the existing UPnP standard "Binary light" because this way every UPnP control point will treat the blinds as a light and show the user an 'on' and 'off' button. We could create our own device type for blinds which had actions "open" and "close", but then the UPnP Control Points (like the iPhone interface) would need to be updated to know how to present the user with blinds. luup.chdev.sync() is called when we're done to synchronize the child device list with Luup's database, and create/remove any new/missing devices, and restart the Luup engine if devices were added or removed. See: [[Luup_Lua_extensions]]

Before you click 'go', restart your tail in the ssh window with: ''tail -f LuaUPnP.log | grep '^5\|^01\|^03\|^09\|^11' '' because the 03 logs indicate when the Luup engine stops and restart, the 09 logs show us when devices are created/deleted, and the 11 logs show when the child device functions are calls. Now when you click 'go', you should see in the logs ''Child_Devices::AddChild'' is called 16 times, and then 16 times ''Child_Devices::ProcessChildDevice created device''. You should also see lines starting with '03' that show the Luup engine is reloading since new devices were just created. When it restarts, you'll see 16 new devices in the logs starting with 09.

Now if you click 'go' again, you'll see 16 logs for ''Child_Devices::AddChild'', but no devices will be created or removed because the 16 devices were already created, and the parent/child device lists are still in sync. We have the same 16 child devices with no new ones or removed ones.

Now if you refresh Vera's web UI, you'll see the Somfy device has '16' embedded devices, each with "on" and "Off". The 'true' at the end of the luup.chdev.append means the child devices are 'embedded'. That means when they're shown in Vera's web UI, they're all grouped together as one compound device. If you changed the 'true' to a 'false', all 16 blinds would show up as completely separate devices. This is really just a cosmetic difference. The advantage to using 'false' (non-embedded) is that the user can put each blind in a different room. In this case it's probably better to treat the devices as non-embedded, since it is likely the 16 blinds will be scattered around the house. So change the true at the end of luup.chdev.append to a false. Then click 'go'. Now, the 16 blinds are removed, and re-added as non-embedded devices. So, if you refresh Vera's web UI and go to devices, you'll 16 different blinds that you can put into different rooms, in addition to the "Somfy blind interface" device.

Next, we'll update our Lua code to only create child devices that are specified in the "ID" parameter of the "Somfy blind interface" so that if the user doesn't have 16 devices he can specify just the ones he does have. To make our coding easier, we'll document in the notes for the user that when specifying the list of blinds in the "ID" he must use 01,02, etc., rather than 1,2, etc. because by storing all child devices as 2 digits, we can do a simple search without having to actually parse the ID. In other words, if we want to know if blind #1 is active, we can safely search the ID for 01 and know that it will only match if blind #1 is active. If the user stored single digit blind numbers, like ''5,6,11'' then searching for '1' would give us a false positive and we'd need to write more Lua code to break the list apart. This also makes it easier to send the blind commands because the Somfy protocol says the blind number must be 2 digits, so we won't need to pad the ID's with 0 for the Somfy device. This is why we did the for loop with 16 text strings using string.format which would have given us normal, non-zero-padded numbers.

Put a -- in front of the luup.chdev.append in the window and click 'go' again. -- means "comments" in Lua, and lines starting with -- are ignored. Therefore, by eliminating the luup.chdev.append, now the luup.chdev.sync will remove all 16 children since none were appended. This way we can reload Vera's web UI, go to the devices page, and we won't have those 16 blinds anymore requiring us to provide a room. Click '+' next to the Somfy blind interface, click 'Advanced' and in the BlindIds enter: '02,07,13', click 'save'. Now in the 'Test Luup code' window enter:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID == nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end

local lul_prefix = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_device)
if (lul_prefix == nil) then
lul_prefix = "01"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_prefix, lul_device)
end

luup.log("Somfy ID is " .. lul_ID .. " prefix is " .. lul_prefix)
child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
if (string.find(lul_ID,s) ~= nil) then
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-upnp-org:device:BinaryLight:1", "D_BinaryLight1.xml", "", "", false)
end
end

luup.chdev.sync(lul_device, child_devices)
end

lug_startup(123)
</source>

Don't forget to change the '123' to your actual device number. Now when you click 'go' you'll see the logs indicate we only have 3 blinds with ID's 02, 07 and 13. Since this part of the code is done, you can copy/paste this from the Luup test code window into the implementation. '''IMPORTANT:''' Be sure the ''lug_startup(123)'' is NOT in your implementation file, or else your lug_startup function will be called twice at each startup: once by the Luup engine with the actual device number, and once when the startup functions are loaded into the Lua engine with your hard-coded number used for testing, which won't necessarily correspond to the real device number. We also add the variable lul_prefix because the URTS version 1 takes an ! in the front of every command, whereas with version 2 it's a 2 digit number from 01 to 16. So we'll default to 01, the default value for an URTS version 2, but we'll let the user change it. We'll store this in a global variable, lul_prefix, so it's available for use in the other functions in our plugin.

If you're editing the XML file by hand, you can save your changes and click 'go' in the Luup files upload page in your web browser to upload your changes.

Every time you re-start the Luup engine, such as clicking 'Save', you'll see in the logs this startup sequence.

==Step 5b: Polish up the startup sequence ==

The the startup sequence as it is the user will always think the Somfy module loaded fine, even when it didn't, giving the user a false sense that everything was ok even when he hadn't yet specified basic parameters.

Now, the code first checks for basic startup parameters, which are stored in UPNP variables, and sets them to a default value if they're not already specified. You should at least set them an empty string because by setting them to something then the user will see them in the web user interface and be able to easily change them, as opposed to creating them again from scratch:

<source lang="lua">
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID = nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end
</source>

Next, since this device uses an IO Port (ie a serial port, or an ethernet port, or a usb connection), we should check that the connection is specified and is active before doing the startup:

<source lang="lua">
if (luup.io.is_connected(lul_device) == false) then
luup.log('No port for Somfy', 1)
luup.task('Choose the Serial Port for the URTSI', 2, 'Somfy Blind Interface', -1)
return false
end
</source>

If there's a failure of any kind, we should call luup.task and put in some sort of description with the status code 2 (Error), and then 'return false'. This way the user sees in the web panel that the module 'Somfy Blind Interface' is in an error condition and what the problem is (he didn't choose the serial port). If we didn't do the 'return false', the user would think the Somfy module was ok since, when the startup function doesn't return false, the architecture assumes the module is running fine. If we called return false, didn't call luup.task, then the user see that the module was failing, but would have only a generic "Startup sequence failed" without knowing the explicit reason.

So now the startup sequence looks like this:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID == nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end

local lul_prefix = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_device)
if (lul_prefix == nil) then
lul_prefix = "01"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_prefix, lul_device)
end

luup.log("Somfy ID is " .. lul_ID .. " prefix is " .. lul_prefix)

if (luup.io.is_connected(lul_device) == false) then
luup.log('No port for Somfy', 1)
luup.task('Choose the Serial Port for the URTSI',2,'Somfy Blind Interface', -1)
return false
end

child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
if (string.find (lul_ID,s) ~= nil) then
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s,
"urn:schemas-micasaverde-com:device:WindowCovering:1",
"D_WindowCovering1.xml", "", "", false)
end
end

luup.chdev.sync(lul_device, child_devices)
end
</source>

==Step 6a: Implementation the actions in the web generator ==

--coming soon--

==Step 6b: Implementation the actions in the xml file ==

The reason we added the ''<handleChildren>1</handleChildren>'' tag to the Somfy blind interface's device file earlier is because we're going to put all the actions for the child devices (the blinds) within the main implementation file for the Somfy. So, whenever an action comes in for a child device (a blind), the Lua code in the parent devices implementation file will handle it. Replace the actionList tag in the implementation file with this:

<source lang="xml">
<actionList>
<action>
<serviceId>urn:upnp-org:serviceId:SwitchPower1</serviceId>
<name>SetTarget</name>
<run>
local lul_command = lul_prefix .. luup.devices[lul_device].id .. 'U\r'
local lul_reverse = luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "ReverseOnOff", lul_device)

if (lul_settings.newTargetValue == "1" or (lul_settings.newTargetValue == "0" and lul_reverse == "1")) then
lul_command = lul_prefix .. luup.devices[lul_device].id .. 'D\r'
end

if (luup.io.write(lul_command) == false) then
luup.log("cannot send: " .. tostring(lul_command),1)
luup.set_failure(true)
return false
end
</run>
</action>
</actionList>
</source>

This provides the implementation or the SetTarget UPnP action, which is what is sent when the user clicks 'on' or 'off' for a light switch, or 'open' or 'close' for blinds. We store the command to send in the variable lul_command and put the 'local' keyword in front so the variable is only available while the 'SetTarget' action is running. We also check the HADevice service's ReverseOnOff value. As a convention in Luup, we created this as a common service that all home automation devices have, and the ReverseOnOff variable, if true, means reverse the usual on/off behavior, so on is off and off is on. We did this because it's not uncommon for binary switches, particularly blinds, to be wired the wrong way, or for it to be subjective which position is on vs. off. This way the user can add this variable for his configuration if the operation is backwards from what he would expect. lu_SetCommFailure sets a "communication failure" flag for the device, which logs a critical error, and allows the user to see that the device is having problems. Whenever the Luup engine reloads, such as clicking 'save', the flag is cleared again.

Now when you click 'on' or 'off' for the blinds you'll see in the log it is sending the corresponding data to the blinds.

Luup Lua extensions

2012-03-23T14:38:33Z

Guessed: /* variable: devices */ Correct lug_devices -> luup.devices (the syntax since 2009)

In addition to the [[http://lua.org Lua]] commands described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]], you can also reference in your Lua code variables and functions from modules which the Luup engine provides as follows:

== Module: luup ==

These are general purpose functions and variables. Call them by using the luup. module, such as: 

<source lang="lua">luup.log('Now running version: ' .. luup.version)</source>

=== variable: device ===

The ID of this device instance, if it's running as part of a device

=== variable: version, version_branch, version_major, version_minor ===

''version'' contains the version of the luup engine, such as "1.0.843", as a string. The version consists of 3 numbers separated by a period: the branch, the major version, and the minor version. To make it easier to compare against a minimum acceptable version, ''version_branch, version_major and version_minor'' return each component as a number. You can put a comparison in the startup function in your Luup plugin and return false if the minimum version isn't met. The user will then see that the Luup device's startup check failed: 

<source lang="lua">if( version_branch ~= 1 or version_major ~= 0 or version_minor < 843 ) then
luup.log("I need version 1.0.843 minimum to run")
return false
end</source>

=== variable: longitude ===

Contains the longitude as a number, as found on the location tab in the setup UI.

=== variable: latitude ===

Contains the latitude as a number, as found on the location tab in the setup UI.

=== variable: timezone ===

Contains the timezone as a number of hours offset from UTC, as found on the location tab in the setup UI. It accounts for DST, so, for example, Pacific Standard time will be -8 or -9 depending on DST.

'''Note:''' Contains 0 for MiOS < 1.5.250 (Vera V2) / < 1.5.249 (Vera V3).

=== variable: city ===

Contains the city as a string, as found on the location tab in the setup UI.

=== variable: devices ===

Contains all the devices in the system as a table indexed by the device number.

The members are:
* '''room_num''': (number) This is the number of the room the device is in.
* '''device_type''': (string) This is a string representing the type of the device.
* '''category_num''': (number) This is a category for the device. See: [[Luup_Device_Categories]] for a list.
* '''device_num_parent''': (number) This is the number of the parent device. See: [[Lua Device Structure]] for details.
* '''ip''': (string) If this device is IP based, this is the IP address.
* '''mac''': (string) If this device is IP based, this is the MAC address.
* '''user''': (string) If this device is IP based and requires http authentication, this is the username
* '''pass''': (string) If this device is IP based and requires http authentication, this is the password
* '''id''': (string) If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.
* '''embedded''': (boolean) If this device is embedded, it means that it doesn't have its own room or exist as a separate device. It should be considered part of its parent. Like a 3-in-1 sensor is a device with 3 embedded child devices.
* '''hidden''': (boolean) If true the user checked the 'hidden' box and doesn't want to see the device on the dashboard.
* '''invisible''': (boolean) If true the device is 'for internal use only' and shouldn't be presented to the user.
* '''description''': (string) This is the text description for the device as supplied by the user in the web UI.
* '''udn''': (string) This is the UDN for the UPnP device.

Example to log device #5's IP addess and its internal ID:
<source lang="lua">luup.log('Device #5 ip: ' .. luup.devices[5].ip .. ' id: ' .. luup.devices[5].id)</source>

This code will log all the attributes from all the devices:
<source lang="lua">for k, v in pairs(luup.devices) do
for k2, v2 in pairs(v) do
luup.log("Device #" .. k .. ":" .. k2 .. "=" .. "v2")
end
end</source>

=== variable: rooms ===

Contains all the rooms as a table of strings indexed by the room number. Example: 

<source lang="lua">luup.log('Room #1 is called: ' .. luup.rooms[1])</source>

=== variable: scenes ===

Contains all the scenes in the system as a table indexed by the scene number. The members are: room_num (number), description(string), hidden(boolean)

=== variable: remotes ===

Contains all the remotes in the system as a table indexed by the remote id. The members are: remote_file (string), room_num (number), description(string)

=== function: log ===

parameters: what_to_log (string), log_level (optional, number)

return: nothing

Writes what_to_log to the log, /var/log/cmh/LuaUPnP.log, with the given log_level, which is 50 by default. See: [[Luup Loglevels]]

=== function: task ===

parameters: message (string), status (number), description (string), handle (number)

return: handle (number)

When the Luup engine is starting status messages are displayed for the various modules as they're initialized. Normally each device, including Luup devices, automatically log their status and the user is shown an error if the device doesn't start, such as if the 'startup' function returns an error.

If you have other startup sequences which you want the user to see to know that startup hasn't finished yet, call this function passing in a handle of -1 for the first call. The status should be: 1=Busy, 2=Error, 4=Successful. Message is the current state, such as 'downloading', and description describes the module, like 'Smartphone UI'. After the first call, store the handle and pass it on future calls to update the status rather than add a new one.

=== function: call_delay ===

parameters: function_name (string), seconds (number), data (string), thread (bool)

returns: result (number)

The function ''function_name'' (the first parameter), which must be passed as a string, will be called in ''seconds'' seconds (the second parameter), and will be passed the string ''data''. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name. function_name will only be called once and you must call call_delay again if you want it called again, or use call_timer instead.

If thread is specified and is true or 1, the call back will be made in it's own thread and can block if needed. Normally it is called by a worker thread and is expected to return immediately.

As of December 19, 2011, for all builds after 1.5.237, the 'thread' will be ignored. Each Lua state has its own worker thread now, so all calls to call_delay and call_timer will occur in a separate thread.

=== function: call_timer ===

parameters: function_name (string), type (number), time (string), days (string), data (string)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called when the timer is triggered, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name.

Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer. For an interval timer, days is not used, and Time should be a number of seconds, minutes, or hours using an optional 'h' or 'm' suffix. Example: 30=call in 30 seconds, 5m=call in 5 minutes, 2h=call in 2 hours. For a day of week timer, Days is a comma separated list with the days of the week where 1=Monday and 7=Sunday. Time is the time of day in hh:mm:ss format. Time can also include an 'r' at the end for Sunrise or a 't' for Sunset and the time is relative to sunrise/sunset. For example: Days="3,5" Time="20:30:00" means your function will be called on the next Wed or Fri at 8:30pm. Days="1,7" Time="-3:00:00r" means your function will be called on the next Monday or Sunday 3 hours before sunrise. Day of month works the same way except Days is a comma separated list of days of the month, such as "15,20,30". For an absolute timer, Days is not used, and Time should be in the format: "yyyy-mm-dd hh:mm:ss"

Data can be a string passed back to the function. The function should be declared so it takes a single argument, which is this data. 

<source lang="lua">function refreshCache(stuff)
....
end

function startup()
--
-- Setup an interval-based timer to call refreshCache after 30 minutes.
-- Note that if you want it to "recur" then you need to call this function again
-- at the end of the refreshCache() implementation.
--
luup.call_timer("refreshCache", 1, "30m", "", "SomeStuff")
end</source>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

version: UI5 and above

Checks whether a device has successfully completed it's startup sequence. If so, <tt>is_ready</tt> returns <tt>true</tt>. If your device shouldn't process incoming data until the startup sequence is finished, you may want to add a condition to the <tt><incoming> block</tt> that only processes data if <tt>is_ready(lul_device)</tt> is <tt>true</tt>.

The <tt>device</tt> parameter, if it's a string, is interpreted as a udn. If it's a number, it's interpreted as a device number.

<source lang="lua"><incoming>
if (luup.is_ready(lul_device) == false) then
return
end

doSomething(lul_device)
</incoming></source>

=== function: call_action ===

parameters: service (string), action (string), arguments (table), device (string or number)

returns: error (number), error_msg (string), job (number), arguments (table)

Invokes the UPnP service + action, passing in the arguments (table of string->string pairs) to the device, which, if it's a string, is interpreted as a udn, and if it's a number, is the device number. If the invocation could not be made, only error will be returned with a value of -1. Otherwise, all 4 values are returned. error is 0 if the UPnP device reported the action was successful. arguments is a table of string->string pairs with the return arguments from the action. If the action is handled asynchronously by a Luup job, then the job number will be returned as a positive integer.

Example to dim device #5 to 50%: 

<source lang="lua">local lul_arguments = {}
lul_arguments["newLoadlevelTarget"] = 50
lul_resultcode, lul_resultstring, lul_job, lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:Dimming1",
"SetLoadLevelTarget", lul_arguments,
5)</source>

=== function: variable_set ===

parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]

returns: nothing

The UPnP service+variable will be set to value for device, which if it's a string, is interpreted as a udn, and if it's a number, as a device id. If there are events or notifications tied to the variable they will be fired.

Optionally, you can add an argument 'startup'. If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will ''not'' be fired.

=== function: variable_get ===

parameters: service (string), variable (string), device (string or number)

returns: value (string), time (number)

If the service+variable or device does not exist, it returns nothing. Otherwise it returns the value of the UPnP service+variable and the time when the variable was last modified, as a unix time stamp (number of seconds since 1/1/1970). You can assign just the value to a variable, as follows: 

<source lang="lua">local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5)
luup.log("Dim level for device #5 is: " .. value)</source>

=== function: attr_set ===

parameters: attribute (string), value(string), device (string or number)

returns: none

Sets the top level attribute for the device to value. Examples of attributes are 'mac', 'name', 'id', etc.

=== function: register_handler ===

parameters: function_name (string), request_name (string)

returns: nothing

When a certain URL is requested from a web browser or other HTTP get, function_name will be called and whatever string it returns will be returned.

See the WAP mobile phone plugin as an example: 

<source lang="lua">luup.register_handler("lug_WapRequest","wap")

function lug_WapRequest (lul_request, lul_parameters, lul_outputformat)
local lul_html = "<head>\n" ..
"<title>Main</title>\n" ..
"</head>\n" ..
"<body>\n" ..
"Choose a room: \n"
return lul_html
end</source>

The request is made with the URL: data_request?id=lr_[the registered name] on port 49451. So: http://192.168.1.1:49451/data_request?id=lr_wap will return the web page defined in the function lug_WapRequest in the example above.

=== function: variable_watch ===

parameters: function_name (string), service (string), variable (string or nil), device (string or number)

returns: nothing

Whenever the UPnP variable is changed for the specified device, which if a string is interpreted as a UDN and if a number as a device ID, ''function_name'' will be called. See [[Luup Declarations#watch_callback]] for the values that will be passed to ''function_name''. If variable is nil, ''function_name'' will be called whenever any variable in the service is changed.

 

=== function: devices_by_service ===

parameters:

returns:

=== function: device_supports_service ===

parameters:

returns:

'''Warning:''' luup.device_supports_service doesn't work reliably: http://forum.micasaverde.com/index.php?topic=5600.0

=== function: set_failure ===

parameters: value (boolean), device (string or number)

returns:

Luup maintains a 'failure' flag for every device to indicate if it is not functioning. You can set the flag to true if the device is failing. If device is a string it is interpreted as a udn, if it's a number, as a device id.

=== function: is_night ===

parameters: none

returns: boolean

Returns true if it's past sunset and before sunrise.

 

=== function: sleep ===

parameters: number of milliseconds

returns: none

Sleeps a certain number of milliseconds

'''Warning:''' luup.sleep doesn't work reliably: http://bugs.micasaverde.com/view.php?id=1480

== Module: luup.inet ==

=== function: wget ===

parameters: URL (String), Timeout (Number), Username (String), Password (String)

returns httpStatusCode (Number), content (String)

This reads the URL and returns 2 variables: the first is a numeric error code which is 0 if successful, and the second is a string containing the contents of the page. If '''Timeout''' is specified, the function will timeout after that many seconds. The default value for '''Timeout''' is 5 seconds. If '''Username''' and '''Password''' are specified, they will be used for HTTP Basic Authentication.

 

== Module: luup.chdev ==

Contains functions for a parent to synchronize its child devices. Whenever a device has multiple end-points, the devices are represented in a parent/child fashion where the parent device is responsible for reporting what child devices it has and giving each one a unique id. For example in the sample [[Luup Somfy Walkthrough]] there is a parent device, which is the interface module that controls up to 16 blinds, and up to 16 child devices, one for each blind. As shown in that sample, the parent calls start, then enumerates each child device with append, and finally calls sync. You will need to pass the same value for device to append and sync that you passed to start.

=== function: start ===

parameters: device (string or number)

returns: ptr (binary object)

Tells Luup you will start enumerating the children of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. The return value is a binary object which you cannot do anything with in Lua, but you do pass it to the append and sync functions.

=== function: append ===

parameters: device (string or number), ptr (binary object), id (string), description (string), device_type (string), device_filename (string), implementation_filename (string), parameters (string), embedded (boolean) [, invisible (boolean)]

returns: nothing

Adds one child to <tt>device</tt>. If <tt>device</tt> is a string it is interpreted as a udn, if it's a number, as a device id.

Pass in the <tt>ptr</tt> which you received from the <tt>luup.chdev.start</tt> call. Give each child a unique id so you can keep track of which is which. You can optionally provide a <tt>description</tt> which the user sees in the user interface.

<tt>device_type</tt> is the UPnP device type, such as <tt>urn:schemas-upnp-org:device:BinaryLight:1</tt>.

If <tt>device_filename</tt> is specified, that is the name of the XML file with the UPnP device specification. The deviceType from the filename will override any <tt>device_type</tt> you set manually. If the device_file contains the implementation file for this child device you do not need to specify it in <tt>implementation_filename</tt>. Otherwise, if there is a Luup implementation for this child device and it's not being handled by the parent device, you can specify it in <tt>implementation_filename</tt>.

If <tt>embedded</tt> is true, the 'embedded' flag is set for the device which generally means that the parent and all the children will be displayed as one compound device, or group, rather than as separate devices which you can put in their own rooms.

The <tt>parameters</tt> are UPnP service,variables you want set when the device is created. You can specify multiple variables by separating them with a line feed (\n) and use a <tt>,</tt> and <tt>=</tt> to separate service, variable and value, like this: <tt>service,variable=value\nservice</tt>...

<source lang="lua">
luup.chdev.append(device, children,
string.format("Input-%d", i), string.format("Input %d", i),
"urn:schemas-micasaverde-com:device:TemperatureSensor:1", "D_TemperatureSensor1.xml",
"", "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=50", true)
</source>

=== function: sync ===

parameters: device (string or number), ptr (binary object),

returns: nothing

If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Tells the Luup engine you have finished enumerating the child devices. If the child devices have changed in any way, the new device tree will be written to the configuration file and the Luup engine is reset.

== Module: io ==

=== function: open ===

parameters: device (string or number), ip (string) port (number),

returns: nothing

If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This opens a socket on 'port' to 'ip' and stores the handle to the socket in 'device'. The opening of a socket can take time depending on the network, and a Luup function should return quickly whenever possible because each top-level device's Lua implementation runs in a single thread. So the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.

Generally you do not need to call the open function because the socket is usually started automatically when the Luup engine starts. This is because the user typically either (a) associates a device with the destination io device, such as selecting an RS232 port for an alarm panel, where the RS232 is proxied by a socket, or (b) because the configuration settings for the device already include an IP address and port.

=== function: write ===

parameters: data (string), device (string or number)

returns: result (boolean)

In Lua a string can contain binary data, so data may be a binary block. If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This sends data on the socket that was opened automatically or with the open function above, and associated to 'device'. If the socket is not already open, write will wait up to 5 seconds for the socket before it returns an error. Result is 'true' if the data was sent successfully, and is 'false' or nill if an error occurred.

=== function: intercept ===

parameters: device (string or number)

returns: nothing

Normally when data comes in on a socket (I/O Port), the block of data is first passed to any pending jobs that are running for the device and are marked as 'waiting for data'. If there are none, or if none of the jobs' incoming data handlers report that they consumed (i.e. processed) the data, then the block of data is passed to the general 'incoming' function handler for the device. If you want to bypass this normal mechanism and read data directly from the socket, call intercept first to tell Luup you want to read incoming data with the read function. This is generally used during the initialization or startup sequences for devices. For example, you may need to send some data (a), receive some response (b), send some more data (c), receive another response (d), etc. In this case you would call 'intercept' first, then send a, then call read and confirm you got b, then call intercept again, then send c, then read d, and so on.

You can call the read function without calling intercept and any incoming data will be returned by that function after it's called. The reason why you generally must call intercept is because normally you want to send some data and get a response. If you write the code like this ''send(data) data=read()'' then it's possible the response will arrive in the brief moment between the execution of send() and read(), and therefore get sent to the incoming data handler for the device. Intercept tells Luup to buffer any incoming data until the next read, bypassing the normal incoming data handler. So ''intercept() send(data) data=read()'' ensures that read will always get the response. If the device you're communicating with sends unsolicited data then there's the risk that the data you read is not the response you're looking for. If so, you can manually pass the response packet to the incoming data handler.

**TBD: Add a function to do this**

=== function: read ===

parameters: timeout (number), device (string or number)

returns: data (string)

This reads a block of data from the socket. You must have called ''intercept'' previously so the data is passed. The time unit for ''timeout'' is seconds. 

=== function: is_connected ===

parameters: device (string or number)

returns: connected (boolean)

This function returns true if there is a valid IO port connected, otherwise returns false

== Module: luup.job ==

=== function: status ===

parameters: job_number (number), device (string or number)

returns: job_status (number), notes (string)

If '''job_number''' is invalid the function returns ''-1''. If '''device''' is a string it is interpreted as an UDN, if it's a number, as a device ID.

This is the list with all job statuses and their meaning:
* '''-1''': No job, i.e. job doesn't exist.
* '''0''': Job waiting to start.
* '''1''': Job in progress.
* '''2''': Job error.
* '''3''': Job aborted.
* '''4''': Job done.
* '''5''': Job waiting for callback. Used in special cases.
* '''6''': Job requeue. If the job was aborted and needs to be started, use this special value.
* '''7''': Job in progress with pending data. This means the job is waiting for data, but can't take it now.

=== function: set ===

parameters: job (userdata), setting (string), value (string)

returns: nothing

This stores a setting for a job.

<source lang="lua"><job>
luup.job.set(lul_job, "comments", "In progress...")
local comments = luup.job.setting(lul_job, "comments")
luup.log("job comments = " .. comments)
</job></source>

=== function: setting ===

parameters: job (userdata), setting (string)

returns: value (string)

This returns a setting for a job.

[[Category:Development]]

ZWave Debugging

2012-03-15T04:19:34Z

Guessed: /* Advanced debugging for developers */ Add a link for Log levels page, since this [legacy] page comes up frequently in searches

[[Category:Development]]

== Custom device types or names based on Z-Wave ID's ==

In the configuration directory (normally /etc/cmh) is a file called zwave_products_sys.xml. This contains a list of hardcoded settings for various ZWave devices. The file is a series of values separated by tabs, with one entry on each line. The format is:

Manufacturer, Basic, Generic, Specific, ChildNumber, ProductType, ProductID, Devicefilename, ZWaveClass, Default name, Custom variables

When a Z-Wave device is added it is compared against this file. If the device's manufacturer ID, Basic ZWave device class, Generic device class, Specific device class, Product Type and Product ID match what's in the file, then rather than using the default device information, the device will use the UPnP XML device file in Devicefilename, and the ZWave class ZWaveClass, and will have the Default name, and the UPnP variables in "Custom variables". If any of Manufacturer, Basic, Generic, Specific, ChildNumber, ProductType, ProductID are not specified, it's considered a match. If any of Devicefilename, ZWaveClass, Default name, Custom variables are not specified, the default values are used. ChildNumber is when there's a multi-channel or multi-instance, this is what the child device will use.

For example, for the Express controls 3-in-1 sensor which has manufacturer 001E and Product Type/ID are 2 and 1, the 3 embedded children are forced to be a motion sensor, light sensor, temperature sensor.

001E 1 2 1 D_MotionSensor1.xml
001E 2 2 1 D_LightSensor1.xml
001E 3 2 1 D_TemperatureSensor1.xml

zwave_products_sys.xml is distributed with each MIOS release, so any changes you make to it are lost on upgrade. However, you can add your own rows in the file: zwave_products_user.conf (or zwave_products_user.xml?) in the same folder with the same format. Those will be saved when you upgrade.

To get the source values (manufacturer id, product type, etc.) grep for UpdateNode in LuaUPnP.log.

== Easy Z-Wave Debugging ==

== Z-Wave specifics ==

Vera maps the command class BASIC to COMMAND_CLASS_SENSOR_BINARY, and responds to BASIC_GET or SENSOR_BINARY_GET with a _REPORT that has a value of 1 if Vera is running (ie it's always 1).

== Advanced debugging for developers ==

Here are some hints for debugging Z-Wave protocol issues. You can access Vera by telnet, or if you already set a password, by ssh.

First, be sure you check the box "verbose logs" under 'Advanced', 'Logging', or, from a console run /usr/bin/VerboseLogging.sh enable.

The logs are in the directory /var/log/cmh. The first 2 digits are the 'log level'. The file: DCERouter.log contains the logging information from the core message router. The file: x-ZWave.log (where x is usually 9) contains all the logs from the Z-Wave module.

Log levels for data sent to the Z-Wave dongle: 01 = critical errors 02 = warnings 04 = jobs 05 = warnings 06 = variables (which indicates state changes) 07 = events 08 = commands 10 = status messages 41 = data sent to the Z-Wave dongle 42 = data received from the Z-Wave dongle 50 = luup log
 

For commands run in a scene, the logs won't be getting data from the user, but from a scene, so to see this requests, you should grep for RunScene .

For a complete list of the log levels, see the [[Luup_Loglevels|Luup Log Levels]] page.

 

So, if you want to watch the router's logs and see what commands are being sent to the various devices, do this:

'''cd /var/log/cmh tail -f DCERouter.log | grep '^08''''

Now from Vera's dashboard, send commands to the devices and you'll see them in the log. The | grep '^08' means to filter only lines that start with 08, meaning log level 08 ("Commands"). tail -f means "follow the log". To stop the tail and get back to the console, if you used ssh to login, you just press Ctrl+C. Unfortunately, often times telnet doesn't forward Ctrl+C, so, when using telnet you need to press Ctrl+Z and then type this to kill the tail command: killall tail; fg

To watch the traffic on the Z-Wave serial bus, type:

'''cd /var/log/cmh tail -f 9-ZWave.log | grep '^41\|^42''''

which means show log level 41 or 42. Normally Vera is polling all the nodes every few seconds, so the logs fill up quickly with Z-Wave traffic from the polling. If you want to turn off automatic polling temporarily for this session so the logs aren't cluttered with polling traffic, type:

'''/usr/bin/MessageSend localhost 0 9 1 966 5 0''' (assuming the Z-Wave device is #9, as default, add 225 1 to make the change permanent)

To force a poll of device 13, type: '''/usr/bin/MessageSend localhost 0 9 1 966 2 13 5 UPDATE'''

Next you can send "COMMAND: #191 - Send Code" to either a Z-Wave Node and the parameter 9 (Text) is a command, or send it to the Z-Wave device and it is a frame. The contents of text are a string of hex or decimal numbers separated with spaces, dashes or underscores, and hex values are preceded with 0x or x. So assuming a dimmable light is device 20 in node 15, either command below will dim it to 50%:

'''/usr/bin/MessageSend localhost 0 9 1 191 9 "0 x13 15 0x3 0x26 0x1 50 4 1"''' #send data (func id x13) to node 15 command class 0x26 command 0x1 (set multi level) to 10% (size=3) with transmit options=4 and funcid=1

'''/usr/bin/MessageSend localhost 0 20 1 191 9 "x26 x1 50"''' #send the message directly to device 20 (the node, not 9 the Z-Wave dongle), so the node id and 'send data' frame are assumed

--Luup update: wget "http://127.0.0.1:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Node=7&Data=x26-x1-20" node 7 to 20%

--Luup update: wget "http://127.0.0.1:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Data=0-x13-7-0x3-0x26-0x1-50-4-1" node 7 to 20%

'''/usr/bin/MessageSend localhost 0 14 1 191 9 "x85 2 1"''' #Tell device 14 to report its association group 1

Ask node 4 (a thermostat) to report its temperature: "0 0x13 0x4 0x2 0x40 0x2 5 1"

You can also put an R in front of the binary data, and include the full frame, and it simulates a received frame on the serial api, rather than sending a frame. So to simulate receiving a FUNC_ID_ZW_APPLICATION_UPDATE from node 1 run: '''/usr/bin/MessageSend localhost 0 9 1 191 9 "R0x1 0x9 0x0 0x49 0x84 0x1 0x3 0x2 0x2 0x1 0x38"''' or an encrypted message from node 29 with FUNC_ID_APPLICATION_COMMAND_HANDLER, COMMAND_CLASS_SECURITY: '''"R0x01 0x1C 0x00 0x04 0x00 29 0x16 0x98 0x81 0xEC 0xE1 0x10 0x56 0xFC 0x13 0xDF 0x04 0x45 0x60 0x24 0xA8 0x43 0x89 0xE8 0x22 0x36 0x15 0xA9 0xB1 0x1C"'''

--Luup update: wget "http://127.0.0.1:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Data=R0x1-0x16-0x0-0x4-0x0-0x4-0x10-0x8f-0x1-0x4-0x3-0x80-0x3-0x64-0x2-0x46-0x4-0x2-0x46-0x7-0x2-0x84-0x7-0x15"

Note that the logs will rotate regularly, meaning the DCERouter.log is archived as DCERouter.log.1.gz, and the old DCERouter.log.1.gz becomes DCERouter.log.2.gz. This is handled by the root cron process that runs /usr/bin/Rotate_Logs.sh.

Every time you do something with Vera this results in a "job". So let's assume you want to see what Vera is doing to configure a device. Type 'date' to see the date/time. Click the 'configure right now' button for the device. Type ''grep AddJob 9-ZWave.log'' to see all the log entries with 'AddJob' in them. Each one is given a number, and an abbreviated description. Say the first job after the 'date' is ''10 01/26/09 16:35:51.640 JobHandler::AddJob job#6 :conf_jh#9 (0x00DD7390) P:40 S:0 <00DD7390> conf_jh#9 type ZWJob_ConfigureNode first 0'' This means it's job#6, the name 'conf_jh#9' means it's a configure job from the main job handler for node #9. You may see lots of other jobs right after #6 to do things like set the Version/Manufacturer, set Associations, etc., because the main configure job (#6) may spawn many other jobs. To see all the log entries for job #6, type ''grep "job#6" 9-ZWave.log''. Pay attention to the lines with m_eJobStatus which indicate the status, such as ''m_eJobStatus Job completed ok''. Let's say you want to see what data is being sent/received as part of job#6, you could do this: ''grep 'job#6\|^41\|^42\|^01\|^05' 9-ZWave.log'' so you see all log entries for job #6, all incoming/outgoing data, plus critical errors (1) and warnings (5). Look for the line 'ready to run' in the logs, which will indicate where job #6 is starting. The logs are color coded, and the less that comes with busybox in Vera doesn't support the -R parameter to view the logs in color, which is much easier to read. So, you can set a root password if you haven't already (type ''passwd''), and then use scp to copy the log files from Vera to another Linux/Mac/Windows with cygwin pc, and then run: ''grep 'job#6\|^41\|^42\|^01\|^05' 9-ZWave.log | less -R'' to see just the filtered portion of the logs in color.

 You can also use MessageSend to send Vera's normal DCE commands directly to devices. The ID's are the same as LinuxMCE. You can also '''tail -f DCERouter.log | grep '^08''''

From the console, if you want to see if a device is configured, enable verbose logging: '''/usr/bin/VerboseLogging.sh enable''', restart the Z-Wave device: '''/usr/bin/MessageSend localhost 0 9 7 1''' then wait for it to finish checking all the devices and '''grep UpdateNode 9-ZWave.log'''. You'll see: '''ZWaveJobHandler::UpdateNodes node 13 PK_DeviceTemplate 37 type ZWaveNonDimmableLight PK_Device 19 cap 0xc9 sec 0xc res 0x0 bas 0x4 gen 0x10 spe 0x3 config 1 LS (on/off)-45W-IPCAM classes 25,27,2b,2c,72,73,77,82,85,86,91,ef,''' config 1 means the device is configured. To reconfigure a device from the command line, send it command 776. For this device it would be: '''/usr/bin/MessageSend localhost 0 19 1 776'''.

Reset the Z-Wave network: '''/usr/bin/MessageSend localhost 0 9 1 776 51 SIS'''

Do a 'soft reset' that doesn't lose any devices, but resets the dongle: '''/usr/bin/MessageSend localhost 0 9 1 776 51 SOFT'''

== Z-Wave Log Messages ==

=== Z-Wave LastNote ===

* '''Status="Aborted" LastNote="Timed out waiting for the node to reply"'''
* '''Status="Aborted" LastNote="Node is not configured"'''
* '''Status="Aborted" LastNote="Unable to get any information on node"'''
* '''Status="Aborted" LastNote="Transmit failed with code: 1"''': ''Code 1'' means that Vera received no acknowledge from the device. This can happen either because the node is out of range, there are interferences or because of routing issues.

== Remote Upgrade with preserve settings ==

curl -k -s -S --fail --retry 3 -o /tmp/firmware.img http://download.controlmyhouse.net/betafirmware/ftp/wl500gP-1.0.543.trx

/usr/bin/cmh-upgrade.sh

== Z-Wave routing matrix ==

See http://forum.micasaverde.com/index.php?topic=2099.msg8292#msg8292 and http://forum.micasaverde.com/index.php?topic=5130.0.

== Z-Wave stress test ==

Start a stress test of the Z-Wave network with this command. Stop by doing a /usr/bin/Reload.sh

wget "http://127.0.0.1:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Stress=X"

where X is:

#define STRESS_TEST_CONSTANT 1 // Constant BASIC_SET's
#define STRESS_TEST_NEIGHBOR_UPDATE 2 // Constant Neighbor updates
#define STRESS_TEST_WATCHDOG 3 // Constant Watchdog checks -- bugs in the Z-Wave serial API cause this to crash
#define STRESS_TEST_SOFT_RESET 4 // Constant soft resets

== Dead battery operated devices ==

Vera does not flag malfunctioning battery operated devices on the GUI.

Use the following code to log all malfunctioning battery operated devices to a file:

http://forum.micasaverde.com/index.php?topic=5100.msg28346#msg28346

Use the following code to get email notifications about malfunctioning battery operated devices:

http://forum.micasaverde.com/index.php?topic=5130.0

== Demo Mode ==

Normally the state of a device changes after the Z-Wave command completes. If, for demos, you want to be able to show the state change immediately, whether or not the job actually succeeds, open this URL:

http://__ip_of_vera__:3480/data_request?id=lu_variableset&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:HaDevice1&Variable=SetState&Value=1

It takes effect on the next reload.

== Not getting status changes with door locks, or door locks out of sync ==

This is a commonly reported problem. To debug this:

(1) Turn on verbose logging: click Advanced from the tool box, logs tab.

(2) Temporarily turn off polling so the logs don't have a bunch of background traffic: uncheck the poll nodes from the Z-Wave/options tab and click save. You can turn polling back on when you're done

(3) Wait a couple minutes after saving for Vera to settle down so the logs aren't going like crazy.

(4) Get Putty, a free Windows ssh client. Just google for putty download. You don't need to install it, just save it to your desktop. Run it, put Vera's IP in the host name, leave SSH checked and click Open. The user name is '''root''' and the password is on the bottom of Vera; it's the same as the wifi password or house id.

(5) Once you're logged in, type this command:

tail -f /var/log/cmh/LuaUPnP.log | grep '^4\|^01\|HandlePoll\|^06'

(6) You'll be following (tailing) Vera's logs. grep is a filter to limit what you see to lines that start with 4 (which are the raw Z-Wave traffic--41 is traffic sent to Vera's Z-Wave chip, 42 is from the Z-Wave chip), lines that start with 01 are critical errors, lines that start with 06 are state changes, like lock/unlock, and lines containing the word HandlePoll indicate how Vera is handling any incoming data. See [[Luup_Loglevels]] If your tail command terminates, it means the logs rotated. Hit the up arrow to bring the command up again, and enter to restart it.

(7) Confirm that it's working by turning on and off a light from Vera's dashboard. You should see some ZWave traffic (41 and 42 lines), and a status change (06 lines) for Target and Status.

(8) Now have someone go next to the lock. Before they do anything hit enter a few times to add some blank space so you can clearly see if there's new log activity. If there's no log activity at all, not even 41 and 42 lines, that means there's no Z-Wave traffic. So the lock is not sending Vera any messages. If you see traffic, you should also see a status change (06 line) to indicate the door is now locked or unlocked. If you don't, copy what you see in putty by just highlighting it with the mouse. Putty automatically copies anything you copy into the clipboard. Paste it into an email you send to support.

== Manual routing ==

If you are using Z-Wave 3.20, you can go to the advanced settings for a device, add a variable with the service id: urn:micasaverde-com:serviceId:ZWaveDevice1 and the variable name: ManualRoute and the value is a dot separated list of Z-Wave node ID's, just like the AutoRoute variable. The Auto route variable may be something like this: "2-20x,7-59x,2.7-78". This means there are 3 routes found. #1 uses node 2 as an intermediary, and it has a 'score' of 20. The score is a measure of latency and accuracy, the lower number is better. The 'x' that follows means the last attempt to use it failed, so it won't be used anymore. The next route uses node #7, it scored worse, and also failed. The 3rd route uses node 2 & 7. It had the worst score (78), but it's currently working (no x).

== Very large Z-Wave networks ==

As part of the Heal/Repair process, each Z-Wave node is asked to discover all its neighbors. This is a standard Z-Wave function and is built into the Z-Wave module and is performed the same way on all Z-Wave controllers. The problem is that the amount of time it takes the Z-Wave network to perform this function grows exponentially based on the number of Z-Wave nodes. So in a really large Z-Wave network, with say 150 nodes, it can take more than 10 minutes per node to do the discovery, which means the heal process can take days. And during the Z-Wave node discovery the entire Z-Wave network is unavailable. We have a built-in watchdog, though, so that after 10 minutes it aborts the neighbor node discovery. Therefore, for large networks, the heal process may not complete at all and Z-Wave's built-in routing may never work. There is a solution which is to use MIOS routing instead. To do this, you need to build a network with the newer Z-Wave standard, 3.20. Go into Setup, Z-Wave Settings, Options. If the Version is not already 3.20, then check the option: Use Z-Wave version 3.20 instead of 2.78, then click save, then wait 5 minutes for it to re-flash the built-in Z-Wave chip, then go back into Setup, Z-Wave Settings, Advanced, and choose Reset Z-Wave network. After a minute, confirm the version is 3.20. Now check the option under Options "Use MiOS routing instead of Z-Wave (requires 4.5)", and uncheck "Limit neighbors to Z-Wave discovery (requries MiOS routing)". Then click Save. Pair your Z-Wave devices as normal. When you are all finished, do a repair network by choosing Z-Wave Settings, Repair, and click 'Go'. The Repair may take longer, however once it completes, you should be able to get a larger Z-Wave network to operate than you otherwise would.

== Association ==

Z-Wave associations for a device are stored in the UPNP Variable service: urn:micasaverde-com:serviceId:ZWaveDevice1 variable: AssociationSet. You can view this by clicking the settings for a device, going to the advanced tab, and finding the AssociationSet variable. The associations are ; delimited, with the first digit being the group number followed by a comma separated list of nodes to be associated with that group. Note these are Z-Wave node ID's, not device ID's (ie the 'altid' in the UI). For multi-channel there is a . following the node id with the endpoint id. Example: 1,3.4,7;2,5.1,8 meaning group #1, node #3 endpoint #4, node #7 is non-multi-channel, group #2 is associated with node #5 endpoint #1, and with node #8.

== Node version ==

The version info variable contains the version data reported by the node, like this: 3,2,78,3,62 Which is the library type, the zwave version & sub version, and the manufacturer version and sub version. So this node is running Z-Wave 2.78, manufacturer version 3.62.

Luup Variables

2012-02-11T05:19:03Z

Guessed: padding between some of the Devices to aid readability.

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

=On/Off Switch=

==Device category==
Device Category 3,
UPnP device id: ''urn:schemas-upnp-org:device:BinaryLight:1''

==Variables==
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left" width="30%"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:SwitchPower1''||''Status''||If the device is on, the value is ''1'', otherwise it's ''0''.
|}

==Examples==
* Getting whether the Switch/Light is on or off
<source lang="lua">
local switchOnOff = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 37)
if (switchOnOff == "1") then
-- Switch is on
...
end if
</source>

* Request that the Switch be turned on. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 37)
</source>

=Dimmable Light=

==Device category==
Device category 2,
UPnP device id: ''urn:schemas-upnp-org:device:DimmableLight:1''

==Variables==
Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, ''LoadLevelStatus'' indicates the dim level.

{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left" width="30%"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:Dimming1''||''LoadLevelStatus''||If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from ''0-100'' indicating a percentage of brightness.
|}

==Examples==
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

=Thermostat=

==Device category==
Device category 5,
UPnP device id: ''urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1''

==Variables==
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left" width="30%"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:HVAC_UserOperatingMode1''||''ModeStatus''||This indicates the current operating mode and will be one of the following basic values:
* ''Off''
* ''HeatOn''
* ''CoolOn''
* ''AutoChangeOver''

In addition to the basic modes, some thermostats may also support the following modes:
* ''InDeadBand''
* ''AuxHeatOn''
* ''EconomyHeatOn''
* ''EmergencyHeatOn''
* ''AuxCoolOn''
* ''EconomyCoolOn''
* ''BuildingProtection''
* ''EnergySavingsHeating''
* ''EnergySavingsCooling''
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat''||''CurrentSetpoint''||This indicates the current heat set point.
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool''||''CurrentSetpoint''||This indicatea the current cool set point.
|-
|''urn:upnp-org:serviceId:TemperatureSensor1''||''CurrentTemperature''||This indicates the current ambient temperature.
|}

==Examples==
* Getting the current temperature
<source lang="lua">
local outsideTemp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 5)
</source>

=Other Devices or Services=
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=Weather Plugin=

For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene: <source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37'' Line 2 compares the returned variable to ''Showers'' If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level) Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene every xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Variables

2012-02-11T05:12:24Z

Guessed: /* Dimmable Light */ Table-ize the display of variables

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

===Device category===
Device Category 3,
UPnP device id: ''urn:schemas-upnp-org:device:BinaryLight:1''

===Variables===
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:SwitchPower1''||''Status''||If the device is on, the value is ''1'', otherwise it's ''0''.
|}

===Examples===
* Getting whether the Switch/Light is on or off
<source lang="lua">
local switchOnOff = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 37)
if (switchOnOff == "1") then
-- Switch is on
...
end if
</source>

* Request that the Switch be turned on. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 37)
</source>

==Dimmable Light==

===Device category===
Device category 2,
UPnP device id: ''urn:schemas-upnp-org:device:DimmableLight:1''

===Variables===
Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, ''LoadLevelStatus'' indicates the dim level.

{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:Dimming1''||''LoadLevelStatus''||If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from ''0-100'' indicating a percentage of brightness.
|}

===Examples===
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

==Thermostat==

===Device category===
Device category 5,
UPnP device id: ''urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1''

===Variables===
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:HVAC_UserOperatingMode1''||''ModeStatus''||This indicates the current operating mode and will be one of the following basic values:
* ''Off''
* ''HeatOn''
* ''CoolOn''
* ''AutoChangeOver''

In addition to the basic modes, some thermostats may also support the following modes:
* ''InDeadBand''
* ''AuxHeatOn''
* ''EconomyHeatOn''
* ''EmergencyHeatOn''
* ''AuxCoolOn''
* ''EconomyCoolOn''
* ''BuildingProtection''
* ''EnergySavingsHeating''
* ''EnergySavingsCooling''
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat''||''CurrentSetpoint''||This indicates the current heat set point.
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool''||''CurrentSetpoint''||This indicatea the current cool set point.
|-
|''urn:upnp-org:serviceId:TemperatureSensor1''||''CurrentTemperature''||This indicates the current ambient temperature.
|}

===Examples===
* Getting the current temperature
<source lang="lua">
local outsideTemp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 5)
</source>

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===

For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene: <source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37'' Line 2 compares the returned variable to ''Showers'' If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level) Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene every xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Variables

2012-02-11T04:59:08Z

Guessed: /* On/Off Switch */ Table-ize the variable listings so it's easier to see.

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

===Device category===
Device Category 3,
UPnP device id: ''urn:schemas-upnp-org:device:BinaryLight:1''

===Variables===
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:SwitchPower1''||''Status''||If the device is on, the value is ''1'', otherwise it's ''0''.
|}

===Examples===
* Getting whether the Switch/Light is on or off
<source lang="lua">
local switchOnOff = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 37)
if (switchOnOff == "1") then
-- Switch is on
...
end if
</source>

* Request that the Switch be turned on. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 37)
</source>

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

===Examples===
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

==Thermostat==

===Device category===
Device category 5,
UPnP device id: ''urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1''

===Variables===
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:HVAC_UserOperatingMode1''||''ModeStatus''||This indicates the current operating mode and will be one of the following basic values:
* ''Off''
* ''HeatOn''
* ''CoolOn''
* ''AutoChangeOver''

In addition to the basic modes, some thermostats may also support the following modes:
* ''InDeadBand''
* ''AuxHeatOn''
* ''EconomyHeatOn''
* ''EmergencyHeatOn''
* ''AuxCoolOn''
* ''EconomyCoolOn''
* ''BuildingProtection''
* ''EnergySavingsHeating''
* ''EnergySavingsCooling''
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat''||''CurrentSetpoint''||This indicates the current heat set point.
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool''||''CurrentSetpoint''||This indicatea the current cool set point.
|-
|''urn:upnp-org:serviceId:TemperatureSensor1''||''CurrentTemperature''||This indicates the current ambient temperature.
|}

===Examples===
* Getting the current temperature
<source lang="lua">
local outsideTemp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 5)
</source>

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===

For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene: <source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37'' Line 2 compares the returned variable to ''Showers'' If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level) Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene every xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Variables

2012-02-11T04:54:53Z

Guessed: /* Thermostat */ Add an example section, table-ize the variables to make it clearer to users.

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

Device category: 3, UPnP device id: urn:schemas-upnp-org:device:BinaryLight:1

Variables:

Service: ''urn:upnp-org:serviceId:SwitchPower1'' Variable name: ''Status''

If the device is on, the value is 1, otherwise it's 0.

===Examples===
* Getting whether the Switch/Light is on or off
<source lang="lua">
local switchOnOff = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 37)
if (switchOnOff == "1") then
-- Switch is on
...
end if
</source>

* Request that the Switch be turned on. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 37)
</source>

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

===Examples===
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

==Thermostat==

===Device category===
Device category 5,
UPnP device id: ''urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1''

===Variables===
{| width="85%" cellpadding="10%" cellspacing="0" border="1"
|+
! align="left"|Service!! align="left"|Variable!! align="left"|Description
|-
|''urn:upnp-org:serviceId:HVAC_UserOperatingMode1''||''ModeStatus''||This indicates the current operating mode and will be one of the following basic values:
* ''Off''
* ''HeatOn''
* ''CoolOn''
* ''AutoChangeOver''

In addition to the basic modes, some thermostats may also support the following modes:
* ''InDeadBand''
* ''AuxHeatOn''
* ''EconomyHeatOn''
* ''EmergencyHeatOn''
* ''AuxCoolOn''
* ''EconomyCoolOn''
* ''BuildingProtection''
* ''EnergySavingsHeating''
* ''EnergySavingsCooling''
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat''||''CurrentSetpoint''||This indicates the current heat set point.
|-
|''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool''||''CurrentSetpoint''||This indicatea the current cool set point.
|-
|''urn:upnp-org:serviceId:TemperatureSensor1''||''CurrentTemperature''||This indicates the current ambient temperature.
|}

===Examples===
* Getting the current temperature
<source lang="lua">
local outsideTemp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 5)
</source>

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===

For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene: <source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37'' Line 2 compares the returned variable to ''Showers'' If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level) Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene every xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Variables

2012-02-11T04:13:47Z

Guessed: /* On/Off Switch */ Add examples for SwitchPower1

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

Device category: 3, UPnP device id: urn:schemas-upnp-org:device:BinaryLight:1

Variables:

Service: ''urn:upnp-org:serviceId:SwitchPower1'' Variable name: ''Status''

If the device is on, the value is 1, otherwise it's 0.

===Examples===
* Getting whether the Switch/Light is on or off
<source lang="lua">
local switchOnOff = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 37)
if (switchOnOff == "1") then
-- Switch is on
...
end if
</source>

* Request that the Switch be turned on. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 37)
</source>

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

===Examples===
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

==Thermostat==

Device category: 5, UPnP device id: urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1

Variables:

Service: ''urn:upnp-org:serviceId:HVAC_UserOperatingMode1'' Variable name: ''ModeStatus''

This indicates the current operating mode and will be one of the following basic values: Off, HeatOn, CoolOn, AutoChangeOver. In addition to the basic modes, some thermostats may also support the following modes: InDeadBand, AuxHeatOn, EconomyHeatOn, EmergencyHeatOn, AuxCoolOn, EconomyCoolOn, BuildingProtection, EnergySavingsHeating, EnergySavingsCooling

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat'' Variable name: ''CurrentSetpoint''

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool'' Variable name: ''CurrentSetpoint''

These indicate the current heat/cool set points.

Service: ''urn:upnp-org:serviceId:TemperatureSensor1'' Variable name: ''CurrentTemperature''

This indicates the current ambient temperature.

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===

For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene: <source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37'' Line 2 compares the returned variable to ''Showers'' If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level) Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene every xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Variables

2012-02-11T04:06:10Z

Guessed: /* Dimmable Light */ Add examples for dealing with the DimmableLight:1

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

Device category: 3, UPnP device id: urn:schemas-upnp-org:device:BinaryLight:1

Variables:

Service: ''urn:upnp-org:serviceId:SwitchPower1'' Variable name: ''Status''

If the device is on, the value is 1, otherwise it's 0.

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

===Examples===
* Getting the current light/load level
<source lang="lua">
local lightLevel = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", 37)
</source>

* Request that the Dimmer be set to 50% light/load level. This will, eventually, set the variable after the device has responded to the request
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
</source>

==Thermostat==

Device category: 5, UPnP device id: urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1

Variables:

Service: ''urn:upnp-org:serviceId:HVAC_UserOperatingMode1'' Variable name: ''ModeStatus''

This indicates the current operating mode and will be one of the following basic values: Off, HeatOn, CoolOn, AutoChangeOver. In addition to the basic modes, some thermostats may also support the following modes: InDeadBand, AuxHeatOn, EconomyHeatOn, EmergencyHeatOn, AuxCoolOn, EconomyCoolOn, BuildingProtection, EnergySavingsHeating, EnergySavingsCooling

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat'' Variable name: ''CurrentSetpoint''

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool'' Variable name: ''CurrentSetpoint''

These indicate the current heat/cool set points.

Service: ''urn:upnp-org:serviceId:TemperatureSensor1'' Variable name: ''CurrentTemperature''

This indicates the current ambient temperature.

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===

For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene: <source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37'' Line 2 compares the returned variable to ''Showers'' If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level) Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene every xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Apps.mios Developer's Guide

2012-01-07T21:49:42Z

Guessed: Add the standard Development category to the page, so it's a little easier to find.

'''apps.mios.com''' is the new MiOS plugins marketplace for plugins compatible with UI5. It allows developers to easily create and publish their plugins.

== Documentation ==

=== Plugin Info ===

==== Plugin Information ====

*Description: The description that will appear next to the title in the Marketplace.
*Instructions URL: URL to the documentation page of this plugin, which should contain instructions for plugin configuration and usage notes.
*Visibility: For plugins intended to be made available to the public, the visibility should be ''public''.
*License: [http://en.wikipedia.org/wiki/Gpl GPL3], [http://en.wikipedia.org/wiki/BSD_licenses BSD], [http://en.wikipedia.org/wiki/Proprietary_software proprietary]

==== UPnP Data ====

This is the necessary information for creating the plugin device.  If your plugin will have more than one device file, MiOS will use the information here to create the main plugin device.  For the ''Elk Alarm Panel Plugin'' the main device is the panel device.

[[Image:UPnP Data.png]]

=== UPnP ===

==== Plugin Devices ====

*The first three fields are the ones from UPnP Data.  This is the necessary information for creating the plugin device.  If your plugin will have more than one device file, MiOS will use the information here to create the main plugin device.  For the ''Elk Alarm Panel Plugin'' the main device is the panel device.
*Invisible: An invisible device is ''for internal use only'' and won't be presented to the user. An example for this is the ''Insteon Network'' device.

 

=== Plugin Files ===

Here you can add, remove, edit, upload and download the files used by the plugin.  This is an interface for the SVN repository where the files are stored.  To revert the files to a previous version, open the log and select which version to revert to.

'''IMPORTANT :''' When you add .lua files to the plugin, add them as '''Miscellaneous files'''.  Do not add them as Lua files because if you do, LuaUPnP will load them into their lua state and run them as stand alone files in addition to merging them into the implementation.

[[Image:Apps mios plugin files.png]]

Pressing the Edit button will open the editor. For the device, service and implementation files there are wizards available for editing the files.

=== Versions ===

==== Releases ====

This is the list with all the released or pending for approval plugin versions.

==== Add Release ====

*Platform: The target platform for the plugin. While most plugins will very likely target all the platforms, some plugins need separate versions for different platforms.
*Compatible firmware: Some plugins require features present only in newer firmwares versions to run. Others did things that were later incorporated in MiOS, so are now obsolete. These versions must be specified here.
*Dev, Alpha, Beta, RC: these are some of the software development phases. Only RC (Release Candidate) versions can be submitted for approval.

After the version has been added to the Releases list, RC versions can be submitted for approval. Someone from Mi Casa Verde will have a look at the plugin and check for malicious code, and test it a little to make sure that it doesn't affect the stability or proper functioning of MiOS. If everything is OK, the plugin will be approved and it will become available to install for the targeted public (selected in the ''Visibility'' drop-down).

==== Versions ====

Versions are snapshots of the plugin, i.e. how the plugin looked at a particular SVN revision. It's recommended to create a version for every milestone or development phase reached, so that you can go back to it if something went wrong in the subsequent revisions.

==== Publish ====

Here you can publish the plugin in its current state and assign it a version. The comments will be added after the version so that you can create versions like ''1.4 Holiday Edition''. If a file contains sensitive data (e.g. a PIN code) it is recommended to encrypt it.

== Steps for releasing a plugin ==

#After you created the plugin and uploaded the files open the '''Versions''' page.
#On the bottom of the page enter the ''Major'' version number, the ''Minor'' version number and optionally a version ''comment'', then click '''Publish'''. The published version will appear in the ''Versions'' box.
#In the '''Add Release''' box select the published version from the ''RC'' drop-down list and optionally select a ''Platform'' and enter a ''Compatible firmware''. Click '''Add Release'''. The release will appear in the ''Releases'' box.
#In the '''Releases''' box click on '''Request approval'''.
#Someone from Mi Casa Verde will check the plugin for malicious code or poorly written code that will affect the MiOS stability, and if everything is OK it will be approved.

[[Category:Plugins]]
[[Category:Development]]

Luup Scenes Events

2011-10-08T15:25:01Z

Guessed: /* Misc actions */ Refactor sub-sections, add Thermostat UserOperatingMode1 example per forum

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if (tonumber(lul_temp) < 26.6) then
return false
end
</source>

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if ((tonumber(lul_temp) < 26.6
and tonumber(lul_temp) > 25)
or tonumber(lul_temp) < 23) then
return false
end
</source>

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

<source lang="lua">
return luup.is_night() == false
</source>

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

<source lang="lua">
if (luup.is_night()) then
return false
else
return true
end
</source>

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Lighting and Switch Actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 5)
</source>

====Turn an appliance switch or a Danfoss thermostat off====

<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "0"}, 5)
</source>

====Do something if switch device #5 is on====

<source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 5)
if (lul_tmp == "1") then
--something to do goes here
end
</source>

====Dim switch #6 to 30%====

<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "30"}, 6)
</source>

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

===Motion Sensor Actions===
====Arm motion sensor #7====

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", "1", 7)
</source>

====Disarm motion sensor #7====

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", "0", 7)
</source>

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

===Scene Actions===
====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

<source lang="lua">
luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1", "RunScene", {SceneNum = "5"}, 0)
</source>

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

===Thermostat Actions===
====Change the Temperature on Thermostat (Cool) device #19====
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", {NewCurrentSetpoint = "68"},
19)
</source>

====Change the Temperature on a Thermostat (Heat) device #19====
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint", {NewCurrentSetpoint = "68"},
19)
</source>

====Change the Thermostat Operating mode device #19====
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:HVAC_UserOperatingMode1",
"SetModeTarget", {NewModeTarget = "Off"},
19)
</source>

===Camera Actions===
===='Privacy' mode for Foscam FI8908[w]====

<source lang="lua">
local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()
luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=0', timeout, username, password)
end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=25', timeout, username, password)

luup.call_delay('move_up', 120)
</source>

===Misc Actions===
====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

<source lang="lua">
os.date (format, time)
</source>

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

<source lang="lua">
t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}
</source>

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

<source lang="lua">
os.date('*t').hour
</source>

Current minute:

<source lang="lua">
os.date('*t').min
</source>

Current second:

<source lang="lua">
os.date('*t').sec
</source>

Do something between 16:00 and 21:15:

<source lang="lua">
local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds) then
-- do something
else
return false
end
</source>

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Lua extensions

2011-10-04T03:56:19Z

Guessed: /* function: call_action */ Wrap the line a little...

In addition to the [[http://lua.org Lua]] commands described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]], you can also reference in your Lua code variables and functions from modules which the Luup engine provides as follows:

== Module: luup ==

These are general purpose functions and variables. Call them by using the luup. module, such as: 

<source lang="lua">luup.log('Now running version: ' .. luup.version)</source>

=== variable: device ===

The ID of this device instance, if it's running as part of a device

=== variable: version, version_branch, version_major, version_minor ===

''version'' contains the version of the luup engine, such as "1.0.843", as a string. The version consists of 3 numbers separated by a period: the branch, the major version, and the minor version. To make it easier to compare against a minimum acceptable version, ''version_branch, version_major and version_minor'' return each component as a number. You can put a comparison in the startup function in your Luup plugin and return false if the minimum version isn't met. The user will then see that the Luup device's startup check failed: 

<source lang="lua">if( version_branch ~= 1 or version_major ~= 0 or version_minor < 843 ) then
luup.log("I need version 1.0.843 minimum to run")
return false
end</source>

=== variable: longitude ===

Contains the longitude as a number, as found on the location tab in the setup UI.

=== variable: latitude ===

Contains the latitude as a number, as found on the location tab in the setup UI.

=== variable: timezone ===

Contains the timezone as a number, as found on the location tab in the setup UI.

'''Warning:''' luup.timezone doesn't work.

=== variable: city ===

Contains the city as a string, as found on the location tab in the setup UI.

=== variable: devices ===

Contains all the devices in the system as a table indexed by the device number. The members are: room_num (number), device_type (string), category_num (number), device_num_parent (number), ip (string), mac (string), id (string), description (string), udn (string). [See also: [[Lua Device Structure]].] Example to log device #5's IP addess and its internal ID: 

<source lang="lua">luup.log('Device #5 ip: ' .. luup.devices[5].ip .. ' id: ' .. luup.devices[5].id)</source>

room_num: This is the number of the room the device is in.

device_type: This is a string representing the type of the device.

category_num: This is a category for the device. See: [[Luup_Device_Categories]] for a list.

device_num_parent: This is the number of the parent device. See: [[Lua Device Structure]] for details.

ip: If this device is IP based, this is the IP address.

mac: If this device is IP based, this is the MAC address.

id: If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.

embedded: (boolean) If this device is embedded, it means that it doesn't have its own room or exist as a separate device. It should be considered part of its parent. Like a 3-in-1 sensor is a device with 3 embedded child devices.

hidden: (boolean) If true the user checked the 'hidden' box and doesn't want to see the device on the dashboard.

invisible: (boolean) If true the device is 'for internal use only' and shouldn't be presented to the user.

description: This is the text description for the device as supplied by the user in the web UI.

udn: This is the UDN for the UPnP device.

This code will log all the attributes from all the devices: 

<source lang="lua">for k, v in pairs(lug_device) do
for k2, v2 in v do
luup.log("Device #" .. k .. ":" .. k2 .. "=" .. "v2")
end
end</source>

=== variable: rooms ===

Contains all the rooms as a table of strings indexed by the room number. Example: 

<source lang="lua">luup.log('Room #1 is called: ' .. luup.rooms[1])</source>

=== variable: scenes ===

Contains all the scenes in the system as a table indexed by the scene number. The members are: room_num (number), description(string), hidden(boolean)

=== variable: remotes ===

Contains all the remotes in the system as a table indexed by the remote id. The members are: remote_file (string), room_num (number), description(string)

=== function: log ===

parameters: what_to_log (string), log_level (optional, number)

return: nothing

Writes what_to_log to the log, /var/log/cmh/LuaUPnP.log, with the given log_level, which is 50 by default. See: [[Luup Loglevels]]

=== function: task ===

parameters: message (string), status (number), description (string), handle (number)

return: handle (number)

When the Luup engine is starting status messages are displayed for the various modules as they're initialized. Normally each device, including Luup devices, automatically log their status and the user is shown an error if the device doesn't start, such as if the 'startup' function returns an error.

If you have other startup sequences which you want the user to see to know that startup hasn't finished yet, call this function passing in a handle of -1 for the first call. The status should be: 1=Busy, 2=Error, 4=Successful. Message is the current state, such as 'downloading', and description describes the module, like 'Smartphone UI'. After the first call, store the handle and pass it on future calls to update the status rather than add a new one.

=== function: call_delay ===

parameters: function_name (string), seconds (number), data (string), thread (bool)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name. function_name will only be called once and you must call call_delay again if you want it called again, or use call_timer instead.

If thread is specified and is true or 1, the call back will be made in it's own thread and can block if needed. Normally it is called by a worker thread and is expected to return immediately.

=== function: call_timer ===

parameters: function_name (string), type (number), time (string), days (string), data (string)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called when the timer is triggered, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name.

Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer. For an interval timer, days is not used, and Time should be a number of seconds, minutes, or hours using an optional 'h' or 'm' suffix. Example: 30=call in 30 seconds, 5m=call in 5 minutes, 2h=call in 2 hours. For a day of week timer, Days is a comma separated list with the days of the week where 1=Monday and 7=Sunday. Time is the time of day in hh:mm:ss format. Time can also include an 'r' at the end for Sunrise or a 't' for Sunset and the time is relative to sunrise/sunset. For example: Days="3,5" Time="20:30:00" means your function will be called on the next Wed or Fri at 8:30pm. Days="1,7" Time="-3:00:00r" means your function will be called on the next Monday or Sunday 3 hours before sunrise. Day of month works the same way except Days is a comma separated list of days of the month, such as "15,20,30". For an absolute timer, Days is not used, and Time should be in the format: "yyyy-mm-dd hh:mm:ss"

Data can be a string passed back to the function. The function should be declared so it takes a single argument, which is this data. 

<source lang="lua">function refreshCache(stuff)
....
end

function startup()
--
-- Setup an interval-based timer to call refreshCache after 30 minutes.
-- Note that if you want it to "recur" then you need to call this function again
-- at the end of the refreshCache() implementation.
--
luup.call_timer("refreshCache", 1, "30m", "", "SomeStuff")
end</source>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

version: UI5 and above

Checks whether a device has successfully completed it's startup sequence. If so, <tt>is_ready</tt> returns <tt>true</tt>. If your device shouldn't process incoming data until the startup sequence is finished, you may want to add a condition to the <tt><incoming> block</tt> that only processes data if <tt>is_ready(lul_device)</tt> is <tt>true</tt>.

The <tt>device</tt> parameter, if it's a string, is interpreted as a udn. If it's a number, it's interpreted as a device number.

<source lang="lua"><incoming>
if (luup.is_ready(lul_device) == false) then
return
end

doSomething(lul_device)
</incoming></source>

=== function: call_action ===

parameters: service (string), action (string), arguments (table), device (string or number)

returns: error (number), error_msg (string), job (number), arguments (table)

Invokes the UPnP service + action, passing in the arguments (table of string->string pairs) to the device, which, if it's a string, is interpreted as a udn, and if it's a number, is the device number. If the invocation could not be made, only error will be returned with a value of -1. Otherwise, all 4 values are returned. error is 0 if the UPnP device reported the action was successful. arguments is a table of string->string pairs with the return arguments from the action. If the action is handled asynchronously by a Luup job, then the job number will be returned as a positive integer.

Example to dim device #5 to 50%: 

<source lang="lua">local lul_arguments = {}
lul_arguments["newLoadlevelTarget"] = 50
lul_resultcode, lul_resultstring, lul_job, lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:Dimming1",
"SetLoadLevelTarget", lul_arguments,
5)</source>

=== function: variable_set ===

parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]

returns: nothing

The UPnP service+variable will be set to value for device, which if it's a string, is interpreted as a udn, and if it's a number, as a device id. If there are events or notifications tied to the variable they will be fired.

Optionally, you can add an argument 'startup'. If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will ''not'' be fired.

=== function: variable_get ===

parameters: service (string), variable (string), device (string or number)

returns: value (string), time (number)

If the service+variable or device does not exist, it returns nothing. Otherwise it returns the value of the UPnP service+variable and the time when the variable was last modified, as a unix time stamp (number of seconds since 1/1/1970). You can assign just the value to a variable, as follows: 

<source lang="lua">local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5)
luup.log("Dim level for device #5 is: " .. value)</source>

=== function: attr_set ===

parameters: attribute (string), value(string), device (string or number)

returns: none

Sets the top level attribute for the device to value. Examples of attributes are 'mac', 'name', 'id', etc.

=== function: register_handler ===

parameters: function_name (string), request_name (string)

returns: nothing

When a certain URL is requested from a web browser or other HTTP get, function_name will be called and whatever string it returns will be returned.

See the WAP mobile phone plugin as an example: 

<source lang="lua">luup.register_handler("lug_WapRequest","wap")

function lug_WapRequest (lul_request, lul_parameters, lul_outputformat)
local lul_html = "<head>\n" ..
"<title>Main</title>\n" ..
"</head>\n" ..
"<body>\n" ..
"Choose a room: \n"
return lul_html
end</source>

The request is made with the URL: data_request?id=lr_[the registered name] on port 49451. So: http://192.168.1.1:49451/data_request?id=lr_wap will return the web page defined in the function lug_WapRequest in the example above.

=== function: variable_watch ===

parameters: function_name (string), service (string), variable (string or nil), device (string or number)

returns: nothing

Whenever the UPnP variable is changed for the specified device, which if a string is interpreted as a UDN and if a number as a device ID, ''function_name'' will be called. See [[Luup Declarations#watch_callback]] for the values that will be passed to ''function_name''. If variable is nil, ''function_name'' will be called whenever any variable in the service is changed.

 

=== function: devices_by_service ===

parameters:

returns:

=== function: device_supports_service ===

parameters:

returns:

'''Warning:''' luup.device_supports_service doesn't work reliably: http://forum.micasaverde.com/index.php?topic=5600.0

=== function: set_failure ===

parameters: value (boolean), device (string or number)

returns:

Luup maintains a 'failure' flag for every device to indicate if it is not functioning. You can set the flag to true if the device is failing. If device is a string it is interpreted as a udn, if it's a number, as a device id.

=== function: is_night ===

parameters: none

returns: boolean

Returns true if it's past sunset and before sunrise.

 

=== function: sleep ===

parameters: number of milliseconds

returns: none

Sleeps a certain number of milliseconds

'''Warning:''' luup.sleep doesn't work reliably: http://bugs.micasaverde.com/view.php?id=1480

== Module: luup.inet ==

=== function: wget ===

parameters: URL (String), Timeout (Number), Username (String), Password (String)

returns httpStatusCode (Number), content (String)

This reads the URL and returns 2 variables: the first is a numeric error code which is 0 if successful, and the second is a string containing the contents of the page. If '''Timeout''' is specified, the function will timeout after that many seconds. The default value for '''Timeout''' is 5 seconds. If '''Username''' and '''Password''' are specified, they will be used for HTTP Basic Authentication.

 

== Module: luup.chdev ==

Contains functions for a parent to synchronize its child devices. Whenever a device has multiple end-points, the devices are represented in a parent/child fashion where the parent device is responsible for reporting what child devices it has and giving each one a unique id. For example in the sample [[Luup Somfy Walkthrough]] there is a parent device, which is the interface module that controls up to 16 blinds, and up to 16 child devices, one for each blind. As shown in that sample, the parent calls start, then enumerates each child device with append, and finally calls sync. You will need to pass the same value for device to append and sync that you passed to start.

=== function: start ===

parameters: device (string or number)

returns: ptr (binary object)

Tells Luup you will start enumerating the children of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. The return value is a binary object which you cannot do anything with in Lua, but you do pass it to the append and sync functions.

=== function: append ===

parameters: device (string or number), ptr (binary object), id (string), description (string), device_type (string), device_filename (string), implementation_filename (string), parameters (string), embedded (boolean) [, invisible (boolean)]

returns: nothing

Adds one child to <tt>device</tt>. If <tt>device</tt> is a string it is interpreted as a udn, if it's a number, as a device id.

Pass in the <tt>ptr</tt> which you received from the <tt>luup.chdev.start</tt> call. Give each child a unique id so you can keep track of which is which. You can optionally provide a <tt>description</tt> which the user sees in the user interface.

<tt>device_type</tt> is the UPnP device type, such as <tt>urn:schemas-upnp-org:device:BinaryLight:1</tt>.

If <tt>device_filename</tt> is specified, that is the name of the XML file with the UPnP device specification. The deviceType from the filename will override any <tt>device_type</tt> you set manually. If the device_file contains the implementation file for this child device you do not need to specify it in <tt>implementation_filename</tt>. Otherwise, if there is a Luup implementation for this child device and it's not being handled by the parent device, you can specify it in <tt>implementation_filename</tt>.

If <tt>embedded</tt> is true, the 'embedded' flag is set for the device which generally means that the parent and all the children will be displayed as one compound device, or group, rather than as separate devices which you can put in their own rooms.

The <tt>parameters</tt> are UPnP service,variables you want set when the device is created. You can specify multiple variables by separating them with a line feed (\n) and use a <tt>,</tt> and <tt>=</tt> to separate service, variable and value, like this: <tt>service,variable=value\nservice</tt>...

<source lang="lua">
luup.chdev.append(device, children,
string.format("Input-%d", i), string.format("Input %d", i),
"urn:schemas-micasaverde-com:device:TemperatureSensor:1", "D_TemperatureSensor1.xml",
"", "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=50", true)
</source>

=== function: sync ===

parameters: device (string or number), ptr (binary object),

returns: nothing

If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Tells the Luup engine you have finished enumerating the child devices. If the child devices have changed in any way, the new device tree will be written to the configuration file and the Luup engine is reset.

== Module: io ==

=== function: open ===

parameters: device (string or number), ip (string) port (number),

returns: nothing

If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This opens a socket on 'port' to 'ip' and stores the handle to the socket in 'device'. The opening of a socket can take time depending on the network, and a Luup function should return quickly whenever possible because each top-level device's Lua implementation runs in a single thread. So the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.

Generally you do not need to call the open function because the socket is usually started automatically when the Luup engine starts. This is because the user typically either (a) associates a device with the destination io device, such as selecting an RS232 port for an alarm panel, where the RS232 is proxied by a socket, or (b) because the configuration settings for the device already include an IP address and port.

=== function: write ===

parameters: data (string), device (string or number)

returns: result (boolean)

In Lua a string can contain binary data, so data may be a binary block. If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This sends data on the socket that was opened automatically or with the open function above, and associated to 'device'. If the socket is not already open, write will wait up to 5 seconds for the socket before it returns an error. Result is 'true' if the data was sent successfully, and is 'false' or nill if an error occurred.

=== function: intercept ===

parameters: device (string or number)

returns: nothing

Normally when data comes in on a socket (I/O Port), the block of data is first passed to any pending jobs that are running for the device and are marked as 'waiting for data'. If there are none, or if none of the jobs' incoming data handlers report that they consumed (i.e. processed) the data, then the block of data is passed to the general 'incoming' function handler for the device. If you want to bypass this normal mechanism and read data directly from the socket, call intercept first to tell Luup you want to read incoming data with the read function. This is generally used during the initialization or startup sequences for devices. For example, you may need to send some data (a), receive some response (b), send some more data (c), receive another response (d), etc. In this case you would call 'intercept' first, then send a, then call read and confirm you got b, then call intercept again, then send c, then read d, and so on.

You can call the read function without calling intercept and any incoming data will be returned by that function after it's called. The reason why you generally must call intercept is because normally you want to send some data and get a response. If you write the code like this ''send(data) data=read()'' then it's possible the response will arrive in the brief moment between the execution of send() and read(), and therefore get sent to the incoming data handler for the device. Intercept tells Luup to buffer any incoming data until the next read, bypassing the normal incoming data handler. So ''intercept() send(data) data=read()'' ensures that read will always get the response. If the device you're communicating with sends unsolicited data then there's the risk that the data you read is not the response you're looking for. If so, you can manually pass the response packet to the incoming data handler.

**TBD: Add a function to do this**

=== function: read ===

parameters: timeout (number), device (string or number)

returns: data (string)

This reads a block of data from the socket. You must have called ''intercept'' previously so the data is passed. The time unit for ''timeout'' is seconds. 

=== function: is_connected ===

parameters: device (string or number)

returns: connected (boolean)

This function returns true if there is a valid IO port connected, otherwise returns false

== Module: luup.job ==

=== function: status ===

parameters: job_number (number), device (string or number)

returns: job_status (number), notes (string)

If job_number is invalid the function returns -1. If device is a string it is interpreted as an UDN, if it's a number, as a device ID.

=== function: set ===

parameters: job (userdata), setting (string), value (string)

returns: nothing

This stores a setting for a job.

<source lang="lua"><job>
luup.job.set(lul_job, "comments", "In progress...")
local comments = luup.job.setting(lul_job, "comments")
luup.log("job comments = " .. comments)
</job></source>

=== function: setting ===

parameters: job (userdata), setting (string)

returns: value (string)

This returns a setting for a job.

[[Category:Development]]

Luup Somfy Walkthrough

2011-09-05T15:45:57Z

Guessed: /* Step 5b: Polish up the startup sequence */ Line wrap

[[Category:Development]]
This page is for developers wanting to learn how to write a plugin. If you simply want to use the Somfy plugin see: [[Somfy_Plugin]]

This page walks through in detail the process of creating a Luup plugin to control the Somfy RS232 interface for motorized blinds as a sample. The Somfy documentation (see: [http://www.blindshademotors.com/documents/accessories-special-applications/rs232-to-rts-compatability.pdf]) explains that you talk to the controller using RS232 9600 Baud, 8 Data Bits, 1 Stop Bit, No Parity. The interface supports up to 16 blinds. The communication is one-way only; there are no response codes or incoming data from the blinds when they change manually. Here is the relevant section from the manual.

RS232 Operation
1. Set RS232 communication settings to: 9600 Baud, 8 Data Bits, 1 Stop Bit, No Parity
2. Use the ASCII protocol command string syntax: <!> <2 digit channel number> <Directional Command>
3. The directional commands must be capital letters and are as follows:
U: UP
D: DOWN
S: STOP
4. Examples: Motor 2 Up: !02U
Motor 5 Down: !05D
Motor 1 Stop: !01S

==Step 1: SSH into Vera==

Since this device is so simple it may not be necessary to debug anything. But we'll do this anyway. You need to give Vera a root password, which is the administrator password to login directly. Do this by either: a) from a command prompt in Windows, Linux or Mac type telnet [ip address of vera] and when you see the ''root@HomeControl:~#'' prompt enter: ''passwd'' and type in a password twice. Then type exit. Or b) In Vera's web ui click Advanced, Net & Wi-fi and the 'Advanced Configuration' link, and supply the password there. Note, sometimes Windows Vista doesn't have the telnet utility installed, so you have to use step b.

Once you have a root password set, you will no longer be able to use telnet to login to Vera, you must use ssh. The reason you should use ssh to login for debugging, and not telnet, is because some of the useful key sequences, like Ctrl+C, don't work in telnet.

Once you've setup a root password, from a Mac or Linux console type: ''ssh [ip of vera]'' From a Windows PC, download putty.exe here: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html]. You don't need to install putty, just put the .exe on your desktop or in a folder. When you run putty.exe, type in Vera's IP address and click 'open'.

When you see ''login as:'', enter: ''root'' and then enter your password. Now from the ''root@HomeControl:#'' prompt type:

cd /var/log/cmh
tail -f LuaUPnP.log

Do something in Vera's web ui and you'll see the logs go. Whenever the system rotates the logs, meaning purges the log files because Vera's memory is limited for storing logs, your tail will end. Press the 'up' arrow and hit 'enter' to display the tail command again and restart it. Press Ctrl + c when you've confirm the logs are working ok.

In Vera's web ui, choose Advanced, Logs, and check 'Verbose logging'. This option will create large logs that have lots of information we may need for debugging. It will stay checked for 24 hours and then automatically turn itself off so you're not creating unnecessarily large log files.

==Step 2a: Add your device with the web generator tool==

--coming soon. for now use step 2b.

== Step 2b: Add your device by building the XML files by hand ==

To do this you'll want a good text editor. I'm using, such as Notepad++ available here: [http://notepad-plus.sourceforge.net/uk/site.htm] by clicking Download, Download Notepad++ executable files, download and run the npp....Installer.exe file, and you may also want to download the 'XML plugin' from the download page, and unzip it putting the file \Program Files\Notepad++\plugins.

In Vera's setup UI, go to Devices, Luup plugins, click 'Luup files' and download the files:

''D_BinaryLight1.xml'' since there is no UPnP device specification for blinds, and blinds are essentially binary devices that are either up/down, we can implement the up/down using the same service that a light switch uses, and that way any UPnP control point that can control a light switch, will also be able to control blinds.

''S_SwitchPower1.xml'' because when you open D_BinaryLight1.xml, you'll see that in the 'services' section, this is the filename (SCPDURL) for the SwitchPower service.

[[Media:D_TestSerial.zip | ''D_TestSerial.xml'']] because this is a sample serial device we can use as a template.

[[Media:I_TestSerial.zip | ''I_TestSerial.xml'']] because this is a sample implementation for our serial device.

Open D_TestSerial.xml in your text editor and re-save it as a different name, such as D_SomfyBlinds.xml. Change the xml field deviceType to "urn:somfy-com:device:blinds:1" or use your own domain name instead of somfy-com. Change friendlyName to "Somfy Blind Controller", manufacturer to "Somfy", manufacturerURL to "somfy.com", modelDescription to "16 port RS232 to Somfy blind interface", modelName to "1810686" (the Somfy part number). modelURL and serialNumber and UPC aren't really important so you can just remove them. Add in their place a protocol tag with the value 'raw', and handlechildren (we'll explain this one later) with the value 1, like this:

<source lang="xml">
<protocol>raw</protocol>
<handleChildren>1</handleChildren>
</source>

The 'raw' protocol is because the Somfy device doesn't have any particular low level protocol, like terminating blocks of data with a carriage return, etc. Remove all the tags in 'servicelist'.

Change the filename in the ''implementationFile'' tag from I_TestSerial.xml to I_SomfyBlinds.xml.

Open I_TestSerial.xml and delete the sample Lua code within the 'actionList' tag. We have to put some Lua code in the implementation file for the Luup engine to start it, so for now just put a placeholder in the 'functions' xml tag:

<source lang="lua">
function lug_startup(lul_device)
luup.log("Somfy blind #" .. lul_device .. " starting up with ID " .. lug_device[lul_device].ID)
end
</source>

and in the 'startup' xml tag, put: ''lug_startup'', like this:

<source lang="xml">
<startup>lug_startup</startup>
</source>

So we've created a Lua function, lug_startup, told the Luup engine to call it when the engine is starting up. The name lug_startup is arbitrary, it can be anything you want. Save the file as I_SomfyBlinds.xml.

Back on Vera's setup ui under 'Luup files' you the first 'upload' button to upload D_SomfyBlinds.xml and the 2nd to upload I_SomfyBlinds.xml. Check ''Restart Luup after upload'' because the files won't be processed unless we restart the Luup engine, and click 'go'. Now leave your browser tab open at this page so that as we change the implementation file we can just click 'go' without having to select the files again.

In another browser tab go to Vera's device page again and under 'Add device' put the new device filename ''D_SomfyBlinds.xml'' in the input box, and choose the room where the blind controller is located, click 'Add device'. You'll have a new, blank device in that room, so give it a description "Somfy Blind Controller", then click 'save'.

Note that if the Somfy device was bi-direction we should attempt to communicate with it during the startup sequence and the startup function should return false if the sequence failed, or true if it succeeded, followed by some comments and the name of the module, which information is shown to the user in the info panel. So: return false,'Interface not responding','Somfy Blind' or return true,'Initialized OK','Somfy Blind'

==Step 3: Setup the port==

Vera talks to serial devices using a serial port proxy that turns the serial port into a network port. This way the serial port can reside anywhere on the network. Here are 3 ways to connect Vera to the Somfy device:

1. Get the UC232R-10 usb->serial adapter here: [http://www.futureelectronics.com/en/Pages/index.aspx] Connect it to one of Vera's USB ports. In Vera's web ui, click the 'save' button, which, even if the 'save' button is grayed out, causes the Luup engine to re-initialize and scan for new serial ports. Wait 30 seconds.

2. Use any Windows COM port or USB->serial port device. Download [[Windows_Serial_Proxy]] and run it as explained there. Wait 30 seconds after running it and it will exit after it has reported the port to the Luup engine.

3. Connect a Global Cache GC-100 to your network. Wait 30 seconds or so for the Luup engine to find it. This should happen automatically. Bring up the GC100's setup page in your web browser; you can find the IP address in Vera's device page under the + sign, and set the baud/parity/etc. for the port to match. In the case of the GC-100, this information is supplied to the GC-100 itself and the values in the Serial Port Configuration page have no effect.

After you've done 1, 2 or 3, go to Devices, Luup plugins and click "Serial port configuration". The serial port should be on the list. Use the pull-down's to set the serial port options: baud=9600, Data Bits=8, Stop Bits=1, Parity=none. For the 'Use with device', select your Somfy Blind controller. Choose 'Save'.

==Step 4: Test the port==

First, make note of the device id for your Somfy blinds by clicking '+' next to the device in the device list. Next, go to Devices, Luup Plugins, Test Luup code. In the 'Device number' input box put the device number for the Somfy blinds. This way whatever code we test uses the Lua instance for the Somfy blinds, which will be configured already to use the serial port.

In the 'Code' input box, type: ''luup.io.write('!01U')'' and click 'Go'. That is a command according to the Somfy specs, which should make motor #1 go up. You can try other commands and click 'Go' each time. If everything is working ok, skip to step 6. If it's not working, you will want to do some debugging. Here's some debug things to try:

1. Be sure you checked 'Verbose logging' in Step 1. In your ssh console (ie putty if you're using windows) enter ''tail -f LuaUPnP.log | grep '^5\|^01' '' where the | means to send the output through the grep utility, which will filter out only certain lines. The ^ means 'lines that start with'. Line that start with 5 are logs related to Lua, and lines that start with 01 are critical errors. The \| means 'or' for grep. Now go back and click 'go' again in the Test Luup window. Return to the ssh console and you should see a line that starts with 51, which means data sent within Luup, that shows !01U, in this format: ''51 06/29/09 17:19:53.453 0x21 0x30 0x31 0x55 0xd 0xa (!01U\r\n)'', where the human-readable ascii text is in () at the end, following the binary/hex. If you're going to be switching back and forth between the ssh console and web ui to do tests, then before you switch to the web ui, you can either hit 'enter' a few times in the ssh console to add some blank space, or press Ctrl+c and then 'up' followed by 'enter' to restart tail. That way you've created some separation between existing log entries and new ones so you can clearly see what is happening when you click 'go'. If you're not seeing anything, in the Test Luup window add the line ''lu_log('test somfy')'' above the luup.io.write. You should see 'test somfy' get logged when you press 'go'.

2. Assuming you do see the line '51' log entry showing that the Luup engine is trying to send data, you may want to check the serial port itself. You can go back to the 'serial port configuration' and remove the 'Somfy blind' device from the serial port so the Luup engine won't open the port. Make a note of the network ip and port for the serial port. Click 'Save' to save your changes. Now from a command prompt run: ''telnet [ip] [port]''. If you don't have telnet, open another putty session and click the 'telnet' radio box, put in the ip address and port and click 'open'. You should now be able to type the commands in the telnet session: ''!01U'' and see the blinds work. If it still doesn't work, try connecting the blinds directly to your PC and using a terminal program, like Hyperterminal, to talk directly to the serial port and confirm the connections are ok.

==Step 5: Create the child devices for the blinds ==

In Luup, when you have an interface device which is able to control multiple devices this is represented as a tree where the interface is a 'virtual' device, that probably doesn't implement any actions itself, and multiple 'child devices' under the interface device for each device the interface can control. The Somfy Blind controller is such a device because the 1 interface can control 16 blinds. If it only controlled 1 blind, we wouldn't need to implement the parent/multiple child architecture, because we would have just 1 device which implemented the blind functions. We also wouldn't need to create any functions in Lua and we'd simply have put the control protocol in the 'action' tags in the implementation XML. But we want a parent 'Somfy interface' with up to 16 different child devices for each of the 16 blinds the device can control. This means it's a bit more complicated, so we'll want to use Lua functions, like 'lug_startup'.

The way to implement multiple children is with the 'Reporting child devices' commands documented in [[Luup_Lua_extensions]]. This is how a parent device, in this case the Somfy blind interface, reports to the Luup engine what child devices it has and what ID number it will use internally to keep track of each one. Every device in Luup has an "ID" value which has no meaning to the Luup engine itself, but which is used by parent devices to keep track of the children. Many interface devices have a way to get from them the list of child devices so the parent can manage the children automatically. The Somfy doesn't. So we have 2 choices: 1) Just automatically report 16 child devices since the interface supports 16 devices, or 2) Let the user indicate which Somfy blind numbers he has and report just those child devices. The advantage of #1 is that it's very simple, but the drawback is that the user will see 16 blinds in his home, even if he only has 1. So, we will do it with #2. The first question is where to let the user store the list of blind numbers that are active. The usual way to store this information is to create a UPnP service which contains variables for all the various parameters the user should specify to configure the device. Creating a UPnP service description document and adding it to the device description is a lot of work to get only 1 parameter: a list of device numbers. But, what we can do is instead just create a variable in Lua using some service id/variable we made up, like this:

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
</source>

This won't be an 'official' UPnP variable and won't show up in a UPnP scanner. But, it does show up in Vera's user interface as a variable the user can edit the value. We want to be sure we set this to a default value if it's not already there so the user sees it in the UI and can change it.

Now we'll add the Lua code to iterate through all the blinds and create the devices, which will go in the lug_startup function we created earlier. We could put the code directly in the XML implementation file. But that means saving/uploading the file each time, and is a bit more tedious. It's often easier to debug it first in the 'Test Luup code' window. So we'll this to test first. First, put in the code box: ''lug_startup(123)'' but change the 123 to the actual device number of the Somfy blind, and click 'go'. Switch back to the ssh console that is tail'ing the LuaUPnP.log. You'll see that it logged ''Somfy blind #... starting up with ID''. This is because we already created the lug_startup function in the implementation file, and in the code box we just called that function. Now put this in the code box:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID="01,02"

luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1","BlindIds", lul_ID, lul_device)
luup.log("test2--Somfy blind #" .. lul_device .. " starting up with ID " .. lul_ID)
end

lug_startup(123)
</source>

where 123 should be your actual device number for the device. The Lua code in ''function lug_startup'' will cause the lug_startup function that was already in the implementation file to be replaced with this version, without actually executing the function (just updating it), so afterward we also have lug_startup(123) to actually run the new version we updated. When you click 'go' you'll see in the ssh log that the it now says ''test2--Somfy blind'', so you can see the lug_startup function was replaced. Note that any functions you create in the 'Test Luup Code' window will still stay in the Luup engine until you reload the Luup engine. So if you type in the code box:

<source lang="lua">
function some_test()
luup.log("some_test")
end
</source>

click 'go', nothing will get logged. If you then erase the code box and type: ''some_test()'' when you click 'go', you'll see "some_test" in the log. If you want to update the some_test function, and run it at the same time, do:

<source lang="lua">
function some_test()
luup.log("some_test2")
end

some_test()
</source>

Now when you click 'go', you'll see "some_test2" be logged. So we'll create a simple startup that creates all 16 blinds by putting this in the Test Luup code window:

<source lang="lua">
function lug_startup(lul_device)
child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-upnp-org:device:BinaryLight:1", "", "", "", true)
end

luup.chdev.sync(lul_device, child_devices)
end

lug_startup(123)
</source>

The ''for i=1,16'' is runs the block before 'end' 16 times, assigning the variable 'i' to 1 to 16 each time. We want the devices to be 0 padded to 2 digits, so 1 should be "01". This is because the ID which the Somfy needs is a zero-padded 2 digit number. It also will make it easier to filter just the blinds we want to control as explained later. The statement ''s = string.format("%02d", i)'' converts the numeric value 'i' to a string that is padded to decimal places. This is documented in Lua (see [http://www.lua.org/pil/20.html#StringLib]).

luup.chdev.start() takes as a parameter our device id (ie the parent device) and it tells the Luup engine we're going to start listing all our children. It returns a handle which we pass in to to the other chdev_ functions. luup.chdev.append() adds each child and it takes the parent device number, the handle from lu_chdev_start, the id the parent will use to identify the device (s=01, 02, etc.), and the device type. This is a UPnP device. We'll use the existing UPnP standard "Binary light" because this way every UPnP control point will treat the blinds as a light and show the user an 'on' and 'off' button. We could create our own device type for blinds which had actions "open" and "close", but then the UPnP Control Points (like the iPhone interface) would need to be updated to know how to present the user with blinds. luup.chdev.sync() is called when we're done to synchronize the child device list with Luup's database, and create/remove any new/missing devices, and restart the Luup engine if devices were added or removed. See: [[Luup_Lua_extensions]]

Before you click 'go', restart your tail in the ssh window with: ''tail -f LuaUPnP.log | grep '^5\|^01\|^03\|^09\|^11' '' because the 03 logs indicate when the Luup engine stops and restart, the 09 logs show us when devices are created/deleted, and the 11 logs show when the child device functions are calls. Now when you click 'go', you should see in the logs ''Child_Devices::AddChild'' is called 16 times, and then 16 times ''Child_Devices::ProcessChildDevice created device''. You should also see lines starting with '03' that show the Luup engine is reloading since new devices were just created. When it restarts, you'll see 16 new devices in the logs starting with 09.

Now if you click 'go' again, you'll see 16 logs for ''Child_Devices::AddChild'', but no devices will be created or removed because the 16 devices were already created, and the parent/child device lists are still in sync. We have the same 16 child devices with no new ones or removed ones.

Now if you refresh Vera's web UI, you'll see the Somfy device has '16' embedded devices, each with "on" and "Off". The 'true' at the end of the luup.chdev.append means the child devices are 'embedded'. That means when they're shown in Vera's web UI, they're all grouped together as one compound device. If you changed the 'true' to a 'false', all 16 blinds would show up as completely separate devices. This is really just a cosmetic difference. The advantage to using 'false' (non-embedded) is that the user can put each blind in a different room. In this case it's probably better to treat the devices as non-embedded, since it is likely the 16 blinds will be scattered around the house. So change the true at the end of luup.chdev.append to a false. Then click 'go'. Now, the 16 blinds are removed, and re-added as non-embedded devices. So, if you refresh Vera's web UI and go to devices, you'll 16 different blinds that you can put into different rooms, in addition to the "Somfy blind interface" device.

Next, we'll update our Lua code to only create child devices that are specified in the "ID" parameter of the "Somfy blind interface" so that if the user doesn't have 16 devices he can specify just the ones he does have. To make our coding easier, we'll document in the notes for the user that when specifying the list of blinds in the "ID" he must use 01,02, etc., rather than 1,2, etc. because by storing all child devices as 2 digits, we can do a simple search without having to actually parse the ID. In other words, if we want to know if blind #1 is active, we can safely search the ID for 01 and know that it will only match if blind #1 is active. If the user stored single digit blind numbers, like ''5,6,11'' then searching for '1' would give us a false positive and we'd need to write more Lua code to break the list apart. This also makes it easier to send the blind commands because the Somfy protocol says the blind number must be 2 digits, so we won't need to pad the ID's with 0 for the Somfy device. This is why we did the for loop with 16 text strings using string.format which would have given us normal, non-zero-padded numbers.

Put a -- in front of the luup.chdev.append in the window and click 'go' again. -- means "comments" in Lua, and lines starting with -- are ignored. Therefore, by eliminating the luup.chdev.append, now the luup.chdev.sync will remove all 16 children since none were appended. This way we can reload Vera's web UI, go to the devices page, and we won't have those 16 blinds anymore requiring us to provide a room. Click '+' next to the Somfy blind interface, click 'Advanced' and in the BlindIds enter: '02,07,13', click 'save'. Now in the 'Test Luup code' window enter:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID == nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end

local lul_prefix = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_device)
if (lul_prefix == nil) then
lul_prefix = "01"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_prefix, lul_device)
end

luup.log("Somfy ID is " .. lul_ID .. " prefix is " .. lul_prefix)
child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
if (string.find(lul_ID,s) ~= nil) then
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-upnp-org:device:BinaryLight:1", "", "", "", false)
end
end

luup.chdev.sync(lul_device, child_devices)
end

lug_startup(123)
</source>

Don't forget to change the '123' to your actual device number. Now when you click 'go' you'll see the logs indicate we only have 3 blinds with ID's 02, 07 and 13. Since this part of the code is done, you can copy/paste this from the Luup test code window into the implementation. '''IMPORTANT:''' Be sure the ''lug_startup(123)'' is NOT in your implementation file, or else your lug_startup function will be called twice at each startup: once by the Luup engine with the actual device number, and once when the startup functions are loaded into the Lua engine with your hard-coded number used for testing, which won't necessarily correspond to the real device number. We also add the variable lul_prefix because the URTS version 1 takes an ! in the front of every command, whereas with version 2 it's a 2 digit number from 01 to 16. So we'll default to 01, the default value for an URTS version 2, but we'll let the user change it. We'll store this in a global variable, lul_prefix, so it's available for use in the other functions in our plugin.

If you're editing the XML file by hand, you can save your changes and click 'go' in the Luup files upload page in your web browser to upload your changes.

Every time you re-start the Luup engine, such as clicking 'Save', you'll see in the logs this startup sequence.

==Step 5b: Polish up the startup sequence ==

The the startup sequence as it is the user will always think the Somfy module loaded fine, even when it didn't, giving the user a false sense that everything was ok even when he hadn't yet specified basic parameters.

Now, the code first checks for basic startup parameters, which are stored in UPNP variables, and sets them to a default value if they're not already specified. You should at least set them an empty string because by setting them to something then the user will see them in the web user interface and be able to easily change them, as opposed to creating them again from scratch:

<source lang="lua">
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID = nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end
</source>

Next, since this device uses an IO Port (ie a serial port, or an ethernet port, or a usb connection), we should check that the connection is specified and is active before doing the startup:

<source lang="lua">
if (luup.io.is_connected(lul_device) == false) then
luup.log('No port for Somfy', 1)
luup.task('Choose the Serial Port for the URTSI', 2, 'Somfy Blind Interface', -1)
return false
end
</source>

If there's a failure of any kind, we should call luup.task and put in some sort of description with the status code 2 (Error), and then 'return false'. This way the user sees in the web panel that the module 'Somfy Blind Interface' is in an error condition and what the problem is (he didn't choose the serial port). If we didn't do the 'return false', the user would think the Somfy module was ok since, when the startup function doesn't return false, the architecture assumes the module is running fine. If we called return false, didn't call luup.task, then the user see that the module was failing, but would have only a generic "Startup sequence failed" without knowing the explicit reason.

So now the startup sequence looks like this:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID == nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end

local lul_prefix = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_device)
if (lul_prefix == nil) then
lul_prefix = "01"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_prefix, lul_device)
end

luup.log("Somfy ID is " .. lul_ID .. " prefix is " .. lul_prefix)

if (luup.io.is_connected(lul_device) == false) then
luup.log('No port for Somfy', 1)
luup.task('Choose the Serial Port for the URTSI',2,'Somfy Blind Interface', -1)
return false
end

child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
if (string.find (lul_ID,s) ~= nil) then
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s,
"urn:schemas-micasaverde-com:device:WindowCovering:1",
"D_WindowCovering1.xml", "", "", false)
end
end

luup.chdev.sync(lul_device, child_devices)
end
</source>

==Step 6a: Implementation the actions in the web generator ==

--coming soon--

==Step 6b: Implementation the actions in the xml file ==

The reason we added the ''<handleChildren>1</handleChildren>'' tag to the Somfy blind interface's device file earlier is because we're going to put all the actions for the child devices (the blinds) within the main implementation file for the Somfy. So, whenever an action comes in for a child device (a blind), the Lua code in the parent devices implementation file will handle it. Replace the actionList tag in the implementation file with this:

<source lang="xml">
<actionList>
<action>
<serviceId>urn:upnp-org:serviceId:SwitchPower1</serviceId>
<name>SetTarget</name>
<run>
local lul_command = lul_prefix .. luup.devices[lul_device].id .. 'U\r'
local lul_reverse = luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "ReverseOnOff", lul_device)

if (lul_settings.newTargetValue == "1" or (lul_settings.newTargetValue == "0" and lul_reverse == "1")) then
lul_command = lul_prefix .. luup.devices[lul_device].id .. 'D\r'
end

if (luup.io.write(lul_command) == false) then
luup.log("cannot send: " .. tostring(lul_command),1)
luup.set_failure(true)
return false
end
</run>
</action>
</actionList>
</source>

This provides the implementation or the SetTarget UPnP action, which is what is sent when the user clicks 'on' or 'off' for a light switch, or 'open' or 'close' for blinds. We store the command to send in the variable lul_command and put the 'local' keyword in front so the variable is only available while the 'SetTarget' action is running. We also check the HADevice service's ReverseOnOff value. As a convention in Luup, we created this as a common service that all home automation devices have, and the ReverseOnOff variable, if true, means reverse the usual on/off behavior, so on is off and off is on. We did this because it's not uncommon for binary switches, particularly blinds, to be wired the wrong way, or for it to be subjective which position is on vs. off. This way the user can add this variable for his configuration if the operation is backwards from what he would expect. lu_SetCommFailure sets a "communication failure" flag for the device, which logs a critical error, and allows the user to see that the device is having problems. Whenever the Luup engine reloads, such as clicking 'save', the flag is cleared again.

Now when you click 'on' or 'off' for the blinds you'll see in the log it is sending the corresponding data to the blinds.

Lua tips

2011-09-04T22:47:01Z

Guessed: Syntax color the Lua code, fix a few typo's

[[Category:Development]]
Lua is a very complete and powerful language, the full reference is at http://www.lua.org. This page attempts to help with common pitfalls, especially those that are likely to appear on scripting the MIOS system.

== Get a default ==

It's customary for some functions to return a '''nil''' value to mean 'nothing'; for example, luup.variable_get() returns '''nil''' if you ask for a non-existant variable, or a wrong service or device.  Unfortunately, using that '''nil''' to build a string causes an error. For example:

<source lang="lua">
local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5)
luup.log("Dim level for device #5 is: " .. value)
</source>

This works perfectly if the device #5 supports the "Dimming" service and has a "LoadLevelTarget" variable; but if you have the wrong device, the whole script would simply fail at the next line, where it tries to concatenate a string with a '''nil''' value.

A common solution is to use the '''or''' keyword to give your variable a default value: 
<source lang="lua">
local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5) or "-none-"
luup.log("Dim level for device #5 is: " .. value)
</source>

Now, if anything gets wrong reading the value, your variable will have a value of "-none-".  In most cases, it's simpler to use the empty string "" as the default value.

 

== Hold on to your locals ==

It's always good practice to avoid 'polluting' the global variable space.  Any temporal variable should be defined with the '''local''' keyword.  Note that making a variable '''local''' means it's accessible only within the current block, for example:
<source lang="lua">
if (value > 5) then
local msg = "good!"
end

luup.log(msg)
</source>

This won't work correctly, the 'msg' is  local to the 'then' block; it can't be accessed in any other context.  The loop.log() function will be called using a global 'msg' variable, which is probably '''nil''', or even worse, could have the wrong value. 

But that also means you can define an outer block, and make your locals 'not so local'.  For example: 
<source lang="lua">
do
local innerval = 0

function increment()
innerval = innerval + 1
end

function getit()
return innerval
end
end
</source>

In this example, 'innerval' is local to the outer block, which contains two functions.  Both functions can access that variable; but no other code can.  This is an example of encapsulation.  Using this, you can be sure that no other code can mess with your variables.  In this example, it's easy to see that innerval will only be incremented, there's no way to go backwards until the system is restarted. 

In many cases in which you might want a global variable, it could be better to use a local variable for a bigger block, even a block that surrounds your whole module.

== Mark your own turf ==

When you do have to use a global variable, keep in mind that any other code could access it and even modify it.  We're not talking about malitious intentions, just about unintended interactions between two different parts of the code. likely written by different people.

To reduce the probability of errors, a common technique is to use a prefix that is likely to be unique.  For example, a plugin called "Energy Monitor" could start all global variables with 'enmon_'.

Somewhat better is to join all global variables in a single global variable that holds a table:
<source lang="lua">
energymonitor = {}
energymonitor.starttime = os.time()
energymonitor.devicecount = 15
</source>

Note that this is what Lua modules do: each one is defined as a single table.  Even the standard library follows this convention, all string related functions are contained in the global 'string' table.

One (current) limitation is that any function that you want to be called by Luup has to be global, not inside a global table.  For those, the best way is to use a unique prefix.

Luup Somfy Walkthrough

2011-09-04T22:41:38Z

Guessed: Syntax color the Lua code, fix a few typo's

[[Category:Development]]
This page is for developers wanting to learn how to write a plugin. If you simply want to use the Somfy plugin see: [[Somfy_Plugin]]

This page walks through in detail the process of creating a Luup plugin to control the Somfy RS232 interface for motorized blinds as a sample. The Somfy documentation (see: [http://www.blindshademotors.com/documents/accessories-special-applications/rs232-to-rts-compatability.pdf]) explains that you talk to the controller using RS232 9600 Baud, 8 Data Bits, 1 Stop Bit, No Parity. The interface supports up to 16 blinds. The communication is one-way only; there are no response codes or incoming data from the blinds when they change manually. Here is the relevant section from the manual.

RS232 Operation
1. Set RS232 communication settings to: 9600 Baud, 8 Data Bits, 1 Stop Bit, No Parity
2. Use the ASCII protocol command string syntax: <!> <2 digit channel number> <Directional Command>
3. The directional commands must be capital letters and are as follows:
U: UP
D: DOWN
S: STOP
4. Examples: Motor 2 Up: !02U
Motor 5 Down: !05D
Motor 1 Stop: !01S

==Step 1: SSH into Vera==

Since this device is so simple it may not be necessary to debug anything. But we'll do this anyway. You need to give Vera a root password, which is the administrator password to login directly. Do this by either: a) from a command prompt in Windows, Linux or Mac type telnet [ip address of vera] and when you see the ''root@HomeControl:~#'' prompt enter: ''passwd'' and type in a password twice. Then type exit. Or b) In Vera's web ui click Advanced, Net & Wi-fi and the 'Advanced Configuration' link, and supply the password there. Note, sometimes Windows Vista doesn't have the telnet utility installed, so you have to use step b.

Once you have a root password set, you will no longer be able to use telnet to login to Vera, you must use ssh. The reason you should use ssh to login for debugging, and not telnet, is because some of the useful key sequences, like Ctrl+C, don't work in telnet.

Once you've setup a root password, from a Mac or Linux console type: ''ssh [ip of vera]'' From a Windows PC, download putty.exe here: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html]. You don't need to install putty, just put the .exe on your desktop or in a folder. When you run putty.exe, type in Vera's IP address and click 'open'.

When you see ''login as:'', enter: ''root'' and then enter your password. Now from the ''root@HomeControl:#'' prompt type:

cd /var/log/cmh
tail -f LuaUPnP.log

Do something in Vera's web ui and you'll see the logs go. Whenever the system rotates the logs, meaning purges the log files because Vera's memory is limited for storing logs, your tail will end. Press the 'up' arrow and hit 'enter' to display the tail command again and restart it. Press Ctrl + c when you've confirm the logs are working ok.

In Vera's web ui, choose Advanced, Logs, and check 'Verbose logging'. This option will create large logs that have lots of information we may need for debugging. It will stay checked for 24 hours and then automatically turn itself off so you're not creating unnecessarily large log files.

==Step 2a: Add your device with the web generator tool==

--coming soon. for now use step 2b.

== Step 2b: Add your device by building the XML files by hand ==

To do this you'll want a good text editor. I'm using, such as Notepad++ available here: [http://notepad-plus.sourceforge.net/uk/site.htm] by clicking Download, Download Notepad++ executable files, download and run the npp....Installer.exe file, and you may also want to download the 'XML plugin' from the download page, and unzip it putting the file \Program Files\Notepad++\plugins.

In Vera's setup UI, go to Devices, Luup plugins, click 'Luup files' and download the files:

''D_BinaryLight1.xml'' since there is no UPnP device specification for blinds, and blinds are essentially binary devices that are either up/down, we can implement the up/down using the same service that a light switch uses, and that way any UPnP control point that can control a light switch, will also be able to control blinds.

''S_SwitchPower1.xml'' because when you open D_BinaryLight1.xml, you'll see that in the 'services' section, this is the filename (SCPDURL) for the SwitchPower service.

[[Media:D_TestSerial.zip | ''D_TestSerial.xml'']] because this is a sample serial device we can use as a template.

[[Media:I_TestSerial.zip | ''I_TestSerial.xml'']] because this is a sample implementation for our serial device.

Open D_TestSerial.xml in your text editor and re-save it as a different name, such as D_SomfyBlinds.xml. Change the xml field deviceType to "urn:somfy-com:device:blinds:1" or use your own domain name instead of somfy-com. Change friendlyName to "Somfy Blind Controller", manufacturer to "Somfy", manufacturerURL to "somfy.com", modelDescription to "16 port RS232 to Somfy blind interface", modelName to "1810686" (the Somfy part number). modelURL and serialNumber and UPC aren't really important so you can just remove them. Add in their place a protocol tag with the value 'raw', and handlechildren (we'll explain this one later) with the value 1, like this:

<source lang="xml">
<protocol>raw</protocol>
<handleChildren>1</handleChildren>
</source>

The 'raw' protocol is because the Somfy device doesn't have any particular low level protocol, like terminating blocks of data with a carriage return, etc. Remove all the tags in 'servicelist'.

Change the filename in the ''implementationFile'' tag from I_TestSerial.xml to I_SomfyBlinds.xml.

Open I_TestSerial.xml and delete the sample Lua code within the 'actionList' tag. We have to put some Lua code in the implementation file for the Luup engine to start it, so for now just put a placeholder in the 'functions' xml tag:

<source lang="lua">
function lug_startup(lul_device)
luup.log("Somfy blind #" .. lul_device .. " starting up with ID " .. lug_device[lul_device].ID)
end
</source>

and in the 'startup' xml tag, put: ''lug_startup'', like this:

<source lang="xml">
<startup>lug_startup</startup>
</source>

So we've created a Lua function, lug_startup, told the Luup engine to call it when the engine is starting up. The name lug_startup is arbitrary, it can be anything you want. Save the file as I_SomfyBlinds.xml.

Back on Vera's setup ui under 'Luup files' you the first 'upload' button to upload D_SomfyBlinds.xml and the 2nd to upload I_SomfyBlinds.xml. Check ''Restart Luup after upload'' because the files won't be processed unless we restart the Luup engine, and click 'go'. Now leave your browser tab open at this page so that as we change the implementation file we can just click 'go' without having to select the files again.

In another browser tab go to Vera's device page again and under 'Add device' put the new device filename ''D_SomfyBlinds.xml'' in the input box, and choose the room where the blind controller is located, click 'Add device'. You'll have a new, blank device in that room, so give it a description "Somfy Blind Controller", then click 'save'.

Note that if the Somfy device was bi-direction we should attempt to communicate with it during the startup sequence and the startup function should return false if the sequence failed, or true if it succeeded, followed by some comments and the name of the module, which information is shown to the user in the info panel. So: return false,'Interface not responding','Somfy Blind' or return true,'Initialized OK','Somfy Blind'

==Step 3: Setup the port==

Vera talks to serial devices using a serial port proxy that turns the serial port into a network port. This way the serial port can reside anywhere on the network. Here are 3 ways to connect Vera to the Somfy device:

1. Get the UC232R-10 usb->serial adapter here: [http://www.futureelectronics.com/en/Pages/index.aspx] Connect it to one of Vera's USB ports. In Vera's web ui, click the 'save' button, which, even if the 'save' button is grayed out, causes the Luup engine to re-initialize and scan for new serial ports. Wait 30 seconds.

2. Use any Windows COM port or USB->serial port device. Download [[Windows_Serial_Proxy]] and run it as explained there. Wait 30 seconds after running it and it will exit after it has reported the port to the Luup engine.

3. Connect a Global Cache GC-100 to your network. Wait 30 seconds or so for the Luup engine to find it. This should happen automatically. Bring up the GC100's setup page in your web browser; you can find the IP address in Vera's device page under the + sign, and set the baud/parity/etc. for the port to match. In the case of the GC-100, this information is supplied to the GC-100 itself and the values in the Serial Port Configuration page have no effect.

After you've done 1, 2 or 3, go to Devices, Luup plugins and click "Serial port configuration". The serial port should be on the list. Use the pull-down's to set the serial port options: baud=9600, Data Bits=8, Stop Bits=1, Parity=none. For the 'Use with device', select your Somfy Blind controller. Choose 'Save'.

==Step 4: Test the port==

First, make note of the device id for your Somfy blinds by clicking '+' next to the device in the device list. Next, go to Devices, Luup Plugins, Test Luup code. In the 'Device number' input box put the device number for the Somfy blinds. This way whatever code we test uses the Lua instance for the Somfy blinds, which will be configured already to use the serial port.

In the 'Code' input box, type: ''luup.io.write('!01U')'' and click 'Go'. That is a command according to the Somfy specs, which should make motor #1 go up. You can try other commands and click 'Go' each time. If everything is working ok, skip to step 6. If it's not working, you will want to do some debugging. Here's some debug things to try:

1. Be sure you checked 'Verbose logging' in Step 1. In your ssh console (ie putty if you're using windows) enter ''tail -f LuaUPnP.log | grep '^5\|^01' '' where the | means to send the output through the grep utility, which will filter out only certain lines. The ^ means 'lines that start with'. Line that start with 5 are logs related to Lua, and lines that start with 01 are critical errors. The \| means 'or' for grep. Now go back and click 'go' again in the Test Luup window. Return to the ssh console and you should see a line that starts with 51, which means data sent within Luup, that shows !01U, in this format: ''51 06/29/09 17:19:53.453 0x21 0x30 0x31 0x55 0xd 0xa (!01U\r\n)'', where the human-readable ascii text is in () at the end, following the binary/hex. If you're going to be switching back and forth between the ssh console and web ui to do tests, then before you switch to the web ui, you can either hit 'enter' a few times in the ssh console to add some blank space, or press Ctrl+c and then 'up' followed by 'enter' to restart tail. That way you've created some separation between existing log entries and new ones so you can clearly see what is happening when you click 'go'. If you're not seeing anything, in the Test Luup window add the line ''lu_log('test somfy')'' above the luup.io.write. You should see 'test somfy' get logged when you press 'go'.

2. Assuming you do see the line '51' log entry showing that the Luup engine is trying to send data, you may want to check the serial port itself. You can go back to the 'serial port configuration' and remove the 'Somfy blind' device from the serial port so the Luup engine won't open the port. Make a note of the network ip and port for the serial port. Click 'Save' to save your changes. Now from a command prompt run: ''telnet [ip] [port]''. If you don't have telnet, open another putty session and click the 'telnet' radio box, put in the ip address and port and click 'open'. You should now be able to type the commands in the telnet session: ''!01U'' and see the blinds work. If it still doesn't work, try connecting the blinds directly to your PC and using a terminal program, like Hyperterminal, to talk directly to the serial port and confirm the connections are ok.

==Step 5: Create the child devices for the blinds ==

In Luup, when you have an interface device which is able to control multiple devices this is represented as a tree where the interface is a 'virtual' device, that probably doesn't implement any actions itself, and multiple 'child devices' under the interface device for each device the interface can control. The Somfy Blind controller is such a device because the 1 interface can control 16 blinds. If it only controlled 1 blind, we wouldn't need to implement the parent/multiple child architecture, because we would have just 1 device which implemented the blind functions. We also wouldn't need to create any functions in Lua and we'd simply have put the control protocol in the 'action' tags in the implementation XML. But we want a parent 'Somfy interface' with up to 16 different child devices for each of the 16 blinds the device can control. This means it's a bit more complicated, so we'll want to use Lua functions, like 'lug_startup'.

The way to implement multiple children is with the 'Reporting child devices' commands documented in [[Luup_Lua_extensions]]. This is how a parent device, in this case the Somfy blind interface, reports to the Luup engine what child devices it has and what ID number it will use internally to keep track of each one. Every device in Luup has an "ID" value which has no meaning to the Luup engine itself, but which is used by parent devices to keep track of the children. Many interface devices have a way to get from them the list of child devices so the parent can manage the children automatically. The Somfy doesn't. So we have 2 choices: 1) Just automatically report 16 child devices since the interface supports 16 devices, or 2) Let the user indicate which Somfy blind numbers he has and report just those child devices. The advantage of #1 is that it's very simple, but the drawback is that the user will see 16 blinds in his home, even if he only has 1. So, we will do it with #2. The first question is where to let the user store the list of blind numbers that are active. The usual way to store this information is to create a UPnP service which contains variables for all the various parameters the user should specify to configure the device. Creating a UPnP service description document and adding it to the device description is a lot of work to get only 1 parameter: a list of device numbers. But, what we can do is instead just create a variable in Lua using some service id/variable we made up, like this:

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
</source>

This won't be an 'official' UPnP variable and won't show up in a UPnP scanner. But, it does show up in Vera's user interface as a variable the user can edit the value. We want to be sure we set this to a default value if it's not already there so the user sees it in the UI and can change it.

Now we'll add the Lua code to iterate through all the blinds and create the devices, which will go in the lug_startup function we created earlier. We could put the code directly in the XML implementation file. But that means saving/uploading the file each time, and is a bit more tedious. It's often easier to debug it first in the 'Test Luup code' window. So we'll this to test first. First, put in the code box: ''lug_startup(123)'' but change the 123 to the actual device number of the Somfy blind, and click 'go'. Switch back to the ssh console that is tail'ing the LuaUPnP.log. You'll see that it logged ''Somfy blind #... starting up with ID''. This is because we already created the lug_startup function in the implementation file, and in the code box we just called that function. Now put this in the code box:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID="01,02"

luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1","BlindIds", lul_ID, lul_device)
luup.log("test2--Somfy blind #" .. lul_device .. " starting up with ID " .. lul_ID)
end

lug_startup(123)
</source>

where 123 should be your actual device number for the device. The Lua code in ''function lug_startup'' will cause the lug_startup function that was already in the implementation file to be replaced with this version, without actually executing the function (just updating it), so afterward we also have lug_startup(123) to actually run the new version we updated. When you click 'go' you'll see in the ssh log that the it now says ''test2--Somfy blind'', so you can see the lug_startup function was replaced. Note that any functions you create in the 'Test Luup Code' window will still stay in the Luup engine until you reload the Luup engine. So if you type in the code box:

<source lang="lua">
function some_test()
luup.log("some_test")
end
</source>

click 'go', nothing will get logged. If you then erase the code box and type: ''some_test()'' when you click 'go', you'll see "some_test" in the log. If you want to update the some_test function, and run it at the same time, do:

<source lang="lua">
function some_test()
luup.log("some_test2")
end

some_test()
</source>

Now when you click 'go', you'll see "some_test2" be logged. So we'll create a simple startup that creates all 16 blinds by putting this in the Test Luup code window:

<source lang="lua">
function lug_startup(lul_device)
child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-upnp-org:device:BinaryLight:1", "", "", "", true)
end

luup.chdev.sync(lul_device, child_devices)
end

lug_startup(123)
</source>

The ''for i=1,16'' is runs the block before 'end' 16 times, assigning the variable 'i' to 1 to 16 each time. We want the devices to be 0 padded to 2 digits, so 1 should be "01". This is because the ID which the Somfy needs is a zero-padded 2 digit number. It also will make it easier to filter just the blinds we want to control as explained later. The statement ''s = string.format("%02d", i)'' converts the numeric value 'i' to a string that is padded to decimal places. This is documented in Lua (see [http://www.lua.org/pil/20.html#StringLib]).

luup.chdev.start() takes as a parameter our device id (ie the parent device) and it tells the Luup engine we're going to start listing all our children. It returns a handle which we pass in to to the other chdev_ functions. luup.chdev.append() adds each child and it takes the parent device number, the handle from lu_chdev_start, the id the parent will use to identify the device (s=01, 02, etc.), and the device type. This is a UPnP device. We'll use the existing UPnP standard "Binary light" because this way every UPnP control point will treat the blinds as a light and show the user an 'on' and 'off' button. We could create our own device type for blinds which had actions "open" and "close", but then the UPnP Control Points (like the iPhone interface) would need to be updated to know how to present the user with blinds. luup.chdev.sync() is called when we're done to synchronize the child device list with Luup's database, and create/remove any new/missing devices, and restart the Luup engine if devices were added or removed. See: [[Luup_Lua_extensions]]

Before you click 'go', restart your tail in the ssh window with: ''tail -f LuaUPnP.log | grep '^5\|^01\|^03\|^09\|^11' '' because the 03 logs indicate when the Luup engine stops and restart, the 09 logs show us when devices are created/deleted, and the 11 logs show when the child device functions are calls. Now when you click 'go', you should see in the logs ''Child_Devices::AddChild'' is called 16 times, and then 16 times ''Child_Devices::ProcessChildDevice created device''. You should also see lines starting with '03' that show the Luup engine is reloading since new devices were just created. When it restarts, you'll see 16 new devices in the logs starting with 09.

Now if you click 'go' again, you'll see 16 logs for ''Child_Devices::AddChild'', but no devices will be created or removed because the 16 devices were already created, and the parent/child device lists are still in sync. We have the same 16 child devices with no new ones or removed ones.

Now if you refresh Vera's web UI, you'll see the Somfy device has '16' embedded devices, each with "on" and "Off". The 'true' at the end of the luup.chdev.append means the child devices are 'embedded'. That means when they're shown in Vera's web UI, they're all grouped together as one compound device. If you changed the 'true' to a 'false', all 16 blinds would show up as completely separate devices. This is really just a cosmetic difference. The advantage to using 'false' (non-embedded) is that the user can put each blind in a different room. In this case it's probably better to treat the devices as non-embedded, since it is likely the 16 blinds will be scattered around the house. So change the true at the end of luup.chdev.append to a false. Then click 'go'. Now, the 16 blinds are removed, and re-added as non-embedded devices. So, if you refresh Vera's web UI and go to devices, you'll 16 different blinds that you can put into different rooms, in addition to the "Somfy blind interface" device.

Next, we'll update our Lua code to only create child devices that are specified in the "ID" parameter of the "Somfy blind interface" so that if the user doesn't have 16 devices he can specify just the ones he does have. To make our coding easier, we'll document in the notes for the user that when specifying the list of blinds in the "ID" he must use 01,02, etc., rather than 1,2, etc. because by storing all child devices as 2 digits, we can do a simple search without having to actually parse the ID. In other words, if we want to know if blind #1 is active, we can safely search the ID for 01 and know that it will only match if blind #1 is active. If the user stored single digit blind numbers, like ''5,6,11'' then searching for '1' would give us a false positive and we'd need to write more Lua code to break the list apart. This also makes it easier to send the blind commands because the Somfy protocol says the blind number must be 2 digits, so we won't need to pad the ID's with 0 for the Somfy device. This is why we did the for loop with 16 text strings using string.format which would have given us normal, non-zero-padded numbers.

Put a -- in front of the luup.chdev.append in the window and click 'go' again. -- means "comments" in Lua, and lines starting with -- are ignored. Therefore, by eliminating the luup.chdev.append, now the luup.chdev.sync will remove all 16 children since none were appended. This way we can reload Vera's web UI, go to the devices page, and we won't have those 16 blinds anymore requiring us to provide a room. Click '+' next to the Somfy blind interface, click 'Advanced' and in the BlindIds enter: '02,07,13', click 'save'. Now in the 'Test Luup code' window enter:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID == nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end

local lul_prefix = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_device)
if (lul_prefix == nil) then
lul_prefix = "01"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_prefix, lul_device)
end

luup.log("Somfy ID is " .. lul_ID .. " prefix is " .. lul_prefix)
child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
if (string.find(lul_ID,s) ~= nil) then
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-upnp-org:device:BinaryLight:1", "", "", "", false)
end
end

luup.chdev.sync(lul_device, child_devices)
end

lug_startup(123)
</source>

Don't forget to change the '123' to your actual device number. Now when you click 'go' you'll see the logs indicate we only have 3 blinds with ID's 02, 07 and 13. Since this part of the code is done, you can copy/paste this from the Luup test code window into the implementation. '''IMPORTANT:''' Be sure the ''lug_startup(123)'' is NOT in your implementation file, or else your lug_startup function will be called twice at each startup: once by the Luup engine with the actual device number, and once when the startup functions are loaded into the Lua engine with your hard-coded number used for testing, which won't necessarily correspond to the real device number. We also add the variable lul_prefix because the URTS version 1 takes an ! in the front of every command, whereas with version 2 it's a 2 digit number from 01 to 16. So we'll default to 01, the default value for an URTS version 2, but we'll let the user change it. We'll store this in a global variable, lul_prefix, so it's available for use in the other functions in our plugin.

If you're editing the XML file by hand, you can save your changes and click 'go' in the Luup files upload page in your web browser to upload your changes.

Every time you re-start the Luup engine, such as clicking 'Save', you'll see in the logs this startup sequence.

==Step 5b: Polish up the startup sequence ==

The the startup sequence as it is the user will always think the Somfy module loaded fine, even when it didn't, giving the user a false sense that everything was ok even when he hadn't yet specified basic parameters.

Now, the code first checks for basic startup parameters, which are stored in UPNP variables, and sets them to a default value if they're not already specified. You should at least set them an empty string because by setting them to something then the user will see them in the web user interface and be able to easily change them, as opposed to creating them again from scratch:

<source lang="lua">
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID = nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end
</source>

Next, since this device uses an IO Port (ie a serial port, or an ethernet port, or a usb connection), we should check that the connection is specified and is active before doing the startup:

<source lang="lua">
if (luup.io.is_connected(lul_device) == false) then
luup.log('No port for Somfy', 1)
luup.task('Choose the Serial Port for the URTSI', 2, 'Somfy Blind Interface', -1)
return false
end
</source>

If there's a failure of any kind, we should call luup.task and put in some sort of description with the status code 2 (Error), and then 'return false'. This way the user sees in the web panel that the module 'Somfy Blind Interface' is in an error condition and what the problem is (he didn't choose the serial port). If we didn't do the 'return false', the user would think the Somfy module was ok since, when the startup function doesn't return false, the architecture assumes the module is running fine. If we called return false, didn't call luup.task, then the user see that the module was failing, but would have only a generic "Startup sequence failed" without knowing the explicit reason.

So now the startup sequence looks like this:

<source lang="lua">
function lug_startup(lul_device)
local lul_ID = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_device)
if (lul_ID == nil) then
lul_ID = "01,02"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "BlindIds", lul_ID, lul_device)
end

local lul_prefix = luup.variable_get("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_device)
if (lul_prefix == nil) then
lul_prefix = "01"
luup.variable_set("urn:micasaverde-com:serviceId:SomfyBlinds1", "UrtsiId", lul_prefix, lul_device)
end

luup.log("Somfy ID is " .. lul_ID .. " prefix is " .. lul_prefix)

if (luup.io.is_connected(lul_device) == false) then
luup.log('No port for Somfy', 1)
luup.task('Choose the Serial Port for the URTSI',2,'Somfy Blind Interface', -1)
return false
end

child_devices = luup.chdev.start(lul_device);
for i = 1,16 do
s = string.format("%02d", i)
if (string.find (lul_ID,s) ~= nil) then
luup.log("Adding blind " .. s)
luup.chdev.append(lul_device, child_devices, s, "Blind #" .. s, "urn:schemas-micasaverde-com:device:WindowCovering:1", "D_WindowCovering1.xml", "", "", false)
end
end

luup.chdev.sync(lul_device, child_devices)
end
</source>

==Step 6a: Implementation the actions in the web generator ==

--coming soon--

==Step 6b: Implementation the actions in the xml file ==

The reason we added the ''<handleChildren>1</handleChildren>'' tag to the Somfy blind interface's device file earlier is because we're going to put all the actions for the child devices (the blinds) within the main implementation file for the Somfy. So, whenever an action comes in for a child device (a blind), the Lua code in the parent devices implementation file will handle it. Replace the actionList tag in the implementation file with this:

<source lang="xml">
<actionList>
<action>
<serviceId>urn:upnp-org:serviceId:SwitchPower1</serviceId>
<name>SetTarget</name>
<run>
local lul_command = lul_prefix .. luup.devices[lul_device].id .. 'U\r'
local lul_reverse = luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "ReverseOnOff", lul_device)

if (lul_settings.newTargetValue == "1" or (lul_settings.newTargetValue == "0" and lul_reverse == "1")) then
lul_command = lul_prefix .. luup.devices[lul_device].id .. 'D\r'
end

if (luup.io.write(lul_command) == false) then
luup.log("cannot send: " .. tostring(lul_command),1)
luup.set_failure(true)
return false
end
</run>
</action>
</actionList>
</source>

This provides the implementation or the SetTarget UPnP action, which is what is sent when the user clicks 'on' or 'off' for a light switch, or 'open' or 'close' for blinds. We store the command to send in the variable lul_command and put the 'local' keyword in front so the variable is only available while the 'SetTarget' action is running. We also check the HADevice service's ReverseOnOff value. As a convention in Luup, we created this as a common service that all home automation devices have, and the ReverseOnOff variable, if true, means reverse the usual on/off behavior, so on is off and off is on. We did this because it's not uncommon for binary switches, particularly blinds, to be wired the wrong way, or for it to be subjective which position is on vs. off. This way the user can add this variable for his configuration if the operation is backwards from what he would expect. lu_SetCommFailure sets a "communication failure" flag for the device, which logs a critical error, and allows the user to see that the device is having problems. Whenever the Luup engine reloads, such as clicking 'save', the flag is cleared again.

Now when you click 'on' or 'off' for the blinds you'll see in the log it is sending the corresponding data to the blinds.

Luup Variables

2011-09-04T22:12:55Z

Guessed: /* Other Devices or Services */ Add Lua syntax coloring

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

Device category: 3, UPnP device id: urn:schemas-upnp-org:device:BinaryLight:1

Variables:

Service: ''urn:upnp-org:serviceId:SwitchPower1'' Variable name: ''Status''

If the device is on, the value is 1, otherwise it's 0.

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

==Thermostat==

Device category: 5, UPnP device id: urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1

Variables:

Service: ''urn:upnp-org:serviceId:HVAC_UserOperatingMode1'' Variable name: ''ModeStatus''

This indicates the current operating mode and will be one of the following basic values: Off, HeatOn, CoolOn, AutoChangeOver. In addition to the basic modes, some thermostats may also support the following modes: InDeadBand, AuxHeatOn, EconomyHeatOn, EmergencyHeatOn, AuxCoolOn, EconomyCoolOn, BuildingProtection, EnergySavingsHeating, EnergySavingsCooling

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat'' Variable name: ''CurrentSetpoint''

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool'' Variable name: ''CurrentSetpoint''

These indicate the current heat/cool set points.

Service: ''urn:upnp-org:serviceId:TemperatureSensor1'' Variable name: ''CurrentTemperature''

This indicates the current ambient temperature.

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

<source lang="lua">
-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)
</source>

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===
For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene:
<source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37''
Line 2 compares the returned variable to ''Showers''
If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level)
Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene ever xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Variables

2011-09-04T22:11:30Z

Guessed: /* Weather Plugin */ Add Lua syntax coloring

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

Device category: 3, UPnP device id: urn:schemas-upnp-org:device:BinaryLight:1

Variables:

Service: ''urn:upnp-org:serviceId:SwitchPower1'' Variable name: ''Status''

If the device is on, the value is 1, otherwise it's 0.

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

==Thermostat==

Device category: 5, UPnP device id: urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1

Variables:

Service: ''urn:upnp-org:serviceId:HVAC_UserOperatingMode1'' Variable name: ''ModeStatus''

This indicates the current operating mode and will be one of the following basic values: Off, HeatOn, CoolOn, AutoChangeOver. In addition to the basic modes, some thermostats may also support the following modes: InDeadBand, AuxHeatOn, EconomyHeatOn, EmergencyHeatOn, AuxCoolOn, EconomyCoolOn, BuildingProtection, EnergySavingsHeating, EnergySavingsCooling

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat'' Variable name: ''CurrentSetpoint''

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool'' Variable name: ''CurrentSetpoint''

These indicate the current heat/cool set points.

Service: ''urn:upnp-org:serviceId:TemperatureSensor1'' Variable name: ''CurrentTemperature''

This indicates the current ambient temperature.

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)

From this we can get the Current Weather Condition using 
Service: ''urn:upnp-micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===
For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene:
<source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-micasaverde-com:serviceId:Weather1", "Condition", 37)
if (lul_tmp == "Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "50"}, 19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "0"}, 19)
end
</source>

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:upnp-micasaverde-com:serviceId:Weather1'' on Device #''37''
Line 2 compares the returned variable to ''Showers''
If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level)
Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene ever xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Luup Scenes Events

2011-09-04T20:52:29Z

Guessed: /* Samples */ Lua color coding

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if (tonumber(lul_temp) < 26.6) then
return false
end
</source>

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if ((tonumber(lul_temp) < 26.6
and tonumber(lul_temp) > 25)
or tonumber(lul_temp) < 23) then
return false
end
</source>

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

<source lang="lua">
return luup.is_night() == false
</source>

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

<source lang="lua">
if (luup.is_night()) then
return false
else
return true
end
</source>

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "1"}, 5)
</source>

====Turn an appliance switch or a Danfoss thermostat off====

<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTargetValue = "0"}, 5)
</source>

====Do something if switch device #5 is on====

<source lang="lua">
local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 5)
if (lul_tmp == "1") then
--something to do goes here
end
</source>

====Dim switch #6 to 30%====

<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", {newLoadlevelTarget = "30"}, 6)
</source>

====Arm motion sensor #7====

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", "1", 7)
</source>

====Disarm motion sensor #7====

<source lang="lua">
luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", "0", 7)
</source>

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

<source lang="lua">
luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1", "RunScene", {SceneNum = "5"}, 0)
</source>

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", {NewCurrentSetpoint = "68"},
19)
</source>

====Change the Temperature on a Thermostat (Heat) device #19====
<source lang="lua">
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint", {NewCurrentSetpoint = "68"},
19)
</source>

===='Privacy' mode for Foscam FI8908[w]====

<source lang="lua">
local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()
luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=0', timeout, username, password)
end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=25', timeout, username, password)

luup.call_delay('move_up', 120)
</source>

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

<source lang="lua">
os.date (format, time)
</source>

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

<source lang="lua">
t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}
</source>

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

<source lang="lua">
os.date('*t').hour
</source>

Current minute:

<source lang="lua">
os.date('*t').min
</source>

Current second:

<source lang="lua">
os.date('*t').sec
</source>

Do something between 16:00 and 21:15:

<source lang="lua">
local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds) then
-- do something
else
return false
end
</source>

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Scenes Events

2011-09-04T20:47:01Z

Guessed: /* Access the current time */ Lua color coding.

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if (tonumber(lul_temp) < 26.6) then
return false
end
</source>

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if ((tonumber(lul_temp) < 26.6
and tonumber(lul_temp) > 25)
or tonumber(lul_temp) < 23) then
return false
end
</source>

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

<source lang="lua">
return luup.is_night() == false
</source>

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

<source lang="lua">
if (luup.is_night()) then
return false
else
return true
end
</source>

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

====Turn an appliance switch or a Danfoss thermostat off====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },5)

====Do something if switch device #5 is on====

local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",5)
if( lul_tmp=="1" ) then
--something to do goes here
end

====Dim switch #6 to 30%====

luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="30" },6)

====Arm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","1",7)

====Disarm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","0",7)

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="5" }, 0)

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", { NewCurrentSetpoint="68" },
19)

====Change the Temperature on a Thermostat (Heat) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint",{ NewCurrentSetpoint="68" },
19)

===='Privacy' mode for Foscam FI8908[w]====

<source lang="lua">
local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()
luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=0', timeout, username, password)
end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=25', timeout, username, password)

luup.call_delay('move_up', 120)
</source>

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

<source lang="lua">
os.date (format, time)
</source>

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

<source lang="lua">
t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}
</source>

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

<source lang="lua">
os.date('*t').hour
</source>

Current minute:

<source lang="lua">
os.date('*t').min
</source>

Current second:

<source lang="lua">
os.date('*t').sec
</source>

Do something between 16:00 and 21:15:

<source lang="lua">
local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds) then
-- do something
else
return false
end
</source>

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Scenes Events

2011-09-04T20:43:33Z

Guessed: /* Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees */ Lua color coding

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if (tonumber(lul_temp) < 26.6) then
return false
end
</source>

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

<source lang="lua">
local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 3)
if ((tonumber(lul_temp) < 26.6
and tonumber(lul_temp) > 25)
or tonumber(lul_temp) < 23) then
return false
end
</source>

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

<source lang="lua">
return luup.is_night() == false
</source>

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

<source lang="lua">
if (luup.is_night()) then
return false
else
return true
end
</source>

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

====Turn an appliance switch or a Danfoss thermostat off====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },5)

====Do something if switch device #5 is on====

local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",5)
if( lul_tmp=="1" ) then
--something to do goes here
end

====Dim switch #6 to 30%====

luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="30" },6)

====Arm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","1",7)

====Disarm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","0",7)

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="5" }, 0)

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", { NewCurrentSetpoint="68" },
19)

====Change the Temperature on a Thermostat (Heat) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint",{ NewCurrentSetpoint="68" },
19)

===='Privacy' mode for Foscam FI8908[w]====

<source lang="lua">
local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()
luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=0', timeout, username, password)
end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=25', timeout, username, password)

luup.call_delay('move_up', 120)
</source>

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

os.date (format, time)

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

os.date('*t').hour

Current minute:

os.date('*t').min

Current second:

os.date('*t').sec

Do something between 16:00 and 21:15:

local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds)
then
-- do something
else
return false
end

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Scenes Events

2011-09-04T20:40:50Z

Guessed: /* Walk-through #2 -- Only run the scene during the daytime */ Add the Lua syntax highlighting

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( tonumber(lul_temp)<26.6 ) then
return false
end

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( (tonumber(lul_temp)<26.6
and tonumber(lul_temp)>25)
or tonumber(lul_temp)<23 ) then
return false
end

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

<source lang="lua">
return luup.is_night() == false
</source>

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

<source lang="lua">
if (luup.is_night()) then
return false
else
return true
end
</source>

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

====Turn an appliance switch or a Danfoss thermostat off====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },5)

====Do something if switch device #5 is on====

local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",5)
if( lul_tmp=="1" ) then
--something to do goes here
end

====Dim switch #6 to 30%====

luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="30" },6)

====Arm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","1",7)

====Disarm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","0",7)

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="5" }, 0)

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", { NewCurrentSetpoint="68" },
19)

====Change the Temperature on a Thermostat (Heat) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint",{ NewCurrentSetpoint="68" },
19)

===='Privacy' mode for Foscam FI8908[w]====

<source lang="lua">
local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()
luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=0', timeout, username, password)
end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=25', timeout, username, password)

luup.call_delay('move_up', 120)
</source>

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

os.date (format, time)

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

os.date('*t').hour

Current minute:

os.date('*t').min

Current second:

os.date('*t').sec

Do something between 16:00 and 21:15:

local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds)
then
-- do something
else
return false
end

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Scenes Events

2011-09-04T20:38:42Z

Guessed: /* 'Privacy' mode for Foscam FI8908[w] */ Add the tags for Lua source code highlighting.

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( tonumber(lul_temp)<26.6 ) then
return false
end

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( (tonumber(lul_temp)<26.6
and tonumber(lul_temp)>25)
or tonumber(lul_temp)<23 ) then
return false
end

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

return luup.is_night()==false

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

if( luup.is_night() ) then
return false
else
return true
end

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

====Turn an appliance switch or a Danfoss thermostat off====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },5)

====Do something if switch device #5 is on====

local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",5)
if( lul_tmp=="1" ) then
--something to do goes here
end

====Dim switch #6 to 30%====

luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="30" },6)

====Arm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","1",7)

====Disarm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","0",7)

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="5" }, 0)

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", { NewCurrentSetpoint="68" },
19)

====Change the Temperature on a Thermostat (Heat) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint",{ NewCurrentSetpoint="68" },
19)

===='Privacy' mode for Foscam FI8908[w]====

<source lang="lua">
local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()
luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=0', timeout, username, password)
end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget('http://' .. IP_address .. '/decoder_control.cgi?command=25', timeout, username, password)

luup.call_delay('move_up', 120)
</source>

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

os.date (format, time)

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

os.date('*t').hour

Current minute:

os.date('*t').min

Current second:

os.date('*t').sec

Do something between 16:00 and 21:15:

local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds)
then
-- do something
else
return false
end

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Scenes Events

2011-09-04T20:33:27Z

Guessed: /* Invoke HTTP URL with GET request (Method 2) */

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( tonumber(lul_temp)<26.6 ) then
return false
end

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( (tonumber(lul_temp)<26.6
and tonumber(lul_temp)>25)
or tonumber(lul_temp)<23 ) then
return false
end

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

return luup.is_night()==false

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

if( luup.is_night() ) then
return false
else
return true
end

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

====Turn an appliance switch or a Danfoss thermostat off====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },5)

====Do something if switch device #5 is on====

local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",5)
if( lul_tmp=="1" ) then
--something to do goes here
end

====Dim switch #6 to 30%====

luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="30" },6)

====Arm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","1",7)

====Disarm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","0",7)

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="5" }, 0)

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", { NewCurrentSetpoint="68" },
19)

====Change the Temperature on a Thermostat (Heat) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint",{ NewCurrentSetpoint="68" },
19)

===='Privacy' mode for Foscam FI8908[w]====

local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()

luup.inet.wget( 'http://'..IP_address..'/decoder_control.cgi?command=0' , timeout, username, password )

end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget( 'http://'..IP_address..'/decoder_control.cgi?command=25', timeout, username, password )

luup.call_delay( 'move_up', 120 )

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with <tt>GET</tt> request (Method 1) ====
<source lang="lua">
-- 5 Second timeout
local status, result = luup.inet.wget("http://www.yahoo.com", 5)
</source>

==== Invoke HTTP URL with <tt>GET</tt> request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')

-- 5 Second timeout
socket.http.TIMEOUT = 5

local response_body = {}
local request_body = ''

local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

==== Invoke HTTP URL with <tt>POST</tt> request (Method 3) ====
<source lang="lua">
local http = require("socket.http")

-- 5 Second timeout
http.TIMEOUT = 5

-- The return parameters are in a different order from luup.inet.wget(...)
result, status = http.request("http://192.168.0.113/runprocess.htm", "run=run")
</source>

=== Access the current time ===

The Lua function

os.date (format, time)

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

os.date('*t').hour

Current minute:

os.date('*t').min

Current second:

os.date('*t').sec

Do something between 16:00 and 21:15:

local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds)
then
-- do something
else
return false
end

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup Scenes Events

2011-09-04T20:19:15Z

Guessed: /* Invoke URL by GET request */ Show using Lua color coding, break out as "method 2" for GET so we can accomodate regular luup.inet.wget style also.

[[Category:Development]]
== Adding Lua code to scenes and events ==
[[Image:SceneFlowchart.png]]

You can add Lua script to scenes and events for simple tasks, like making a scene or event conditional. Conditional meaning "do something only '''if''' some condition is met", such as attaching a condition to your "Come Home" scene so it is only run '''if''' the temperature is over 70 degrees. Basic conditional expressions are easy, and, if that's all you're looking to do, skip to the walk-through below.

If you're more technically inclined you can also do very advanced things too. For an overview of all the advanced things you can do with Vera's Luup engine, and how scenes and events fit in, see the [[Luup_Intro]] page.

To add Lua code to a scene, create the [[Scenes]] and click 'Luup scene'. Fill in your Lua code in the input box. To do a simple condition, see the sample below. Or if you want to do advanced scripting you can use any [[http://lua.org Lua]] commands as described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]] as well as the variables and functions that the Luup engine adds to Lua documented here: [[Luup_Lua_extensions]]. The Lua code will be run every time the scene is activated either by the user or a scene or a timer. The Lua code is run before the commands that you included in the scene. If your Lua code ends with this: "return false" then the commands in the scene will not be run.

You can also add Lua code to an event by clicking 'Luup event'. Since events are attached to scenes anyway, there is usually little difference between adding the code to an event, or to the scene the event is part of. If the Lua code in an event returns false, then the event is aborted, meaning the scene that the event is attached to will not be triggered by the event. The main reason for attaching Lua code to an event is if you have multiple events to a scene. For example, you may have a scene called "Turn lights on in hallway" which is triggered by 2 events: 1) The front door opens, and 2) the motion sensor in the hallway is tripped. Perhaps whenever the front door opens you always want the scene to be activated, but you only want the motion sensor to activate the scene before 10:00. In this case, you would add Lua code to the motion sensor's event which does something like (pseudo-code): "if time>10:00 return false". That way the event from the motion sensor will be aborted if it's after 10:00, but the event from the front door will always activate the scene regardless.

When you edit the Lua code in a scene or event you must click 'Save' before the code is saved. Then you can activate the scene or trigger the event to see what happens when your code is run. If you're doing some advanced scripting that you'll need to debug this can be tedious, but there are easy ways to test your Lua script immediately without saving first as explained in [[Lua_Debugging]].

If you're doing advanced Lua scripting, you should note that all the Lua code in your scenes and events run in a single Lua instance, which is separate from any Lua plugins. This means if you set a global variable in one scene, or create a function inside the Lua code in a scene, then in another scene's Lua code you can use that global variable or call that function. You do not need to worry about conflicting with a Luup plugin, though, since they have their own Lua instance, meaning they have their own global variables and functions.

== Walk-through #1 -- At 12 noon, turn off the interior lights if the temperature is over 80 degrees ==

Before you start, in Vera's setup interface go to 'Devices' and click the '+' button next to the thermostat. Make note of the Device #.

In this walkthrough we'll assume it's Device #3, but use the actual device number of''your'' thermostat. Next, visit [[Luup Variables]] to get a list of all the variables for devices. A variable is a piece of information about the current state of a device, such as whether it's on or off, it's current temperature, etc.

Look down at ''Thermostat'', and copy the name of the service/variable which corresponds to the current temperature, namely. In this case, it's

urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature

Notice that it states the <tt>CurrentTemperature</tt> is in Celsius. So type in "80 degrees Fahrenheit to Celsius" in Google and you'll see that it's 26.6 degrees Celsius.

Now, the first step is to create the scene that turns off the lights. In Vera's setup interface, click 'Scenes', and click 'Add Scene' to add a new scene to one of the rooms. It's not important which room you choose. Scenes are categorized in rooms just to help you keep track of them if you have a lot of scenes. You can also put the scene in 'Global Scenes', or, you can create dummy rooms on the 'Rooms' tab if you want to have more "rooms" to organize your scenes with. After you click 'Add Scene', type in a description to remember your scene by, such as "Lights off 12:00 if 80". Under the 'Commands' area you'll see all the rooms. Click '+' next to the rooms that have lights you want to control, and choose "Off" in the pull-down. At this point, you have a normal scene, and, if you were to save your changes now, whenever you click the scene on the dashboard or on a remote control, the lights should turn off.

Second, next to the scene's description click 'add timer'. You can give the timer a description too so that if you have multiple timers you can see in the logs which one is activating the scene. Choose "Day of week based". If you want this scene to only run on certain days of the week, just check off which days you want this scene to run on. Otherwise, you can leave them all unchecked (or check them all) to do it every day. Leave the pull-down at "a certain time of day", and choose 12 : 00 : 00 from the pull-downs. At this point, if you were to save your changes, the lights would turn off automatically at 12 noon.

Third, the last step is to add the condition. To the right of the scene's description you'll see the button "Luup Scene". Click it and in the code box, copy and paste the following:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( tonumber(lul_temp)<26.6 ) then
return false
end

Don't forget to change the "3" to whatever is the actual device number of your thermostat. Assign the result of <tt>luup.variable_get</tt> to a variable first, rather than putting it directly in the <tt>tonumber()</tt>, because <tt>luup.variable_get</tt> actually returns 2 values: the value of the variable, and the time when the variable was modified. The '<tt>tonumber</tt>' is needed because all of a device's variables are stored as plain text--not numbers--so if you want to do arithmetic or numeric comparison of a variable, you need to put <tt>tonumber()</tt> around <tt>luup.variable_get</tt>.

<tt>luup.variable_get</tt> is documented in [[Luup Lua extensions]].

Now click 'Update', and then click 'Save' to save everything. The "return false" means "don't run this scene". So if the current temperature is <26.6, the scene will be aborted and won't run. The timer will make it trigger every day at 12 noon.

To test it, you can click the scene button on the dashboard. The lights will turn off only if the temperature is over 80 degrees. If it's less than 80 degrees, the scene won't do anything. Since this scene is something that happens automatically and you probably won't execute manually, you can go to the scene again and check the "Hidden" box so the scene doesn't show up on Vera's 'Dashboard' and on your remote controls, like the iPhone. If you want to have a scene that turns off the lights which you can run whenever you want from 'Dashboard'' or your remote control, you should create another scene that has the same commands and simply don't add the timers and Luup conditions, and don't check the "Hidden" box.

You can substitute other service/variables and device ID's to make other types of conditions. The "if" statement above also supports nesting with ( and ), as well as the keywords 'and' and 'or'. So the following means the scene would abort if the temperature is <26.6 and >25, unless it's <23:

local lul_temp=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",3)
if( (tonumber(lul_temp)<26.6
and tonumber(lul_temp)>25)
or tonumber(lul_temp)<23 ) then
return false
end

If the scene doesn't run, it's possible there is a syntax error. The easiest way to test this is to copy the Lua code from the scene, then go to Devices, Luup Plugins, and "Test Luup code". Paste the code in the box and click 'go'. If the info box above the 'go' button has a check and says "Message sent successful", your code is okay. If there's an error, it says: "Code failed".

To see if that's true, use putty, or telnet or ssh to log-in to Vera, as explained in detail in [[Lua Debugging]], and type:

cd /var/log/cmh
tail -f LuaUPnP.log | grep '^01'

Now click 'Save' in Vera's setup page, even if it's gray, as that will cause Vera to restart the Luup engine and log any syntax errors. See: [[Lua Debugging]] for in-depth details on how to debug.

== Walk-through #2 -- Only run the scene during the daytime ==

In the Luup tab for the scene paste this:

return luup.is_night()==false

That works because if the return is 'true' the scene runs, and if it's 'false' it doesn't. So during the daytime the expression is true. Or, an alternative long form:

if( luup.is_night() ) then
return false
else
return true
end

== Samples ==

This page is a wiki which anyone can edit. If you have some Lua code you think other users might find useful, feel free to add it here.

=== Misc actions ===

Did you see the sample here already: http://wiki.micasaverde.com/index.php/Luup_Scenes_Events

====Turn an appliance switch or a Danfoss thermostat on for device #5====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

====Turn an appliance switch or a Danfoss thermostat off====

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="0" },5)

====Do something if switch device #5 is on====

local lul_tmp = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",5)
if( lul_tmp=="1" ) then
--something to do goes here
end

====Dim switch #6 to 30%====

luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="30" },6)

====Arm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","1",7)

====Disarm motion sensor #7====

luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","Armed","0",7)

Note, arming and disarming isn't a concept within UPnP or Z-Wave. It's just a flag that the Luup engine uses, and is stored in a variable we created called "Armed".

====Run Scene #5====

Thanks "denix" on the forum for the correct syntax.
"Actually, the 4th parameter IS required, but it's not used. Otherwise the command fails with an error message"

luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="5" }, 0)

In this case we left the device number off (the 4th parameter to <tt>luup.call_action</tt>), because the "<tt>RunScene</tt>" action is handled by the Luup engine itself--not by some device within Z-Wave, etc.

However, normally you don't need to <tt>luup.call_action</tt> in Lua code. Rather, whatever actions, or commands, you want to run, you put into the scene itself, and the only Lua code is to simply check if some condition is true and abort the scene if the condition isn't met.

====Change the Temperature on Thermostat (Cool) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
"SetCurrentSetpoint", { NewCurrentSetpoint="68" },
19)

====Change the Temperature on a Thermostat (Heat) device #19====
luup.call_action("urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
"SetCurrentSetpoint",{ NewCurrentSetpoint="68" },
19)

===='Privacy' mode for Foscam FI8908[w]====

local IP_address = '<IP address of camera>'
local username = '<username>'
local password = '<password>'
local timeout = 5

function move_up()

luup.inet.wget( 'http://'..IP_address..'/decoder_control.cgi?command=0' , timeout, username, password )

end

-- center the camera; takes some time, so we have to wait 2 minutes for the command to complete

luup.inet.wget( 'http://'..IP_address..'/decoder_control.cgi?command=25', timeout, username, password )

luup.call_delay( 'move_up', 120 )

====Blinking lights====

http://forum.micasaverde.com/index.php?topic=5127.0

====Playing an announcement====

http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405

=== Calculate sunrise and sunset ===

See http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132

... or use DAD: http://forum.micasaverde.com/index.php?topic=5466.0

=== Access the web ===
==== Invoke HTTP URL with GET request (Method 2) ====
Based on code by Jim/jgc94131
<source lang="lua">
require('ltn12')
local http = require('socket.http')
local response_body = {}
local request_body = ''
socket.http.TIMEOUT = 4
local r, c, h = socket.http.request{
url = 'http://website/page?parameter1=value&parameter2=value',
method = "GET",
port = 80,
headers = {
["Content-Length"] = string.len(request_body),
["Content-Type"] = "application/x-www-form-urlencoded"
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
</source>

=== Access the current time ===

The Lua function

os.date (format, time)

converts a time value `time` into a human readable date/time string, according to `format`. If you leave out the optional `time` parameter, it defaults to current time. The `format` parameter defaults to a fairly complete format. If you specify '*t' as the format, it will return a table instead of a formatted string.

t = os.date('*t')
t => {year=2010, month=2, day=19, yday=50, wday=6, hour=22, min=45, sec=45, isdst=false}

The fields are year, month, day of month, day of year, day of week, hour in 24 hour clock, minutes, seconds and if it's Daylight Savings Time.

Current hour:

os.date('*t').hour

Current minute:

os.date('*t').min

Current second:

os.date('*t').sec

Do something between 16:00 and 21:15:

local t = os.date('*t')
local current_second = t.hour * 3600 + t.min * 60 + t.sec -- number of seconds since midnight
local min_time_in_seconds = 16 * 3600 + 0 * 60 -- 16:00
local max_time_in_seconds = 21 * 3600 + 15 * 60 -- 21:15

if (current_second > min_time_in_seconds) and (current_second < max_time_in_seconds)
then
-- do something
else
return false
end

See http://forum.micasaverde.com/index.php?topic=2015.0 and http://www.lua.org/manual/5.1/manual.html#5.8.

=== Set Z-Wave parameters ===

See http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803

=== a scene if the temperature is outside of a range ===

add snippets here...

Luup plugins and Luup code

2011-08-28T01:56:51Z

Guessed: /* Alphabetical list of all Luup plugins, Luup code fragments and Vera clients */ Add Brultech Energy Monitoring Plugin

[[Category:Development]]
[[Category:Plugins]]

= '''All Luup plugins, Luup code fragments and Vera clients by category''' =

== '''Alarm System integration''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Ademco Honeywell Vista 20P Alarm Plugin
| 
| plugin
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4531.0]
| 
| N/A
| 
|-
| DSC Alarm Panel
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| GE Caddx Networx NX-584 NX-8E Alarm Plugin
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
|-
| Paradox Alarm Plugin
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
|}

 

== '''Development''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
|}

 

== '''Energy management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
|-
| Trane Thermostats
| 
| plugin
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
|}

 

== '''Home Entertainment management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Denon Receiver Control Plugin
| 
| plugin
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
|-
| Learning IR codes
| 
| Windows application
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| MCV
| 
| 
| 
| 
| 
| N/A
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
|-
| Sending IR codes
| 
| code
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
|-
| TiVo
| 
| 
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
|}

 

== '''Interfacing''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| [http://forum.micasaverde.com/index.php?topic=6007.0]
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
|}

 

== '''Monitoring''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| MCV
| 
| IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| [http://wiki.micasaverde.com/index.php/ICamView]
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|}

 

== '''Notifications''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=1412.0]
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
|}

 

== '''System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ADD
| Alerter for Drowsy Devices
| code
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| cf. Battery low notification
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| cf. ADD
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| based on 'Z-Wave routing matrix' by Ap15e
|-
| LSI
| Luup System Information
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
|-
| Z-Wave routing matrix
| 
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
|}

 

== '''Temperature or Weather measurement''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
|}

 

== '''UI''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled rece
| client
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| MCV
| 
| 
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Elisa
| Control device locally and remote
| client
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
|}

 

== '''Utility''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
|-
| Closing a window shutter partially
| 
| code
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| TedStriker
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| 
| Working
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| [http://forum.micasaverde.com/index.php?topic=5609.0]
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
|-
| Slowly dim your lights
| 
| code
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| cf. WakeupRamp
|-
| Sunrise/sunset
| 
| code
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| cf. Slowly dim your lights
|-
| Wavemaking
| 
| code
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
|}

 

== '''Watering System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
|}

 

= '''Alphabetical list of all Luup plugins, Luup code fragments and Vera clients''' =

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Category
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Unique MCVID
! Remarks
! Screenshot
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| Interfacing
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
| 
| 
|-
| ADD
| Alerter for Drowsy Devices
| code
| System management
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| 
| cf. Battery low notification
| 
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| UI
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
| 
| 
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| Utility
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled receivers.
| client
| UI
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
| 
| 
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| Energy management
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| UI
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| UI
| MCV
| 
| 
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| System management
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| 
| cf. ADD
| 
|-
| Brultech Power Monitor
| Energy Monitoring integration for Brultech ECM-1240 devices.
| plugin
| Energy management
| guessed
| 
| Brultech ECM-1240
| 
| [http://forum.micasaverde.com/index.php?topic=7589.0]
| [http://code.mios.com/trac/mios_brultech-power-monitor]
| Working
| 
| 
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
| 
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| Utility
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
| 
| 
|-
| Closing a window shutter partially
| 
| code
| Utility
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Interfacing
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
| 
| 
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Utility
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| 
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
| 
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| System management
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| 
| based on 'Z-Wave routing matrix' by Ap15e
| 
|-
| Denon Receiver Control Plugin
| 
| plugin
| Home Entertainment management
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
| 
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| Home Entertainment management
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#DSC_PowerSeries_Panels|DSC Alarm Panel ]]
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Alarm System integration
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Elisa
| Control device locally and remote
| client
| UI
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
| 
| 
|-
| Elk M1 Family Panels 
| Integration with the Elk M1 alarm panels via the RS232 port.
| plugin 
| Alarm System integration
| mcvflorin 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6916.0] 
| [http://code.mios.com/trac/mios_elk-alarm-panel] 
| Working 
| 
| 
| 
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| Notifications
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
| 
| 
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| Utility
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Energy management
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| Interfacing
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
| 
| 
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| Watering System management
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
| 
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Utility
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| 
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
| 
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| Monitoring
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
| 
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Monitoring
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
| 
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| Utility
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#GE.2FCaddx_NetworX_Panels|GE Caddx NetworX NX-584 NX-8E Alarm Plugin]]
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| Alarm System integration
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
| 
| 
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| Monitoring
| MCV
| 
| IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
| 
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Development
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| Interfacing
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| Utility
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| UI
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
| 
| 
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Temperature or Weather measurement
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
| 
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| Home Entertainment management
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| Utility
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
| 
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| UI
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
| 
| 
|-
| Honeywell Ademco Vista Panels via AD2USB
| Integration with Honeywell's Ademco Vista panels via the AD2USB adapter.
| plugin
| Alarm System integration
| mcvflorin 
| 
| AD2USB Adapter 
| 
| [http://forum.micasaverde.com/index.php?topic=7266.0]
| [http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb] 
| Beta
| 
| 
| 
|-
| Honeywell Ademco Vista Panels with RS232 
| Integration with Honeywell's Ademco Vista panels with a RS232 interface.
| plugin
| Alarm System integration
| dfad1469
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6626.0]
| [http://code.mios.com/trac/mios_ademco-panels-plugin]
| Working
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| UI
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
| 
| 
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| Monitoring
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/ICamView]
| 
|-
| IO Relay Plugin
| This component permits the control of Relay and Analog IO boards from IORelay.com (National Control Devices). Controls up to 8 Relays and 8 Analog inputs.
| plugin
| Interfacing
| guessed
| 
| ProXR, ProXR Lite, Reactor Relay board from iorelay.com
| 
| [http://forum.micasaverde.com/index.php?topic=7589.0]
| [http://code.mios.com/trac/mios_iorelay]
| Working
| 
| 
| 
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| Interfacing
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
| 
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Home Entertainment management
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
| 
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| UI
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| UI
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
| 
| 
|-
| Learning IR codes
| 
| Windows application
| Home Entertainment management
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
| 
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Interfacing
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Home Entertainment management
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
| 
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| Home Entertainment management
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
| 
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Utility
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
| 
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| UI
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
| 
| 
|-
| LSI
| Luup System Information
| plugin
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
| 
| 
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Interfacing
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| Development
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
| 
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| 
| 
| N/A
| 
| 
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| Interfacing
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| 
| [http://forum.micasaverde.com/index.php?topic=6007.0]
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| System management
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
| 
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| Home Entertainment management
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
| 
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| Home Entertainment management
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
| 
| 
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| Monitoring
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| Home Entertainment management
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#Paradox_EVO_Panels|Paradox Alarm Plugin]]
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| Alarm System integration
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
| 
| 
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| Interfacing
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| Utility
| TedStriker
| guessed, Henk
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| [http://code.mios.com/trac/mios_ping-sensor]
| Working
| 
| 
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| Notifications
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
| 
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| Utility
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
| 
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| 
| [http://forum.micasaverde.com/index.php?topic=5609.0]
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| System management
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
| 
| 
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| Interfacing
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Interfacing
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
| 
| 
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Utility
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
| 
| 
|-
| Sending IR codes
| 
| code
| Home Entertainment management
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| 
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
| 
|-
| Slowly dim your lights
| 
| code
| Utility
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| 
| cf. WakeupRamp
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| UI
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Notifications
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
| 
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| Interfacing
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| UI
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
| 
| 
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| Home Entertainment management
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
| 
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| Home Entertainment management
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Home Entertainment management
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
| 
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| Home Entertainment management
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
| 
| 
|-
| Sunrise/sunset
| 
| code
| Utility
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
| 
| 
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| Energy management
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
| 
| 
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| Interfacing
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
| 
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| Utility
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
| 
| 
|-
| TiVo
| 
| 
| Home Entertainment management
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
| 
|-
| Trane Thermostats
| 
| plugin
| Energy management
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
| 
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| Notifications
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=1412.0]
| 
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| Notifications
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
| 
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| Notifications
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
| 
| 
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
| 
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Utility
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| UI
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
| 
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| Notifications
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
| 
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| Utility
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
| 
| 
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
| 
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| Utility
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
| 
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| Utility
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| 
| cf. Slowly dim your lights
| 
|-
| Wavemaking
| 
| code
| Utility
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
| 
| [http://forum.micasaverde.com/index.php?action=dlattach;topic=5865.0;attach=1826;image]
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| Temperature or Weather measurement
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
| 
| 
|-
| Z-Wave routing matrix
| 
| code
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
| 
|}

 

= '''Sources''' =

Sources: http://forum.micasaverde.com/ http://code.mios.com/ http://wiki.micasaverde.com/index.php/Luup_Projects http://forum.micasaverde.com/index.php?topic=6280.msg40147#msg40147 http://www.micasaverde.com/list-of-apps.php 

 

= '''Todo''' =

Luup plugins and Luup code

2011-08-28T01:51:00Z

Guessed: /* Alphabetical list of all Luup plugins, Luup code fragments and Vera clients */ Updated Ping sensor contributors and pointer to code repository.

[[Category:Development]]
[[Category:Plugins]]

= '''All Luup plugins, Luup code fragments and Vera clients by category''' =

== '''Alarm System integration''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Ademco Honeywell Vista 20P Alarm Plugin
| 
| plugin
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4531.0]
| 
| N/A
| 
|-
| DSC Alarm Panel
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| GE Caddx Networx NX-584 NX-8E Alarm Plugin
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
|-
| Paradox Alarm Plugin
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
|}

 

== '''Development''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
|}

 

== '''Energy management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
|-
| Trane Thermostats
| 
| plugin
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
|}

 

== '''Home Entertainment management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Denon Receiver Control Plugin
| 
| plugin
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
|-
| Learning IR codes
| 
| Windows application
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| MCV
| 
| 
| 
| 
| 
| N/A
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
|-
| Sending IR codes
| 
| code
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
|-
| TiVo
| 
| 
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
|}

 

== '''Interfacing''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| [http://forum.micasaverde.com/index.php?topic=6007.0]
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
|}

 

== '''Monitoring''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| MCV
| 
| IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| [http://wiki.micasaverde.com/index.php/ICamView]
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|}

 

== '''Notifications''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=1412.0]
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
|}

 

== '''System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ADD
| Alerter for Drowsy Devices
| code
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| cf. Battery low notification
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| cf. ADD
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| based on 'Z-Wave routing matrix' by Ap15e
|-
| LSI
| Luup System Information
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
|-
| Z-Wave routing matrix
| 
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
|}

 

== '''Temperature or Weather measurement''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
|}

 

== '''UI''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled rece
| client
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| MCV
| 
| 
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Elisa
| Control device locally and remote
| client
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
|}

 

== '''Utility''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
|-
| Closing a window shutter partially
| 
| code
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| TedStriker
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| 
| Working
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| [http://forum.micasaverde.com/index.php?topic=5609.0]
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
|-
| Slowly dim your lights
| 
| code
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| cf. WakeupRamp
|-
| Sunrise/sunset
| 
| code
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| cf. Slowly dim your lights
|-
| Wavemaking
| 
| code
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
|}

 

== '''Watering System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
|}

 

= '''Alphabetical list of all Luup plugins, Luup code fragments and Vera clients''' =

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Category
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Unique MCVID
! Remarks
! Screenshot
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| Interfacing
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
| 
| 
|-
| ADD
| Alerter for Drowsy Devices
| code
| System management
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| 
| cf. Battery low notification
| 
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| UI
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
| 
| 
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| Utility
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled receivers.
| client
| UI
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
| 
| 
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| Energy management
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| UI
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| UI
| MCV
| 
| 
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| System management
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| 
| cf. ADD
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
| 
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| Utility
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
| 
| 
|-
| Closing a window shutter partially
| 
| code
| Utility
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Interfacing
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
| 
| 
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Utility
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| 
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
| 
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| System management
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| 
| based on 'Z-Wave routing matrix' by Ap15e
| 
|-
| Denon Receiver Control Plugin
| 
| plugin
| Home Entertainment management
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
| 
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| Home Entertainment management
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#DSC_PowerSeries_Panels|DSC Alarm Panel ]]
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Alarm System integration
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Elisa
| Control device locally and remote
| client
| UI
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
| 
| 
|-
| Elk M1 Family Panels 
| Integration with the Elk M1 alarm panels via the RS232 port.
| plugin 
| Alarm System integration
| mcvflorin 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6916.0] 
| [http://code.mios.com/trac/mios_elk-alarm-panel] 
| Working 
| 
| 
| 
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| Notifications
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
| 
| 
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| Utility
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Energy management
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| Interfacing
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
| 
| 
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| Watering System management
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
| 
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Utility
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| 
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
| 
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| Monitoring
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
| 
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Monitoring
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
| 
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| Utility
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#GE.2FCaddx_NetworX_Panels|GE Caddx NetworX NX-584 NX-8E Alarm Plugin]]
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| Alarm System integration
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
| 
| 
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| Monitoring
| MCV
| 
| IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
| 
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Development
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| Interfacing
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| Utility
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| UI
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
| 
| 
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Temperature or Weather measurement
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
| 
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| Home Entertainment management
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| Utility
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
| 
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| UI
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
| 
| 
|-
| Honeywell Ademco Vista Panels via AD2USB
| Integration with Honeywell's Ademco Vista panels via the AD2USB adapter.
| plugin
| Alarm System integration
| mcvflorin 
| 
| AD2USB Adapter 
| 
| [http://forum.micasaverde.com/index.php?topic=7266.0]
| [http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb] 
| Beta
| 
| 
| 
|-
| Honeywell Ademco Vista Panels with RS232 
| Integration with Honeywell's Ademco Vista panels with a RS232 interface.
| plugin
| Alarm System integration
| dfad1469
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6626.0]
| [http://code.mios.com/trac/mios_ademco-panels-plugin]
| Working
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| UI
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
| 
| 
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| Monitoring
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/ICamView]
| 
|-
| IO Relay Plugin
| This component permits the control of Relay and Analog IO boards from IORelay.com (National Control Devices). Controls up to 8 Relays and 8 Analog inputs.
| plugin
| Interfacing
| guessed
| 
| ProXR, ProXR Lite, Reactor Relay board from iorelay.com
| 
| [http://forum.micasaverde.com/index.php?topic=7589.0]
| [http://code.mios.com/trac/mios_iorelay]
| Working
| 
| 
| 
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| Interfacing
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
| 
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Home Entertainment management
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
| 
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| UI
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| UI
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
| 
| 
|-
| Learning IR codes
| 
| Windows application
| Home Entertainment management
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
| 
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Interfacing
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Home Entertainment management
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
| 
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| Home Entertainment management
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
| 
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Utility
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
| 
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| UI
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
| 
| 
|-
| LSI
| Luup System Information
| plugin
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
| 
| 
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Interfacing
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| Development
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
| 
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| 
| 
| N/A
| 
| 
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| Interfacing
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| 
| [http://forum.micasaverde.com/index.php?topic=6007.0]
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| System management
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
| 
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| Home Entertainment management
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
| 
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| Home Entertainment management
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
| 
| 
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| Monitoring
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| Home Entertainment management
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#Paradox_EVO_Panels|Paradox Alarm Plugin]]
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| Alarm System integration
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
| 
| 
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| Interfacing
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| Utility
| TedStriker
| guessed, Henk
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| [http://code.mios.com/trac/mios_ping-sensor]
| Working
| 
| 
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| Notifications
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
| 
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| Utility
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
| 
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| 
| [http://forum.micasaverde.com/index.php?topic=5609.0]
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| System management
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
| 
| 
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| Interfacing
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Interfacing
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
| 
| 
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Utility
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
| 
| 
|-
| Sending IR codes
| 
| code
| Home Entertainment management
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| 
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
| 
|-
| Slowly dim your lights
| 
| code
| Utility
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| 
| cf. WakeupRamp
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| UI
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Notifications
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
| 
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| Interfacing
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| UI
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
| 
| 
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| Home Entertainment management
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
| 
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| Home Entertainment management
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Home Entertainment management
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
| 
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| Home Entertainment management
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
| 
| 
|-
| Sunrise/sunset
| 
| code
| Utility
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
| 
| 
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| Energy management
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
| 
| 
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| Interfacing
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
| 
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| Utility
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
| 
| 
|-
| TiVo
| 
| 
| Home Entertainment management
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
| 
|-
| Trane Thermostats
| 
| plugin
| Energy management
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
| 
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| Notifications
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=1412.0]
| 
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| Notifications
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
| 
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| Notifications
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
| 
| 
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
| 
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Utility
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| UI
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
| 
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| Notifications
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
| 
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| Utility
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
| 
| 
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
| 
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| Utility
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
| 
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| Utility
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| 
| cf. Slowly dim your lights
| 
|-
| Wavemaking
| 
| code
| Utility
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
| 
| [http://forum.micasaverde.com/index.php?action=dlattach;topic=5865.0;attach=1826;image]
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| Temperature or Weather measurement
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
| 
| 
|-
| Z-Wave routing matrix
| 
| code
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
| 
|}

 

= '''Sources''' =

Sources: http://forum.micasaverde.com/ http://code.mios.com/ http://wiki.micasaverde.com/index.php/Luup_Projects http://forum.micasaverde.com/index.php?topic=6280.msg40147#msg40147 http://www.micasaverde.com/list-of-apps.php 

 

= '''Todo''' =

Luup plugins and Luup code

2011-08-28T01:44:41Z

Guessed: /* Alphabetical list of all Luup plugins, Luup code fragments and Vera clients */ Add IORelay Plugin

[[Category:Development]]
[[Category:Plugins]]

= '''All Luup plugins, Luup code fragments and Vera clients by category''' =

== '''Alarm System integration''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Ademco Honeywell Vista 20P Alarm Plugin
| 
| plugin
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4531.0]
| 
| N/A
| 
|-
| DSC Alarm Panel
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| GE Caddx Networx NX-584 NX-8E Alarm Plugin
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
|-
| Paradox Alarm Plugin
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
|}

 

== '''Development''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
|}

 

== '''Energy management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
|-
| Trane Thermostats
| 
| plugin
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
|}

 

== '''Home Entertainment management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Denon Receiver Control Plugin
| 
| plugin
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
|-
| Learning IR codes
| 
| Windows application
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| MCV
| 
| 
| 
| 
| 
| N/A
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
|-
| Sending IR codes
| 
| code
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
|-
| TiVo
| 
| 
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
|}

 

== '''Interfacing''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| [http://forum.micasaverde.com/index.php?topic=6007.0]
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
|}

 

== '''Monitoring''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| MCV
| 
| IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| [http://wiki.micasaverde.com/index.php/ICamView]
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|}

 

== '''Notifications''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=1412.0]
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
|}

 

== '''System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| ADD
| Alerter for Drowsy Devices
| code
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| cf. Battery low notification
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| cf. ADD
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| based on 'Z-Wave routing matrix' by Ap15e
|-
| LSI
| Luup System Information
| plugin
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
|-
| Z-Wave routing matrix
| 
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
|}

 

== '''Temperature or Weather measurement''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
|}

 

== '''UI''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled rece
| client
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| MCV
| 
| 
| 
| 
| 
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| Elisa
| Control device locally and remote
| client
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| [http://www.micasaverde.com/list-of-apps.php]
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
|}

 

== '''Utility''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
|-
| Closing a window shutter partially
| 
| code
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| TedStriker
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| 
| Working
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| [http://forum.micasaverde.com/index.php?topic=5609.0]
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
|-
| Slowly dim your lights
| 
| code
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| cf. WakeupRamp
|-
| Sunrise/sunset
| 
| code
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| cf. Slowly dim your lights
|-
| Wavemaking
| 
| code
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
|}

 

== '''Watering System management''' ==

DO NOT EDIT! Automatically generated from the alphabetical list below.

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Remarks
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
|}

 

= '''Alphabetical list of all Luup plugins, Luup code fragments and Vera clients''' =

{| cellpadding="2" border="1"
|-
! Name
! Description
! Type
! Category
! Author
! Contributor
! HW requirements
! SW requirements
! Forum link
! Code repository link
! Status
! Unique MCVID
! Remarks
! Screenshot
|-
| ActiveRFID
| Affordable RFID solution, supporting multiple transmitters on multiple receivers.
| plugin
| Interfacing
| woodsby
| 
| ActiveRFID hardware
| 
| [http://forum.micasaverde.com/index.php?topic=3855.0]
| [http://code.mios.com/trac/mios_activerfid]
| Working
| 
| 
| 
|-
| ADD
| Alerter for Drowsy Devices
| code
| System management
| Ap15e
| dcowan, guessed, Les F, mda
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5130.0]
| 
| Working
| 
| cf. Battery low notification
| 
|-
| air4vera
| The system supports findvera.com or the home LAN, motion sensors, light sensors, temperature sensors, light switches and dimmers, door locks, scenes, generic IO, window shades.
| client
| UI
| chairman_bubba
| 
| 
| Adobe AIR
| [http://forum.micasaverde.com/index.php?topic=2150.0]
| 
| 
| 
| 
| 
|-
| AquaLink RS Plugin
| Smart pool control
| plugin
| Utility
| mcvflorin
| 
| 
| 
| 
| 
| On hold
| 
| 
| 
|-
| AutoHTN
| AutoHTN is made by Home Theater Network and can control a Vera home system’s lights, sensors, thermostat, switched power devices, scenes, and window blinds. AutoHTN can also be used as a remote for Boxee or XBMC media software as well as web enabled receivers.
| client
| UI
| Home Theater Network, LLC
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=16.0]
| 
| 
| 
| 
| 
|-
| Automated "occupied/unoccupied" VR mode for thermostat control
| 
| code
| Energy management
| neilios
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4809.0]
| 
| 
| 
| 
| 
|-
| Automator.App
| Take complete control of your home from anywhere using your iOS device (iPhone, iPod, or iPad).
| client
| UI
| Vakoc Woodworks, LLC
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=18.0]
| 
| 
| 
| 
| 
|-
| Basic mobile phone Web interface (WAP)
| Basic HTML/WAP interface for accessing Vera from any mobile phone that has web capabilities.
| plugin
| UI
| MCV
| 
| 
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Battery low notification
| Detecting a low battery level in any number of devices.
| code
| System management
| axill, FlyBoyBob
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6169.msg38081#msg38081][http://forum.micasaverde.com/index.php?topic=6169.msg38084#msg38084][http://forum.micasaverde.com/index.php?topic=6169.msg40871#msg40871]
| 
| 
| 
| cf. ADD
| 
|-
| CalDAV Scheduler
| Integration with an external Calendaring service via CalDAV protocol.
| plugin (nearly)
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3761.0]
| [http://code.mios.com/trac/mios_caldav-scheduler]
| On hold
| 
| 
| 
|-
| Christmas Toolkit
| Christmas Lights off when raining, Blinking christmas tree
| code
| Utility
| mikemsd, Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=4932.0][http://forum.micasaverde.com/index.php?topic=5127.0]
| 
| Working
| 
| 
| 
|-
| Closing a window shutter partially
| 
| code
| Utility
| huwu
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3512.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=3359.msg15891#msg15891]
| 
|-
| Crestron Status Engine Plugin
| Provides real-time status feedback to the Crestron system when the state of one of the Z-Wave devices changes.
| plugin
| Interfacing
| Wendell Manley
| 
| 
| 
| 
| 
| Working
| 
| 
| 
|-
| DAD
| DAD displays the times for sunrise/sunset and moonrise/moonset, the current zodiac sign and the current moon phase on the GUI. DAD provides earthquake and radiation data.
| plugin
| Utility
| Ap15e
| futzle, javier, JOD, oTi@
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5466.0]
| 
| Working
| 
| Please note the limitations: [http://forum.micasaverde.com/index.php?topic=6052.0].
| 
|-
| Debugging Utilities
| Utilities for Vera debugging
| plugin
| System management
| mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.msg36320#msg36320]
| [http://code.mios.com/trac/mios_debugging-utilities]
| 
| 
| based on 'Z-Wave routing matrix' by Ap15e
| 
|-
| Denon Receiver Control Plugin
| 
| plugin
| Home Entertainment management
| Rick Naething
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5863.0]
| 
| WIP
| 
| 
| 
|-
| DirecTV Media Control Plugin
| The DirecTV Media Control plugin is a Luup component that permits the Remote Control of HR2X series DirecTV DVR and other receivers.
| plugin
| Home Entertainment management
| guessed
| 
| HR2X series DirecTV DVR, two USB to R232 adapters or Ethernet connection
| 
| [http://forum.micasaverde.com/index.php?topic=3079.0]
| [http://code.mios.com/trac/mios_directv-media-control]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#DSC_PowerSeries_Panels|DSC Alarm Panel ]]
| Integration with DSC's Alarm Panel, via an IT-100 data interface module.
| plugin
| Alarm System integration
| Javier Guerra, guessed
| 
| Power 1616, 1632 or 1632 series panel, IT100 RS232 Keybus module, USB to Serial or USB to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=5154.0]
| [http://code.mios.com/trac/mios_dscalarmpanel]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Elisa
| Control device locally and remote
| client
| UI
| structor
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?topic=3219.0]
| 
| 
| 
| 
| 
|-
| Elk M1 Family Panels 
| Integration with the Elk M1 alarm panels via the RS232 port.
| plugin 
| Alarm System integration
| mcvflorin 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6916.0] 
| [http://code.mios.com/trac/mios_elk-alarm-panel] 
| Working 
| 
| 
| 
|-
| Email notifications
| Send emails via SMTP server that doesn't require SSL
| code
| Notifications
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3584.msg17474#msg17474][http://forum.micasaverde.com/index.php?topic=6153.msg37159#msg37159]
| 
| Working
| 
| 
| 
|-
| Emergency light
| Get Vera to blink your porch light.
| code
| Utility
| aa6vh
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3015.0]
| 
| Working
| 
| 
| 
|-
| Energy Reporting framework
| Several parts to an all-encompassing, hopefully-extensible energy reporting/storing/graphing system. Energy Plugin allows you to see the live and historical energy usage in your home.
| 
| Energy management
| Javier Guerra
| 
| 
| 
| 
| [http://code.mios.com/trac/mios_energry-reporting]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Enocean Gateway
| Interface to an Enocean TCM120 transceiver. For receiving sensor telegrams and for sending telegrams.
| plugin
| Interfacing
| evanes
| 
| Enocean TCM120 transceiver, USB to Serial or Serial to Ethernet adapter
| 
| [http://forum.micasaverde.com/index.php?topic=4990.0]
| [http://code.mios.com/trac/mios_enocean]
| 
| 
| 
| 
|-
| Etherrain Controller Plugin
| EtherRain8 Sprinkler Controller allows controlling of up to 8 regular 24V irrigation valves.
| plugin
| Watering System management
| 325xi
| 
| EtherRain Sprinkler Controller
| 
| [http://forum.micasaverde.com/index.php?topic=1846.0]
| [http://code.mios.com/trac/mios_etherrain-controller]
| Working
| 
| 
| 
|-
| FCM
| FRITZ!Box Call Monitor
| plugin
| Utility
| Ap15e
| 
| FRITZ!Box
| 
| [http://forum.micasaverde.com/index.php?topic=6658.0]
| 
| Working
| 
| Tested with FRITZ!Box 7170/29.04.67 and 7390/84.04.88
| 
|-
| Foscam plugin
| Pan, tilt, patrol support for Foscam FI8908[w]
| plugin
| Monitoring
| MCV, Ap15e
| shady
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=3720.0][http://forum.micasaverde.com/index.php?topic=3720.msg21954#msg21954]
| 
| Working
| 
| 
| 
|-
| FPM
| Foscam Privacy Mode - have the camera automatically point up.
| code
| Monitoring
| Ap15e
| 
| Foscam FI8908[w]
| 
| [http://forum.micasaverde.com/index.php?topic=5082.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#.27Privacy.27_mode_for_Foscam_FI8908.5Bw.5D]
| 
|-
| Garage Door Plugin
| Takes the combination of the door sensor device and the contact closure device on a garage door setup and consolidates them into a single device that behaves as a door lock.
| plugin
| Utility
| woodsby
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5106]
| 
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#GE.2FCaddx_NetworX_Panels|GE Caddx NetworX NX-584 NX-8E Alarm Plugin]]
| Plugin for the security system interface variously sold around the world as the Caddx or GE or Networx NX-584.
| plugin
| Alarm System integration
| futzle
| 
| NX-8E or NX-584
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Working
| 
| 
| 
|-
| Generic IP Camera
| The Generic IP Camera plugin is used for adding and manipulating the IP Cameras.
| plugin
| Monitoring
| MCV
| 
| IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php][http://wiki.micasaverde.com/index.php/IP_Cameras]
| 
|-
| Generic Lua Utilities
| Some Lua helping code
| code
| Development
| Javier Guerra, mcvflorin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3319.0]
| [http://code.mios.com/trac/mios_genericutils]
| 
| 
| 
| 
|-
| Global Cache GC100
| Allows Vera to control any setting that the GC100 offers.
| plugin
| Interfacing
| MCV
| 
| GC100
| 
| [http://forum.micasaverde.com/index.php?topic=4060.0]
| [http://code.mios.com/trac/mios_caddxnx584]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Graphing tool for Vera
| A Windows dialog based app that can track any data from any Vera connected device.
| Windows application
| Utility
| FlyBoyBob
| 
| 
| Windows
| [http://forum.micasaverde.com/index.php?topic=5870.0]
| 
| 
| 
| 
| 
|-
| Grasshopper
| Grasshopper is a Windows Phone 7 application that interfaces with Vera to control Z-Wave compatible devices around your home.
| client
| UI
| Amgine Creations
| 
| Windows Phone 7
| 
| [http://forum.micasaverde.com/index.php?topic=5846.0]
| 
| Working
| 
| 
| 
|-
| GWC
| Google Weather Companion - a graphical interface for guessed's Google Weather plugin.
| plugin
| Temperature or Weather measurement
| Ap15e
| 
| 
| Google Weather plugin by guessed
| [http://forum.micasaverde.com/index.php?topic=6553.0]
| 
| Working
| 
| 
| 
|-
| HDMI-CEC Media Controller Plugin
| A HDMI-CEC Driver for Rainshadow Tech and Kwikwai HDMI-CEC Controllers adapting them to MiOS Media Control APIs.
| plugin
| Home Entertainment management
| guessed
| 
| Rainshadow Tech or Kwikwai HDMI-CEC controller
| 
| [http://forum.micasaverde.com/index.php?topic=5468.0]
| [http://code.mios.com/trac/mios_hdmi-cec-media-controller]
| On hold
| 
| 
| 
|-
| Home Care Plugin
| Sends notification if the motion sensors aren't triggered in the user set period.
| plugin
| Utility
| mcvflorin
| 
| 
| MiOS >= 1.1.1161
| [http://forum.micasaverde.com/index.php?topic=6517.0]
| [http://code.mios.com/trac/mios_home-care]
| Working
| 
| 
| 
|-
| Home Buddy
| Home Buddy is a native Android application that interfaces with Mi Casa Verde's Vera to control Z-Wave compatible devices around your home.
| client
| UI
| rakstar
| 
| 
| Android
| [http://forum.micasaverde.com/index.php?board=15.0]
| 
| 
| 
| 
| 
|-
| Honeywell Ademco Vista Panels via AD2USB
| Integration with Honeywell's Ademco Vista panels via the AD2USB adapter.
| plugin
| Alarm System integration
| mcvflorin 
| 
| AD2USB Adapter 
| 
| [http://forum.micasaverde.com/index.php?topic=7266.0]
| [http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb] 
| Beta
| 
| 
| 
|-
| Honeywell Ademco Vista Panels with RS232 
| Integration with Honeywell's Ademco Vista panels with a RS232 interface.
| plugin
| Alarm System integration
| dfad1469
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6626.0]
| [http://code.mios.com/trac/mios_ademco-panels-plugin]
| Working
| 
| 
| 
|-
| HTML GUI creator
| A Lua application which parses the user_data and creates a compact HTML GUI for Vera.
| code
| UI
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1775.0]
| 
| Proof of concept
| 
| 
| 
|-
| ICamView
| ICamView camera server allows to connect up to two compatible iCamView cameras, USB hubs, storage device for local storage, compatible Wi-Fi USB adapters, etc. Plugin supports Pan-Tilt for compatible cameras.
| plugin
| Monitoring
| 325xi
| 
| compatible IP camera
| 
| 
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/ICamView]
| 
|-
| IO Relay Plugin
| This component permits the control of Relay and Analog IO boards from IORelay.com (National Control Devices). Controls up to 8 Relays and 8 Analog inputs.
| plugin
| Interfacing
| guessed
| 
| ProXR, ProXR Lite, Reactor Relay board from iorelay.com
| 
| [http://forum.micasaverde.com/index.php?topic=7589.0]
| [http://code.mios.com/trac/mios_iorelay]
| Working
| 
| 
| 
|-
| IPSerial Plugin
| This component permits the registration of IP-based Serial devices with Vera.
| plugin
| Interfacing
| guessed
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| [http://forum.micasaverde.com/index.php?topic=2989.0]
| [http://code.mios.com/trac/mios_ipserial]
| Working
| 
| 
| 
|-
| IR plugin
| Sends IR Pronto codes stored in a text file
| plugin
| Home Entertainment management
| Roy S
| 
| UPnP IrTransmitter1 device
| 
| [http://forum.micasaverde.com/index.php?topic=6532.msg40741#msg40741]
| 
| WIP
| 
| 
| 
|-
| iVera
| iVera is a simple and efficient home automation remote control for Vera system from MiCasaVerde.
| client
| UI
| Thinkiwi LLC
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?board=11.0]
| 
| 
| 
| 
| 
|-
| j9 (now: Elve) Automation Engine Driver
| The driver currently supports lighting and thermostats.
| external driver
| UI
| johnnynine
| 
| 
| 
| 
| 
|  ?
| 
| 
| 
|-
| Learning IR codes
| 
| Windows application
| Home Entertainment management
| 
| 
| USB-UIRT
| lrnhelper [http://www.usbuirt.com/lrnhelper_0_0_5.zip]
| [http://forum.micasaverde.com/index.php?topic=3617.0]
| 
| 
| 
| 
| 
|-
| Leviton Vizia RF+ Emulator
| Emulates a Leviton Vizia RF+ Serial/ZWave interface, lets serial panels to control devices connected to Vera.
| plugin
| Interfacing
| Javier Guerra
| 
| Serial-to-Ethernet gateway (e.g., WIZNet 110SR)
| 
| 
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| LIRC2LuupDevice4SBS
| Control your IR capable devices via IR
| code/plugin
| Home Entertainment management
| Ap15e
| 
| Squeezebox V2/V3 or Transporter, IR transmitter
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5709.0]
| 
| Working
| 
| 
| 
|-
| LIRC for Vera
| LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.
| compiled binaries
| Home Entertainment management
| 
| 
| IR transmitter
| 
| [http://forum.micasaverde.com/index.php?topic=5856.0]
| 
|  ?
| 
| 
| 
|-
| Locale Android App Plugin
| Plugin for running scenes from the Locale app.
| plugin
| Utility
| Jason Parekh
| 
| 
| 
| 
| 
| Pending
| 
| 
| 
|-
| LOUIS4Vera
| A Line-Oriented User Interface for Squeezebox devices for Vera
| plugin
| UI
| Ap15e
| 
| Squeezebox V2/V3 or Transporter (or software emulation)
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5232.0]
| 
| Working
| 
| 
| 
|-
| LSI
| Luup System Information
| plugin
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6614.0]
| 
| Working
| 
| 
| 
|-
| Lutron RadioRA2 Devices Control
| 
| plugin
| Interfacing
| Bo Li
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5092.0][http://forum.micasaverde.com/index.php?topic=5964.0]
| 
| WIP
| 
| 
| 
|-
| Luup Code Generator
| This will help all of us who are new to Luup coding get started.
| LabVIEW application
| Development
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6508.0]
| 
| WIP
| 
| 
| 
|-
| Magnavox 19MF337B/27 LCD TV
| 
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| 
| 
| N/A
| 
| 
| 
|-
| Modbus/TCP plugin
| A Luup plugin for controlling Modbus/TCP slaves.
| plugin
| Interfacing
| ekarak
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2907.0]
| 
|  ?
| 
| [http://forum.micasaverde.com/index.php?topic=6007.0]
| 
|-
| Modify user_data (dangerous, read the thread)
| Modify any setting of your Vera.
| code
| System management
| mikkelj
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6277.0]
| 
| Working
| 
| 
| 
|-
| Monoprice Matrix HDMI Switch
| The Monoprice Matrix 4x4 HDMI Switch plugin is a Luup component that permits the Remote Control of a Monoprice Matrix switch (Model HDX-404E)
| plugin
| Home Entertainment management
| guessed, strangely
| 
| Monoprice HDX-404E
| 
| 
| [http://code.mios.com/trac/mios_monoprice-hdmi-switch]
| Working
| 
| 
| 
|-
| Onkyo Media Control Plugin
| A Luup component that permits the Remote Control of an Onkyo Receiver that has a built-in RS-232/Serial, or Ethernet, port and conforms to Onkyo's ISCP.
| plugin
| Home Entertainment management
| guessed
| 
| compatible Onky receiver
| 
| 
| [http://code.mios.com/trac/mios_onkyo-media-control]
| Working
| 
| 
| 
|-
| Panasonic IP Camera
| Used for adding and manipulating Panasonic IP Cameras.
| plugin
| Monitoring
| MCV
| 
| compatible IP camera
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Panasonic TV Plugin
| A Luup component that permits the Remote Control of a Panasonic Plasma TV that have a built-in RS-232/Serial port
| plugin
| Home Entertainment management
| guessed
| 
| compatible Panasonic TV
| 
| [http://forum.micasaverde.com/index.php?topic=3043.0]
| [http://code.mios.com/trac/mios_panasonic-tv]
| Working
| 
| 
| 
|-
| [[Alarm Panel Plugins#Paradox_EVO_Panels|Paradox Alarm Plugin]]
| A Luup component that connects Vera to a Paradox Security Alarm panel (Digiplex DGP-848 or EVO series) via their Home Automation interface (Paradox PRT3) over USB.
| plugin
| Alarm System integration
| guessed
| 
| Paradox Digiplex DGP-848 or EVO series, Paradox PRT3
| 
| [http://forum.micasaverde.com/index.php?topic=2492.0]
| [http://code.mios.com/trac/mios_paradox-alarm]
| Working
| 
| 
| 
|-
| Phone Dialer plugin
| Allows to automatically connect two (or more) parties via phones and/or VoIP.
| plugin
| Interfacing
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1589.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Dialer_Plugin]
| 
|-
| Ping sensor
| A plugin which pings defined addresses (IP and domain names) a keeps the result of the ping in a variable.
| plugin
| Utility
| TedStriker
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6096.msg39996#msg39996][http://forum.micasaverde.com/index.php?topic=1997.0]
| 
| Working
| 
| 
| 
|-
| Prowl notifications
| Get notifications via Prowl on your iPhone
| code
| Notifications
| futzle
| 
| 
| iOS
| [http://forum.micasaverde.com/index.php?topic=4508.0]
| 
| Working
| 
| 
| 
|-
| Public Holiday virtual switch
| A binary switch, which is ON if today is a public holiday, and OFF if today is not.
| plugin
| Utility
| futzle
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6355.0][http://forum.micasaverde.com/index.php?topic=6355.msg39216#msg39216]
| 
| WIP
| 
| 
| 
|-
| Randomizer plugin
| The code waits for a "random" period of time between intervalLower and intervalUpper (in minutes), and then it does an evaluation of whether to turn the Scene event "on" or "off".
| plugin
| Utility
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175]
| 
| WIP
| 
| [http://forum.micasaverde.com/index.php?topic=5609.0]
| 
|-
| Report Generator
| Gives you all your system information in one neat package.
| LabVIEW application
| System management
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6547.0]
| 
| WIP
| 
| 
| 
|-
| RFXcom Gateway
| Gateway to RFXCOM devices wich can receive and send X10 RF, Homeeasy, Klik-aan Klik-Uit, Oregon, Harrison curtains etc..
| plugin
| Interfacing
| evanes
| 
| RFXCOM interface
| 
| [http://forum.micasaverde.com/index.php?topic=4991.0]
| [http://code.mios.com/trac/mios_rfxcom]
| 
| 
| 
| 
|-
| RS-485 RCS Thermostats Plugin
| The RCS thermostat plugin is a Luup component that connects Vera to RCS serial RS-485 thermostats.
| plugin
| Interfacing
| Bo Li
| 
| RS-485 thermostat
| 
| 
| 
| Pending
| 
| 
| 
|-
| SABnzbd download control
| Control SABnzbd downloads as a device
| plugin
| Utility
| Klunket
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3789.0]
| [http://code.mios.com/trac/mios_sabnzbd-control]
| 
| 
| 
| 
|-
| Sending IR codes
| 
| code
| Home Entertainment management
| Ap15e
| 
| IR emitter, Squeezebox V2/V3 or Transporter
| IRBlaster[http://www.gwendesign.com/slimserver/dev_hard_and_software.htm#irblaster], Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3712.0]
| 
| Working
| 
| [http://wiki.micasaverde.com/index.php/Squeezebox#Sending_IR_codes_.28SB2.2F3_and_Transporter.29]
| 
|-
| Setting Z-Wave parameters
| Setting Z-Wave parameters using Luup/Lua
| code
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1937.msg7803#msg7803]
| 
| Working
| 
| ModifyUserData might be a simpler, but more dangerous way [http://forum.micasaverde.com/index.php?topic=6277.msg38070#msg38070].
| 
|-
| Slowly dim your lights
| 
| code
| Utility
| brsipaq
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2386.0]
| 
| Working
| 
| cf. WakeupRamp
| 
|-
| SmartPhone plugin
| This is a basic HTML interface for accessing Vera from a smartphone web browser
| plugin
| UI
| Javier Guerra
| 
| compatible smartphone
| 
| [http://forum.micasaverde.com/index.php?topic=3320.0]
| [http://code.mios.com/trac/mios_smartphones]
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SND
| SMTP Notification Device - SMTP via UPnP
| plugin
| Notifications
| Ap15e
| guessed
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6656.0]
| 
| Working
| 
| 
| 
|-
| Somfy Blind Interface & Somfy ST30 Blind Interface
| Used to setup and control the Somfy blind control device.
| plugin
| Interfacing
| MCV
| 
| Somfy Blind Interface
| 
| 
| 
| Published
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| SQ Remote
| SQ Remote will allow you to control your MiOS home control system directly from your iPhone, iPod touch and iPad.
| client
| UI
| Square Connect Inc.
| 
| iPhone or iPod or iPad
| iOS
| [http://forum.micasaverde.com/index.php?board=9.0]
| 
| 
| 
| 
| 
|-
| SQBlaster
| An IRTransmitter1 implementation, for SquareConnect SQBlaster users control IR devices via Vera; permits the registration of the SquareConnect SQBlaster IR Blaster device with Vera
| plugin
| Home Entertainment management
| guessed
| 
| SquareConnect SQBlaster
| 
| 
| [http://code.mios.com/trac/mios_sqblaster]
| Working
| 
| 
| 
|-
| Squeezebox Control
| Let's you control and monitor Squeezebox music players.
| plugin
| Home Entertainment management
| MCV
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=5097.msg28878#msg28878]
| 
| Unreleased (beta)
| 
| [http://www.micasaverde.com/list-of-apps.php]
| 
|-
| Squeezebox control for 'go to bed scene'
| Turns the player on, sets the player to sleep in an hour, plays an internet station.
| code
| Home Entertainment management
| Klunket
| 
| Squeezebox music player or software emulation
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=3889.0]
| 
| Working
| 
| 
| 
|-
| squeezedVera, squeezedVeraScenes
| Run scripts that control your Z-Wave devices through Vera and define conditions for when they shall run.
| Squeezebox plugin
| Home Entertainment management
| m_gustafsson
| 
| Squeezebox music player
| Squeezebox Server
| [http://forum.micasaverde.com/index.php?topic=1047.0]
| 
| Working
| 
| 
| 
|-
| Sunrise/sunset
| 
| code
| Utility
| Ap15e, javier
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2073.msg8132#msg8132][http://forum.micasaverde.com/index.php?topic=3836.0]
| [http://code.mios.com/svn_public/mios_genericutils/suntime.lua]
| Working
| 
| 
| 
|-
| TED5000
| Electricity and energy monitoring and management system
| plugin
| Energy management
| woodsby
| 
| TED 5000
| 
| [http://forum.micasaverde.com/index.php?topic=5371]
| 
| Working
| 
| 
| 
|-
| TI eZ430-Chronos Wireless Watch Plugin
| Plugin that allows wireless control via Texas Instruments' eZ430-Chronos Wireless Watch.
| plugin
| Interfacing
| obot, ojas(?)
| 
| TI eZ430-Chronos
| 
| [http://forum.micasaverde.com/index.php?topic=5822.0]
| [http://code.mios.com/trac/mios_ez430-chronos]
| Pending
| 
| 
| 
|-
| TimerAnnouncer device
| Returns the the PC date and Time from the PC to circumvent issues with the Vera clock and reads any text and announces it as Voice (TTS).
| UPnP device
| Utility
| achalhoub
| 
| 
| Windows with .NET 4.0, MiOS >= 1.1.1234
| [http://forum.micasaverde.com/index.php?topic=5493.0][http://forum.micasaverde.com/index.php?topic=5466.msg36405#msg36405]
| 
| Working
| 
| 
| 
|-
| TiVo
| 
| 
| Home Entertainment management
| 
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3437.0]
| 
| 
| 
| [http://david.blackledge.com/tivo/URLMenu.zip][http://www.tivocommunity.com/tivo-vb/showthread.php?t=392385]
| 
|-
| Trane Thermostats
| 
| plugin
| Energy management
| jgdurbin
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1730.msg39409#msg39409]
| 
| 
| 
| 
| 
|-
| Twitter notifications
| A little plugin that tweets current time when you click on On button.
| plugin/code
| Notifications
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2320.0][http://forum.micasaverde.com/index.php?topic=3662.0]
| 
| Working
| 
| [http://forum.micasaverde.com/index.php?topic=1412.0]
| 
|-
| UDP listener
| Get your message across to Vera via UDP.
| plugin
| Notifications
| nixterrimus
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=3385.0]
| 
| WIP
| 
| 
| 
|-
| UDP notifier
| Send a udp message whenever a device switches on or off or dims.
| code
| Notifications
| martin12345
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6489.msg40643#msg40643]
| 
| WIP
| 
| 
| 
|-
| USB-UIRT
| USB-UIRT (Universal Infrared Receiver/Transmitter) allows to Transmit and Receive Infrared signals to common AV equipment.
| plugin
| Home Entertainment management
| MCV
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6304.0]
| 
| Working
| 
| 
| 
|-
| Vera Chrome Extension
| Permanent icon in the toolbar as the entry point. Clicking this would bring up an overlay that has all of the user's favorites (scenes or devices) within one-click.
| plugin
| Utility
| Shemoni Parekh
| 
| 
| 
| 
| 
| WIP
| 
| 
| 
|-
| Vera UI (LabVIEW)
| This will be for displaying your Vera information in nice neat tables, parses your system and builds a TAB Based interface with built in dimmers that work well with a touch screen computer.
| client
| UI
| TimAlls
| 
| 
| Windows, [http://ftp.ni.com/support/softlib/labview/labview_runtime/8.0/windows/LabVIEW_8.0_Runtime_Engine.exe]
| [http://forum.micasaverde.com/index.php?topic=6515.0]
| 
| WIP
| 
| 
| 
|-
| Veralert
| Set up alerts/notifications to go straight to your 2.2 and above Android phone.
| plugin
| Notifications
| ragmondo
| 
| 
| Android >= 2.2
| [http://forum.micasaverde.com/index.php?board=21.0]
| 
| 
| 
| 
| 
|-
| Virtual StateDevice
| A simple virtual switch based on binary switch
| plugin
| Utility
| 325xi
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6375.msg40051#msg40051][http://forum.micasaverde.com/index.php?topic=2138.msg9104#msg9104]
| 
| Working
| 
| 
| 
|-
| WAI
| Where Am I? Converts Vera's location to an address and can be used to display debug messages on the GUI.
| plugin
| Development
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=6441.0]
| 
| Working
| 
| 
| 
|-
| Wake-On-Lan plugin
| Used to create a virtual device that when configured with the MAC address of a machine on your LAN can send a command to wake that machine up.
| plugin
| Utility
| mikeholczer, mcvflorin
| 
| Device with WoL support
| 
| [http://forum.micasaverde.com/index.php?topic=3718.0]
| [http://code.mios.com/trac/mios_wake-on-lan]
| Working
| 
| 
| 
|-
| WakeupRamp
| Device for ramping up a set of lights slowly
| plugin
| Utility
| ZMaF
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=5718.msg33307#msg33307]
| 
| Working
| 
| cf. Slowly dim your lights
| 
|-
| Wavemaking
| 
| code
| Utility
| aa6vh
| 
| two pumps
| 
| [http://forum.micasaverde.com/index.php?topic=5865.msg34754#msg34754]
| 
| Working
| 
| 
| [http://forum.micasaverde.com/index.php?action=dlattach;topic=5865.0;attach=1826;image]
|-
| Weather Plugin
| Captures, displays, and periodically updates Temperature and Humidity data based upon Vera's current location.
| plugin
| Temperature or Weather measurement
| guessed
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=1435.0]
| [http://code.mios.com/trac/mios_weather]
| Working
| 
| 
| 
|-
| Z-Wave routing matrix
| 
| code
| System management
| Ap15e
| 
| 
| 
| [http://forum.micasaverde.com/index.php?topic=2099.0]
| 
| 
| 
| obsoleted by ADD; cf. Debugging Utilities
| 
|}

 

= '''Sources''' =

Sources: http://forum.micasaverde.com/ http://code.mios.com/ http://wiki.micasaverde.com/index.php/Luup_Projects http://forum.micasaverde.com/index.php?topic=6280.msg40147#msg40147 http://www.micasaverde.com/list-of-apps.php 

 

= '''Todo''' =

Luup Lua extensions

2011-08-14T22:23:53Z

Guessed: /* function: append */ Provide an example, augment the text a little since it was a mix-mash

In addition to the [[http://lua.org Lua]] commands described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]], you can also reference in your Lua code variables and functions from modules which the Luup engine provides as follows:

== Module: luup ==

These are general purpose functions and variables. Call them by using the luup. module, such as: 

<source lang="lua">luup.log('Now running version: ' .. luup.version)</source>

=== variable: device ===

The ID of this device instance, if it's running as part of a device

=== variable: version, version_branch, version_major, version_minor ===

''version'' contains the version of the luup engine, such as "1.0.843", as a string. The version consists of 3 numbers separated by a period: the branch, the major version, and the minor version. To make it easier to compare against a minimum acceptable version, ''version_branch, version_major and version_minor'' return each component as a number. You can put a comparison in the startup function in your Luup plugin and return false if the minimum version isn't met. The user will then see that the Luup device's startup check failed: 

<source lang="lua">if( version_branch ~= 1 or version_major ~= 0 or version_minor < 843 ) then
luup.log("I need version 1.0.843 minimum to run")
return false
end</source>

=== variable: longitude ===

Contains the longitude as a number, as found on the location tab in the setup UI.

=== variable: latitude ===

Contains the latitude as a number, as found on the location tab in the setup UI.

=== variable: timezone ===

Contains the timezone as a number, as found on the location tab in the setup UI.

'''Warning:''' luup.timezone doesn't work.

=== variable: city ===

Contains the city as a string, as found on the location tab in the setup UI.

=== variable: devices ===

Contains all the devices in the system as a table indexed by the device number. The members are: room_num (number), device_type (string), category_num (number), device_num_parent (number), ip (string), mac (string), id (string), description (string), udn (string). [See also: [[Lua Device Structure]].] Example to log device #5's IP addess and its internal ID: 

<source lang="lua">luup.log('Device #5 ip: ' .. luup.devices[5].ip .. ' id: ' .. luup.devices[5].id)</source>

room_num: This is the number of the room the device is in.

device_type: This is a string representing the type of the device.

category_num: This is a category for the device. See: [[Luup_Device_Categories]] for a list.

device_num_parent: This is the number of the parent device. See: [[Lua Device Structure]] for details.

ip: If this device is IP based, this is the IP address.

mac: If this device is IP based, this is the MAC address.

id: If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.

embedded: (boolean) If this device is embedded, it means that it doesn't have its own room or exist as a separate device. It should be considered part of its parent. Like a 3-in-1 sensor is a device with 3 embedded child devices.

hidden: (boolean) If true the user checked the 'hidden' box and doesn't want to see the device on the dashboard.

invisible: (boolean) If true the device is 'for internal use only' and shouldn't be presented to the user.

description: This is the text description for the device as supplied by the user in the web UI.

udn: This is the UDN for the UPnP device.

This code will log all the attributes from all the devices: 

<source lang="lua">for k, v in pairs(lug_device) do
for k2, v2 in v do
luup.log("Device #" .. k .. ":" .. k2 .. "=" .. "v2")
end
end</source>

=== variable: rooms ===

Contains all the rooms as a table of strings indexed by the room number. Example: 

<source lang="lua">luup.log('Room #1 is called: ' .. luup.rooms[1])</source>

=== variable: scenes ===

Contains all the scenes in the system as a table indexed by the scene number. The members are: room_num (number), description(string), hidden(boolean)

=== variable: remotes ===

Contains all the remotes in the system as a table indexed by the remote id. The members are: remote_file (string), room_num (number), description(string)

=== function: log ===

parameters: what_to_log (string), log_level (optional, number)

return: nothing

Writes what_to_log to the log, /var/log/cmh/LuaUPnP.log, with the given log_level, which is 50 by default. See: [[Luup Loglevels]]

=== function: task ===

parameters: message (string), status (number), description (string), handle (number)

return: handle (number)

When the Luup engine is starting status messages are displayed for the various modules as they're initialized. Normally each device, including Luup devices, automatically log their status and the user is shown an error if the device doesn't start, such as if the 'startup' function returns an error.

If you have other startup sequences which you want the user to see to know that startup hasn't finished yet, call this function passing in a handle of -1 for the first call. The status should be: 1=Busy, 2=Error, 4=Successful. Message is the current state, such as 'downloading', and description describes the module, like 'Smartphone UI'. After the first call, store the handle and pass it on future calls to update the status rather than add a new one.

=== function: call_delay ===

parameters: function_name (string), seconds (number), data (string), thread (bool)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name. function_name will only be called once and you must call call_delay again if you want it called again, or use call_timer instead.

If thread is specified and is true or 1, the call back will be made in it's own thread and can block if needed. Normally it is called by a worker thread and is expected to return immediately.

=== function: call_timer ===

parameters: function_name (string), type (number), time (string), days (string), data (string)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called when the timer is triggered, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name.

Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer. For an interval timer, days is not used, and Time should be a number of seconds, minutes, or hours using an optional 'h' or 'm' suffix. Example: 30=call in 30 seconds, 5m=call in 5 minutes, 2h=call in 2 hours. For a day of week timer, Days is a comma separated list with the days of the week where 1=Monday and 7=Sunday. Time is the time of day in hh:mm:ss format. Time can also include an 'r' at the end for Sunrise or a 't' for Sunset and the time is relative to sunrise/sunset. For example: Days="3,5" Time="20:30:00" means your function will be called on the next Wed or Fri at 8:30pm. Days="1,7" Time="-3:00:00r" means your function will be called on the next Monday or Sunday 3 hours before sunrise. Day of month works the same way except Days is a comma separated list of days of the month, such as "15,20,30". For an absolute timer, Days is not used, and Time should be in the format: "yyyy-mm-dd hh:mm:ss"

Data can be a string passed back to the function. The function should be declared so it takes a single argument, which is this data. 

<source lang="lua">function refreshCache(stuff)
....
end

function startup()
--
-- Setup an interval-based timer to call refreshCache after 30 minutes.
-- Note that if you want it to "recur" then you need to call this function again
-- at the end of the refreshCache() implementation.
--
luup.call_timer("refreshCache", 1, "30m", "", "SomeStuff")
end</source>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

version: UI5 and above

Checks whether a device has successfully completed it's startup sequence. If so, <tt>is_ready</tt> returns <tt>true</tt>. If your device shouldn't process incoming data until the startup sequence is finished, you may want to add a condition to the <tt><incoming> block</tt> that only processes data if <tt>is_ready(lul_device)</tt> is <tt>true</tt>.

The <tt>device</tt> parameter, if it's a string, is interpreted as a udn. If it's a number, it's interpreted as a device number.

<source lang="lua"><incoming>
if (luup.is_ready(lul_device) == false) then
return
end

doSomething(lul_device)
</incoming></source>

=== function: call_action ===

parameters: service (string), action (string), arguments (table), device (string or number)

returns: error (number), error_msg (string), job (number), arguments (table)

Invokes the UPnP service + action, passing in the arguments (table of string->string pairs) to the device, which, if it's a string, is interpreted as a udn, and if it's a number, is the device number. If the invocation could not be made, only error will be returned with a value of -1. Otherwise, all 4 values are returned. error is 0 if the UPnP device reported the action was successful. arguments is a table of string->string pairs with the return arguments from the action. If the action is handled asynchronously by a Luup job, then the job number will be returned as a positive integer.

Example to dim device #5 to 50%: 

<source lang="lua">local lul_arguments = {}
lul_arguments["newLoadlevelTarget"]=50
lul_resultcode, lul_resultstring, lul_job, lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", lul_arguments, 5)</source>

=== function: variable_set ===

parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]

returns: nothing

The UPnP service+variable will be set to value for device, which if it's a string, is interpreted as a udn, and if it's a number, as a device id. If there are events or notifications tied to the variable they will be fired.

Optionally, you can add an argument 'startup'. If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will ''not'' be fired.

=== function: variable_get ===

parameters: service (string), variable (string), device (string or number)

returns: value (string), time (number)

If the service+variable or device does not exist, it returns nothing. Otherwise it returns the value of the UPnP service+variable and the time when the variable was last modified, as a unix time stamp (number of seconds since 1/1/1970). You can assign just the value to a variable, as follows: 

<source lang="lua">local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5)
luup.log("Dim level for device #5 is: " .. value)</source>

=== function: attr_set ===

parameters: attribute (string), value(string), device (string or number)

returns: none

Sets the top level attribute for the device to value. Examples of attributes are 'mac', 'name', 'id', etc.

=== function: register_handler ===

parameters: function_name (string), request_name (string)

returns: nothing

When a certain URL is requested from a web browser or other HTTP get, function_name will be called and whatever string it returns will be returned.

See the WAP mobile phone plugin as an example: 

<source lang="lua">luup.register_handler("lug_WapRequest","wap")

function lug_WapRequest (lul_request, lul_parameters, lul_outputformat)
local lul_html = "<head>\n" ..
"<title>Main</title>\n" ..
"</head>\n" ..
"<body>\n" ..
"Choose a room: \n"
return lul_html
end</source>

The request is made with the URL: data_request?id=lr_[the registered name] on port 49451. So: http://192.168.1.1:49451/data_request?id=lr_wap will return the web page defined in the function lug_WapRequest in the example above.

=== function: variable_watch ===

parameters: function_name (string), service (string), variable (string or nill), device (string or number)

returns: nothing

Whenever the UPnP variable is changed for the specified device, which if a string is interpreted as a udn and if a number as a device id, function_name will be called. See [[Luup Declarations#watch_callback]] for the values that will be passed to function_name. If variable is nill, function_name will be called whenever any variable in the service is changed.

 

=== function: devices_by_service ===

parameters:

returns:

=== function: device_supports_service ===

parameters:

returns:

'''Warning:''' luup.device_supports_service doesn't work reliably: http://forum.micasaverde.com/index.php?topic=5600.0

=== function: set_failure ===

parameters: value (boolean), device (string or number)

returns:

Luup maintains a 'failure' flag for every device to indicate if it is not functioning. You can set the flag to true if the device is failing. If device is a string it is interpreted as a udn, if it's a number, as a device id.

=== function: is_night ===

parameters: none

returns: boolean

Returns true if it's past sunset and before sunrise.

 

=== function: sleep ===

parameters: number of milliseconds

returns: none

Sleeps a certain number of milliseconds

'''Warning:''' luup.sleep doesn't work reliably: http://bugs.micasaverde.com/view.php?id=1480

== Module: luup.inet ==

=== function: wget ===

parameters: URL (String), Timeout (Number), Username (String), Password (String)

returns httpStatusCode (Number), content (String)

This reads the URL and returns 2 variables: The first is a numeric error code which is 0 if successful, and the second is a string containing the contents of the page. If Timeout is specified, the function will timeout after that many seconds. If Username and Password are specified, they will be used for HTTP Basic Authentication.

 

== Module: luup.chdev ==

Contains functions for a parent to synchronize its child devices. Whenever a device has multiple end-points, the devices are represented in a parent/child fashion where the parent device is responsible for reporting what child devices it has and giving each one a unique id. For example in the sample [[Luup Somfy Walkthrough]] there is a parent device, which is the interface module that controls up to 16 blinds, and up to 16 child devices, one for each blind. As shown in that sample, the parent calls start, then enumerates each child device with append, and finally calls sync. You will need to pass the same value for device to append and sync that you passed to start.

=== function: start ===

parameters: device (string or number)

returns: ptr (binary object)

Tells Luup you will start enumerating the children of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. The return value is a binary object which you cannot do anything with in Lua, but you do pass it to the append and sync functions.

=== function: append ===

parameters: device (string or number), ptr (binary object), id (string), description (string), device_type (string), device_filename (string), implementation_filename (string), parameters (string), embedded (boolean) [, invisible (boolean)]

returns: nothing

Adds one child to <tt>device</tt>. If <tt>device</tt> is a string it is interpreted as a udn, if it's a number, as a device id.

Pass in the <tt>ptr</tt> which you received from the <tt>luup.chdev.start</tt> call. Give each child a unique id so you can keep track of which is which. You can optionally provide a <tt>description</tt> which the user sees in the user interface.

<tt>device_type</tt> is the UPnP device type, such as <tt>urn:schemas-upnp-org:device:BinaryLight:1</tt>.

If <tt>device_filename</tt> is specified, that is the name of the XML file with the UPnP device specification. The deviceType from the filename will override any <tt>device_type</tt> you set manually. If the device_file contains the implementation file for this child device you do not need to specify it in <tt>implementation_filename</tt>. Otherwise, if there is a Luup implementation for this child device and it's not being handled by the parent device, you can specify it in <tt>implementation_filename</tt>.

If <tt>embedded</tt> is true, the 'embedded' flag is set for the device which generally means that the parent and all the children will be displayed as one compound device, or group, rather than as separate devices which you can put in their own rooms.

The <tt>parameters</tt> are UPnP service,variables you want set when the device is created. You can specify multiple variables by separating them with a line feed (\n) and use a <tt>,</tt> and <tt>=</tt> to separate service, variable and value, like this: <tt>service,variable=value\nservice</tt>...

<source lang="lua">
luup.chdev.append(device, children,
string.format("Input-%d", i), string.format("Input %d", i),
"urn:schemas-micasaverde-com:device:TemperatureSensor:1", "D_TemperatureSensor1.xml",
"", "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=50", true)
</source>

=== function: sync ===

parameters: device (string or number), ptr (binary object),

returns: nothing

If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Tells the Luup engine you have finished enumerating the child devices. If the child devices have changed in any way, the new device tree will be written to the configuration file and the Luup engine is reset.

== Module: io ==

=== function: open ===

parameters: device (string or number), ip (string) port (number),

returns: nothing

If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This opens a socket on 'port' to 'ip' and stores the handle to the socket in 'device'. The opening of a socket can take time depending on the network, and a Luup function should return quickly whenever possible because each top-level device's Lua implementation runs in a single thread. So the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.

Generally you do not need to call the open function because the socket is usually started automatically when the Luup engine starts. This is because the user typically either (a) associates a device with the destination io device, such as selecting an RS232 port for an alarm panel, where the RS232 is proxied by a socket, or (b) because the configuration settings for the device already include an IP address and port.

=== function: write ===

parameters: data (string), device (string or number)

returns: result (boolean)

In Lua a string can contain binary data, so data may be a binary block. If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This sends data on the socket that was opened automatically or with the open function above, and associated to 'device'. If the socket is not already open, write will wait up to 5 seconds for the socket before it returns an error. Result is 'true' if the data was sent successfully, and is 'false' or nill if an error occurred.

=== function: intercept ===

parameters: device (string or number)

returns: nothing

Normally when data comes in on a socket (I/O Port), the block of data is first passed to any pending jobs that are running for the device and are marked as 'waiting for data'. If there are none, or if none of the jobs' incoming data handlers report that they consumed (i.e. processed) the data, then the block of data is passed to the general 'incoming' function handler for the device. If you want to bypass this normal mechanism and read data directly from the socket, call intercept first to tell Luup you want to read incoming data with the read function. This is generally used during the initialization or startup sequences for devices. For example, you may need to send some data (a), receive some response (b), send some more data (c), receive another response (d), etc. In this case you would call 'intercept' first, then send a, then call read and confirm you got b, then call intercept again, then send c, then read d, and so on.

You can call the read function without calling intercept and any incoming data will be returned by that function after it's called. The reason why you generally must call intercept is because normally you want to send some data and get a response. If you write the code like this ''send(data) data=read()'' then it's possible the response will arrive in the brief moment between the execution of send() and read(), and therefore get sent to the incoming data handler for the device. Intercept tells Luup to buffer any incoming data until the next read, bypassing the normal incoming data handler. So ''intercept() send(data) data=read()'' ensures that read will always get the response. If the device you're communicating with sends unsolicited data then there's the risk that the data you read is not the response you're looking for. If so, you can manually pass the response packet to the incoming data handler.

**TBD: Add a function to do this**

=== function: read ===

parameters: timeout (number), device (string or number)

returns: data (string)

This reads a block of data from the socket. You must have called ''intercept'' previously so the data is passed. The time unit for ''timeout'' is seconds. 

=== function: is_connected ===

parameters: device (string or number)

returns: connected (boolean)

This function returns true if there is a valid IO port connected, otherwise returns false

== Module: luup.job ==

=== function: status ===

parameters: job_number (number), device (string or number)

returns: job_status (number), notes (string)

If job_number is invalid the function returns -1. If device is a string it is interpreted as an UDN, if it's a number, as a device ID.

=== function: set ===

parameters: job (userdata), setting (string), value (string)

returns: nothing

This stores a setting for a job.

<source lang="lua"><job>
luup.job.set(lul_job, "comments", "In progress...")
local comments = luup.job.setting(lul_job, "comments")
luup.log("job comments = " .. comments)
</job></source>

=== function: setting ===

parameters: job (userdata), setting (string)

returns: value (string)

This returns a setting for a job.

[[Category:Development]]

Install LUUP Plugins

2011-08-14T20:08:28Z

Guessed: /* Prerequisites */ Reference to avoid using IE...

[[Category:User Instructions]]
[[Category:How To]]
'''HOWTO install LUUP plugins on your Vera.'''

=== Prerequisites ===
* Vera 1 or 2 hardware.
* Luup/Lua capable firmware version (all recent firmwares are).
* Locally available plugin files (downloaded in advance).
* A Web Browser, other than Internet Exporer (IE), to upload the files.

=== Introduction ===
Luup coded plugins can be used for a variety of tasks, like creating scenes, virtual devices and even tweaking your Vera to your own likes. These plugins can be referred to as "beta plugins" or "user-created plugins".

Code is mainly discussed (and sometimes available from) here: [http://forum.micasaverde.com/index.php?board=20.0]

Officially supported plugins are available here [http://code.mios.com]

This manual starts with the assumption you have downloaded the appropriate .json and .xml files to your harddisk.

=== Exclusion ===
These instructions should not be used in combination with plugins that are available through the MiOS Marketplace. Plugins from the Marketplace have a "click and install" functionality.

=== Instructions ===
# Open your Vera UI4.
# Upload the files of the plugin you downloaded to your Vera box: 'MiOS Developers' -> 'Luup files' -> 'Upload files'. Do not check 'Restart Luup after upload' (bottom of the page); if it's checked, uncheck it.
# Go to 'Create device' and create a new Luup device with UpnpDevFilename ''D_<your_plugin>.xml''.
# Set the Description to whatever you want to name the device.
# Restart the Lua engine to initialize the UPnP variables (curving arrows top right in your UI).
# Reload the webpage. Best use <CTRL + F5> to do so.
# Make the appropriate Luup variable settings as per directions for the creator of the plugin.

'''IMPORTANT''': In some cases a power cycle/reboot of your Vera is necessary.

=== References ===
Official repository for plugins:
http://code.mios.com

Alternative location (for now)
[http://wiki.micasaverde.com/index.php/Luup_plugins_and_Luup_code]

Related forum threads are here:

http://forum.micasaverde.com/index.php?board=20.0

- and -

http://forum.micasaverde.com/index.php?topic=6569.0

Luup Lua extensions

2011-08-13T22:40:45Z

Guessed: /* function: is_ready */ Indicate that this isn't implemented until UI5, provide an example snippet.

In addition to the [[http://lua.org Lua]] commands described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]], you can also reference in your Lua code variables and functions from modules which the Luup engine provides as follows:

== Module: luup ==

These are general purpose functions and variables. Call them by using the luup. module, such as: 

<source lang="lua">luup.log('Now running version: ' .. luup.version)</source>

=== variable: device ===

The ID of this device instance, if it's running as part of a device

=== variable: version, version_branch, version_major, version_minor ===

''version'' contains the version of the luup engine, such as "1.0.843", as a string. The version consists of 3 numbers separated by a period: the branch, the major version, and the minor version. To make it easier to compare against a minimum acceptable version, ''version_branch, version_major and version_minor'' return each component as a number. You can put a comparison in the startup function in your Luup plugin and return false if the minimum version isn't met. The user will then see that the Luup device's startup check failed: 

<source lang="lua">if( version_branch ~= 1 or version_major ~= 0 or version_minor < 843 ) then
luup.log("I need version 1.0.843 minimum to run")
return false
end</source>

=== variable: longitude ===

Contains the longitude as a number, as found on the location tab in the setup UI.

=== variable: latitude ===

Contains the latitude as a number, as found on the location tab in the setup UI.

=== variable: timezone ===

Contains the timezone as a number, as found on the location tab in the setup UI.

'''Warning:''' luup.timezone doesn't work.

=== variable: city ===

Contains the city as a string, as found on the location tab in the setup UI.

=== variable: devices ===

Contains all the devices in the system as a table indexed by the device number. The members are: room_num (number), device_type (string), category_num (number), device_num_parent (number), ip (string), mac (string), id (string), description (string), udn (string). [See also: [[Lua Device Structure]].] Example to log device #5's IP addess and its internal ID: 

<source lang="lua">luup.log('Device #5 ip: ' .. luup.devices[5].ip .. ' id: ' .. luup.devices[5].id)</source>

room_num: This is the number of the room the device is in.

device_type: This is a string representing the type of the device.

category_num: This is a category for the device. See: [[Luup_Device_Categories]] for a list.

device_num_parent: This is the number of the parent device. See: [[Lua Device Structure]] for details.

ip: If this device is IP based, this is the IP address.

mac: If this device is IP based, this is the MAC address.

id: If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.

embedded: (boolean) If this device is embedded, it means that it doesn't have its own room or exist as a separate device. It should be considered part of its parent. Like a 3-in-1 sensor is a device with 3 embedded child devices.

hidden: (boolean) If true the user checked the 'hidden' box and doesn't want to see the device on the dashboard.

invisible: (boolean) If true the device is 'for internal use only' and shouldn't be presented to the user.

description: This is the text description for the device as supplied by the user in the web UI.

udn: This is the UDN for the UPnP device.

This code will log all the attributes from all the devices: 

<source lang="lua">for k, v in pairs(lug_device) do
for k2, v2 in v do
luup.log("Device #" .. k .. ":" .. k2 .. "=" .. "v2")
end
end</source>

=== variable: rooms ===

Contains all the rooms as a table of strings indexed by the room number. Example: 

<source lang="lua">luup.log('Room #1 is called: ' .. luup.rooms[1])</source>

=== variable: scenes ===

Contains all the scenes in the system as a table indexed by the scene number. The members are: room_num (number), description(string), hidden(boolean)

=== variable: remotes ===

Contains all the remotes in the system as a table indexed by the remote id. The members are: remote_file (string), room_num (number), description(string)

=== function: log ===

parameters: what_to_log (string), log_level (optional, number)

return: nothing

Writes what_to_log to the log, /var/log/cmh/LuaUPnP.log, with the given log_level, which is 50 by default. See: [[Luup Loglevels]]

=== function: task ===

parameters: message (string), status (number), description (string), handle (number)

return: handle (number)

When the Luup engine is starting status messages are displayed for the various modules as they're initialized. Normally each device, including Luup devices, automatically log their status and the user is shown an error if the device doesn't start, such as if the 'startup' function returns an error.

If you have other startup sequences which you want the user to see to know that startup hasn't finished yet, call this function passing in a handle of -1 for the first call. The status should be: 1=Busy, 2=Error, 4=Successful. Message is the current state, such as 'downloading', and description describes the module, like 'Smartphone UI'. After the first call, store the handle and pass it on future calls to update the status rather than add a new one.

=== function: call_delay ===

parameters: function_name (string), seconds (number), data (string), thread (bool)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name. function_name will only be called once and you must call call_delay again if you want it called again, or use call_timer instead.

If thread is specified and is true or 1, the call back will be made in it's own thread and can block if needed. Normally it is called by a worker thread and is expected to return immediately.

=== function: call_timer ===

parameters: function_name (string), type (number), time (string), days (string), data (string)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called when the timer is triggered, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name.

Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer. For an interval timer, days is not used, and Time should be a number of seconds, minutes, or hours using an optional 'h' or 'm' suffix. Example: 30=call in 30 seconds, 5m=call in 5 minutes, 2h=call in 2 hours. For a day of week timer, Days is a comma separated list with the days of the week where 1=Monday and 7=Sunday. Time is the time of day in hh:mm:ss format. Time can also include an 'r' at the end for Sunrise or a 't' for Sunset and the time is relative to sunrise/sunset. For example: Days="3,5" Time="20:30:00" means your function will be called on the next Wed or Fri at 8:30pm. Days="1,7" Time="-3:00:00r" means your function will be called on the next Monday or Sunday 3 hours before sunrise. Day of month works the same way except Days is a comma separated list of days of the month, such as "15,20,30". For an absolute timer, Days is not used, and Time should be in the format: "yyyy-mm-dd hh:mm:ss"

Data can be a string passed back to the function. The function should be declared so it takes a single argument, which is this data. 

<source lang="lua">function refreshCache(stuff)
....
end

function startup()
--
-- Setup an interval-based timer to call refreshCache after 30 minutes.
-- Note that if you want it to "recur" then you need to call this function again
-- at the end of the refreshCache() implementation.
--
luup.call_timer("refreshCache", 1, "30m", "", "SomeStuff")
end</source>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

version: UI5 and above

Checks whether a device has successfully completed it's startup sequence. If so, <tt>is_ready</tt> returns <tt>true</tt>. If your device shouldn't process incoming data until the startup sequence is finished, you may want to add a condition to the <tt><incoming> block</tt> that only processes data if <tt>is_ready(lul_device)</tt> is <tt>true</tt>.

The <tt>device</tt> parameter, if it's a string, is interpreted as a udn. If it's a number, it's interpreted as a device number.

<source lang="lua"><incoming>
if (luup.is_ready(lul_device) == false) then
return
end

doSomething(lul_device)
</incoming></source>

=== function: call_action ===

parameters: service (string), action (string), arguments (table), device (string or number)

returns: error (number), error_msg (string), job (number), arguments (table)

Invokes the UPnP service + action, passing in the arguments (table of string->string pairs) to the device, which, if it's a string, is interpreted as a udn, and if it's a number, is the device number. If the invocation could not be made, only error will be returned with a value of -1. Otherwise, all 4 values are returned. error is 0 if the UPnP device reported the action was successful. arguments is a table of string->string pairs with the return arguments from the action. If the action is handled asynchronously by a Luup job, then the job number will be returned as a positive integer.

Example to dim device #5 to 50%: 

<source lang="lua">local lul_arguments = {}
lul_arguments["newLoadlevelTarget"]=50
lul_resultcode, lul_resultstring, lul_job, lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", lul_arguments, 5)</source>

=== function: variable_set ===

parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]

returns: nothing

The UPnP service+variable will be set to value for device, which if it's a string, is interpreted as a udn, and if it's a number, as a device id. If there are events or notifications tied to the variable they will be fired.

Optionally, you can add an argument 'startup'. If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will ''not'' be fired.

=== function: variable_get ===

parameters: service (string), variable (string), device (string or number)

returns: value (string), time (number)

If the service+variable or device does not exist, it returns nothing. Otherwise it returns the value of the UPnP service+variable and the time when the variable was last modified, as a unix time stamp (number of seconds since 1/1/1970). You can assign just the value to a variable, as follows: 

<source lang="lua">local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget", 5)
luup.log("Dim level for device #5 is: " .. value)</source>

=== function: attr_set ===

parameters: attribute (string), value(string), device (string or number)

returns: none

Sets the top level attribute for the device to value. Examples of attributes are 'mac', 'name', 'id', etc.

=== function: register_handler ===

parameters: function_name (string), request_name (string)

returns: nothing

When a certain URL is requested from a web browser or other HTTP get, function_name will be called and whatever string it returns will be returned.

See the WAP mobile phone plugin as an example: 

<source lang="lua">luup.register_handler("lug_WapRequest","wap")

function lug_WapRequest (lul_request, lul_parameters, lul_outputformat)
local lul_html = "<head>\n" ..
"<title>Main</title>\n" ..
"</head>\n" ..
"<body>\n" ..
"Choose a room: \n"
return lul_html
end</source>

The request is made with the URL: data_request?id=lr_[the registered name] on port 49451. So: http://192.168.1.1:49451/data_request?id=lr_wap will return the web page defined in the function lug_WapRequest in the example above.

=== function: variable_watch ===

parameters: function_name (string), service (string), variable (string or nill), device (string or number)

returns: nothing

Whenever the UPnP variable is changed for the specified device, which if a string is interpreted as a udn and if a number as a device id, function_name will be called. See [[Luup Declarations#watch_callback]] for the values that will be passed to function_name. If variable is nill, function_name will be called whenever any variable in the service is changed.

 

=== function: devices_by_service ===

parameters:

returns:

=== function: device_supports_service ===

parameters:

returns:

'''Warning:''' luup.device_supports_service doesn't work reliably: http://forum.micasaverde.com/index.php?topic=5600.0

=== function: set_failure ===

parameters: value (boolean), device (string or number)

returns:

Luup maintains a 'failure' flag for every device to indicate if it is not functioning. You can set the flag to true if the device is failing. If device is a string it is interpreted as a udn, if it's a number, as a device id.

=== function: is_night ===

parameters: none

returns: boolean

Returns true if it's past sunset and before sunrise.

 

=== function: sleep ===

parameters: number of milliseconds

returns: none

Sleeps a certain number of milliseconds

'''Warning:''' luup.sleep doesn't work reliably: http://bugs.micasaverde.com/view.php?id=1480

== Module: luup.inet ==

=== function: wget ===

parameters: URL (String), Timeout (Number), Username (String), Password (String)

returns httpStatusCode (Number), content (String)

This reads the URL and returns 2 variables: The first is a numeric error code which is 0 if successful, and the second is a string containing the contents of the page. If Timeout is specified, the function will timeout after that many seconds. If Username and Password are specified, they will be used for HTTP Basic Authentication.

 

== Module: luup.chdev ==

Contains functions for a parent to synchronize its child devices. Whenever a device has multiple end-points, the devices are represented in a parent/child fashion where the parent device is responsible for reporting what child devices it has and giving each one a unique id. For example in the sample [[Luup Somfy Walkthrough]] there is a parent device, which is the interface module that controls up to 16 blinds, and up to 16 child devices, one for each blind. As shown in that sample, the parent calls start, then enumerates each child device with append, and finally calls sync. You will need to pass the same value for device to append and sync that you passed to start.

=== function: start ===

parameters: device (string or number)

returns: ptr (binary object)

Tells Luup you will start enumerating the children of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. The return value is a binary object which you cannot do anything with in Lua, but you do pass it to the append and sync functions.

=== function: append ===

parameters: device (string or number), ptr (binary object), id (string), description (string), device_type (string), device_filename (string), implementation_filename (string), parameters (string), embedded (boolean) [, invisible (boolean)]

returns: nothing

Enumerates one child of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Give each child a unique id so you can keep track of which is which. You can optionally provide a description which the user sees in the user interface. device_type is the UPnP device type, such as urn:schemas-upnp-org:device:BinaryLight:1. If device_filename is specified, that is the name of the XML file with the UPnP device specification. The deviceType from the filename will override any device_type you set manually. If the device_file contains the implementation file for this child device you do not need to specify it in implementation_filename. Otherwise, if there is a Luup implementation for this child device and it's not being handled by the parent device, you can specify it in implementation_filename. If embedded is true, the 'embedded' flag is set for the device which generally means that the parent and all the children will be displayed as one compound device, or group, rather than as separate devices which you can put in their own rooms.

The parameters are UPnP service+variables you want set when the device is created. You can specify multiple variables by separating them with a line feed (\n) and use a , and = to separate service, variable and value, like this: service,variable=value \n service...

=== function: sync ===

parameters: device (string or number), ptr (binary object),

returns: nothing

If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Tells the Luup engine you have finished enumerating the child devices. If the child devices have changed in any way, the new device tree will be written to the configuration file and the Luup engine is reset.

== Module: io ==

=== function: open ===

parameters: device (string or number), ip (string) port (number),

returns: nothing

If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This opens a socket on 'port' to 'ip' and stores the handle to the socket in 'device'. The opening of a socket can take time depending on the network, and a Luup function should return quickly whenever possible because each top-level device's Lua implementation runs in a single thread. So the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.

Generally you do not need to call the open function because the socket is usually started automatically when the Luup engine starts. This is because the user typically either (a) associates a device with the destination io device, such as selecting an RS232 port for an alarm panel, where the RS232 is proxied by a socket, or (b) because the configuration settings for the device already include an IP address and port.

=== function: write ===

parameters: data (string), device (string or number)

returns: result (boolean)

In Lua a string can contain binary data, so data may be a binary block. If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This sends data on the socket that was opened automatically or with the open function above, and associated to 'device'. If the socket is not already open, write will wait up to 5 seconds for the socket before it returns an error. Result is 'true' if the data was sent successfully, and is 'false' or nill if an error occurred.

=== function: intercept ===

parameters: device (string or number)

returns: nothing

Normally when data comes in on a socket (I/O Port), the block of data is first passed to any pending jobs that are running for the device and are marked as 'waiting for data'. If there are none, or if none of the jobs' incoming data handlers report that they consumed (i.e. processed) the data, then the block of data is passed to the general 'incoming' function handler for the device. If you want to bypass this normal mechanism and read data directly from the socket, call intercept first to tell Luup you want to read incoming data with the read function. This is generally used during the initialization or startup sequences for devices. For example, you may need to send some data (a), receive some response (b), send some more data (c), receive another response (d), etc. In this case you would call 'intercept' first, then send a, then call read and confirm you got b, then call intercept again, then send c, then read d, and so on.

You can call the read function without calling intercept and any incoming data will be returned by that function after it's called. The reason why you generally must call intercept is because normally you want to send some data and get a response. If you write the code like this ''send(data) data=read()'' then it's possible the response will arrive in the brief moment between the execution of send() and read(), and therefore get sent to the incoming data handler for the device. Intercept tells Luup to buffer any incoming data until the next read, bypassing the normal incoming data handler. So ''intercept() send(data) data=read()'' ensures that read will always get the response. If the device you're communicating with sends unsolicited data then there's the risk that the data you read is not the response you're looking for. If so, you can manually pass the response packet to the incoming data handler.

**TBD: Add a function to do this**

=== function: read ===

parameters: timeout (number), device (string or number)

returns: data (string)

This reads a block of data from the socket. You must have called ''intercept'' previously so the data is passed. The time unit for ''timeout'' is seconds. 

=== function: is_connected ===

parameters: device (string or number)

returns: connected (boolean)

This function returns true if there is a valid IO port connected, otherwise returns false

== Module: luup.job ==

=== function: status ===

parameters: job_number (number), device (string or number)

returns: job_status (number), notes (string)

If job_number is invalid the function returns -1. If device is a string it is interpreted as an UDN, if it's a number, as a device ID.

=== function: set ===

parameters: job (userdata), setting (string), value (string)

returns: nothing

This stores a setting for a job.

<source lang="lua"><job>
luup.job.set(lul_job, "comments", "In progress...")
local comments = luup.job.setting(lul_job, "comments")
luup.log("job comments = " .. comments)
</job></source>

=== function: setting ===

parameters: job (userdata), setting (string)

returns: value (string)

This returns a setting for a job.

[[Category:Development]]

Update Firmware

2011-07-29T20:33:19Z

Guessed: Minor tweaks to make formatting clearer, and menu's work correctly.

[[Category:How To]]

'''How to update Vera to a new firmware'''

== Prerequisites ==
* Vera Hardware (either Vera 1 or Vera 2)
* Internet connection
* Reliable power source (Do NOT update Vera while on battery operation)

== Introduction ==
Your Vera box can be upgraded with software from MiOS. You can either be asked to upgrade automatically or you can decide to do a manual upgrade at any point in time.

=== General Notice ===
When installing the firmware, make sure you have the login to your vera system set to standard (no http login needed) via the remote control server.

If you have chosen http authentication "YES" from the https://cp.mios.com site (settings section) you will get a pop up where you should enter username and password.
Currently there is an issue that this pop-up disappears within 10 seconds in some browswers. Most users will therefore be unable to provide their username and password.

The current workaround is to
* disable authentication
* upgrade
* re-enable the authentication from cp.mios.com

== Upgrades ==

=== Create a backup! ===
You can create and restore backup form the advanced settings section in your toolbox. After double clicking that, go to the "BACKUP" tab.
If you check the "Backup my configuration at MiOS.com" option, Vera will automatically backup your configuration online each night so that if Vera breaks and we send you another one, you can go to MiOS.com, download the last backup file, and restore it so you don't need to setup Vera again.
MiOS.com keeps 5 daily backups, so if you somehow mess up Vera's setup, you can also restore Vera to a prior backup.

To manually backup Vera, click 'Create Backup'. Vera will give you a backup file to save to your PC.

To restore a backup file, either one that you created manually with 'Create Backup', or an automatic backup at MiOS.com, click 'Browse' to find the backup file, select it, and click 'Restore'.

You can also click 'Restore to Factory Defaults' to reset Vera's configuration just like it was when Vera first arrived.

=== Manual Upgrades ===

To manually load a firmware to your Vera:
* click the Advanced icon in the toolbox section of your Vera's UI.
* Select the tab "FIRMWARE"
* Vera automatically checks connectivity to the download server (download1.mios.com or download2.mios.com).
* Vera shows you the current firmware version and provides info if this firmware is up to date or not.
* You can upgrade your Vera by dropping a specific download URL for your Vera in the "URL for MiOS custom firmware" box. 
Please contact MiOS for the correct URL first.

=== Automatic Upgrades ===
*NOTE: Updating a Vera 1 to the latest official firmware requires an intermediate step. Always consult MiOS tech support when attempting to upgrade your Vera 1 to the latest firmware when your current firmware is older than 1.1.1062.

See also:
http://wiki.micasaverde.com/index.php/Vera1_To_Vera2_Migration

You can automatically update your Vera by accepting the pop-up notice that a new firmware is available, asking you if you want to upgrade. 
Also you can go to this url: 
http://micasaverde.com/vera2

From there you can follow the steps to automatically update your Vera to the latest official firmware release.

== Known Issues ==
* Vera 1 upgrading to 1.1.1245 directly from a version older than 1.1.1062 does not work. Please contact tech support at MiOS and ask them to help you install intermediate release 1.1.1062.
* Sometimes an upgrade makes Vera go back to her default locale settings (USA). For users in the EU their devices do not work anymore. As for the locale issue mentioned in this thread, please refer to [http://forum.mios.com/index.php?topic=6652.0 this Forum post]

== References ==
* Update URL for your Vera 1 or 2 Hardware http://micasaverde.com/vera2
* Recovery procedures
** Vera 1 hardware [http://wiki.micasaverde.com/index.php/Firmware_Flash_Vera_1 Recovery]
** Vera 2 hardware [http://wiki.micasaverde.com/index.php/Firmware_Flash_Vera2 Recovery]
Note: To be done only if you Vera unit doesn't boot anymore!!! See in each link how the leds should blink if this is the case !!!

* Related forum threads
** http://forum.mios.com/index.php?topic=6652.0 
** http://forum.mios.com/index.php?topic=4423.0

Store logs USB

2011-05-18T02:11:58Z

Guessed: Minor edits to simplify and standardize the page

[[Category:User Instructions]]
[[Category:How To]]
'''HOWTO get your Vera log an attached USB drive.'''

==Introduction==
On larger Vera deployments, with large numbers of Z-Wave Devices, Plugins or Scenes, it may be necessary to move the Vera log files to external storage to free-up space for Vera to function correctly.

MiOS Version 1.1.1245 introduced an option to let users attach a standard USB drive to offload Vera's log files, the details are in the MiOS [[Release Notes]], inlined here:

:''2. There is an option with Vera2 on Advanced, Logs to enable logging to a USB drive. This frees up quite a bit of memory, so if you have a lot of devices or plugins and your Vera is running slow or crashing because it's running out of memory, this is a solution. Note that after you check the box it can take up to 30 minutes to format the USB drive, and bootup will take a couple minutes longer with the USB drive installed. It will continue to boot up fine without the USB drive connected, just don't remove it while Vera is running. ''

:''IMPORTANT: Use a new USB drive that hasn't already been formatted. In particular, don't use a USB drive that is already formatted for Mac''

This [[:Category:How To|How To]] note shows you how to enable this option, how to validate that it's been enabled, and provides pointers to further reading.

==Prerequisites==
This solution will requires:
* Vera 2 Hardware ''only''
* Firmware 1.1.1245 and above
* A ''new'' USB Drive
** Drive should be between 512Mb and 1Gb
** Vera will create its own partition on it which will be 512Mb in size and use that to write logfiles to it.
** Experienced users only: a ''newly'' FAT-formatted ''existing'' USB drive may work. The jury is out on this one.

==Instructions==

* After you got your usb-drive connected to the USB port on the backside of your Vera. Please be patient, it might not work the first time, but it will work. DO NOT REMOVE THE DRIVE while Vera boots/reboots or during power-cycle operations.
* Log into the UI
* Select "Advanced" on the sop right (next to "MiOS developers" in the toolbox)
* Select the "Logs"tab
* Activate the "Store logs on USB device*" option and READ the text there:
: ''Please connect an USB drive first then check the checkbox.''
: ''WARNING: The USB drive will be erased. Wait 20 minutes after clicking OK.''
: ''Status''
* Click the "OK" button.

Wait until vera reports progress.

If MiOS reports "FAILURE", repeat the process.
If MiOS reports Success, you are done.

==Validation==
For those who would like to validate it's setup correctly, here are some detailed steps.

SSH into your vera (using Putty or any other SSH client)
Login as <tt>root</tt> with the password thats on the back of your box.

At the prompt type:
root@MiOS_1xxxx:~# df -h

If you find something like:
Filesystem Size Used Available Use% Mounted on
...
/dev/scsi/host0/bus0/target0/lun0/part1
506.2M 29.2M 451.3M 6% /tmp/log/cmh
...

Then your USB drive is being used to storing MiOS log files.

==References==
* USB Drive logging discussion [http://forum.micasaverde.com/index.php?topic=6439]

Category:How To

2011-05-18T00:50:13Z

Guessed: Removing all content from page

Category:How Tos

2011-05-18T00:46:55Z

Guessed: Removing all content from page

Security device

2011-05-17T17:47:09Z

Guessed:

[[Category:User Instructions]]
[[Category:How To's]]

Here are some general answers to "How can I..."
You may find more info in the linked forumthreads.

==A==
==B==
==C==
==D==
==E==
==F==
==G==
==H==
==I==
==J==
==K==
==L==
==M==
==N==
==O==
==P==
==Q==
==R==
==S==
===Security===
====Make a button on a Z-Wave handheld remote be a 'panic' button that sends out a text message====
Add yourself and your contact information on the [[Users]] page, add the handheld remote using Method #2 in create a scene and attach the event 'Scene button is pressed' as explained in [[ZWave_Add_Controller]], and check off your user name in the notification section of the event.
==T==
==U==
===USB===
====How to store vera's logs onto an USB drive====
see here how to [[Store logs USB]]

==V==
==W==
==X==
==Y==
==Z==

Paradox Alarm Plugin

2011-04-04T17:04:38Z

Guessed: Undo revision 2829 by Silviu.parvana (Talk) Content lives at code.mios.com, not here!

[[Category:Plugins]]
[[Category:3rd Party]]
This page has moved to the MiOS Code Respository, along with it's Installation procedures

http://code.mios.com/trac/mios_paradox-alarm

Luup Lua extensions

2011-01-22T01:16:42Z

Guessed: /* function: variable_set */ Changed wording a little to make intent clearer for variable_set's startup parameter (introduced 1.1.1174)

In addition to the [[http://lua.org Lua]] commands described in the [[http://www.lua.org/manual/5.1/ Lua reference manual]], you can also reference in your Lua code variables and functions from modules which the Luup engine provides as follows:

== Module: luup ==

These are general purpose functions and variables. Call them by using the luup. module, such as:

luup.log('Now running version: ' .. luup.version)

=== variable: device ===

The ID of this device instance, if it's running as part of a device

=== variable: version, version_branch, version_major, version_minor ===

''version'' contains the version of the luup engine, such as "1.0.843", as a string. The version consists of 3 numbers separated by a period: the branch, the major version, and the minor version. To make it easier to compare against a minimum acceptable version, ''version_branch, version_major and version_minor'' return each component as a number. You can put a comparison in the startup function in your Luup plugin and return false if the minimum version isn't met. The user will then see that the Luup device's startup check failed:

if( version_branch~=1 or version_major~=0 or version_minor<843 ) then
luup.log("I need version 1.0.843 minimum to run")
return false
end

=== variable: longitude ===

Contains the longitude as a number, as found on the location tab in the setup UI.

=== variable: latitude ===

Contains the latitude as a number, as found on the location tab in the setup UI.

=== variable: timezone ===

Contains the timezone as a number, as found on the location tab in the setup UI.

=== variable: city ===

Contains the city as a string, as found on the location tab in the setup UI.

=== variable: devices ===

Contains all the devices in the system as a table indexed by the device number. The members are: room_num (number), device_type (string), category_num (number), device_num_parent (number), ip (string), mac (string), id (string), description (string), udn (string). [See also: [[Lua Device Structure]].] Example to log device #5's IP addess and its internal ID:

luup.log('Device #5 ip: ' .. luup.devices[5].ip .. ' id: ' .. luup.devices[5].id)

room_num: This is the number of the room the device is in.

device_type: This is a number representing the type of device. See: [[Luup Device Types Categories]] for a list.

category_num: This is a category for the device. [See: [[Luup Device Types Categories]]]

device_num_parent: This is the number of the parent device. See: [[Lua Device Structure]] for details.

ip: If this device is IP based, this is the IP address.

mac: If this device is IP based, this is the MAC address.

id: If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.

embedded: (boolean) If this device is embedded, it means that it doesn't have its own room or exist as a separate device. It should be considered part of its parent. Like a 3-in-1 sensor is a device with 3 embedded child devices.

hidden: (boolean) If true the user checked the 'hidden' box and doesn't want to see the device on the dashboard.

invisible: (boolean) If true the device is 'for internal use only' and shouldn't be presented to the user.

description: This is the text description for the device as supplied by the user in the web UI.

udn: This is the UDN for the UPnP device.

This code will log all the attributes from all the devices:

for k,v in pairs(lug_device) do
for k2,v2 in v
luup.log("Device #" .. k .. ":" .. k2 .. "=" .. "v2")
end
end

=== variable: rooms ===

Contains all the rooms as a table of strings indexed by the room number. Example:

luup.log('Room #1 is called: ' .. luup.rooms[1])

=== variable: scenes ===

Contains all the scenes in the system as a table indexed by the device number. The members are: room_num (number), description(string), hidden(boolean)

=== variable: remotes ===

Contains all the remotes in the system as a table indexed by the remote id. The members are: remote_file (string), room_num (number), description(string)

=== function: log ===

parameters: what_to_log (string), log_level (optional, number)

return: nothing

Writes what_to_log to the log, /var/log/cmh/LuaUPnP.log, with the given log_level, which is 50 by default. See: [[Luup Loglevels]]

=== function: task ===

parameters: message (string), status (number), description (string), handle (number)

return: handle (number)

When the Luup engine is starting status messages are displayed for the various modules as they're initialized. Normally each device, including Luup devices, automatically log their status and the user is shown an error if the device doesn't start, such as if the 'startup' function returns an error.

If you have other startup sequences which you want the user to see to know that startup hasn't finished yet, call this function passing in a handle of -1 for the first call. The status should be: 1=Busy, 2=Error, 4=Successful. Message is the current state, such as 'downloading', and description describes the module, like 'Smartphone UI'. After the first call, store the handle and pass it on future calls to update the status rather than add a new one.

=== function: call_delay ===

parameters: function_name (string), seconds (number), data (string), thread (bool)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name. function_name will only be called once and you must call call_delay again if you want it called again, or use call_timer instead.

If thread is specified and is true or 1, the call back will be made in it's own thread and can block if needed. Normally it is called by a worker thread and is expected to return immediately.

=== function: call_timer ===

parameters: function_name (string), type (number), time (string), days (string), data (string)

returns: result (number)

The function 'function_name', which must be passed as a string, will be called when the timer is triggered, and will be passed the string 'data'. The function returns 0 if successful. See: [[Luup Declarations#timed_function_callback]] for the names and syntax of the parameters that will be passed to function_name.

Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer. For an interval timer, days is not used, and Time should be a number of seconds, minutes, or hours using an optional 'h' or 'm' suffix. Example: 30=call in 30 seconds, 5m=call in 5 minutes, 2h=call in 2 hours. For a day of week timer, Days is a comma separated list with the days of the week where 1=Monday and 7=Sunday. Time is the time of day in hh:mm:ss format. Time can also include an 'r' at the end for Sunrise or a 't' for Sunset and the time is relative to sunrise/sunset. For example: Days="3,5" Time="20:30:00" means your function will be called on the next Wed or Fri at 8:30pm. Days="1,7" Time="-3:00:00r" means your function will be called on the next Monday or Sunday 3 hours before sunrise. Day of month works the same way except Days is a comma separated list of days of the month, such as "15,20,30". For an absolute timer, Days is not used, and Time should be in the format: "yyyy-mm-dd hh:mm:ss"

Data can be a string passed back to the function. The function should be declared so it takes a single argument, which is this data.
<pre>function refreshCache(stuff)
....
end

function startup()
--
-- Setup an interval-based timer to call refreshCache after 30 minutes.
-- Note that if you want it to "recur" then you need to call this function again
-- at the end of the refreshCache() implementation.
--
luup.call_timer("refreshCache", 1, "30m", "", "SomeStuff")
end
</pre>
=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

Checks whether device - which, if it's a string, is interpreted as a udn, and if it's a number, as the device number - is ready and has successfully completed the startup sequence. If so, ready is true. If your device shouldn't process incoming data until the startup sequence is finished, you may want to add a check to the incoming function handler that ignores any data if is_ready(lul_device) isn't true.

=== function: call_action ===

parameters: service (string), action (string), arguments (table), device (string or number)

returns: error (number), error_msg (string), job (number), arguments (table)

Invokes the UPnP service + action, passing in the arguments (table of string->string pairs) to the device, which, if it's a string, is interpreted as a udn, and if it's a number, is the device number. If the invocation could not be made, only error will be returned with a value of -1. Otherwise, all 4 values are returned. error is 0 if the UPnP device reported the action was successful. arguments is a table of string->string pairs with the return arguments from the action. If the action is handled asynchronously by a Luup job, then the job number will be returned as a positive integer.

Example to dim device #5 to 50%:

local lul_arguments = {}
lul_arguments["newLoadlevelTarget"]=50
lul_resultcode,lul_resultstring,lul_job,lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",lul_arguments,5)

=== function: variable_set ===

parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]

returns: nothing

The UPnP service+variable will be set to value for device, which if it's a string, is interpreted as a udn, and if it's a number, as a device id. If there are events or notifications tied to the variable they will be fired.

Optionally, you can add an argument 'startup'. If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will ''not'' be fired.

=== function: variable_get ===

parameters: service (string), variable (string), device (string or number)

returns: value (string), time (number)

If the service+variable or device does not exist, it returns nothing. Otherwise it returns the value of the UPnP service+variable and the time when the variable was last modified, as a unix time stamp (number of seconds since 1/1/1970). You can assign just the value to a variable, as follows:

local value = luup.variable_get("urn:upnp-org:serviceId:Dimming1","LoadLevelTarget",5)
luup.log("Dim level for device #5 is: " .. value)

=== function: attr_set ===

parameters: attribute (string), value(string), device (string or number)

returns: none

Sets the top level attribute for the device to value. Examples of attributes are 'mac', 'name', 'id', etc.

=== function: register_handler ===

parameters: function_name (string), request_name (string)

returns: nothing

When a certain URL is requested from a web browser or other HTTP get, function_name will be called and whatever string it returns will be returned.

See the WAP mobile phone plugin as an example:

luup.register_handler("lug_WapRequest","wap")

function lug_WapRequest (lul_request, lul_parameters, lul_outputformat)
local lul_html = "<head>\n" ..
"<title>Main</title>\n" ..
"</head>\n" ..
"<body>\n" ..
"Choose a room: \n"
return lul_html
end

The request is made with the URL: data_request?id=lr_[the registered name] on port 49451. So: http://192.168.1.1:49451/data_request?id=lr_wap will return the web page defined in the function lug_WapRequest in the example above.

=== function: variable_watch ===

parameters: function_name (string), service (string), variable (string or nill), device (string or number)

returns: nothing

Whenever the UPnP variable is changed for the specified device, which if a string is interpreted as a udn and if a number as a device id, function_name will be called. See [[Luup Declarations#watch_callback]] for the values that will be passed to function_name. If variable is nill, function_name will be called whenever any variable in the service is changed.

 

=== function: devices_by_service ===

parameters:

returns:

=== function: device_supports_service ===

parameters:

returns:

=== function: set_failure ===

parameters: value (boolean), device (string or number)

returns:

Luup maintains a 'failure' flag for every device to indicate if it is not functioning. You can set the flag to true if the device is failing. If device is a string it is interpreted as a udn, if it's a number, as a device id.

=== function: is_night ===

parameters: none

returns: boolean

Returns true if it's past sunset and before sunrise.

=== function: sleep ===

parameters: number of milliseconds

returns: none

Sleeps a certain number of milliseconds

== Module: luup.inet ==

=== function: wget ===

parameters: URL (String), Timeout (Number), Username (String), Password (String)

returns httpStatusCode (Number), content (String)

This reads the URL and returns 2 variables: The first is a numeric error code which is 0 if successful, and the second is a string containing the contents of the page. If Timeout is specified, the function will timeout after that many seconds. If Username and Password are specified, they will be used for HTTP Basic Authentication.

 

== Module: luup.chdev ==

Contains functions for a parent to synchronize its child devices. Whenever a device has multiple end-points, the devices are represented in a parent/child fashion where the parent device is responsible for reporting what child devices it has and giving each one a unique id. For example in the sample [[Luup Somfy Walkthrough]] there is a parent device, which is the interface module that controls up to 16 blinds, and up to 16 child devices, one for each blind. As shown in that sample, the parent calls start, then enumerates each child device with append, and finally calls sync. You will need to pass the same value for device to append and sync that you passed to start.

=== function: start ===

parameters: device (string or number)

returns: ptr (binary object)

Tells Luup you will start enumerating the children of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. The return value is a binary object which you cannot do anything with in Lua, but you do pass it to the append and sync functions.

=== function: append ===

parameters: device (string or number), ptr (binary object), id (string), description (string), device_type (string), device_filename (string), implementation_filename (string), parameters (string), embedded (boolean) [, invisible (boolean)]

returns: nothing

Enumerates one child of device. If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Give each child a unique id so you can keep track of which is which. You can optionally provide a description which the user sees in the user interface. device_type is the UPnP device type, such as urn:schemas-upnp-org:device:BinaryLight:1. If device_filename is specified, that is the name of the XML file with the UPnP device specification. The deviceType from the filename will override any device_type you set manually. If the device_file contains the implementation file for this child device you do not need to specify it in implementation_filename. Otherwise, if there is a Luup implementation for this child device and it's not being handled by the parent device, you can specify it in implementation_filename. If embedded is true, the 'embedded' flag is set for the device which generally means that the parent and all the children will be displayed as one compound device, or group, rather than as separate devices which you can put in their own rooms.

The parameters are UPnP service+variables you want set when the device is created. You can specify multiple variables by separating them with a line feed (\n) and use a , and = to separate service, variable and value, like this: service,variable=value \n service...

=== function: sync ===

parameters: device (string or number), ptr (binary object),

returns: nothing

If device is a string it is interpreted as a udn, if it's a number, as a device id. Pass in the ptr which you received from the start function. Tells the Luup engine you have finished enumerating the child devices. If the child devices have changed in any way, the new device tree will be written to the configuration file and the Luup engine is reset.

== module: io ==

=== function: open ===

parameters: device (string or number), ip (string) port (number),

returns: nothing

If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This opens a socket on 'port' to 'ip' and stores the handle to the socket in 'device'. The opening of a socket can take time depending on the network, and a Luup function should return quickly whenever possible because each top-level device's Lua implementation runs in a single thread. So the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.

Generally you do not need to call the open function because the socket is usually started automatically when the Luup engine starts. This is because the user typically either (a) associates a device with the destination io device, such as selecting an RS232 port for an alarm panel, where the RS232 is proxied by a socket, or (b) because the configuration settings for the device already include an IP address and port.

=== function: write ===

parameters: data (string), device (string or number)

returns: result (boolean)

In Lua a string can contain binary data, so data may be a binary block. If 'device' is a string it is interpreted as a UDN; if it's a number, as a device ID. This sends data on the socket that was opened automatically or with the open function above, and associated to 'device'. If the socket is not already open, write will wait up to 5 seconds for the socket before it returns an error. Result is 'true' if the data was sent successfully, and is 'false' or nill if an error occurred.

=== function: intercept ===

parameters: device (string or number)

returns: nothing

Normally when data comes in on a socket (I/O Port), the block of data is first passed to any pending jobs that are running for the device and are marked as 'waiting for data'. If there are none, or if none of the jobs' incoming data handlers report that they consumed (i.e. processed) the data, then the block of data is passed to the general 'incoming' function handler for the device. If you want to bypass this normal mechanism and read data directly from the socket, call intercept first to tell Luup you want to read incoming data with the read function. This is generally used during the initialization or startup sequences for devices. For example, you may need to send some data (a), receive some response (b), send some more data (c), receive another response (d), etc. In this case you would call 'intercept' first, then send a, then call read and confirm you got b, then call intercept again, then send c, then read d, and so on.

You can call the read function without calling intercept and any incoming data will be returned by that function after it's called. The reason why you generally must call intercept is because normally you want to send some data and get a response. If you write the code like this ''send(data) data=read()'' then it's possible the response will arrive in the brief moment between the execution of send() and read(), and therefore get sent to the incoming data handler for the device. Intercept tells Luup to buffer any incoming data until the next read, bypassing the normal incoming data handler. So ''intercept() send(data) data=read()'' ensures that read will always get the response. If the device you're communicating with sends unsolicited data then there's the risk that the data you read is not the response you're looking for. If so, you can manually pass the response packet to the incoming data handler.

**TBD: Add a function to do this**

=== function: read ===

parameters: timeout (number), device (string or number)

returns: data (string)

This reads a block of data from the socket. You must have called intercept previously so the data is passed.

=== function: is_connected ===

parameters: device (string or number)

returns: connected (boolean)

This function returns true if there is a valid IO port connected, otherwise returns false

=== Job Handling ===

lu_job_set

lu_job_get

[[Category:Development]]

Rooms

2011-01-21T14:43:29Z

Guessed: Undo revision 2657 by TimothyJenkins (Talk) Rookie Spammer, removed content.

[[Category:User Instructions]]
[[Category:Glossary]]
All the devices and scenes in Vera are grouped by room. So you must list the rooms in your house, and then on the 'Devices' page, you need to specify which rooms your devices are in. Some devices, like handheld controllers, may be used throughout the house. In this case, just pick the room where the device is most commonly used or kept. The sole purpose of rooms is to help organize your devices and scenes so you can find them easily and and keep track of which is which. So you don't have to take the term "Room" too literally. You could, for example, create a "Room" called "Back yard" or "Outdoors", or even a room called "John's stuff".

When you create a scene you generally add the scene to a room as well, namely whatever room you are most likely to want to use the scene in. Again, this is just to help organize your scenes and remember which scene is which. Note that what room you add a scene to does not have any effect on which devices it can control. For example, you can create a scene in the "Living Room" that turns on bedroom lights. Create the scene in whatever room you are most likely to want to use that scene. The reason for putting scenes in rooms is just to make it easier to keep track of which scene is which and to quickly find the scenes for the room you are in. For example, on remote controls like iPhone and mobile phones, when you enter a room you need only pick the room once. Then you will see all the scenes in that room without being distracted by all the other scenes in other rooms. This also means you can create multiple scenes with the same name in different rooms. For example, you may have 3 scenes called "go to bed" in 3 different bedrooms. Each scene may do something different.

There may be a couple scenes that are not really tied to a room, or are used throughout the home or in different rooms. For example, you may have a scene called "Entertaining Mode" which you use when guests arrive. You could put this scene in any room that will allow you to easily find it, remember the purpose of putting scenes in rooms is solely to make it easier for you to find the scenes. In a case like this, "Entertaining Mode" would probably be put in the "Entry Room" or "Living Room" if that's where you usually greet your guests. If you truly want a "global scene", meaning a scene that you would normally use from anywhere in the home, then you will note on the 'Scenes' tab there is a special place called "Global Scenes" to add those scenes. If you add a scene to "Global Scenes", then it's like adding to every room. For example, say you create a global scene called "Energy savings mode" that turns off all the lights in the home. And, say you have an iPhone you use as a remote control. The iPhone will let you pick the room it's in, but no matter what room you pick, you'll see the global scene "Energy savings mode". If the iPhone is showing the Living Room, you'll see the global scene ''plus'' the scenes in the Living Room. The global scenes appear in every room. On the [[Dashboard]] the global scenes appear at the top.

For more advanced users, if you have a very large house, or if you want to create graphical floorplans to control the devices with icons, you can also create "Sections", and organize the rooms by section. Examples of sections may be: "First Floor" and "Second Floor", or "Main House", "Guest House" and "Grounds". Create sections by clicking the "Advanced" tab and choosing the sub-tab "Sections". You can create a floorplan for each section using your favorite paint or draw program and upload them to Vera on that page. You can also position the devices on the floorplan. Before you do this, go back to the 'Rooms' tab and be sure to indicate which section each room is in. Since most users don't create sections, by default Vera has only one section "My Home" and all rooms are put there.

Luup Debugging

2011-01-16T17:10:11Z

Guessed: /* Luup logs */ Add info about where Vera2's password is.

[[Category:Development]]
This document assumes you have already read [[Luup_Intro]] for a general introduction to Luup, [[Luup_Plugins]] to learn what goes into a plugin, and that you are creating the Luup plugin using either the web-based Luup plugin generator (coming soon) or are creating Luup's XML files by hand as described here: [[Luup_Plugins_ByHand]]. This document will help you debug the Lua code that you write and see what's going on with your plugins.

To learn about Lua, see [http://www.lua.org/ lua.org] and the [http://www.lua.org/manual/5.1/ Lua reference manual] which lists all the functions and variables that are built into Lua.

The [http://lua-users.org/wiki/TutorialDirectory Lua Tutorial], on [http://Lua-Users.org lua-users.org], can also be of great help here.

Additionally, the Luup engine provides a set of [[Luup_Lua_extensions|Extensions]] (variables and functions) you can call
within your Lua code.

==Third party tools==

There are tools that will aid you in debugging your plugin:

*'''putty''' If you are using Microsoft Windows you can download a utility, putty, to login to Vera's console here: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe] You don't need to install putty. Just put the .exe file on your desktop, run it, and in the host name type in the IP address of Vera and click 'open'. At the ''<tt>login as:</tt>'' prompt enter the username: ''<tt>root</tt>'' and then when prompted enter the root password you setup.

*'''DeviceSpy / Intel Tools for UPnP''' This is a set of tools for Microsoft Windows you can download here: [http://www.intel.com/cd/ids/developer/asmo-na/eng/downloads/upnp/tools/218896.htm?desturl=http://softwarecommunity.intel.com/isn/downloads/zips/IntelToolsForUPnPTechnology.zip] We use the utility called ''DeviceSpy''

==Luup logs==
Vera is running Linux, and you can login to Vera's console to monitor the logs. A special user, called ''root'', is used to login to Vera. The password setup mechanism is different between Vera1 or a Vera2 models.

=== Logging in on Vera1 ===
The ''root'' password must first be set in Vera's configuration menu's. Do this by either going to Vera's Advanced, Net & Wi-fi tab and clicking 'Advanced configuration'

Alternatively, at a Windows prompt, you can type ''telnet vera_ip'' (where vera_ip is the IP address of Vera). If you login with telnet, type: ''passwd'' and press enter to set a root password.

=== Logging in on Vera2 ===
The ''root'' password for a Vera2 box is printed on a label on the underside of the box.

=== Getting around ===
If you have a Mac or Linux PC you can now login directly to Vera using ''ssh''. From the console type: ''ssh root@vera_ip'' (where vera_ip is the IP address of Vera). If you are using Windows, use putty as described above.

When you are at the ''root@HomeControl:~#'' prompt type in:

''cd /var/log/cmh''

to go to the log directory. The command:

''ls -lh''

lists all the log files.

<tt>LuaUPnP.log</tt> is the main log file. To see everything that is being logged by Luup in real time is called "tailing the log".

Do this by typing:

''tail -f LuaUPnP.log''

To stop following the log press '''Ctrl+C'''. Press the up arrow to scroll through the recent commands to run them again by hitting enter, without retyping them.

Note that Vera doesn't have a lot of memory for the logs. So regularly you will see the logs say 'Going to rotate logs' and then stop. This means the memory filled up so the logs are being removed. If the check box in Vera's Advanced, Logs page "Archive old logs on findvera (recommended)" is checked, the logs will be sent to Mi Casa Verde's server and archived for 7 days before purging.

TODO: We'll add instructions for logging to a USB memory stick so you have more room.

Each line starts with the log level and the date time, such as:

02 06/12/09 18:50:15.254

The first number, log level, has this meaning:

*01 - Critical error. Something is wrong that shouldn't happen
*02 - Warning. This is something to make note of, though it's not always a problem
*03 - StartStop. These log messages indicate Luup engine is starting/stopping. This happens every time you save configuration changes.
*04 - Job. This relates to 'jobs'
*05 - Home Automation. These logs are status messages from Home Automation devices
*06 - Variable. A UPnP Variable has changed
*07 - Event. An event is triggered. This is what you attach to a scene
*08 - Action. A UPnP Action was received
*09 - Enumeration. When the Luup engine starts this lists all the devices in the system.
*10 - General Status. There are lots of these messages to indicate something happening in the system.
*40 - outgoing data. This is all data coming and going to external devices, such as the Z-Wave dongle, in their raw form. This true for your Luup plugins talking to serial/network devices too.
*41 - incoming data (as above)
*50 - Lua code. When you log something in Lua code using the <tt>luup.log</tt> function it has this log level.
*51 - Raw outgoing Serial data, from any Serial port attached to the Plugin.
*52 - Raw incoming Serial data, from any Serial port attached to the Plugin.
*200 - UPnP message. There are a huge amount of logs generated from the UPnP engine showing all activity.

By default the Luup engine will skip logs with status 10 and 200 because they generate such a large amount of activity. Vera can actually be less reliable when 10 and 200 are activated because the logs grow so quickly sometimes that it is hard to archive them as fast as they come in.

You can see what logs will shown by typing:

''cat /etc/cmh/cmh.conf''

By default you will see:

LogLevels = 1,2,3,4,5,6,7,8,9,50

meaning the Luup engine will log those log levels and ignore the rest. When you click 'Verbose logging' in Vera's web UI under setup, logs, you will see:

#LogLevels = 1,2,3,4,5,6,7,8,9,50

The <tt>#</tt> in front means the log levels are ignored and all logs are stored, except UPnP. If you really want to see the UPnP messages, which will fill up the memory very fast, you can type

''vi /etc/cmh/cmh.conf''

and move the cursor on top of the 0 in LogUPnP = 0. Then press ''r1'' to replace the 0 with a 1, and then type '':wq'' to write the changes and quit. These somewhat arcane commands are part of Linux's default text editor, vi. After you make a change, you will want to restart the Luup engine. Do this by clicking the 'save' button. Because you normally just want full logging temporarily, Luup will automatically revert to the default log levels after 4 hours unless you check 'Lock log levels' in Vera's Advanced, Log page.

To make sense of what's in the logs it's best to use grep and 'regular expressions'. If you're a true uber geek this is the greatest joy. If you're a mere mortal, it's best to just stick to some examples. In regular expressions the symbol ^ means 'show me lines that start with' and the symbol \| means 'or'. So here are some samples:

Show me everything in the log that is a 'critical error':

''grep '^01' LuaUPnP.log''

I enabled Verbose logging, so incoming/outgoing data is logged, show me that plus any normal log messages (0-9) plus any log messages in my Lua code:

''grep '^0\|^4\|^5' LuaUPnP.log''

(meaning any line that starts with 0, which 0-9, or 4, which is 40 and 41, or 5, which is 50.

I want the same data, but I want to follow the logs in real time with the same filter:

''tail -f LuaUPnP.log | grep '^0\|^4\|^5' ''

You can also put in the 'grep' strings that you want to match. Let's say you see in the logs that every time a job status changes it logs using log level 10 (status) some line that includes the string: 'Job::m_eJobStatus'. You want to follow the logs and show just Lua logs, critical errors, and job status changes:

''tail -f LuaUPnP.log | grep '^5\|^01\|Job::m_eJobStatus' ''

When you are writing your Lua code, include copious logging with <tt>luup.log</tt> (see [[Luup_Lua_extensions#function:_log|Luup_Lua_extensions log function]]) to see what's happening in your Lua code.

==Debug in small chunks without restarting each time==

If you are adding code for an action, it takes time to upload your files and initiate the action. So it's best to debug the Lua code in tiny bite sized pieces first to be sure the syntax and basic operation is ok.

In Vera's web ui choose Devices, Luup plugins and click 'Test Lua UPnP code'. For the device number put in the number of the device you are debugging, which is shown when you click the + button next to the device. Or, if your Lua code isn't going to be calling any of the functions and variables you created in that device, you can just put in a device number of 0, which means this snippet of code runs by itself. If you put in a valid device number for a Luup plugin, it runs in the context of that device meaning it can call the other functions and variables in the plugin.

Put your small chunk of code in the input box and click 'go' to run it. Be sure the code outputs something to the log with <tt>luup.log</tt>.

In another console or putty window you can be following the logs with:

''tail -f LuaUPnP.log | grep '^01\|^5' ''

Always log critical errors, <tt>01</tt>, because that way if your Lua code won't run due to a syntax error you will see the log entry.

In the real implementation your Lua code will probably be passed variables. For example, if the Lua code being run is in response to an action, it will be passed as a variable the arguments to the UPnP action. To test your small blocks of code with this you can simply add the same variable names and hardcode some test variables. The list of variables that are passed to your Lua code are documents here: [[Luup_Declarations]]. You can also see the complete Lua code that the Luup engine has generated including the function declarations with the <tt>lu_lua</tt> (See [[Luup_Requests#lu_lua|Luup_Requests lu_lua]]) request on the URL.

For example, I will view the complete Lua code for device #8:

http://vera_ip:49451/data_request?id=lu_lua&DeviceNum=8

and I can see that the Lua code I put in my 'run' XML tag in the implementation file for the <tt>SetTarget</tt> action looks like this is within this function declaration:

''function SetTarget_run(lul_device,lul_settings)''

As explained in [[Luup_Declarations]] the <tt>lul_device</tt> will the device number that is receiving the command. So if I want to test some Lua code that I will put inside a 'run' tag for the <tt>SetTarget</tt> action, which logs the device that received the UPnP Action (we'll use 10) and the argument <tt>newTargetValue</tt> which indicates if the device is being turned on or off, then I would put in the test code:

lul_device=10
lul_settings['newTargetValue']=1
luup.log("Got a SetTarget action for device " .. lul_device .. " to turn on/off: " .. lul_settings['newTargetValue'])

now when you click 'go' see what goes in the Log. If your log entry is ok, copy the <tt>luup.log</tt> line from this test code, without the <tt>lul_device=</tt> and <tt>lul_settings=</tt> lines, into the actual implementation and you know that it will work when the real UPnP action is called and the Luup engine passes the actual <tt>lul_device</tt> and <tt>lul_settings</tt> to your Lua code.

Luup Loglevels

2010-12-19T02:50:09Z

Guessed: Clarify the logging levels a little.

[[Category:Development]]
Vera records different types of log entries, in it's log files, according to logging levels. By default only log levels 1-10 will make it to <tt>/var/log/cmh/LuaUPnP.log</tt> and all other types of messages are discarded.

To add more log levels edit the file <tt>/etc/cmh/cmh.conf</tt>. To see all log entries check the verbose option on Advanced/Logs, or put a comment character (<tt>#</tt>) in front of the <tt>LogLevels=</tt> line in <tt>/etc/cmh/cmh.conf</tt>

#LogLevels = 1,2,3,4,5,6,7,8,9,50,40

You can use <tt>grep</tt> to see only certain types of log entries.

For example, to watch the log and see only critical errors and Z-Wave serial API traffic, use:

tail -f /var/log/cmh/LuaUPnP.log | grep '^01\|^41\|^42'

or to view the list of all devices in the system use:

grep '^09' /var/log/cmh/LuaUPnP.log

Here's a full list of the log types that Vera supports:

LV_CRITICAL 1
LV_WARNING 2
LV_STARTSTOP 3
LV_JOB 4
LV_HA 5
LV_VARIABLE 6
LV_EVENT 7
LV_ACTION 8
LV_ENUMERATION 9
LV_STATUS 10
LV_CHILD_DEVICES 11
LV_LOCKING 20
LV_IR 28
LV_ALARM 31
LV_SOCKET 32
LV_DEBUG 35
LV_PROFILER 37
LV_PROCESSUTILS 38

// Z-Wave starts with 4
LV_ZWAVE 40
LV_SEND_ZWAVE 41
LV_RECEIVE_ZWAVE 42

// Lua starts with 5
LV_LUA 50
LV_SEND_LUA 51
LV_RECEIVE_LUA 52

// Insteon starts with 6
LV_INSTEON 60
LV_SEND_INSTEON 61
LV_RECEIVE_INSTEON 62

Luup Variables

2010-12-01T20:17:00Z

Guessed: Made WeatherPlugin example directly hyperlinkable. Mods to make it a little more consistent with the prior examples presented. Will now hyperlink this from code.mios.com page for the Weather Plugin.

[[Category:Development]]
The "Variables" for a device tell you it's current state, such as if it's on or off, what temperature it has, and so on. Variables are given a name and a service ID, which is defined by the UPnP forum. You can use this service ID/variable name pair to get the state of a device in the Luup engine by using the function luup.variable_get, as documented in [[Luup_Lua_extensions]]. You can also see the current value of a device's variables by going into Vera's setup page, click 'Devices', click + next to the device, then click 'Advanced'. The name of every variable for the device is shown along with the current value, and if you move your mouse over the variable name, you will the corresponding service ID in a popup window.

==On/Off Switch==

Device category: 3, UPnP device id: urn:schemas-upnp-org:device:BinaryLight:1

Variables:

Service: ''urn:upnp-org:serviceId:SwitchPower1'' Variable name: ''Status''

If the device is on, the value is 1, otherwise it's 0.

==Dimmable Light==

Device category: 2, UPnP device id: urn:schemas-upnp-org:device:DimmableLight:1

Variables:

Dimmable lights contain the same variable of an On/Off Switch to indicate the current on/off value, and, if it's on, LoadLevelStatus indicates the dim level.

Service: ''urn:upnp-org:serviceId:Dimming1'' Variable name: ''LoadLevelStatus''

If the device is off (see On/Off switch) this value indicates the last known dim level, if it's on, this value is the actual dim level. The value is a number from 0-100 indicating a percentage of brightness.

==Thermostat==

Device category: 5, UPnP device id: urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1

Variables:

Service: ''urn:upnp-org:serviceId:HVAC_UserOperatingMode1'' Variable name: ''ModeStatus''

This indicates the current operating mode and will be one of the following basic values: Off, HeatOn, CoolOn, AutoChangeOver. In addition to the basic modes, some thermostats may also support the following modes: InDeadBand, AuxHeatOn, EconomyHeatOn, EmergencyHeatOn, AuxCoolOn, EconomyCoolOn, BuildingProtection, EnergySavingsHeating, EnergySavingsCooling

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Heat'' Variable name: ''CurrentSetpoint''

Service: ''urn:upnp-org:serviceId:TemperatureSetpoint1_Cool'' Variable name: ''CurrentSetpoint''

These indicate the current heat/cool set points.

Service: ''urn:upnp-org:serviceId:TemperatureSensor1'' Variable name: ''CurrentTemperature''

This indicates the current ambient temperature.

==Other Devices or Services==
You can find other variables by looking at code. For example, looking at the code for the LUUP Weather plugin, we can see where the "serviceID" for Current Conditions is ''urn:micasaverde-com:serviceId:Weather1'' (taken from the XML file):

-- Store the current Condition (eg. "Sunny")
luup.variable_set("urn:micasaverde-com:serviceId:Weather1", "Condition",
condition, PARENT_DEVICE)

From this we can get the Current Weather Condition using 
Service: ''urn:micasaverde-com:serviceId:Weather1'' Variable name: ''Condition''

All we have to add is the device ID that Vera creates. In my case #''37''

=== Weather Plugin ===
For my testing, I wanted to create a Luup scene that will turn on a light when the ''Condition'' is ''Showers''. So I create a new Scene and add the following to the Luup Scene:

local lul_tmp = luup.variable_get("urn:micasaverde-com:serviceId:Weather1","Condition",37)
if (lul_tmp=="Showers") then
luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="50" },19)
else
luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="0" },19)
end

To break this down, line 1 gets the variable ''Condition'' from the ''serviceID'' ''urn:micasaverde-com:serviceId:Weather1'' on Device #''37''
Line 2 compares the returned variable to ''Showers''
If the condition is true then it calls line 3 which turns on the lamp (Device #''19'' at ''50%'' level)
Otherwise, it turns the lamp Off

What good is this? Nothing past testing but it would be a good method to close the garage door if it is raining.

*Be sure to set a timer to poll this scene ever xx minutes or hours. Please edit if you know of a way to have it automatically poll.

Insteon Debugging

2010-10-19T16:16:13Z

Guessed: Undo revision 2595 by Bubujin (Talk) Spammer

[[Category:Hardware]]
turn light off by sending full frame

http://127.0.0.1:49451/data_request?id=lu_action&output_format=xml&DeviceNum=31&serviceId=urn:micasaverde-com:serviceId:InsteonNetwork1&action=SendData&Data=0x62-0x11-0x58-0x6c-0x5-0x11-0x0

turn light on by specifying the node

http://127.0.0.1:49451/data_request?id=lu_action&output_format=xml&DeviceNum=31&serviceId=urn:micasaverde-com:serviceId:InsteonNetwork1&action=SendData&Node=11586c&Data=0x11-0xFF

Receive device category info from 11586c:

http://127.0.0.1:49451/data_request?id=lu_action&output_format=xml&DeviceNum=31&serviceId=urn:micasaverde-com:serviceId:InsteonNetwork1&action=SendData&Data=R0x50-0x11-0x58-0x6c-0x2-0x9-0x32-0x8b-0x1-0x0

Clone Dongle

2010-10-15T17:45:04Z

Guessed: Undo revision 2590 by Bettytaylor23 (Talk) SPAM Removal...

[[Category:User Instructions]]
The Z-Wave chip inside the black dongle maintains the master list of all the other Z-Wave devices that you have included into your Z-Wave network. Vera also maintains its own database with a list of devices, and Vera's database has a lot more detail, such as the name of the device, the room that it's in and so on. Vera continually syncs its database with the master list of devices in the Z-Wave dongle. This is why you can remove the dongle, carry it around to pair and unpair devices devices, and when you reconnect the dongle to Vera, Vera will show any new or removed devices. If you insert a new dongle in Vera, then all your devices will disappear since the new dongle doesn't have any devices paired to it and so Vera deletes the ones in its database.

Starting with Luup version 1.0.880 and higher, Vera is able to backup not only Vera's database, but also the data stored in the dongle.  Vera also has the ability to restore, or clone, this backup into another dongle.

For example, if you receive a replacement dongle, you can restore a backup of your old dongle's data to the new dongle so you don't have to rebuild your network.

To do this follow these steps:

#Be sure that you have not made any changes to Vera within the past 2 hours. Vera will backup the dongle's configuration whenever the list of devices in the dongle changes. The backup process is slow, so Vera does it in small increments when there is no activity on the Z-Wave network. In Vera's setup page, go to Devices, Z-Wave, More Z-Wave options, and look at the value for '''Last Dongle Backup'''. This will show the date & time that Vera last completed a successful backup of the dongle. Be sure that this is not empty of "''N/A''". If it is, leave Vera alone for a couple hours, refresh the Vera setup page, and check again.
#Once you've confirmed that Vera has a backup of your dongle, go to ''Advanced'', ''Backup'' and choose '''Create backup'''. Your browser will prompt you to save a file. Save it to your computer somewhere, such as on the Desktop. Be sure to wait until your browser has finished downloading.  That backup file contains both Vera's database as well as the dongle's.
#Insert your new dongle. Wait a minute to be sure that it's recognized. You should see all your Z-Wave devices have disappeared.
#Go to Advanced, Backup and in the restore section, click 'choose file' and locate the backup file. Check the box 'Restore Dongle Firmware'. Then click Restore.
#Leave Vera alone for 15 minutes. Vera will restore its database, which has all the detailed information on the device, and will also restore the dongle's data from the backup file, which takes several minutes.
#Confirm your new dongle is working and that you have a complete list of devices.

'''NOTE ''' In case you forgot to backup your existing settings and you have the findvera.com service activated from Findvera.com tab, your Vera will backup your data once per day. So, go to https://findvera.com and click Settings and you will see there the backups. Select the last one and restore it to your Vera unit. Read here about the restore process: [[Advanced#Backup.2FRestore|Backup / Restore]]

Paradox Alarm Plugin

2010-10-08T22:02:05Z

Guessed: Correct case of "MiOS"

[[Category:Plugins]]
[[Category:3rd Party]]
This page has moved to the MiOS Code Respository:

http://code.mios.com/trac/mios_paradox-alarm

Weather Plugin

2010-10-08T22:01:11Z

Guessed: Correct case of "MiOS"

[[Category:Plugins]]
[[Category:3rd Party]]
This page has moved to the MiOS Code Respository:

http://code.mios.com/trac/mios_weather/wiki

IP Cameras

2010-10-08T21:59:46Z

Guessed: Undo revision 2583 by Morcheeeba (Talk) Remove SPAM by this user...

If you buy an IP camera from Mi Casa Verde, we will pre-configure it to work with Vera right out of the box. If you get the camera yourself, and it's a model that is 'Plug and Play' compatible with Vera (see 'Supported Cameras' below), then you should be sure the camera is configured to get an IP address automatically, and that the username is set to: '''dceadmin''' and the password is set to: '''dcepass'''. Vera will add the camera automatically and fill in the settings. (Specific info for users of [[Panasonic IP Cameras|Panasonic IP Cameras]])  When adding a camera that is not on the supported list, see the section ''''Manually adding a camera'''' below.

=== '''Supported Cameras''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Panasonic
| IP Camera
| BL-C131/BL-C30
| all
| 
| Indoor
| 
| 
| The Panasonic IP cameras work well with Vera. However, for unknown reasons, the Panasonic camera will not get an IP address on your LAN until you run the Windows software supplied with it. You do not need to install the software; just insert the CD and tell the camera to get an IP address automatically (DHCP). If you buy the camera from the Mi Casa Verde web shop we do this before we ship it so the camera will work out of the box. Mac/Linux users who buy the camera elsewhere will need a Windows PC to 'activate' the camera. Set the default username/password on the camera to: dceadmin and dcepass for Vera to detect the camera automatically, or, if you use your own username/password, add the camera to Vera manually and provide Vera your username/password to access the camera.
|}

=== '''Cameras that work''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Path for JPEG image
! Product Review
! Added by
! Notes
|-
| Foscam [http://www.foscam.us/] [http://www.foscam.com/]
| IP Camera
| [http://www.foscam.com/Products_List.asp?id=128 FI8908/FI8908W]
| firmware 11.14.1.46 / 2.4.8.12
| 2010
| Indoor
| /snapshot.cgi
| [http://www.amazon.com/Wireless-Windows-compatible-Installation-Included/product-reviews/B0030FR08W/ref=dp_top_cm_cr_acr_txt?ie=UTF8&showViewpoints=1 Customer reviews]
| Ap15e
| Use the Foscam IP Camera Tool for initial setup, then copy IP address and path into Vera setup fields. For Pan, Tilt, Patrol support see: [http://forum.micasaverde.com/index.php?topic=3720.0 DIY instructions]
|-
| Linksys
| IP Camera
| [http://homesupport.cisco.com/en-us/wireless/lbc/WVC54GCA/download WVC54GCA]
| all
| 2009
| Indoor
| img/snapshot.cgi
| 
| 
| An inexpensive camera with moderate image quality. Use the Linksys setup wizard for initial setup, then copy IP address and path into Vera setup fields. Use a static IP address.
|-
| Linksys
| IP Camera
| [http://www.cisco.com/en/US/products/ps9948/index.html WVC210]
| all
| 2009
| Indoor
| img/snapshot.cgi
| 
| 
| A more expensive camera with good image quality and pan/tilt ability. Use the Linksys setup wizard for initial setup, then copy IP address and path into Vera setup fields. Use a static IP address. Pan/tilt controls will not work with Vera.
|-
| Linksys
| IP Camera
| [http://homesupport.cisco.com/en-us/wireless/lbc/WVC80N?referrer=www.linksysbycisco.com WVC80N]
| all
| 2009
| Indoor
| img/snapshot.cgi?size=2&quality=1
| 
| 
| A more expensive camera with good image quality and wireless N. Use the Linksys setup wizard for initial setup, then copy IP address and path into Vera setup fields. Use a static IP address. Pan/tilt controls will not work with Vera.
Size can be (160 x 120 = 1,320 x 240 = 2,640 x 480 = 3) and Quality can be (Very High= 1,High= 2,Normal= 3,Low= 4,Very Low= 5)

|-
| iCamView
| IP Camera Server
| [http://icamview.com/icv22.htm iCV-22], [http://icamview.com/icv32.htm iCV-32]
| all
| 2009 
| Indoor/Outdoor
| pda.cgi?user=admin&password=1234&page=image&cam=1 pda.cgi?user=admin&password=1234&page=image&cam=2 
| 
| 
| Feature-rich IP camera server, suports up to two compatible USB cameras, optional WiFi support, USB storage, USB hubs, motion; works with range of cameras, see icamview.co.uk. Excellent modular solution. They do ship to North America.
|-
| SmartHome.com.au
| IP Camera
| [http://www.smarthome.com.au/zseries/wirelesssecuritycamera.php Z~Series Wireless Camera]
| all
| 2009 
| Indoor
| tmpfs/auto.jpg
| 
| 
| Inexpensive IP security camera designed for the Australian and New Zealand Z-Wave users, but shipping world wide.
|-
| [http://global.level1.com LevelOne]
| IP Camera
| [http://global.level1.com/product_d.php?id=54 WCS-2030]
| all
| 2010
| Indoor
| cgi-bin/video.jpg
| [http://reviews.cnet.com/search-results/levelone-camcon-wcs-2030/1707-5_7-31972011.html CNET review]
| 
| An inexpensive IP camera with good image quality. Can be connected wired or wirelessly. Most LevelOne cameras use the same path for the JPEG image, so most of their line (both low and high end) should be compatible. Video and audio also stream over RTSP, which can be customized through the camera's web interface.
|-
| Asante
| IP Camera
| [http://www.asante.com/products/SecureNetCam/Voyager1.asp Voyager I]
| firmware 2.02 and above
| 2010
| Indoor
| image.cgi
| 
| 
| An inexpensive IP camera that is very feature rich, has good image quality, night vision capabilities, motion detection, two-way audio, video streaming over TCP, UDP, or HTTP, and other configurable features. In firmware version 2.02, Asante added the capability to retrieve an image via a URL (however, it is delayed by 3 seconds). Offers a full-featured web interface in IE using an ActiveX plug-in (limited capabilites in other browsers).
|-
| TrendNet
| IP Camera
| [http://www.trendnet.com/products/proddetail.asp?prod=155_TV-IP512WN&cat=149 TV-IP512WN]
| all
| 2009
| Indoor
| /image/jpeg.cgi
| 
| 
| Feature-rich inexpensive IP camera with good image quality, features 802.11n, GPIO ports, not bad optics
|-
| D-Link
| IP Camera
| [http://www.dlink.com/products/?pid=DCS-950G DCS-950G]
| firmware 1.07
|  ?
| Indoor
| /_gCVimage.jpg
| [http://www.amazon.com/D-Link-Securicam-DCS-950G-Wireless-Internet/product-reviews/B0006GDCD0/ref=dp_top_cm_cr_acr_txt?ie=UTF8&showViewpoints=1 Customer reviews]
| Ap15e
| It takes about 9(!) seconds to get the jpg file from the camera, but Vera's generic Luup IP camera plugin times out after 5 seconds by default. Starting with Ui4 a timeout option was added to the device settings for the camera, which you can increase to 10.
|}

=== '''Cameras that don't work''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Path for JPEG image
! Product Review
! Added by
! Notes
|-
| Trendnet
| IP Camera
| TV-IP100W
| all
| 2007 
| Indoor
| none 
| 
| 
| This camera can only serve images using DirectX or Java. The workaround is complex: "using a PC you can use MPlayer to strip out a JPG image from the video stream (asf). You can then store the JPG snapshot on a PC, then run a web server and vera can then "fetch" the image from the PC instead of the camera."
|-
| Schlage
| IP Camera
| WCW100
| all
| 2010
| Indoor
| none
|
| Ray
| This camera does not give an IP address out of the box. In order for it work, it needs to be activated using the Schlage LiNK system. Without paying for the Schlage LiNK membership, this camera cannot be used with Vera unless there's a way of forcing the activation.
|-
| Asante
| IP Camera
| Voyager I
| firmware 2.00
| 2010
| Indoor
| none
|
| Ray
| This camera is inexpensive, very feature rich, has very good image quality, and has night vision capabilities. However, there is no publicly accessible URL to grab a live JPG from the camera. The web interface requires an ActiveX plug-in to view the live video feed and there is a snapshot button that will deliver a JPG. Asante is reportedly making changes to their camera in the next version of the firmware that should resolve some of these issues.
|}

=== '''Manually adding a camera''' ===

[[Image:Camera1.jpg|thumb|center|512px]] [[Image:Camera2.jpg|thumb|center|512px|Manually adding a camera]]

In Vera's setup page click Devices, Luup plugins, Install/uninstall plugins, and click 'install' next to either the 'Generic IP Camera' plugin, or, if you see a plugin for your particular camera, such as 'Panasonic IP Camera with Pan/Tilt/Zoom' use that instead.

If you have more than one camera, you can click "install another" to have multiple instances of the plugin.

In most cases, IP cameras have a URL method for obtaining a SNAPSHOT or JPG image from the camera. If your camera supports this method, you can then use it with Vera and the FindVera.com service can archive these snapshots over time for security purposes. Most IP/Network cameras made in the past few years will have a JPG Snapshot mode. Some examples from Linksys are WVC54GCA, WVC200/WVC210.  D-link, Trend-Net, and many others make similar cameras.

If your camera is not a 'Plug and Play' model or not on the supported list, you need to specify the settings for the camera by going to the 'Devices' tab on Vera's setup page, adding the camera if it's not already there, and clicking the '+' icon to edit the camera's settings.

You will need to specify:

1. the IP address or domain name of the camera 2. the URL or path to retrieve the current image from the camera as a JPEG file 3. any username and password to retrieve the JPEG file

The URL (your camera's manual may denote this as "path" or "snapshot address") needs to retrieve the actual JPEG file, not just an HTML page that has the JPEG file somewhere on it. For example, if you can view a JPEG file from your camera with this URL: '''http://192.168.81.5/Snapshot.JPG?Quality=Standard''', then put in these settings:

IP Address: '''192.168.81.5''' Path: '''Snapshot.JPG?Quality=Standard'''

and be sure to provide the username/password if one is needed. After you specify this information, click the red 'Save' button, and then you can see the camera by clicking the 'View Camera' option.

=== '''Configuring the Panasonic IP camera to connect wirelessly to Vera''' ===

The Panasonic IP Cameras have a switch on the bottom: WIRED/WIRELESS. In order to connect your camera wirelessly to Vera, you'll need to follow these steps:

- set the switch to WIRED
- connect your camera to Vera's LAN port using an Ethernet cable
- turn the camera on, confirm Vera's LAN LED turns orange, and wait for the IP Cam LED to turn green
- wait for the camera to be detected in Devices -> Unassigned Device
- assign the camera to a 'Room' and click 'Save'
(for the camera to be detected it should have the default username/password: dceadmin/dcepass and listen on port 80)
- confirm that you can see images from the camera
- click on the "+" sign near your camera and note its IP address (e.g. 192.168.81.200)

- connect your computer to the same network as your camera
- open your web browser and type in: http://camera1_ip (in this example, http://192.168.81.200)
- login with the default camera username: dceadmin and password: dcepass
- go to Setup -> Wireless and set SSID, Cipher and Password to Vera's wireless settings
which can be found an the bottom of Vera. (default Cipher is WPA2-PSK)
- click 'Save Settings'
- turn the camera's bottom switch to WIRELESS and reboot your camera by cycling its power

Your camera should now connect wirelessly to Vera. If you change your Vera's wireless settings you'll have first to update them on your cameras, so you won't lose connection to them.

=== Example of using a Linksys WVC54GCA or WVC210 camera with Vera ===

For example, if you can view a JPEG file from your camera with this URL: http://192.168.81.5/img/snapshot.cgi, then put in these settings: Domain or IP: 192.168.81.5 (or ''YourDomain.MyLinksysCam.com'' if remote access is enabled) Path: img/snapshot.cgi A username and password must be used unless all users are allowed in the USERS section. 

*If you have more than one camera, you will be using the PORT as part of the URL. If your second camera is on PORT 1024 and the IP is 192.168.81.6, you would use 192.168.81.6:1024 or YourDomain.MyLinksysCam.com:1024

 

=== iCAMView and some Lorex network cameras ===

For [http://www.icamview.co.uk iCAMView] based cameras, including a few Lorex-branded ones, the path would be: <tt>showimg_pda.cgi?cam=1 for the first camera</tt> <tt>showimg_pda.cgi?cam=2 for the second camera</tt> 

Older models may require slightly different path: <tt>pda.cgi?cam=1 for the first camera</tt> <tt>pda.cgi?cam=2 for the second camera</tt> 

Other parameters would be the same as above.

=== Axis IP Cameras ===

Path: axis-cgi/jpg/image.cgi (or ''lastshot.jpg'' depending of the model) More information here: [http://www.axis.com/techsup/cam_servers/tech_notes/live_snapshots.htm Axis live_snapshots] [http://www.axis.com/techsup/cam_servers/cam_200p/techoverview.htm Axis techoverview]

[[Category:Hardware]] [[Category:Supported_Devices_Table]]

MiOS:Current events

2010-09-18T14:16:57Z

Guessed: Remove spam