MiOS - User contributions [en]

Supported Hardware

2012-01-18T22:23:27Z

Autotoronto:

This is a page for Supported Z-Wave devices.

Alternative hardware pages exist for

*[[ZWave Add Controller|Z-Wave Handheld Remote Controls, Gateways and Scene Controllers]]
*[[IP Cameras|IP Enabled Cameras]]
*[[Insteon Supported Hardware|Insteon/X10 devices]]
*USB, or USB-Serial, [[Serial Supported Hardware|Interface devices]]

In general, any device with the Z-Wave logo should work with Vera. A list of tested Z-Wave devices is below, with specific notes for each type of device. This is a wiki, so feel free to add to the page. To learn about Z-Wave routing and fixing routing problems see: [[Heal Network]]

== Hardware Reported to Work ==

*We strongly encourage users to list any and all products they tested and installed.
*If a product works but you did not like it, please list it anyway. It may be the only product available to some users.

 

----

'''IMPORTANT! The devices listed here have been added by installers, technicians and users like yourself. Results may vary upon installations. MiCasaVerde does not guarantee operation and compatibility with your installation. The listed devices were found to work with their specific installation. Mixing different series and brands of equipment is not guaranteed in any way to work with other series and brands. It is very likely that users have not fully tested all features of the devices, so it is possible that a device listed here as compatible, will not prove compatible with your hardware. If you are editing this wiki DO NOT REMOVE a listed working device if it hasn't worked for you. Seek help to get the device to work under your individual circumstance. If you are adding to this wiki, please provide links to data for the device and add any tips you feel may benefit someone wanting to implement the device into an installation.'''

----

 

=== '''Lighting Devices''' ===

{| cellpadding="2" border="1" style="width: 1220px; height: 491px;"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| 2-way Dimmer Switch
| ZDW120
| 
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZDW120---Z-Wave-600-Watt-2-Wire-Dimmer-ACT-HomePro-P17C64.aspx Link]
| [http://store.homeseer.com/store/ZDW120---Z-Wave-600-Watt-2-Wire-Dimmer-ACT-HomePro-P17C64.aspx Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=49 WSeverino]
| Works well, easy to install, LED is a very bright blue....can be programmed to be off when the light is off or on. "series 200" model supports Group Associations 2 & 3. (The older "series 100" supported Groups 1-4, but is no longer available.)
|-
| ACT
| 3-way Dimmer Switch
| ZDW103
| 
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZDW103---Z-Wave-500-Watt-3-way-Dimmer-ACT-HomePro-P19C64.aspx Link]
| [http://store.homeseer.com/store/ZDW103---Z-Wave-500-Watt-3-way-Dimmer-ACT-HomePro-P19C64.aspx Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=49 WSeverino]
| Works well, can be tricky to install due to the different combination of 3 way circuits, LED is a very bright blue....can be programmed to be off when the light is off or on.
|-
| ACT
| 2-wire Dimmer Switch
| ZDW232
| 
| Jul 2010
| Indoor
| [http://www.zwave4u.com/products/en/Switches-and-Dimmers/HomePro-Single-Wall-Dimmer-2-wire.html Link]
| [http://www.zwave4u.com/products/en/Switches-and-Dimmers/HomePro-Single-Wall-Dimmer-2-wire.html Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=5198 Newb]
| Wall-mount, 230v, 500W, 2-Wire (no neutral), works well. Can be programmed to be off when the light is off or on.
|-
| ACT
| 2-way Relay Switch
| ZRW113
| 
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRW113---Z-Wave-20-Amp-3-way-ISO-Relay-ACT-HomePro-P491C63.aspx Link]
| [http://store.homeseer.com/store/ZRW113---Z-Wave-20-Amp-3-way-ISO-Relay-ACT-HomePro-P491C63.aspx Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=49 WSeverino]
| Controls Florescent Lamps very well! No humming at all.
|-
| ACT
| Companion Switch
| AS101
| 
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/AS101---Z-Wave-3-Way-Companion-Switch-ACT-HomePro-P10C63.aspx Link]
| [http://store.homeseer.com/store/AS101---Z-Wave-3-Way-Companion-Switch-ACT-HomePro-P10C63.aspx Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=49 WSeverino]
| Works well, can be tricky to install due to the different combination of 3 way circuits, The trick here is to install this device where the power comes in.
|-
| ACT 
| 3-way Dimmer Switch, 2 rocker 
| ZDM230 
| 1.1 
| Aug 2009 
| Indoor 
| [http://www.act-solutions.com/HomePro/pdfs/HomePro/Specs/ZDM230_spec.pdf Link] 
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=3015 TedStriker] 
| Dimmer, Wall-mount, 230v, 500W, 3-way, 3 Wire, 2 rocker 
|-
| ACT
| 3-way Relay Switch, 2 rocker
| ZRM230 
| 1.1 
| Aug 2009 
| Indoor 
| [http://www.act-solutions.com/HomePro/pdfs/HomePro/Specs/ZRM230_spec.pdf Link] 
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=3015 TedStriker] 
| Relay, Wall-mount, 230v, 6A, 3-way, 3 Wire, 2 rocker - '''Status polling does not work with Vera''' 
|-
| Cooper
| Accessory (3-way slave)
| 
| 
| 
| Indoor
| 
| 
| 
| See [[Cooper Accessory Slave]]
|-
| Düwi
| 2 wire dimmer
| 
| 
| July 2011
| Indoor
| 
| 
| intveltr
| In-wall dimmer.
|-
| Düwi
| 3 wire switch
| 05431
| 
| July 2011
| Indoor
| 
| 
| intveltr
| In-wall switch.
|-
| Düwi
| 3 wire switch
| 06431
| 
| July 2011
| Indoor
| 
| 
| intveltr
| The newer in-wall Düwi switch (also designated Düwi.me), marked with a green sticker on the housing. This switch supports status push.
|-
| Fibar
| 3 wire double switch
| FGS221
| 
| Oct 2011
| Indoor
| 
| 
| intveltr
| This device is designed to use (and be mounted behind) existing light switches. Supports status push. Also available: single switch, dimmer, blind control.
|-
| GE/Jasco
| 2-wire Dimmer
| 45606
|  
| 2/2011
| Indoor
| [http://www.jascoproducts.com/support/manual-downloads/applications/DocumentLibraryManager/upload/45606-Manual-Eng.pdf Link] [http://www.jascoproducts.com/products/pc/GE-Z-Wave-Wireless-Lighting-Control-Dimmer-Switch-63p555.htm Link]
|  
| [http://forum.micasaverde.com/index.php?action=profile;u=64 Anthonyris]
| Works fine with most bulbs. With Philips AmbientLED, flickers at >95% brightness. Supports beaming.
|-
| Innovus
| Relay Switch Adapter
| RAone SmartPower
|  
| Aug 2009
| Indoor
| [http://www.innovus.eu/fileadmin/user_upload/manual/z-wave/smartpower_zw_tech_doc.pdf Link]
|  
| [http://forum.micasaverde.com/index.php?action=profile;u=3015 TedStriker]
| Works very well + it has a build in powermeter which works perfect with Vera
|-
| Innovus
| Dimmer Switch Adapter
| RAone SmartDimmer
|  
| Aug 2009
| Indoor
| [http://www.innovus.eu/fileadmin/user_upload/manual/z-wave/smartdimmer-00110001-tech.pdf Link]
|  
| [http://forum.micasaverde.com/index.php?action=profile;u=3015 TedStriker]
| Works very well + it has a build in powermeter which works perfect with Vera
|-
| Intermatic
| Lamp Module
| HA03C
|  
| Sept 2010
| Indoor
| [http://www.homesettings.com/products/modules/ha03.aspx Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=5852 JonnyO]
| Easy to Instal, supports dimming
|-
| Intermatic
| Screw-in Lamp Module
| HA05C
| 
| Nov 2008
| Indoor/Outdoor
| [http://store.homeseer.com/store/HA05C---Z-Wave-IndoorOutdoor-Screw-in-Module-Intermatic-HomeSettings-P1C62.aspx Link]
| [http://store.homeseer.com/store/HA05C---Z-Wave-IndoorOutdoor-Screw-in-Module-Intermatic-HomeSettings-P1C62.aspx Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=49 WSeverino]
| Easy install, easy to pair with Vera!
|-
| Intermatic
| 300 watt dimmer
| HA06
| 
| July 2007
| Indoor
| [http://www.homesettings.com/products/modules/ha06.aspx Link]
| 
| 
| Affordable Dimmer Switch. incandescent/halogen only. Loads for 300 watts or less no neutral required. Great for dimming one bulb.
|-
| Intermatic
| 3-way Switch
| HA18
| 
| Dec 2008
| Indoor
| [http://www.homesettings.com/products/new%20products/ha18.aspx Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=66 Kozanator]
| Affordable 3-way Switch
|-
| Intermatic
| 3-way Dimmer Switch
| HA20
| 
| Nov 2008
| Indoor
| [http://www.homesettings.com/products/new%20products/ha20.aspx Link]
| [http://www.smarthome-products.com/p-460-intermatic-homesettings-ha20c-3-way-in-wall-switch-dimmer.aspx Link]
| 
| Affordable 3-way 600W dimmer
|-
| Leviton
| Dimmer Switch
| VRI06-1LX
|  
| Aug 2009
| Indoor
| [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=305784&section=25501 Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=2618 guessed]
| Works well
|-
| Leviton
| 4-Scene Controller with Switch
| VRCS4-MRX
| 7,2,67,0,2
| Aug 2009
| Indoor
| [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=433270&section=28563 Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=2618 guessed]
| Works well, pair as per [http://wiki.micasaverde.com/index.php/Leviton_Scene_Controller Leviton 4-Scene Controller], then again holding "2" and "4" to pair the Switch ("Load") itself.
|-
| Leviton
| Dimmer Switch
| VRM10-1LX
| 1
| Nov 2008
| Indoor
| [http://shop.micasaverde.com/index.php?main_page=product_info&cPath=104&products_id=170 Link]
| [http://www.amazon.com/review/product/B000ZKM7I8/ref=dp_top_cm_cr_acr_txt?_encoding=UTF8&showViewpoints=1 Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=65 mark-hc]
| This is a high quality dimmer geared towards high-end installations
|-
| Leviton
| Scene capable 3-way switch (non-dimming)
| VRS15-1L
|  
| May 2011
| Indoor
| [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=305791&section=25502&minisite=10026 Link]
| 
| DaveL17
| (Coordinating Remote??)
|-
| Leviton
| Scene capable 3-way switch (non-dimming)
| VRS15-1LX
|  
| Oct 2011
| Indoor
| [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=305791&section=25502&minisite=10026 Link]
| 
| DaveL17
| Works well. Pair normally. Can also be used in single pole applications. [Note: white, ivory, [[almond]].]
|-
| Leviton
| Scene capable 3-way switch (non-dimming)
| VRS15-1LZ
|  
|  
| Indoor
| [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=305791&section=25502&minisite=10026 Link]
| 
| DaveL17
| Works well. Pair normally. Can also be used in single pole applications. [Note: white, ivory, [[light almond]].]
|-
| Merten
| Radio sensor cover for dimmer inserts
| 5026xx, 5036xx, 5046xx
| 6,2,7,1,5
| Apr 2009
| Indoor
| [http://www.merten.de/download/DL_doku/V5026_581_01_web.pdf Link]
|  
| Ap15e
| Works well
|-
| Merten
| Radio sensor cover for switch inserts
| 5024xx, 5034xx, 5044xx
| 6,2,27,2,2
|  
| Indoor
| [http://www.merten.de/download/DL_doku/5024xx_5034xx_5044xx_Sensorflaeche4pin_CONNECT_INT.pdf Link]
|  
| Ap15e
| Works well
|-
| Merten
| Single Radio flush-mounted receiver
| 507001
| 6,2,27,2,2
| Apr 2009
| Indoor
| [http://www.merten.de/download/DL_doku/V5070_581_01_web.pdf Link]
|  
| Ap15e
| Works well
|-
| Merten
| switch, flush-mounted
| 507501, 507601
|  
|  
| Indoor
| [http://www.merten.de/download/DL_doku/V5075_581_00_web.pdf Link]
|  
| Ap15e
| Works well (according to [http://forum.micasaverde.com/index.php?topic=276.15 Link])
|-
| Merten
| 1-gang universal dimmer, flush-mounted
| 507900
|  
|  
| Indoor
| [http://www.merten.de/download/DL_doku/V5079_581_01_web.pdf Link]
|  
| Ap15e
| Works well (according to [http://forum.micasaverde.com/index.php?topic=276.15 Link])
|-
| Monster
| 4-Scene Controller with Switch
| IWC600
|
| Dec 2011
| Indoor
| [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=433270&section=28563 Link]
| 
|
| This is the same as the Leviton scene controller. Follow these instructions: [http://wiki.micasaverde.com/index.php/Leviton_Scene_Controller Leviton 4-Scene Controller]
|-
| Schlage
| Lamp Module
| RP200
| 1.0
| Aug 2009
| Indoor
| [http://consumer.schlage.com/products/Productdetail3.asp?StyleID=139&FinishID=12&FunctionID=77 Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=2870 LibraSun]
| Works well Sold with Schlage LiNK lock system
|}

 

=== '''Plug & Receptacle Devices''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Frequency
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
|  
| Nov 2008
| Indoor
| [http://www.smarthome-products.com/p-527-homepro-zrr150-wall-receptacle.aspx Link]
| [http://www.smarthome-products.com/p-527-homepro-zrr150-wall-receptacle.aspx Link]
| 
| Works like a champ! Easy to Install. One receptacle RF controlled, the other is hot
|-
| ACT
| In-Wall Receptacle
| ZRP200
|  
| EU
| July 2011
| Indoor
|  
|  
| intveltr
| Basic plug-in switch.
|-
| ACT
| In-Wall Receptacle
| ZDP200
|  
| EU
| July 2011
| Indoor
|  
|  
| intveltr
| Basic plug-in dimmer.
|-
| Cooper Wiring Devices
| In-Wall Receptacle
| RFTR9505-T
|  
|  
|  
| Indoor
| [http://solutions.cooperwiringdevices.com/common/brands.cfm?pg=Detail&brandName=CWD%20Technology&category=Aspire%20RF%20Lighting%20Control%20System%3A%20Receptacles&id=16772 Link]
| 
| 
| One receptacle is RF controlled, the other is hot
|-
| Duwi
| Z-Wave switch 3500 W
| 05437
|  
| EU
| Feb 2009
| Indoor
| [http://www.duewi.com/ Link]
| 
| ezhome
| High quality Plug-in switch, Easy install and works well
|-
| Everspring
| Z-Wave switch 3500 W
| AN157-2
| 4,2,64,1,2
| EU
|  
| Indoor
| [http://www.everspring.com/Products/Home_Automation_Detail.asp?parentUID=83&UID=501&CateUIDList=0,83 Link]
| 
| Ap15e
| Works well.
|-
| Everspring
| Z-Wave switch 3500 W
| AN158
|  
| EU
|  
| Indoor
|  
| 
| intveltr
| Works well. Supports status push and power metering
|-
| GE/Jasco
| In-wall Duplex Receptacle
| 45605
|  
| US
| 2/2011
| Indoor
| [http://www.jascoproducts.com/products/pc/GE-Z-Wave-Wireless-Lighting-Control-Duplex-Receptacle-63p554.htm Link] [http://www.jascoproducts.com/support/manual-downloads/applications/DocumentLibraryManager/upload/45605-Manual-Eng.pdf Link]
|  
| [http://forum.micasaverde.com/index.php?action=profile;u=64 Anthonyris]
| Easy. Works.
|-
| Home Manageables
| Lamp Module (Dimming)
| HM-LM001
|  
|  
| Nov 2011
| Indoor
| 200W maximum load, 25W minimum load
| [http://www.homemanageables.com/manuals/HM-LM001%20Manual%20Final.pdf Link]
| DaveL17
| Works well. Support for incandescent loads only. Not load sensing.
|-
| Intermatic
| In-Wall Receptacle
| CA3500
| 1
|  
| Nov 2008
| Indoor
| [http://shop.micasaverde.com/index.php?main_page=product_info&cPath=105&products_id=97 Link]
| [http://www.amazon.com/review/product/B000U3XYPA/ref=dp_top_cm_cr_acr_txt?_encoding=UTF8&showViewpoints=1 Link]
| 
| This is a decent, but expensive solution for in-wall receptacles. One receptacle RF controlled, the other is hot.
|-
| Intermatic
| Appliance Module
| HA02C
| 1
|  
| Nov 2008
| Indoor
| [http://shop.micasaverde.com/index.php?main_page=product_info&cPath=108&products_id=98 Link]
| [http://www.amazon.com/Intermatic-HA02C-Settings-Heavy-Duty-Appliance/dp/B000BJSDZO/ref=sr_1_3?ie=UTF8&qid=1227467418&sr=8-3 Link]
| 
| Seems to work well
|-
| Intermatic
| Outdoor Module
| HA04C
| 1
|  
| Dec 2008
| Outdoor
| [http://store.homeseer.com/store/HA04C---Z-Wave-Outdoor-Module-Intermatic-HomeSettings-P6C62.aspx Link]
| [http://store.homeseer.com/store/HA04C---Z-Wave-Outdoor-Module-Intermatic-HomeSettings-P6C62.aspx Link]
| [http://forum.micasaverde.com/index.php?action=profile;u=66 Kozanator]
| Easy to Install.
|-
| Merten
| switch, plug adapter, 2000 W
| 508519
| 6,2,7,1,5
| EU
|  
| Indoor
| [http://www.merten.de/download/DL_doku/V5085_581_01_web.pdf Link]
|  
| Ap15e
| Works well.
|-
| Monster Central
| 1800W Appliance Module
| ML-LAS1000
| 1
|  
| Jan 2009
| Indoor
| [http://www.monstercable.com/productdisplay.asp?pin=3164 Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=2618 guessed]
| Easy to Install. I use this as a ZWave signal repeater. Appears to be a badge-engineering of [http://www.leviton.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=309748&section=25542 Leviton VRP15-1LW]
|-
| Wayne Dalton
| Appliance Module
|
HA-02L (HA-02WD)

|
|
| Dec 2011
| Indooor
| [http://www.waynedaltonstore.com/ssi/pdf/wayne/HA-02WD.pdf Link]
|
| DaveL17
| Note: link is to HA-02WD manual.
|-
| Wayne Dalton
| Lamp Module
| HA-03WD
|
|
| Dec 2011
| Indoor
| [http://www.waynedaltonstore.com/ssi/pdf/wayne/HA-03WD.pdf Link]
|
| DaveL17
| Not load sensing.
|}

 

=== '''Thermostat Devices''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Frequency
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added By User
! Notes
|-
| Wayne Dalton
| Wall Stat
| WDTC-20
|  ??
|  
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/WDTC-20---Z-Wave-Thermostat-Wayne-Dalton-P599C38.aspx Link]
| [http://www.amazon.com/Wayne-Dalton-Corporation-Z-Wave-Thermostat/dp/B001F8QKYQ Link]
| 
| Has 2 inclusion modes: 1) press and release the bind button and the STAT will be included as a thermostat and works with Vera, 2) press and hold the bind button and it will be added as a binary switch for compatibility with old, non-compliant remotes. If it's added in the wrong mode, remove it and re-add it. Works great simple to use!
|-
| HAI
| Wall Stat
| RC-80BZ
|  ??
|  
| Nov 2007
| Indoor
| [http://www.homeauto.com Link]
| [http://www.homeauto.com/Downloads/Products/Omnistat/rcr80.pdf Link]
| 
| Shows up as Standard Thermostat in Vera, Hold button feature not able to control by Vera at this time. Priced above 200.00. Has internal setback programs. Works great.
|-
| RCS
| Wall Stat
| TZ43
|  ??
|  
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/TZ43---Z-Wave-Thermostat-RCS-P627C67.aspx Link]
| [http://store.homeseer.com/store/TZ43---Z-Wave-Thermostat-RCS-P627C67.aspx Link]
| 
| Shows up as Standard Thermostat in Vera, much more feature rich the the WDTC-20 but comes with a hefty price tag ($214.95). Wish Vera could use all the features in this Thermostat! '''Note:'''''You need to set the thermostat to show the temperature, on its display, in Celsius degree in order to be able to receive "Set Temp" commands from Vera. This is no longer required in firmwares above '''''1.0.862 (luup)'''
|-
| Schlage/Trane
| Wall Stat
| Trane
|  ??
|  
|  ??
| Indoor
| [http://www.link.schlage.com/Products/Pages/Thermostat.aspx Link]
| [http://www.trane.com/Residential/Products/Thermostats Link]
| 
| It's the same thermostat as the RCS TZ43 and it has the same issue: it's accepting "Set Temp Point" commands only in the measurement unit that is displayed on its screen. '''Note:'''''You need to set the thermostat to show the temperature, on its screen, in Celsius degree in order to be able to receive "Set Temp" commands from Vera. This is no longer required in firmwares above '''''1.0.862 (luup)'''
|-
| Intermatic
| InTouch
| CA8900
| 
|  
| Nov 2008
| Indoor
| [http://www.smarthome-products.com/p-663-intermatic-intouch-ca8900-z-wave-digital-thermostat.aspx Link]
| 
| 
| Looks very similar to the Wayne Dalton WDTC-20 listed here. works great, simple to use
|-
| Danfoss
| Radiator thermostat
| RA PLUS-w
| 
| EU
| 
| Indoor
| [http://raplusw.com/Content/E962FC0B-6461-4319-82FE-3E1E765142CF.html Link] [http://raplusw.com/PCMPDF/Data%20sheet%20RA-PLUS-w_02.pdf Link]
| [http://www.eurox10.com/Product/ZWave/Actuators/ZWDNF_RA_PLUS-W.htm Link] [http://www.eurox10.com]
| 
| See: [[Danfoss Thermostat]] for installation instructions If the device cannot be configured at the final location, move the device closer to Vera and try again (this device might require a direct connection to Vera for configuration).
|-
| Radio Thermostat
| Wall Stat
| CT22
| 
| US
| 
| Indoor
| [http://www.radiothermostat.com/documents/CT-22-Operation-27aug10.pdf Link] [http://www.radiothermostat.com/documents/CT-22-Installation-27aug10.pdf Link]
| 
| Daniel
| To include the thermostat into your network, you just have to install the USNAP module in the thermostat while Vera is in Include mode. You can watch a video about how to install it [http://www.youtube.com/watch?v=M9VNuHGENP0 here]
|-
| Horstmann
| Wall Stat
| HRT4-ZW
|
| EU
|
| Indoor
| [http://horstmann.co.uk/downloads/ElectronicDocuments/Central-Heating/HRT4-ZWweb.pdf Link] [http://horstmann.co.uk/downloads/ElectronicDocuments/Central-Heating/HRT4B-ZWManual.pdf Link]
| [http://horstmann.co.uk/downloads/ElectronicDocuments/Central-Heating/HRT4B-ZWManual.pdf ]
| Daniel
| After you include the thermostat in Vera's network, you will have to make some configuration changes in order for it to report the temperature change. See: [[HRT4-ZW]] for more information.
|}

 

=== '''Sensors''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Frequency
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| ZIR000 / ZIR010
| 
| EU (ZIR010) or US (ZIR000)
| 
| Indoor
| [http://www.act-solutions.com/HomePro/pdfs/HomePro/Specs/ZIR000_spec.pdf Link] [http://www.act-solutions.com/HomePro/pdfs/HomePro/Inst/ZIR000_instr.pdf Link] [http://www.act-solutions.com/HomePro/pdfs/HomePro/Specs/ZIR010_spec.pdf Link] [http://www.act-solutions.com/HomePro/pdfs/HomePro/Inst/ZIR010_instr.pdf Link]
| 
| 
| Remove the cover, pair to Vera's dongle by using the push-button on the left of the circuit board. Vera must configure it to work, and it can only be configured within less of a minute (30 sec best) of inserting the batteries. With Vera's dongle removed, remove/reinsert the batteries, and within 30 seconds insert Vera's dongle. Within a few minutes confirm the "configure" icon for the device is green on Vera's setup page
|-
| Aeon Labs
| 3-in-1 sensor (light/humidity/temperature)
| MultiSensor
| 
| EU or US
| 
| Indoor/Outdoor
| [http://www.aeon-labs.com/site/public/lib/download.php?type=s&f=29 Specs]
| 
| 
| Pair to Vera by using the push-button. Vera must configure it to work, and it can only be configured within 10 minutes of inserting the batteries.
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
| HSM100 / EZMotion
| 
| EU or US
| 
| 
| [http://www.expresscontrols.com/pdf/EZMotionOwnerManual.pdf Link]
| 
| 
| See [[ExpressControls3in1]] If the motion sensor does not work right after inclusion and configuration, remove the batteries for a few seconds.
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| EU or US
| Apr 2009
| Indoor
| [http://www.everspring.com/Products/Home_Automation_Detail.asp?parentUID=83&UID=355&CateUIDList=0,83 Link] [http://www.everspring.com/Archive/Image/File/A501110873R01_SM103_-ECR.pdf Link]
|  
| Ap15e
| Pair using the intrusion button. The sensor will accept configuration within a few minutes of the initial pairing, or of pressing the intrusion button on the back even after it's paired. Pair the device, or if it's already paired, press the intrusion button, and within 30 seconds insert Vera's dongle. Within a few minutes confirm the "configure" icon for the device is green on Vera's setup page. NOTE: There is some confusion about the orientation of the sensor. The main sensor body has a back (where the intrusion is), a front (where the logo and LED is), and the 2 other surfaces, one of which has a curved edge, and the other is flat. The magnet needs to go against the flat surface. And the flat surface on the magnet should be as close as possible to the flat surface on the sensor, lined up in the middle so the line which passes through the LED lines up with the sensor.
Note: In case the inclusion/exclusion fails you should remove/reinsert the batteries from the sensor and within a few seconds the sensor should be automatically detected.

|-
| EverSpring/Home Manageables
| Humidity + Temperature sensor
| HM-TS001
| 
| 
| Jan 2010 (requires version 1.1.0 or greater)
| Indoor
| [http://www.asihome.com/ASIshop/product_info.php?products_id=3946 Link] [http://www.homeseer.com/pdfs/guides/HM_TD001.pdf Link]
|  
| micasaverde
| Pair or unpair the device by tapping the CF button 3 times very quickly. Once it's paired and shows up in the UI as a generic device, press the CF button 3 times again quickly to make it wakeup and get configured. Then it will correctly be identified as 3 devices (combo device + temperature + humidity).
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| EU or US
| Apr 2009
| Indoor
| [http://www.everspring.com/Products/Home_Automation_Detail.asp?parentUID=83&UID=354&CateUIDList=0,83 Link] [http://www.everspring.com/Archive/Image/File/A501110874R01_SP103_%20-%20ECR.pdf Link]
|  
| Ap15e
| Works well
|-
| Fortrezz
| Water /Freeze
| WWA-001
|  ??????
| US
| Apr 2009
| Indoor
| [http://www.Fortrezz.com Link] [http://www.fortrezz.com/resources/WWA_manual_01May2009.pdf Link]
| 
| Zmistro
| Works great I would place a few in your house. Bathrooms, laundry , kitchen , basement. Great product!
|-
| Intermatic
| Motion Sensor
| CA-9000
| 
| US
| 
| Indoor
| 
| 
| Aaron
| This device has limited functionality as a sensor. It can only be used to turn on and off a light directly by setting an association, which Vera supports. It does not fire events, so you cannot use it as an event on a scene.
|-
| Merten
| 4-gang radio transmitter, flush-mounted
| 506004
| 2,2,27,1,4
| EU
|  
| Indoor
| [http://www.merten.de/download/DL_doku/V5060_581_02_web.pdf Link]
|  
| Ap15e
| Note: There is proprietary functionality here. Support will be added soon.
Quite complex device; partially supported by Vera; can be used as a window/door sensor (as of firmware 1.0.900) ...

|}

 

=== '''Door Locks''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added By User
! Notes
|-
| Schlage
| Door lock and deadbolt
| BE369 (deadbolt)
| 
| Mid 2009
| Indoor
| [http://consumer.schlage.com/link/product_tour/ Link]
| 
| [http://forum.micasaverde.com/index.php?action=profile;u=2870 LibraSun]
| Read the instructions here: [[Schlage Lock]]
|-
| Kwikset
| Door lock and deadbolt
|
|
|
| Indoor
|
|
|
| Read instructions here:[[Kwikset Lock]]
|-
| Yale
| Deadbolt
| Real Living
|
|
| Indoor
|
[http://www.yaleresidential.com/Yale/Yale%20US/Real%20Living/Documents%20Library/Yale%20DB%20PUSH%20Quickstart%2018JUL11_Rev%20B.pdf Link]

[http://www.yaleresidential.com/Yale/Yale%20US/Real%20Living/Documents%20Library/Yale%20DB%20PUSH%20Instructions%2023AUG11_Rev%20B.pdf Link]

|
|
| Read instructions here: [[Yale Lock]]
|}

 

=== '''Drapes/Blinds''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added By User
! Notes
|-
| Electronic Solutions
| Drape/Blind Motor Controller
| DBMZ
| V2+1
| 
| Indoor
| For 12-24VDC Motors
| [http://www.elec-solutions.com/products/dc_mot_ctrls/z-wave/dbmz/dbmz.html Link]
| Shady
| 2-Wire Motors
|-
| Electronic Solutions
| Drape/Blind Motor Controller
| ABMHZ
| V2+1
| 
| Indoor
| For 110-230VAC Motors
| [http://www.elec-solutions.com/products/int_ac_mot_ctrls/z-wave/abmhz/abmhz.html Link]
| Shady
| 4-Wire Motors
|-
| Lagotek / RSSceneAutomation
| Drape/Blind Motor Controller
| DC1-ZW
| 
| 
| Indoor
| For 12-24VDC Motors
| [http://www.lagotek.com/blindspdf/AC1-ZW%20Cut%20Sheet.pdf Link]
| Shady
| 2-Wire Motors
|-
| Lagotek / RSSceneAutomation
| Drape/Blind Motor Controller
| AC1-ZW
| 
| 
| Indoor
| For 110-230VAC Motors
| [http://www.lagotek.com/blindspdf/DC1-ZW%20Cut%20Sheet.pdf Link]
| Shady
| 4-Wire Motors
|}

 

=== '''Relay controls''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added By User
! Notes
|-
| Intermatic
| Contactor control box
| CA3750
| 
| Nov 2007
| Indoor/Outdoor
| [http://www.intouchcontrols.com/~/media/Files/InTouchControls/Products/Spec%20Sheets/CA3750.ashx Link]
| 
| 
| Multi-instance class supported for this device. Vera is able to control each of the 2 relays independently if desired. please note unit shows as three switches this is a bug with Intermatic not a real issue.You can check the box in devices to not show the second listing of the first relay in "Dasboard" You can control heavy loads like a water heater ,pool pump motor/s. great device
|}

 

=== '''Window Coverings''' ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Frequency
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| Merten
| Radio roller shutter push-button
| 5025xx, 5035xx, 5045xx
| 6,2,27,2,3 and 6,2,27,2,4
| EU
| Apr 2009
| Indoor
| [http://www.merten.de/download/DL_doku/V5025_581_01_web.pdf Link]
|  
| Ap15e
| Open/Close buttons work well, but slide bar does not work. GUI buttons do not work with Luup release 1.0.843 and 1.0.862 (fixed with Luup release 1.0.879). Workaround: Use a Luup Scene with the following code:<tt></tt>
<tt>local lul_arguments = {}</tt>

<tt>lul_arguments["newTargetValue"]="0"</tt>

<tt>lul_resultcode,lul_resultstring,lul_job,lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",lul_arguments,6) </tt> Replace "6" with your device number, replace "0" with "1" for inverse action.

|-
| Duewi
| Radio roller shutter push-button
| 054368
| 6,2,51,1,0
| EU
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work. Some additional observations by Ap15e (Vera V1, firmware 1.0.979):
*GUI button 'Stop' and corresponding UPnP service does not work.
*GUI button 'Up' moves the shutter down, GUI button 'Down' moves the shutter up ...
*After adjusting the running times even the slide bar seems to work!
*I got a report from a user that the düwi device may fail due to interference from the shutter motor. In this case an additional filter is required (costs about 25 €/direction).
*More information is available at [http://forum.micasaverde.com/index.php?topic=3359.msg16142#msg16142 Link]

|}

 

=== '''Cameras that work''' ===

See [http://wiki.micasaverde.com/index.php/IP_Cameras IP Cameras] for a more comprehensive and up to date list

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Path for JPEG image
! Product Review
! Notes
|-
| Linksys
| IP Camera
| 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
| 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
| 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
| iCV-22, 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
| 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
| 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
| 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).
|}

 

=== Alarm Panels ===

{| cellpadding="2" border="1"
|-
! Manufacturer
! Model(s)
! Required module
! Plugin
! Notes
|-
| DSC
|
*[http://www.dsc.com/index.php?n=products&o=view&id=1 PowerSeries PC1616]
*[http://www.dsc.com/index.php?n=products&o=view&id=2 PowerSeries PC1832]
*[http://www.dsc.com/index.php?n=products&o=view&id=3 PowerSeries PC1864]

| [http://www.dsc.com/index.php?n=products&o=view&id=22 IT-100]
| [http://code.mios.com/trac/mios_dscalarmpanel/wiki/WikiStart Link]
|
|-
| Elk
|
*[http://www.elkproducts.com/_webapp_2981420/M1_Gold_Cross_Platform_Control%C2%AE M1 Gold]
*[http://www.elkproducts.com/_webapp_3127911/M1EZ8_Cross_Platform_Control%C2%AE M1EZ8]

| The M1EZ8 panel requires the [http://www.elkproducts.com/_webapp_2981423/elk-m1ez8msi__m1ez8_main_serial_interface ELK-M1EZ8MSI] Main Serial Port Interface.
| [http://code.mios.com/trac/mios_elk-alarm-panel/wiki/WikiStart Link]
| You can use the ELK-M1XEP Ethernet Interface to connect the panels to Vera on the Ethernet port.
|-
| GE Security / Interlogix / Caddx
|
*[http://www.interlogix.com/resources/intrusion/906-3179_NetworX_brochure.pdf NetworX NX-4]
*[http://www.interlogix.com/resources/intrusion/906-3179_NetworX_brochure.pdf NetworX NX-6]
*[http://www.interlogix.com/resources/intrusion/906-3179_NetworX_brochure.pdf NetworX NX-8]
*[http://www.interlogix.com/resources/intrusion/906-3179_NetworX_brochure.pdf NetworX NX-8E]

| [http://utcfssecurityproducts.com/ProductsAndServices/Pages/NX-584.aspx NX-584]
| [http://code.mios.com/trac/mios_caddxnx584/wiki/WikiStart Link]
| NetworX NX-8E already has a RS-232 interface, so it doesn't require the NX-584 module.
|-
| Honeywell / Ademco
| VISTA-50P, VISTA-128BP, VISTA-128BPT, VISTA-128BPE, VISTA-128FBP, VISTA-250BP, VISTA-250BPT, VISTA-250BPE and VISTA-250FBP
| VISTA-50P, VISTA-128BP, VISTA-128FBP, VISTA-250BP, and VISTA-250FBP panels require the [http://www.security.honeywell.com/me/intrusion/products/exp/ac/138478.html 4100SM] module.
| [http://code.mios.com/trac/mios_ademco-panels-plugin/wiki/WikiStart Link]
| If your Vista panel is not on this list, look at the next row.
|-
| Honeywell / Ademco
| 10SE, 20SE, 10P, 15P, 20P, 50P, etc.
| [http://www.nutech.com/online-store/18.html AD2USB]
| [http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb/wiki/WikiStart Link]
|
|-
| Paradox
|
*Digiplex DGP-848
*EVO48
*[http://www.paradox.com/Products/default.asp?CATID=7 EVO192]

| [http://www.paradox.com/Products/default.asp?CATID=7&SUBCATID=75&PRD=234 PRT3 Integration Module]
| [http://code.mios.com/trac/mios_paradox-alarm/wiki/WikiStart Link]
|
|-
| Visonic
|
*[http://www.visonic.com/Products/Wireless-Property-Protection/PowerMax PowerMax]
*[http://www.visonic.com/Products/Wireless-Property-Protection/PowerMaxPlus PowerMax+]
*[http://www.visonic.com/Products/Wireless-Property-Protection/PowerMaxComplete PowerMaxComplete]
*[http://www.visonic.com/Products/Wireless-Property-Protection/PowerMaxPro PowerMaxPro]

| RS-232 Interface Module
| [http://code.mios.com/trac/mios_visonic-powermax/wiki/WikiStart Link]
|
|}

[[Category:User_Instructions]] [[Category:Hardware]]

Luup plugins: Static JSON file

2012-01-12T16:16:28Z

Autotoronto: /* What the static JSON file controls */

[[Category:Development]]

Starting in UI4, Luup plugins can specify a ''static JSON'' file. This file describes how the plugin appears in the web interface.

=What the static JSON file controls=

* The icon used by the plugin in the dashboard.
* The text that displays in the one-to-two-row status message in the dashboard.
* Whether the icon changes depending on the value of a variable in the device (for example, a binary light's icon changes from lit to unlit).
* The tabs that appear in the device's detail dialog (when you click the wrench/spanner).
* The content of these tabs.
* The triggers or events that are available for the device in the "Triggers" or "Events" tag of a scene.

=Referencing the static JSON file from the Device XML file=

The device XML file (customarly '''D_PluginName.xml''') contains a reference to the static JSON file, in the '''staticJson''' element. Place the element as a child of the '''device''' element:

<pre><nowiki>
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion></specVersion>
<device>
<deviceType>urn:schemas-futzle-com:device:holidayvirtualswitch:1</deviceType>
<staticJson>D_HolidayVirtualSwitch1.json</staticJson>

</nowiki></pre>

Capitalization is important, as with all XML.

The static JSON file is customarily called '''D_PluginName.json'''.

=The static JSON file=

The static JSON file is a single JSON object (associative array).

==Root keys==

These keys have been seen at the top level in static JSON files in the wild:

; flashicon
: The device's icon, as a string. Despite the name, the icon is not related to Flash in UI4. See [[Luup plugin icons]].
; imgIconBody
: A string which appears to have no effect.
; imgIconDimmable
: A string which appears to have no effect.
; imgIconTurnable
: A string which appears to have no effect.
; imgIconMin
: A string which appears to have no effect.
; imgIconMax
: A string which appears to have no effect.
; halloIconsDir
: A string which appears to have no effect. Usually contains "pics\/hallo", for reasons unknown.
; DisplayStatus
: A JSON object (associative array). For devices where the icon changes based on a variable's value, describes which variable, and the range of values that produce different icon images. See [[Luup plugin icons]].
; doc_url
: A JSON object (associative array). Appears to have no effect.
; Tabs
: A JSON array. Describes the tabs in the detail dialog, and what subset of the first tab appears in the dashboard. See [[Luup plugin tabs]].
; DeviceType
: A JSON string. Must match the '''deviceType''' element in the corresponding device XML ('''D_PluginName.xml''') file.
; eventList
: A JSON object (associative array). Describes the events that this plugin can produce. Events are triggers that can fire off actions in scenes. This key is required for UI4, and obsoleted in UI5. For UI5, use the eventList2 tag, which has a different format. For compatibility with both UI4 and UI5 you need the same information in both keys. See [[UI4 UI5 Migration]] for more information.
; eventList2
: see eventList, above.
; sceneList
: A JSON object (associative array). Describes the actions that this plugin can perform (for instance, as the action in a scene). This key is not required and is ignored in UI5, however it is needed for UI4 compatibility. See [[UI4 UI5 Migration]] for more information about its format.
; sceneList2
: see sceneList, above.

Luup plugins: Static JSON file

2012-01-12T16:10:37Z

Autotoronto:

[[Category:Development]]

Starting in UI4, Luup plugins can specify a ''static JSON'' file. This file describes how the plugin appears in the web interface.

=What the static JSON file controls=

* The icon used by the plugin in the dashboard.
* The text that displays in the one-to-two-row status message in the dashboard.
* Whether the icon changes depending on the value of a variable in the device (for example, a binary light's icon changes from lit to unlit).
* The tabs that appear in the device's detail dialog (when you click the wrench/spanner).
* The content of these tabs.

=Referencing the static JSON file from the Device XML file=

The device XML file (customarly '''D_PluginName.xml''') contains a reference to the static JSON file, in the '''staticJson''' element. Place the element as a child of the '''device''' element:

<pre><nowiki>
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion></specVersion>
<device>
<deviceType>urn:schemas-futzle-com:device:holidayvirtualswitch:1</deviceType>
<staticJson>D_HolidayVirtualSwitch1.json</staticJson>

</nowiki></pre>

Capitalization is important, as with all XML.

The static JSON file is customarily called '''D_PluginName.json'''.

=The static JSON file=

The static JSON file is a single JSON object (associative array).

==Root keys==

These keys have been seen at the top level in static JSON files in the wild:

; flashicon
: The device's icon, as a string. Despite the name, the icon is not related to Flash in UI4. See [[Luup plugin icons]].
; imgIconBody
: A string which appears to have no effect.
; imgIconDimmable
: A string which appears to have no effect.
; imgIconTurnable
: A string which appears to have no effect.
; imgIconMin
: A string which appears to have no effect.
; imgIconMax
: A string which appears to have no effect.
; halloIconsDir
: A string which appears to have no effect. Usually contains "pics\/hallo", for reasons unknown.
; DisplayStatus
: A JSON object (associative array). For devices where the icon changes based on a variable's value, describes which variable, and the range of values that produce different icon images. See [[Luup plugin icons]].
; doc_url
: A JSON object (associative array). Appears to have no effect.
; Tabs
: A JSON array. Describes the tabs in the detail dialog, and what subset of the first tab appears in the dashboard. See [[Luup plugin tabs]].
; DeviceType
: A JSON string. Must match the '''deviceType''' element in the corresponding device XML ('''D_PluginName.xml''') file.
; eventList
: A JSON object (associative array). Describes the events that this plugin can produce. Events are triggers that can fire off actions in scenes. This key is required for UI4, and obsoleted in UI5. For UI5, use the eventList2 tag, which has a different format. For compatibility with both UI4 and UI5 you need the same information in both keys. See [[UI4 UI5 Migration]] for more information.
; eventList2
: see eventList, above.
; sceneList
: A JSON object (associative array). Describes the actions that this plugin can perform (for instance, as the action in a scene). This key is not required and is ignored in UI5, however it is needed for UI4 compatibility. See [[UI4 UI5 Migration]] for more information about its format.
; sceneList2
: see sceneList, above.

Luup Plugins ByHand

2012-01-12T15:59:33Z

Autotoronto:

[[Category:Development]]
==Description of the XML files==

Because the web generator is not yet operational you need to create the XML files by hand. The easiest way to do this is to start with an existing device as a template that you modify to suit your needs. In Vera's Setup Web UI, choose Devices, Luup plug-ins. There is a list of all the XML files which came with Vera by default. Files that start with D_ are UPnP device specifications. Files that start with S_ are UPnP service specifications. And files that start with I_ are Luup implementation files. Click view to see the XML file. We recommend using the Firefox web browser because it has built-in support for nicely displaying XML files in a graphical tree. XML can be hard to read in other web browser.

When you open a device specification file the xml tag deviceType defines what kind of device it is. This is how a UPnP Control Point knows what this device is. If the device type starts with urn:schemas-upnp-org, that means it's a UPnP defined standard, and the list of services the device must support are defined by the UPnP forum. If you're creating your own device type you can substitute the schemas-upnp-org with your own web domain name and change the other parts of the name. But stick to the same convention and use only a-z, 0-9 and hypens (-) and colons (:). Remember though that if you use your own device type chances are UPnP Control Points won't know what to do with it unless the author of the control point makes a custom addition for you.

The device file references the service files (S_) and gives each service a serviceType and a serviceId. The serviceType what defines the standard UPnP service. But since it's possible to have multiple instances of a given service, each needs a unique serviceId. For example, there is a standard UPnP service to set the setpoint on a thermostat called: urn:schemas-upnp-org:service:TemperatureSetpoint:1. But many thermostats have multiple setpoints, such as heat and cool. So in the standard for a UPnP thermostat device (D_HVAC_ZoneThermostat1.xml), there are 2 instances of the serviceType "urn:schemas-upnp-org:service:TemperatureSetpoint:1", one has the id "urn:upnp-org:serviceId:TemperatureSetpoint1_Cool" and the other "urn:upnp-org:serviceId:TemperatureSetpoint1_Heat". They both use the same service specification, S_TemperatureSetpoint1.xml, which is in the XML tag SCPDURL.

The controlURL and eventSubURL are set by the Luup engine and the values in the device specification file are ignored.

The UPnP specification allows that we can add our own custom xml tags. So we add the xml tags "implemenationList" to the device specification which references the implementation files that device will use.

== The Luup XML implementation file ==

We recommend looking at the file I_TestIR.xml for a sample of a typical a/v device, like a TV, for the device file D_TestIR.xml. I_TestSerial.xml has a typical serial device, like a TV with an RS232 serial port for home automation, for the device file D_TestSerial.xml. The Test Serial device is described in detail here: [[Luup TestSerial]].

I_GC100.xml is a full featured, functional implementation for the Global Cache GC100, which is an ethernet device with relay switches, input sensors, infrared transmitters and serial ports. I_GC100.xml shows a complete Luup plugin with parent/child devices. The corresponding UPnP Device specification file is D_GC100.xml. In all the implementation files the top-level XML tag (ie root node) is called "implementation". It contains the following nodes:

=== settings ===

The settings node contains various settings for the implementation.

protocol: Is the protocol to use to talk to the device if you'll be sending data over the network or a serial port. The protocol tag tells Luup what's considered a single ''chunk'' of data. By using a format, from the supported list below, you avoid byte-by-byte processing on input streams as the Luup engine will ''chunk'' the data to you and pass it to your Lua code handling <tt><incoming></tt> requests.
Lua code is much cleaner when it handles data in chunks. If you have a protocol that's not natively supported, and is likely to be used by other devices, let us know and we'll add it to the Luup engine so you don't need to mess with it.

Valid values for this tag are:
*<tt>crlf</tt> - all incoming commands are terminated with a carriage return+line feed character, and all outgoing data should have a cr+lf appended.
*<tt>stxetx</tt> - all incoming commands are surrounded by STX and ETX characters. If you send the string "test" the framework will add the STX before and the ETX at the end, and if the string "<tt>''<stx>''test''<etx>''</tt>" is received, the framework will strip the STX and ETX and pass the string "test" to your incoming data handler.
*<tt>raw</tt> - makes no modifications to outgoing data, and calls your incoming data callback for each byte received. This adds more overhead since the engine needs to call your Luup function for every character, and makes your code complex. So, generally avoid using '<tt>raw</tt>' and let us add support for your protocol if you have a new one we don't yet support.

ioPort: One way to have the device talk to another device on the internet. If you put a TCP port number here, an outgoing connection attempt is made automatically when the device initializes. (The remote IP address should be placed in the 'ip' box in the device's advanced configuration tab.)

handleChildren: If this flag is 1, then any actions that are sent to one of this device's children will be handled within this devices implementation file. Look at the I_GC100.xml file to see how this is done. The GC100 is a parent device which has no services or actions, but has child devices like IR transmitters and relays. This implementation file handles the SwitchPower/SetTarget action for the relays, as well as the SendProntoCode action for the ir transmitters, even though those actions will be sent to the GC100's child device--not the device GC100 itself.

=== functions ===

Put here the Lua code for functions you want to be able to use in other places in your Lua code.

=== startup ===

This tag is a comma separated list of functions you want the Luup engine to call when it's starting up. Generally these are functions in the 'functions' tag.

=== actionList ===

This is where you specify what to do when an action comes in. Create an "action" node for each action, which contains "serviceId" and "name" tags to indicate what action is being implemented. The "name" tag refers to the name of the Action as defined in the UPnP Service Specification file.

There are several different nodes you can put within the "action" node.

==== ir ====

Put an ir code in pronto format in this tag. Luup will send a SendProntoCode action to whatever device is specified as the [[Luup IO Device]] in the [[Luup Configuration File]].

==== run/job/incoming/timeout ====

Put Lua code in the 'run' node that is run immediately when the action is received. This code should be short and quick and return right away because the UPnP Control Point will probably be blocked while it waits for the reply. Also, your Luup device will not do anything else while the 'run' code is executing. If it will take some time to handle the action, use the 'job' tag instead. Job's will run asynchronously, meaning they happen in the background. If you implement this action in a Job, you won't be able to give the result code (ie success/failure) to the UPnP Control Point because the Luup engine gives the Control Point an "action successful" as soon as it creates the job. You can put code in both the 'run' and 'job' tags. In this case, the code in the 'run' tag is run immediately and can return an error condition which is sent back to the UPnP Control Point, or, if it returns 'OK', then Luup will send the 'ok' to the UPnP Control Point and run the job later. The job can take as long as you want.

The UPnP forum did not create an action "on" or "off" for a light switch because they know that it can take some time to actually turn the light on or off, and you don't want to block the UPnP control point waiting for the light to go on or off. So, the UPnP action to turn a light on is called "SetTarget". The UPnP action tells the control point it executed the action ok simply when it receives the action. If the control point wants to know for sure if the light actually turned on, the control point should watch the 'Status' variable and see if it changes to "1" when the light is actually on.

In the case of the GC100, (see: I_GC100.xml), on/off of the relays happens immediately. So the implementation is inside a 'run' tag, which sets the "Status" variables. In the case of SendProntoCode, the implementation is inside a 'job' tag since the pronto commands may take time.

When you have Lua code inside a 'job' tag, Luup will return 'OK' to the Control Point in response to the action, and then queues up the job and runs the Lua in your 'job' code. The job code returns 2 values: 1) the status of the job, and 2) how long to wait before the job times out in seconds. The status can be:

0=job_WaitingToStart: In vera's UI a job in this state is displayed as a gray icon. It means it's waiting to start. If you return this value your 'job' code will be run again in the 'timeout' seconds

2=job_Error, or 3=job_Aborted: In vera's UI a job in this state is displayed as a red icon. This means the job failed. Your code won't be run again.

4=job_Done: In vera's UI a job in this state is displayed as a green icon. This means the job finished ok. Your code won't be run again.

5=job_WaitingForCallback: In vera's UI a job in this state is displayed as a moving blue icon. This means the job is running and you're waiting for return data. Any data that comes in while the job is in this state will go to the lua code in the job's 'incoming' tag. If no data comes in before the number of seconds you return in the timeout, then the code in the job's 'timeout' tag is run.

So in the SendProntoCode job code for the I_GC100, we return 5,10 which means we're waiting for data and should wait up to 10 seconds.

While a job is active, a UPnP control point will see the status of the job when it uses the GetStatus action for Vera. In Vera's web ui an active job is shown as an icon next to the device. While Luup is in the middle of executing the Lua code for your job, the status is reported to the control point as 1=job_InProgress.

Whenever your job is in status 5=job_WaitingForCallback, whatever data comes in on the I/O port will be first given to the job's 'incoming' Lua code *before* it's given to the general purpose 'incoming' Lua code (see below). If the incoming data is not for this job, you should not return a 'true' as the 3rd return parameter from 'incoming', and the Luup engine will forward the incoming data to the general purpose 'incoming' Lua code. If you do return 'true', the Luup engine assumes you handled the incoming data and there's nothing more to do with it. See the incoming tag for the SendProntoCode job code for the I_GC100 as an example. The 'incoming' code returns 3 values. The first 2 are the same as for the 'job', and the 3rd is true or false depending on if the incoming data was for this job or not.

The Luup engine will only run one chunk of Lua code at a time. This is necessary to prevent problems with the shared variables. However, there can be multiple jobs in the 5=job_WaitingForCallback state. When one job is run, and it returns the status 5=job_WaitingForCallback, the Luup engine will start another job while the first one is waiting. So when incoming data is received, the Luup engine will pass the data to the 'incoming' Lua code for all the jobs in the 5=job_WaitingForCallback state, in the order the jobs were created. As soon as a job returns 'true' for the 3rd parameter, Luup discards the incoming data. As long as the jobs return 'false' the data is passed on to the next job, and eventually to the general purpose 'incoming' Lua code. If, when you start a job, you do not want other jobs to run until your job is done, call the [[Luup Lua extensions]] lu_block_jobs. Other Luup plugins will continue to run asynchronously, but no other jobs will run for this particular Luup plugin until this job becomes 'done' or 'error/abort'.

[[Luup Declarations]] lists what variables this Lua code receives and what it should return.

==== incoming ====

This block defines what to do when data is received by the device, if this device is talking on a serial port, ethernet port, or some other generic I/O port. The Luup engine handles low-level I/O for these types of ports so you only need to call one of the [[Luup Lua extensions]] to send data on the port.

This is the general purpose incoming data handler that the Luup engine will call whenever data comes in on an I/O Port. It has a node 'lua' which contains the Lua code that is called.

[[Luup Declarations]] lists what variables this Lua code receives and what it should return.

=== function declarations ===

Whatever Lua code you create in the tags will be put inside a function automatically by the Luup engine, and your code will be passed variables that are relevant to whatever the code needs to do. For example, the code inside the 'run' tag is passed lul_device,lul_settings where lul_device is the id of the device the action was sent to, and lul_settings has the arguments to the UPnP action. See: [[Luup Declarations]] for details.

==Walkthrough to create a device==

We have documented step-by-step the detailed process of creating a Luup interface, including everything that was done to debug, for Somfy blind control device (see: [http://www.blindshademotors.com/documents/accessories-special-applications/rs232-to-rts-compatability.pdf]), which is a simple 1-way serial device (ie send data, but don't get any response) here: [[Luup_Somfy_Walkthrough]]

No matter type of Luup plugin you'll be creating the procedure to create it is the same. This is true for Luup plugins which do not talk to any external hardware, such as a 'Weather' plugin to provide weather services, as well as plugins that talk to infrared devices like a TV, and serial/network devices.

The first step is to create the UPnP device specification and service specification files. Whenever possible you will want to re-use existing service specification files, as explained in "Introduction to UPnP" [[Luup_Plugins#Introduction_to_UPnP here]]. And if your device is functionally the same as an existing UPnP Device type, like a light switch, you should re-use an existing UPnP Device Specification file also so that a UPnP Control Point will know how to control your device with modification. A list of all currently known UPnP Device and Service specification files is here: [[Luup_UPNP_Files]]. Find the existing UPnP device file that is most similar to the Luup plugin you are creating, and list all the services that device will implement. Download these files on your computer either from the [[Luup_UPNP_Files]] page, or by going to Vera's setup page and choosing Devices, Luup plugins.

Modify the UPnP device specification file as needed, such as changing the manufacturer and model. Do not worry about the UDN tag as Luup will create a UDN for you automatically. If your device is functionally the same as the template you started from, leave the deviceType the same. If it's different, modify the deviceType replacing the "schemas-upnp-org" or "micasaverde-com" with some domain that you have, or if you don't have one, just use your name. Leave the :device: but change the word after it to describe your device. The deviceType must contain only a-z, 0-9, : and -.

In the serviceList tag, add all the services you will implement. You can also create new services at this time. Save your new device file and service files as D_[some name] and S_[some name]. This is not mandated by UPnP, but is a convention we use so it's easy to recognize the file type by the name.

Now refer to "The Luup XML implementation file" section above to learn how to create an implementation file.

To add the device to Vera's configuration file, so Vera will load and use the device, go to the Devices tab and at the bottom fill in the UPnP Device filename in the 'Add Device' box and pick a room. When you save your changes, which causes the Luup engine to reload the new configuration, it will look for the device, service and implementation files to start the device. If the files don't already exist on Vera, Vera will log an error and will not start the device. So you need to upload any new files you created by going to the Devices, Luup plugins page in Vera's setup web page. You can upload several files at once. The files will not be used until the Loop engine is reset so you probably want to check the "Restart Luup after upload" box before you click 'go'. If you upload the files without checking the box and want to restart the Luup engine, just click 'save', even if the button is grayed out. You will likely need to make several changes to the files before they're right so you can leave one web browser open to the 'Luup plugin' page and just modify the files in your text editor then click 'go' again to re-upload them after saving your changes. You can open another browser window or tab to access other pages in Vera's web ui and control the device while leaving the list of files to upload on the Luup plugin page intact so you can re-upload by clicking 'go'.

Next you'll want to know how to debug your Luup plugins and Lua code. See [[Luup_Debugging]]

Luup Plugins ByHand

2012-01-12T15:58:44Z

Autotoronto:

[[Category:Development]]
==Description of the XML files==

Because the web generator is not yet operational you need to create the XML files by hand. The easiest way to do this is to start with an existing device as a template that you modify to suit your needs. In Vera's Setup Web UI, choose Devices, Luup plug-ins. There is a list of all the XML files which came with Vera by default. Files that start with D_ are UPnP device specifications. Files that start with S_ are UPnP service specifications. And files that start with I_ are Luup implementation files. Click view to see the XML file. We recommend using the Firefox web browser because it has built-in support for nicely displaying XML files in a graphical tree. XML can be hard to read in other web browser.

When you open a device specification file the xml tag deviceType defines what kind of device it is. This is how a UPnP Control Point knows what this device is. If the device type starts with urn:schemas-upnp-org, that means it's a UPnP defined standard, and the list of services the device must support are defined by the UPnP forum. If you're creating your own device type you can substitute the schemas-upnp-org with your own web domain name and change the other parts of the name. But stick to the same convention and use only a-z, 0-9 and hypens (-) and colons (:). Remember though that if you use your own device type chances are UPnP Control Points won't know what to do with it unless the author of the control point makes a custom addition for you.

The device file references the service files (S_) and gives each service a serviceType and a serviceId. The serviceType what defines the standard UPnP service. But since it's possible to have multiple instances of a given service, each needs a unique serviceId. For example, there is a standard UPnP service to set the setpoint on a thermostat called: urn:schemas-upnp-org:service:TemperatureSetpoint:1. But many thermostats have multiple setpoints, such as heat and cool. So in the standard for a UPnP thermostat device (D_HVAC_ZoneThermostat1.xml), there are 2 instances of the serviceType "urn:schemas-upnp-org:service:TemperatureSetpoint:1", one has the id "urn:upnp-org:serviceId:TemperatureSetpoint1_Cool" and the other "urn:upnp-org:serviceId:TemperatureSetpoint1_Heat". They both use the same service specification, S_TemperatureSetpoint1.xml, which is in the XML tag SCPDURL.

The controlURL and eventSubURL are set by the Luup engine and the values in the device specification file are ignored.

The UPnP specification allows that we can add our own custom xml tags. So we add the xml tags "implemenationList" to the device specification which references the implementation files that device will use.

== The Luup XML implementation file ==

We recommend looking at the file I_TestIR.xml for a sample of a typical a/v device, like a TV, for the device file D_TestIR.xml. I_TestSerial.xml has a typical serial device, like a TV with an RS232 serial port for home automation, for the device file D_TestSerial.xml. The Test Serial device is described in detail here: [[Luup TestSerial]].

I_GC100.xml is a full featured, functional implementation for the Global Cache GC100, which is an ethernet device with relay switches, input sensors, infrared transmitters and serial ports. I_GC100.xml shows a complete Luup plugin with parent/child devices. The corresponding UPnP Device specification file is D_GC100.xml. In all the implementation files the top-level XML tag (ie root node) is called "implementation". It contains the following nodes:

=== settings ===

The settings node contains various settings for the implementation.

protocol: Is the protocol to use to talk to the device if you'll be sending data over the network or a serial port. The protocol tag tells Luup what's considered a single ''chunk'' of data. By using a format, from the supported list below, you avoid byte-by-byte processing on input streams as the Luup engine will ''chunk'' the data to you and pass it to your Lua code handling <tt><incoming></tt> requests.
Lua code is much cleaner when it handles data in chunks. If you have a protocol that's not natively supported, and is likely to be used by other devices, let us know and we'll add it to the Luup engine so you don't need to mess with it.

Valid values for this tag are:
*<tt>crlf</tt> - all incoming commands are terminated with a carriage return+line feed character, and all outgoing data should have a cr+lf appended.
*<tt>stxetx</tt> - all incoming commands are surrounded by STX and ETX characters. If you send the string "test" the framework will add the STX before and the ETX at the end, and if the string "<tt>''<stx>''test''<etx>''</tt>" is received, the framework will strip the STX and ETX and pass the string "test" to your incoming data handler.
*<tt>raw</tt> - makes no modifications to outgoing data, and calls your incoming data callback for each byte received. This adds more overhead since the engine needs to call your Luup function for every character, and makes your code complex. So, generally avoid using '<tt>raw</tt>' and let us add support for your protocol if you have a new one we don't yet support.

ioPort: For use if the device talks to another device on the internet. If you put a TCP port number here, an outgoing connection attempt is made automatically when the device initializes. (The remote IP address should be placed in the 'ip' box in the device's advanced configuration tab.)

handleChildren: If this flag is 1, then any actions that are sent to one of this device's children will be handled within this devices implementation file. Look at the I_GC100.xml file to see how this is done. The GC100 is a parent device which has no services or actions, but has child devices like IR transmitters and relays. This implementation file handles the SwitchPower/SetTarget action for the relays, as well as the SendProntoCode action for the ir transmitters, even though those actions will be sent to the GC100's child device--not the device GC100 itself.

=== functions ===

Put here the Lua code for functions you want to be able to use in other places in your Lua code.

=== startup ===

This tag is a comma separated list of functions you want the Luup engine to call when it's starting up. Generally these are functions in the 'functions' tag.

=== actionList ===

This is where you specify what to do when an action comes in. Create an "action" node for each action, which contains "serviceId" and "name" tags to indicate what action is being implemented. The "name" tag refers to the name of the Action as defined in the UPnP Service Specification file.

There are several different nodes you can put within the "action" node.

==== ir ====

Put an ir code in pronto format in this tag. Luup will send a SendProntoCode action to whatever device is specified as the [[Luup IO Device]] in the [[Luup Configuration File]].

==== run/job/incoming/timeout ====

Put Lua code in the 'run' node that is run immediately when the action is received. This code should be short and quick and return right away because the UPnP Control Point will probably be blocked while it waits for the reply. Also, your Luup device will not do anything else while the 'run' code is executing. If it will take some time to handle the action, use the 'job' tag instead. Job's will run asynchronously, meaning they happen in the background. If you implement this action in a Job, you won't be able to give the result code (ie success/failure) to the UPnP Control Point because the Luup engine gives the Control Point an "action successful" as soon as it creates the job. You can put code in both the 'run' and 'job' tags. In this case, the code in the 'run' tag is run immediately and can return an error condition which is sent back to the UPnP Control Point, or, if it returns 'OK', then Luup will send the 'ok' to the UPnP Control Point and run the job later. The job can take as long as you want.

The UPnP forum did not create an action "on" or "off" for a light switch because they know that it can take some time to actually turn the light on or off, and you don't want to block the UPnP control point waiting for the light to go on or off. So, the UPnP action to turn a light on is called "SetTarget". The UPnP action tells the control point it executed the action ok simply when it receives the action. If the control point wants to know for sure if the light actually turned on, the control point should watch the 'Status' variable and see if it changes to "1" when the light is actually on.

In the case of the GC100, (see: I_GC100.xml), on/off of the relays happens immediately. So the implementation is inside a 'run' tag, which sets the "Status" variables. In the case of SendProntoCode, the implementation is inside a 'job' tag since the pronto commands may take time.

When you have Lua code inside a 'job' tag, Luup will return 'OK' to the Control Point in response to the action, and then queues up the job and runs the Lua in your 'job' code. The job code returns 2 values: 1) the status of the job, and 2) how long to wait before the job times out in seconds. The status can be:

0=job_WaitingToStart: In vera's UI a job in this state is displayed as a gray icon. It means it's waiting to start. If you return this value your 'job' code will be run again in the 'timeout' seconds

2=job_Error, or 3=job_Aborted: In vera's UI a job in this state is displayed as a red icon. This means the job failed. Your code won't be run again.

4=job_Done: In vera's UI a job in this state is displayed as a green icon. This means the job finished ok. Your code won't be run again.

5=job_WaitingForCallback: In vera's UI a job in this state is displayed as a moving blue icon. This means the job is running and you're waiting for return data. Any data that comes in while the job is in this state will go to the lua code in the job's 'incoming' tag. If no data comes in before the number of seconds you return in the timeout, then the code in the job's 'timeout' tag is run.

So in the SendProntoCode job code for the I_GC100, we return 5,10 which means we're waiting for data and should wait up to 10 seconds.

While a job is active, a UPnP control point will see the status of the job when it uses the GetStatus action for Vera. In Vera's web ui an active job is shown as an icon next to the device. While Luup is in the middle of executing the Lua code for your job, the status is reported to the control point as 1=job_InProgress.

Whenever your job is in status 5=job_WaitingForCallback, whatever data comes in on the I/O port will be first given to the job's 'incoming' Lua code *before* it's given to the general purpose 'incoming' Lua code (see below). If the incoming data is not for this job, you should not return a 'true' as the 3rd return parameter from 'incoming', and the Luup engine will forward the incoming data to the general purpose 'incoming' Lua code. If you do return 'true', the Luup engine assumes you handled the incoming data and there's nothing more to do with it. See the incoming tag for the SendProntoCode job code for the I_GC100 as an example. The 'incoming' code returns 3 values. The first 2 are the same as for the 'job', and the 3rd is true or false depending on if the incoming data was for this job or not.

The Luup engine will only run one chunk of Lua code at a time. This is necessary to prevent problems with the shared variables. However, there can be multiple jobs in the 5=job_WaitingForCallback state. When one job is run, and it returns the status 5=job_WaitingForCallback, the Luup engine will start another job while the first one is waiting. So when incoming data is received, the Luup engine will pass the data to the 'incoming' Lua code for all the jobs in the 5=job_WaitingForCallback state, in the order the jobs were created. As soon as a job returns 'true' for the 3rd parameter, Luup discards the incoming data. As long as the jobs return 'false' the data is passed on to the next job, and eventually to the general purpose 'incoming' Lua code. If, when you start a job, you do not want other jobs to run until your job is done, call the [[Luup Lua extensions]] lu_block_jobs. Other Luup plugins will continue to run asynchronously, but no other jobs will run for this particular Luup plugin until this job becomes 'done' or 'error/abort'.

[[Luup Declarations]] lists what variables this Lua code receives and what it should return.

==== incoming ====

This block defines what to do when data is received by the device, if this device is talking on a serial port, ethernet port, or some other generic I/O port. The Luup engine handles low-level I/O for these types of ports so you only need to call one of the [[Luup Lua extensions]] to send data on the port.

This is the general purpose incoming data handler that the Luup engine will call whenever data comes in on an I/O Port. It has a node 'lua' which contains the Lua code that is called.

[[Luup Declarations]] lists what variables this Lua code receives and what it should return.

=== function declarations ===

Whatever Lua code you create in the tags will be put inside a function automatically by the Luup engine, and your code will be passed variables that are relevant to whatever the code needs to do. For example, the code inside the 'run' tag is passed lul_device,lul_settings where lul_device is the id of the device the action was sent to, and lul_settings has the arguments to the UPnP action. See: [[Luup Declarations]] for details.

==Walkthrough to create a device==

We have documented step-by-step the detailed process of creating a Luup interface, including everything that was done to debug, for Somfy blind control device (see: [http://www.blindshademotors.com/documents/accessories-special-applications/rs232-to-rts-compatability.pdf]), which is a simple 1-way serial device (ie send data, but don't get any response) here: [[Luup_Somfy_Walkthrough]]

No matter type of Luup plugin you'll be creating the procedure to create it is the same. This is true for Luup plugins which do not talk to any external hardware, such as a 'Weather' plugin to provide weather services, as well as plugins that talk to infrared devices like a TV, and serial/network devices.

The first step is to create the UPnP device specification and service specification files. Whenever possible you will want to re-use existing service specification files, as explained in "Introduction to UPnP" [[Luup_Plugins#Introduction_to_UPnP here]]. And if your device is functionally the same as an existing UPnP Device type, like a light switch, you should re-use an existing UPnP Device Specification file also so that a UPnP Control Point will know how to control your device with modification. A list of all currently known UPnP Device and Service specification files is here: [[Luup_UPNP_Files]]. Find the existing UPnP device file that is most similar to the Luup plugin you are creating, and list all the services that device will implement. Download these files on your computer either from the [[Luup_UPNP_Files]] page, or by going to Vera's setup page and choosing Devices, Luup plugins.

Modify the UPnP device specification file as needed, such as changing the manufacturer and model. Do not worry about the UDN tag as Luup will create a UDN for you automatically. If your device is functionally the same as the template you started from, leave the deviceType the same. If it's different, modify the deviceType replacing the "schemas-upnp-org" or "micasaverde-com" with some domain that you have, or if you don't have one, just use your name. Leave the :device: but change the word after it to describe your device. The deviceType must contain only a-z, 0-9, : and -.

In the serviceList tag, add all the services you will implement. You can also create new services at this time. Save your new device file and service files as D_[some name] and S_[some name]. This is not mandated by UPnP, but is a convention we use so it's easy to recognize the file type by the name.

Now refer to "The Luup XML implementation file" section above to learn how to create an implementation file.

To add the device to Vera's configuration file, so Vera will load and use the device, go to the Devices tab and at the bottom fill in the UPnP Device filename in the 'Add Device' box and pick a room. When you save your changes, which causes the Luup engine to reload the new configuration, it will look for the device, service and implementation files to start the device. If the files don't already exist on Vera, Vera will log an error and will not start the device. So you need to upload any new files you created by going to the Devices, Luup plugins page in Vera's setup web page. You can upload several files at once. The files will not be used until the Loop engine is reset so you probably want to check the "Restart Luup after upload" box before you click 'go'. If you upload the files without checking the box and want to restart the Luup engine, just click 'save', even if the button is grayed out. You will likely need to make several changes to the files before they're right so you can leave one web browser open to the 'Luup plugin' page and just modify the files in your text editor then click 'go' again to re-upload them after saving your changes. You can open another browser window or tab to access other pages in Vera's web ui and control the device while leaving the list of files to upload on the Luup plugin page intact so you can re-upload by clicking 'go'.

Next you'll want to know how to debug your Luup plugins and Lua code. See [[Luup_Debugging]]