MiOS - User contributions [en]

Insteon Intro

2009-08-31T21:31:48Z

LibraSun:

Here's a quick walkthrough of how to get started with Insteon/X10 in Vera.

1. Connect a SmartLabs 2412U PowerLinc Modem to one of Vera's USB ports. Alternatively, you can use a 2412S (RS-232) version and this Serial to USB adapter: http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductID=UC232R10FUTURETECHNOLOGYDEVICES2297802

2. Go to Vera's Setup page in your browser and click 'Devices', 'Insteon/X10'. If you see the message: "Insteon interface not found, do you want to enable it?", click the 'Enable it' button, and then click 'Save'. Wait a minute for Vera to enable the Insteon/X10 module and find the PowerLinc.

3. Go to 'Devices', 'Insteon/X10'. If Vera had a problem finding or setting up your Insteon modem, then you will see an error message at the top of the page under the 'Insteon/X10'. Otherwise you're good to go.

4. To add Insteon devices, click the 'Add/Remove Insteon device' button. To add X10 devices, choose the device type, house id and room in the 'Add an X10' section, then click 'go'.

5. When you've added new Insteon devices and Vera doesn't yet know what room they're in, you will see the 'unassigned devices' page, which shows you the new devices and asks you to pick the room the device is in. Do this and click continue.

6. If Vera was successfully able to talk to your Insteon device, you will see a green cog wheel next to the device as explained in [[Device Control Status]] You can click the '+' button next to a device to see more detailed information on the device, including it's ID.

Refer to the page [[Insteon Supported Hardware]] for notes on specific Insteon devices and how they work.

Supported Hardware

2009-08-23T21:41:58Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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
|  ??????
| 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!
|}

=== '''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]]
|}

=== '''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
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|
|}

=== '''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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-23T21:32:42Z

LibraSun: /* Sensors */

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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
|  ??????
| 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!
|}

=== '''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
|
|
|
| Indoor
|
|
|
| Read the instructions here: [[Schlage 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
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|
|}

=== '''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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Schlage Lock

2009-08-21T12:55:57Z

LibraSun: /* Controlling the lock with handheld remotes and scene controllers */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's 'Dashboard'. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. (See [[ZWave Add Controller|Z-Wave Add Controller]] method #2.) So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's 'Dashboard' shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

UI Notes

2009-08-20T15:40:12Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides a simple HTTP GET interface as well, which is discussed below. Vera also translates between XML and JSON, so you can retrieve data in JSON format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: '''http://findvera.com/locator.php'''

Each Vera, when it boots up, reports its internal IP address to the central findvera.com server, which tracks this along with the external IP address. '''locator.php''' shows all serial numbers and internal network IP addresses on the same external IP. For example, if '''http://findvera.com/locator.php''' returns the following:

 

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (i.e. sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP internal (LAN) addresses shown.

You can also pass a FindVera username to '''locator.php''' and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple HTTP requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://[ipadress]:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The '''output_format=xml''' on the URL means the data returned should be in XML format. You can instead use '''output_format=json'''

== Getting the system configuration ==

Either use the UPnP service/action: '''urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData'''

or use the built-in request:

'''http://ipaddress:49451/data_request?id=user_data&output_format=json''' (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask whether the user wants to (a) access Vera remotely; (b) through the FindVera service, and if so, the user's username/password; or (c) access Vera on the home network. You can use locator.php to show the Vera on the home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for a FindVera username and password. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php (without the username) indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with Wi-Fi (which is much faster of course) and remote access with FindVera and the mobile phone network.

2. Once the connection is established, retrieve the '''user_data''' to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and continually parse it. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene ID, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as '''x''', and it will return an OK if it went okay:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. (See [[Luup UPNP Files]] for a list of the categories.) When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup CP Mandatory Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job ID back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use '''lu_status '''(explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job ''per se'', but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through okay. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with '''lu_status''', like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an 'off' state. '''lu_status''' also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interest, particularly
when creating a full replacement for Vera's built-in web user interface.

The unassigned devices and automation devices in the '''user_data''' JSON request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (i.e. the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (i.e. FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable '''urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom''' set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since JavaScript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices not yet assigned to a room, he asked us to put a counter in the JSON (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to rooms and displays the popup for those that are not yet in a room.

He also wanted an 'automation devices' counter, again, so he doesn't need to parse the JSON tree unnecessarily. If the counter is 0, then the user has no Z-Wave devices and he doesn't bother rendering the devices tab.

The counters and data in the '''user_data''' are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls '''user_data''' every 60 seconds or so. Each time it polls '''user_data''', it passes in the DataVersion from the last '''user_data''' it got. This way if there are no changes, rather than returning an identical JSON tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the '''user_data''' changes, the UI needs to update all the devices/trees/etc. because that means something has changed.

Separately, there's another background poll of '''lu_status''' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling '''zwave_status''' every 2 seconds. This is because things are changing quickly (i.e. the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next '''zwave_status '''poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based UI's and engines like JavaScript, implementing raw socket transfers isn't as easy as simple HTTP GETs, so it just uses polling of the HTTP GETs.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T15:32:00Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides a simple HTTP GET interface as well, which is discussed below. Vera also translates between XML and JSON, so you can retrieve data in JSON format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: '''http://findvera.com/locator.php'''

Each Vera, when it boots up, reports its internal IP address to the central findvera.com server, which tracks this along with the external IP address. '''locator.php''' shows all serial numbers and internal network IP addresses on the same external IP. For example, if '''http://findvera.com/locator.php''' returns the following:

 

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (i.e. sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP internal (LAN) addresses shown.

You can also pass a FindVera username to '''locator.php''' and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple HTTP requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://[ipadress]:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The '''output_format=xml''' on the URL means the data returned should be in XML format. You can instead use '''output_format=json'''

== Getting the system configuration ==

Either use the UPnP service/action: '''urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData'''

or use the built-in request:

'''http://ipaddress:49451/data_request?id=user_data&output_format=json''' (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask whether the user wants to (a) access Vera remotely; (b) through the FindVera service, and if so, the user's username/password; or (c) access Vera on the home network. You can use locator.php to show the Vera on the home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for a FindVera username and password. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php (without the username) indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with Wi-Fi (which is much faster of course) and remote access with FindVera and the mobile phone network.

2. Once the connection is established, retrieve the '''user_data''' to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and continually parse it. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene ID, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as '''x''', and it will return an OK if it went okay:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. (See [[Luup UPNP Files]] for a list of the categories.) When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup CP Mandatory Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job ID back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use '''lu_status '''(explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job ''per se'', but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through okay. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with '''lu_status''', like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an 'off' state. '''lu_status''' also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T15:23:28Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides a simple HTTP GET interface as well, which is discussed below. Vera also translates between XML and JSON, so you can retrieve data in JSON format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: '''http://findvera.com/locator.php'''

Each Vera, when it boots up, reports its internal IP address to the central findvera.com server, which tracks this along with the external IP address. '''locator.php''' shows all serial numbers and internal network IP addresses on the same external IP. For example, if '''http://findvera.com/locator.php''' returns the following:

 

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (i.e. sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP internal (LAN) addresses shown.

You can also pass a FindVera username to '''locator.php''' and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple HTTP requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://[ipadress]:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The '''output_format=xml''' on the URL means the data returned should be in XML format. You can instead use '''output_format=json'''

== Getting the system configuration ==

Either use the UPnP service/action: '''urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData'''

or use the built-in request:

'''http://ipaddress:49451/data_request?id=user_data&output_format=json''' (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T15:22:28Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides a simple HTTP GET interface as well, which is discussed below. Vera also translates between XML and JSON, so you can retrieve data in JSON format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: '''http://findvera.com/locator.php'''

Each Vera, when it boots up, reports its internal IP address to the central findvera.com server, which tracks this along with the external IP address. '''locator.php''' shows all serial numbers and internal network IP addresses on the same external IP. For example, if '''http://findvera.com/locator.php''' returns the following:

 

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (i.e. sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP internal (LAN) addresses shown.

You can also pass a FindVera username to '''locator.php''' and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple HTTP requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://[ipadress]:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The '''output_format=xml''' on the URL means the data returned should be in XML format. You can instead use '''output_format=json'''

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T15:19:19Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides a simple HTTP GET interface as well, which is discussed below. Vera also translates between XML and JSON, so you can retrieve data in JSON format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: '''http://findvera.com/locator.php'''

Each Vera, when it boots up, reports its internal IP address to the central findvera.com server, which tracks this along with the external IP address. '''locator.php''' shows all serial numbers and internal network IP addresses on the same external IP. For example, if '''http://findvera.com/locator.php''' returns the following:

 

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (i.e. sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP internal (LAN) addresses shown.

You can also pass a FindVera username to '''locator.php''' and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple http requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The "output_format=xml" on the URL means the data returned should be in XML format. You can instead use: output_format=json

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T15:17:00Z

LibraSun: /* UPnP messaging system */

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides a simple HTTP GET interface as well, which is discussed below. Vera also translates between XML and JSON, so you can retrieve data in JSON format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: http://findvera.com/locator.php

Each Vera, when it boots up, reports it's internal IP address to the central findvera.com server, which tracks this along with the external IP address. locator.php shows all serial numbers and internal network IP addresses on the same external IP. For example, if http://findvera.com/locator.php returns the following:

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (ie sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP addresses shown.

You can also pass a findvera username to locator.php and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple http requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The "output_format=xml" on the URL means the data returned should be in XML format. You can instead use: output_format=json

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T14:20:20Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides simple a HTTP GET interface as well, which is discussed below. Vera also translates between XML and json, so you can retrieve data in json format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: http://findvera.com/locator.php

Each Vera, when it boots up, reports it's internal IP address to the central findvera.com server, which tracks this along with the external IP address. locator.php shows all serial numbers and internal network IP addresses on the same external IP. For example, if http://findvera.com/locator.php returns the following:

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (ie sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP addresses shown.

You can also pass a findvera username to locator.php and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple http requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The "output_format=xml" on the URL means the data returned should be in XML format. You can instead use: output_format=json

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the '''template_data''' JSON file explained [[Data Provider Catalog Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic Parameters: #8 On/Off: Set this value to 1 to put the thermostat in 'on' mode, and 0 to put it in 'auto' mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full 'auto' mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. Parameters: #28 PK_CommandGroup: This is the ID of the scene (i.e. the number following scene_). Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the Dashboard (i.e. a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'Test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (lines starting with 08 are commands) after clicking 'Test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file: Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a Z-Wave node):''' When sent to a Z-Wave node (i.e. a child of the device Z-Wave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. Parameters: none

'''#776 Reset (when sent to the Z-Wave interface):''' When sent to the parent Z-Wave device, the interface which is often device #9, it resets the Z-Wave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairings will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, Z-Wave options, 'reset zwave network' button explained here: [[ZWave Options]]. Parameters: #51 Arguments: This parameter can be: SUC or SIS (i.e. send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a Z-Wave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'pairing' mode to add new devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send one of the following values to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exit add mode.

'''#968 Remove Node:''' When sent to the parent Z-Wave device, the interface which is often device #9, it causes the dongle to go into 'reset' mode to remove devices. See [[ZWave Options|Z-Wave Options]] Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send one of the following values to restrict what type of node is removed: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the node to be removed. Parameters: #259 Multiple: If true (i.e. 1) then multiple devices can be removed and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exit remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. Parameters: #2 PK_Device: This is the device ID of the sensors Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. Parameters: #17 PK_Users: This is user code to set Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T14:01:51Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides simple a HTTP GET interface as well, which is discussed below. Vera also translates between XML and json, so you can retrieve data in json format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: http://findvera.com/locator.php

Each Vera, when it boots up, reports it's internal IP address to the central findvera.com server, which tracks this along with the external IP address. locator.php shows all serial numbers and internal network IP addresses on the same external IP. For example, if http://findvera.com/locator.php returns the following:

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (ie sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP addresses shown.

You can also pass a findvera username to locator.php and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple http requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The "output_format=xml" on the URL means the data returned should be in XML format. You can instead use: output_format=json

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the template_data json file explained [[Data_Provider_Catalog_Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level 
Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks 
Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature 
Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic 
Parameters: #8 On/Off: Set this value to 1 to put the thermostat is 'on' mode, and 0 to put it in auto mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool 
Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full auto mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. 
Parameters: #28 PK_CommandGroup: This is the id of the scene (ie the number following scene_). 
Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: 
PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" 
where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the dashboard (ie a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (ie lines starting with 08 are commands) after clicking 'test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. 
Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file:
Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. 
Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a ZWave node):''' When sent to a ZWave node (ie a child of the device ZWave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. 
Parameters: none

'''#776 Reset (when sent to the ZWave interface):''' When sent to the parent ZWave device, the interface which is often device #9, it resets the ZWave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairing's will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, ZWave options, 'reset zwave network' button explained here: [[ZWave_Options]]. 
Parameters: #51 Arguments: This parameter can be: SUC or SIS (ie send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a ZWave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent ZWave device, the interface which is often device #9, it causes the to go into 'pairing' mode to add new devices. See [[ZWave_Options]] 
Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. 
Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send on the of the Zensys define's to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed 
Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. 
Parameters: #259 Multiple: If true (ie 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exist add mode.

'''#968 Remove Node:''' When sent to the parent ZWave device, the interface which is often device #9, it causes the to go into 'reset' mode to remove devices. See [[ZWave_Options]] 
Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. 
Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send on the of the Zensys define's to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed 
Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. 
Parameters: #259 Multiple: If true (ie 1) then multiple devices can be added and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exist remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. 
Parameters: #2 PK_Device: This is the device id of the sensors 
Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. 
Parameters: #17 PK_Users: This is user code to set 
Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event ID numbers and the parameters for each are defined in'''template_data'''. Therefore, when you add an event, this is a free-form template that can be used for any type of event. '''PK_CriteriaParmList''' is one of the following:

1=CRITERIAPARMLIST_System_CONST 2=CRITERIAPARMLIST_PK_Installation_CONST 3=CRITERIAPARMLIST_PK_Skin_CONST 5=CRITERIAPARMLIST_Month_CONST 8=CRITERIAPARMLIST_PK_Device_CONST 10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 11=CRITERIAPARMLIST_Time_of_day_CONST 12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 13=CRITERIAPARMLIST_PK_Room_CONST 14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 15=CRITERIAPARMLIST_House_Mode_CONST 16=CRITERIAPARMLIST_Room_Mode_CONST 17=CRITERIAPARMLIST_Day_Of_Week_CONST 18=CRITERIAPARMLIST_Day_Of_Month_CONST 19=CRITERIAPARMLIST_Specific_Date_CONST 20=CRITERIAPARMLIST_PK_RoomType_CONST 22=CRITERIAPARMLIST_PK_EventList_CONST 23=CRITERIAPARMLIST_PK_EventHandler_CONST 24=CRITERIAPARMLIST_PK_EventParameter_CONST 25=CRITERIAPARMLIST_User_Mode_CONST 26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field for the criteria, and in this case, the "Parm" field is the ID of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated TRUE when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 -- that is, (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": { "Description":"Temperature is reached", "FK_Event":"25", "bIsAnd":"1", "bIsNot":"0" },

So it's an event handler for event #25, which is:

"PK_Event_25": { "FK_EventCategory":"10", "Description":"Temperature Changed" },

'''bIsAnd''' means all the parameters are AND'd together and must all match. If bIsAnd were 0, it would be an OR. bIsNot means the negative, that is, trip the event if all the criteria are false. You also see:

"PK_CannedEvents_CriteriaParmList_102": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"8", "Description":"Which device?", "Comments":"", "Operator":"1", "Parm":"", "DefaultValue":"1", "ExtraInfo":"", "Required":"0" }, "PK_CannedEvents_CriteriaParmList_103": { "FK_CannedEvents":"101", "FK_CriteriaParmList":"24", "Description":"What temperature?", "Comments":"", "Operator":"1", "Parm":"30", "DefaultValue":"", "ExtraInfo":"", "Required":"0" },

So, when prompting the user for a "Temperature changed" event, we will want to get 2 things: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. (See '''template_data''' for the complete list of events.)

You do not necessarily need to parse '''template_data''' in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, '''template_data''' explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T13:55:00Z

LibraSun:

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides simple a HTTP GET interface as well, which is discussed below. Vera also translates between XML and json, so you can retrieve data in json format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: http://findvera.com/locator.php

Each Vera, when it boots up, reports it's internal IP address to the central findvera.com server, which tracks this along with the external IP address. locator.php shows all serial numbers and internal network IP addresses on the same external IP. For example, if http://findvera.com/locator.php returns the following:

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (ie sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP addresses shown.

You can also pass a findvera username to locator.php and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple http requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The "output_format=xml" on the URL means the data returned should be in XML format. You can instead use: output_format=json

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the template_data json file explained [[Data_Provider_Catalog_Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level 
Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks 
Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature 
Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic 
Parameters: #8 On/Off: Set this value to 1 to put the thermostat is 'on' mode, and 0 to put it in auto mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool 
Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full auto mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. 
Parameters: #28 PK_CommandGroup: This is the id of the scene (ie the number following scene_). 
Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: 
PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" 
where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the dashboard (ie a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (ie lines starting with 08 are commands) after clicking 'test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. 
Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file:
Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. 
Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a ZWave node):''' When sent to a ZWave node (ie a child of the device ZWave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. 
Parameters: none

'''#776 Reset (when sent to the ZWave interface):''' When sent to the parent ZWave device, the interface which is often device #9, it resets the ZWave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairing's will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, ZWave options, 'reset zwave network' button explained here: [[ZWave_Options]]. 
Parameters: #51 Arguments: This parameter can be: SUC or SIS (ie send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a ZWave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent ZWave device, the interface which is often device #9, it causes the to go into 'pairing' mode to add new devices. See [[ZWave_Options]] 
Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. 
Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send on the of the Zensys define's to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed 
Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. 
Parameters: #259 Multiple: If true (ie 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exist add mode.

'''#968 Remove Node:''' When sent to the parent ZWave device, the interface which is often device #9, it causes the to go into 'reset' mode to remove devices. See [[ZWave_Options]] 
Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. 
Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send on the of the Zensys define's to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed 
Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. 
Parameters: #259 Multiple: If true (ie 1) then multiple devices can be added and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exist remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. 
Parameters: #2 PK_Device: This is the device id of the sensors 
Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. 
Parameters: #17 PK_Users: This is user code to set 
Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event id numbers and the parameters for each are defined in template_data. Therefore, when you add an event, this is a free-form template that can be used for any type of event. PK_CriteriaParmList is one of the following:

1=CRITERIAPARMLIST_System_CONST 
2=CRITERIAPARMLIST_PK_Installation_CONST 
3=CRITERIAPARMLIST_PK_Skin_CONST 
5=CRITERIAPARMLIST_Month_CONST 
8=CRITERIAPARMLIST_PK_Device_CONST 
10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 
11=CRITERIAPARMLIST_Time_of_day_CONST 
12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 
13=CRITERIAPARMLIST_PK_Room_CONST 
14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 
15=CRITERIAPARMLIST_House_Mode_CONST 
16=CRITERIAPARMLIST_Room_Mode_CONST 
17=CRITERIAPARMLIST_Day_Of_Week_CONST 
18=CRITERIAPARMLIST_Day_Of_Month_CONST 
19=CRITERIAPARMLIST_Specific_Date_CONST 
20=CRITERIAPARMLIST_PK_RoomType_CONST 
22=CRITERIAPARMLIST_PK_EventList_CONST 
23=CRITERIAPARMLIST_PK_EventHandler_CONST 
24=CRITERIAPARMLIST_PK_EventParameter_CONST 
25=CRITERIAPARMLIST_User_Mode_CONST 
26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field the criteria, and in this case, the "Parm" field is the id of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated true when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 ie (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": {
"Description":"Temperature is reached",
"FK_Event":"25",
"bIsAnd":"1",
"bIsNot":"0"
},

So it's an event handler for event #25, which is:

"PK_Event_25": {
"FK_EventCategory":"10",
"Description":"Temperature Changed"
},

bIsAnd means all the parameters are AND'd together and must all match. If bisAnd were 0, it would be an OR. bIsNot means the negative, ie trip the event if all the criteria is false. You also see:

"PK_CannedEvents_CriteriaParmList_102": {
"FK_CannedEvents":"101",
"FK_CriteriaParmList":"8",
"Description":"Which device?",
"Comments":"",
"Operator":"1",
"Parm":"",
"DefaultValue":"1",
"ExtraInfo":"",
"Required":"0"
},
"PK_CannedEvents_CriteriaParmList_103": {
"FK_CannedEvents":"101",
"FK_CriteriaParmList":"24",
"Description":"What temperature?",
"Comments":"",
"Operator":"1",
"Parm":"30",
"DefaultValue":"",
"ExtraInfo":"",
"Required":"0"
},

So, when prompting the user for his "Temperature changed" event, we will want to get 2 things from him: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. See template_data for the complete list of events.

You do not necessarily need to parse template_data in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, template_data explains all the events Vera's UI prompts for and what values are used.

== Sending Commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data Provider Catalog Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities, a job is created and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that tries to re-send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the Z-Wave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor its progress, you can do 3 things:

1) you can use the '''zwave_status''' request (see [[ZWave Status|Z-Wave Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID.

2) use '''job_status''' passing in the device ID only, such as '''http://127.0.0.1:3451/data_request?id=job_status&parameters=13''' (for the parameter, you can pass either the device id of the Z-Wave device itself, or any of its children). This will return all jobs that are currently active. Jobs that are completed are not on the list. (See [[Data Provider Catalog Plugin Requests]])

3) use the same request, but add [job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. ( See [[Data Provider Catalog Plugin Requests]])

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job is completed and 30 seconds has passed, you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dumped.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

UI Notes

2009-08-20T13:46:27Z

LibraSun: /* Misc test tips */

Here is some general information about getting information to display in a user interface:

== UPnP messaging system ==

Vera uses UPnP for all the messaging. So Vera translates Z-Wave, Insteon, infrared codes, etc., into UPnP actions. If you have already implemented a UPnP stack and can send properly formated UPnP SOAP/XML requests, you can do that. If you did not, Vera provides simple a HTTP GET interface as well, which is discussed below. Vera also translates between XML and json, so you can retrieve data in json format, which is very light, if it's easier.

== Finding Vera on the local network ==

You can find Vera by using the traditional UPnP discovery process, or you can retrieve this URL: http://findvera.com/locator.php

Each Vera, when it boots up, reports it's internal IP address to the central findvera.com server, which tracks this along with the external IP address. locator.php shows all serial numbers and internal network IP addresses on the same external IP. For example, if http://findvera.com/locator.php returns the following:

7300 192.168.1.114
6907 192.168.1.102
7618 192.168.1.117

Then there are 3 Vera's on the same internal network (ie sharing the same external IP as your browser), with serial numbers 7300, 6907 and 7618, with the 3 IP addresses shown.

You can also pass a findvera username to locator.php and it will return the serial number and IP associated with it, such as:

http://findvera.com/locator.php?username=demovera

== The HTTP interface ==

Vera listens on port 49451. Vera responds to UPnP actions the normal way, or by making simple http requests. For example, to turn on a light you can either send the UPnP action "SetTarget" to the device using the normal UPnP mechanism, or you can simply put this URL in your web browser, or with wget, or similar:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

That URL will return the same results of the action as using the normal UPnP architecture. The "output_format=xml" on the URL means the data returned should be in XML format. You can instead use: output_format=json

== Getting the system configuration ==

Either use the UPnP service/action: urn:micasaverde-com:serviceId:HomeAutomationGateway1/GetUserData or use the built-in request:

http://ipaddress:49451/data_request?id=user_data&output_format=json (or xml)

This returns the system configuration file for Vera. It's assumed you understand the way Vera categorizes devices with Rooms, Devices, Scenes, etc. When creating a user interface for controlling Vera only, like on a mobile phone, most of the tags can be ignored, since usually you just need the list of rooms and devices.

== Accessing Vera remotely through the findvera server ==

Everything you can do locally with Vera on port 49451, you can do remotely with findvera using the exact same syntax. You only need to ask the user for his username and password and pass them on the URL to the remote access server. For example, the above user_data is the syntax for local access. To retrieve the same URL over findvera use:

https://ra1.findvera.com/demovera/myvera123/49451/data_request?id=lu_status&output_format=json

assuming demovera is the username and myvera123 is the password.

== Building a control-only UI for Vera ==

If you just want to control Vera, and not modify the configuration, such as with a cell phone interface or web pad, the flow might possibly work like this:

1. For the initial setup, you need to ask the user if he wants to access Vera remotely, through the findvera service, and if so what are his username/password, or if he will access Vera on the home network. You can use locator.php to show him the Vera that's on his home network. You might want to do an auto-detect. For example, you could use locator.php to see if Vera exists locally, and if not, prompt the user for his username and password on findvera. You can use locator.php and pass the username to get the serial number and internal IP, and then automatically switch to direct access if locator.php without the username indicates that serial number is found on the local network. This would allow the user to automatically switch between local access with wi-fi (which is much faster of course) and remote access with findvera and the mobile phone network.

2. Once the connection is established, retrieve the user_data to get the list of rooms, scenes, devices, and remotes. You can cache this data locally so you don't need to retrieve it and parse it all the time. If you do, store the contents of the 'DataVersion' tag and pass it on the URL as &DataVersion=x. You will receive a page with the text NO_CHANGES if the user_data has not changed. You should still check periodically so that if the data changes you can refresh your copy. For rooms and scenes, you only need the room/scene id, which is the number after Room_Num_/scene_ in the tag, and the description. For devices, you need the device number, the description and the category.

3. Present the user with the rooms, scenes, devices and remotes. Generally we show first the rooms and then let the user pick a device, scene or remote in the room.

4. If the user picks a scene you can run the scene with the following URL, passing the scene number as X, and it will return an OK if it went ok:

http://127.0.0.1:49451/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=x

5. If the user picks a device, you use the category to determine what type of controls to present the user. See [[Luup_UPNP_Files]] for a list of the categories. When the user chooses an action, you can send it like this:

http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

For a list of common actions and device types see: [[Luup_CP_Mandatory_Types]]

Some actions return immediately with an 'OK'. Other jobs may take time to complete. For these you will get a job id back. There are several ways to present this to the user. One possibility is to do what Vera does in the UI, namely to use lu_status (explained next) to find all active jobs and to put a 'job' icon next to each device to indicate the progress of the job. In this way the user isn't tracking a particular job, per se, but just has visual feedback that a device is busy, and if the job icon(s) turn green, that everything went through ok. You could instead track the action individually using the job number that is returned.

6. Periodically poll the system with lu_status, like this:

http://ipaddress:49451/data_request?id=lu_status&output_format=json

That returns the current values of the UPnP variables, which you can use to show the user current status. For example, if the variable Status is 1 for a switch, you can show the 'on' button in a selected state, while 0 shows it in an off state. lu_status also shows any active jobs for a device.

== Building a replacement UI for Vera ==

Here are some notes on other tags that might be of interested, particularly if creating a full replacement for Vera's build-in web user interface.

The unassigned devices and automation devices in the user_data json request are just counters. You can probably ignore them. Automation devices is just the count of all the devices that are children of 'zwave' (ie the count of your light switches, thermostats, etc.). Unassigned devices is the count of devices that haven't yet been assigned a room (ie FK_Room=0). It's your responsibility, in the UI, to be sure that every device which does *NOT* have the tag "Hidden"=1 or the variable urn:micasaverde-com:serviceId:HaDevice1/IgnoreRoom set to 1. You don't have to, actually; the devices work fine if they're not in a room. It's just a convention in our user paradigm that all devices have to be put in rooms as a way of cataloging. And our web developer said that since javascript is slow, rather than him parsing the whole device tree in order to figure out if there are any devices he needs to ask the user what room it's in, he asked us to put a counter in the json (UnassignedDevices). If it's 0, he doesn't need to display the popup "Tell me what rooms these new devices are in". If it's >0, then he goes ahead and parses the device tree to figure out what devices are already assigned to a room and displays the popup for those that are not yet in a room.

He also wanted a 'automation devices' counter, again, so he doesn't need to parse the json tree unnecessarily. If the counter is 0, then the user has no zwave devices and he doesn't bother rendering the devices tab.

The counters and data in the user_data are the 'master database' of all the devices in the home and their parameters. The database is updated whenever the list of devices changes, or the user makes changes to the configuration.

The way our UI works is there's a background thread that polls user_data every 60 seconds or so. Each time it polls user_data, it passes in the DataVersion from the last user_data it got. This way if there no changes, rather than returning an identical json tree for you to parse all over again, you just get back an empty tree meaning "that DataVersion is still current". When the user_data changes, the ui needs to update all the devices/trees/etc. because that means stuff has changed.

Separately, there's another background poll of 'lu_status' (explained later) to get the realtime info on the devices. This is used to determine which action button to highlight (on/off/etc.), what color code to use for the config cog wheel, what job icons to display, and so on. The way we implemented it is that when the user does something in the UI, we start polling zwave_status every 2 seconds. This is because things are changing quickly (ie the job may be succeeding/failing/etc.). Then after 15 seconds, the polling is reduced to once every 15 seconds. Then after 1 minute, the polling is reduced to 1 minute intervals. This way, when the UI is idle, and the user turns off a light, you won't see the change immediately in the UI because it can be 1 minute before the next zwave_status poll. But, you're not generating constant network traffic to keep polling the devices over and over again when there's nothing going on.

If you use the binary socket layer, you don't need to poll since you can register to receive events when things change. But for web based ui's and engines like javascript, implementing raw socket transfers isn't as easy as simple http get's, so it just uses polling of the http gets.

== Saving configuration settings ==

This doesn't apply when creating a UI for control only, like a cell phone.

All the configuration data is stored in the user_data json file. The UI should allow the user to modify this data, set configuration parameters, and so on. Refer to the user_data request on [[Data_Provider_Catalog_Plugin_Requests]] for instructions on how to submit the user's changes to the json files. You can add your own tags to the JSON file to store your own information about devices. Vera will simply ignore json tags that it doesn't recognize.

== Current state of devices ==

The state variables in user_data are not necessarily up to date. They are just what was last saved in the database. To get the up to date values, along with a list of the active jobs for a device, use the UPnP action GetStatus, or call: http://ipaddress:49451/data_request?id=lu_status&output_format=xml

The job status will be one of the following:

job_None=-1, // no icon
job_WaitingToStart=0, // gray icon
job_InProgress=1, // blue icon
job_Error=2, // red icon
job_Aborted=3, // red icon
job_Done=4, // green icon
job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

== Configuration parameters for devices ==

--- this section is not current ---

Here are configuration settings the UI should prompt the user for and store in the "DeviceData" section.

'''Global'''

'''DEVICEDATA_Manage_Associations_CONST 300:''' Some Z-Wave devices report information about their state (ie fire events), such as motion sensors, remote controls which fire 'button pressed' events, and so on. Generally you tell the device where to send the events by assigning them 'associations'. For example, a motion sensor can be associated with a light switch and it will turn the light on/off automatically, or it can be associated with Vera so Vera gets 'sensor tripped' events. If this is the sort of device that Vera would normally want to set associations for, Vera adds this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Allow Vera to manage associations" and, if checked, store a 1, otherwise a 0.

'''DEVICEDATA_Scenes_As_Events_CONST 298:''' Normally ZWave handheld remote controls work with light switches only, and you can't receive events in Vera to allow them to execute Vera's scenes, which can do anything. If this is a handheld remote control that Vera can "trick" into sending scene commands to Vera, which Vera can in turn translate into events, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", display a check box that says something like "Treat Scenes as events" and, if checked, store a 1, otherwise a 0. See: [[ZWave_Add_Controller]] method #2

'''DEVICEDATA_Wakeup_Interval_CONST 299:''' If this is a battery operated device, that is not a FLiRS (see Zensys definition), it is normally 'sleeping' and cannot be communicated with except when it periodically wakes up and broadcasts a wakeup message. If Vera detects this type of device, Vera will add this configuration parameter to the device, with an empty value. If the UI sees this parameter in "DeviceData", prompt the user for the wakeup interval and store the value, as # of seconds, in this parameter.

'''DEVICEDATA_Manufacturer_Desc_CONST 294/DEVICEDATA_Model_Desc_CONST 295:''' This is a read-only setting with the name of the manufacturer/name of the model of the device, if known. Do not overwrite these values.

'''DEVICEDATA_Battery_Level_CONST 292:''' This is a read-only setting with the percentage of battery life left, from 0-100.

'''DEVICEDATA_Battery_Alarm_CONST 293:''' If DEVICEDATA_Battery_Level_CONST 292 is specified, you can display an input box asking the user for the minimum battery life before firing an event (0-99) and store it in this setting. When the battery level drops below this level an event will be fire, which can be attached to a scene to notify a user.

'''DEVICEDATA_Capabilities_CONST 207:''' This may be of interest to more advanced users. It has the device classes followed by a | and the supported command classes. An S at the end means its a 'secure' command class.

'''DEVICEDATA_PortChannel_Number_CONST 12:''' This is read-only, and it's the ZWave Node id.

'''DEVICEDATA_Multi_Channel_End_Point_CONST 296/DEVICEDATA_Multi_Channel_Capabilities_CONST 297/#define DEVICEDATA_Model_CONST 233/DEVICEDATA_Configuration_CONST 59/DEVICEDATA_Update_Name_CONST 41/DEVICEDATA_Only_One_Per_PC_CONST 162/DEVICEDATA_Energy_Log_CONST 286:''' Internal use only. Do not modify or present to the user.

'''DEVICEDATA_LastUpdate_CONST 234:''' This is the unix time stamp indicating when the device was successfully configured. Vera sets this when configuration is done. If this is not empty or 0, Vera will not attempt to configure the device. Whenever the user makes any change to a device, such as changing the settings in the UI, the UI must reset this to 0 when saving so Vera will re-configurate the device.

'''DEVICEDATA_Polling_Settings_CONST 283:''' This is the maximum frequency, in seconds, to poll the device. If set to empty, the default values will be used. 0 means the device will not be pulled. 60, for example, means poll the device at most once per 60 seconds.

'''DEVICEDATA_PK_FloorplanObjectType_CONST 11:''' Vera has no use for this value, but it is traditionally used to indicate which type of icon the user wants to see this device represented with on the floorplan. It is made available to any controllers.

'''DEVICEDATA_InputOrOutput_CONST 18/DEVICEDATA_Default_State_CONST 19/DEVICEDATA_EK_AlertType_CONST 45:''' These are for sensors indicating if they are input/output, normally open/close, and what type of alert they fire. You should not need to modify these because the default values pulled from template_data.json, which are set when the device is created, should be correct.

'''DEVICEDATA_Wattage_CONST 285:''' This is how many watts the device uses at full power. The user should be allowed to edit this so the estimated energy usage is accurate.

'''Device specific notes:'''

'''Light switches/lamp & appliance modules/Sensors:''' There are no special settings. Just follow the general settings above.

'''Thermostats:''' Note the syntax of Wattage here: [[Watts]] Otherwise no special settings.

'''IP Cameras:''' There are special json tags for the IP address and MAC address. Store the username/password for http authentication in: DEVICEDATA_AuthUser_CONST 114/DEVICEDATA_AuthPassword_CONST 115 and the URL to retrieve a JPEG image in DEVICEDATA_Path_CONST 2. Store information about archiving images and association with lights/motion sensors in DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184,DEVICEDATA_Video_settings_CONST 89.

DEVICEDATA_sPK_Device_Relations_For_Creat_CONST 184 = comma separated list of associated lights, dash, comma separated list of associated sensors.

DEVICEDATA_Video_settings_CONST 89 = comma separated values: # of seconds to archive, # of minutes/seconds to take automatic picture as a # followed by m or s, # of days to keep archives, [1|0] for 'turn on lights when viewing camera', [1|0] for 'turn on lights when the sensors are tripped and armed', [1|0] for 'turn on lights when the sensors are tripped and not armed', [1|0] for 'turn on lights for automatic picture'. So, the following is data is stored for the following configuration:

"FK_DeviceData_184": "13,14,17-20" 
"FK_DeviceData_89": "98,97m,96,1,1,0,0"

Archive a photo whenever the following sensors are tripped: 
(20) 
And after the sensor(s) are tripped archive the video for 98 seconds. 
Which lights should be turned on when viewing this camera: 
(13,14,17) 
For archival purposes, take a picture from the camera every 97 minutes, and keep the pictures 96 days. 
Turn on the lights: 
[x] When I view the camera from the web or phone. 
[x] When the sensor(s) above are tripped and they are armed 
[ ] When the sensors above are tripped and they are *not* armed 
[ ] When you take an automatic picture for the archive 

== Configuration parameters for the Z-Wave device ==

-- this section is not current --

The Z-Wave device, the parent of all Z-Wave nodes, has configuration parameters as well:

'''DEVICEDATA_COM_Port_on_PC_CONST 37:''' The com port/linux device for the Z-Wave dongle.

'''DEVICEDATA_Polling_Settings_CONST 283:''' The default poll settings, comma separated: [0|1] polling enabled, seconds to wait after startup before polling, seconds of idle time on the network before doing a poll, how many seconds to wait between polling nodes, seconds to wait between polling each node. 
So, "FK_DeviceData_283": "1,20,10,10,60" is displayed as: 
[x] Poll nodes 
Wait 20 seconds to start polling. 
Only poll a node if the Z-Wave network is idle at least 10 seconds. 
Poll a node every 10 seconds. 
Unless specified otherwise, poll each node at most once every 60 seconds. 

'''DEVICEDATA_Configuration_CONST 59:''' Firmware version of the dongle. Read only

'''DEVICEDATA_PortChannel_Number_CONST 12:''' House code and node id of the dongle. Read only.

'''DEVICEDATA_Capabilities_CONST 207:''' Read only status if the device is SUC/SIS and primary or not, such as: "Suc SIS:YES PRI:YES"

== Creating scenes in the user_data.json ==

--this section is not current--

A scene is just a list of commands to send to various devices. The Scenes section of user_data contains the pre-defined scenes. For example:
{
"scenes": {
"scene_10": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 20
}
}
}
}
}
}

This defines a scene called "leave home" which is in room. It sets a thermostat (device #21) to 'cool' mode (command #280) and to 20 degrees celsius (command #278). It also arms a motion detector (command #972). As explained below, ZWave motion detectors themselves don't have an arm/disarm command. It's just a flag which the security plugin keeps so that when a sensor is tripped, it knows if it's an "armed sensor tripped event" or a normal "sensor tripped event". So the command goes to device #5 (the security plugin), and the device id of the motion sensor (24) is a parameter to it. It also sets device #14 (a light) to 75% (command #184) and after 60 seconds turns it off (command #193). The list of device #'s is found in user_data Devices section. The command and parameters and how to use them are explained below.

To add this scene, you would submit the following JSON in the POST data for the user_data request. Note that if you do a POST with an existing scene ID, the entire scene is replaced. Changes are not merged. For example, if you want to add a timer to an existing scene, send the entire scene again, with command, and include the timer. We did this because it was difficult in the java script UI to keep track of all the changes and was easier to have the UI just re-send the whole scene each time. See: [[Data_Provider_Catalog_Plugin_Requests]]

{
"scenes": {
"scene_1000010": {
"Description": "leave home",
"FK_Room": "5",
"commands_ids": [
1,
2,
3,
4,
5
],
"commands": {
"command_1": {
"Device_To": 5,
"FK_Command": "972",
"params": {
"FK_CommandParameter_2": 24,
"FK_CommandParameter_5": "ARMED"
}
},
"command_2": {
"Device_To": 14,
"FK_Command": "184",
"params": {
"FK_CommandParameter_76": 75
}
},
"command_3": {
"Device_To": 14,
"FK_Command": "193",
"Delay": 60
},
"command_4": {
"Device_To": 21,
"FK_Command": "280",
"params": {
"FK_CommandParameter_8": "C"
}
},
"command_5": {
"Device_To": 21,
"FK_Command": "278",
"params": {
"FK_CommandParameter_5": 80
}
}
},
"json_action": "add"
}
}
}

Note the tag "json_action": "add" within the scene. This tells the data provider handler to add this scene. Also note that the scene id number is 1000010. The convention is that when adding new devices, scenes, rooms, sections or users you should use an id number > 1,000,000. When the data provider handler sees an id number >1m, it automatically changes it to be the next available id #. This is because all devices, scenes, rooms, sections and users need a unique id #. Since there could be multiple web ui's submitting user changes at once, you don't want the web ui to assign the id # as there may be a collision. If there were, the plugin would merge the data from the 2 post's. By using an id# > 1m, you are ensured there will be no conflicts as the id # will be changed when it's processed. Note that the same user_data you POST to with the new data, will also return the resulting user_data after the POST. So after POST'ing the data, you should parse and use the user_data that is returned, and discard any copy of the user_data you posted, as the id #'s may be different.

POST'ing the commands_ids is purely optional. The Vera back-end doesn't ever use any of the _ids parameters in the json file. They are there purely for the convenience of the web engine if it makes it easier to parse the json files.

== List of commands and parameters to send to devices ==

The complete list of all commands and parameters is in the template_data json file explained [[Data_Provider_Catalog_Plugin|here]]. There are over 1,000 commands in the full LinuxMCE command set. But the common ones used in Vera are:

'''#184 Set Level:''' Sets a device to a certain level. For dimmable lights this sets the level 
Parameters: #76 Level: a number between 0 and 100

'''#192 On/#193 Off:''' Turns a device on or off. This is also used for unlock/lock door locks 
Parameters: #76 Level: a number between 0 and 100

'''#278 Set Temperature:''' Sets a thermostat's set point to a given temperature 
Parameters: #5 Value_To_Assign: The temperature in degrees celsius. The number may be preceded with a - or a + to decrease/increase the temperature relative to its current setting, and may be followed by an H or C to set only heat or cool set point. If H or C is not specified, both heat/cool set points will be set for those thermostats that support dual set points

'''#279 Set Fan:''' Sets the fan of a thermostat to always on or to automatic 
Parameters: #8 On/Off: Set this value to 1 to put the thermostat is 'on' mode, and 0 to put it in auto mode.

'''#280 Set Heat/Cool:''' Sets the thermostat to heat/cool 
Parameters: #8 On/Off: Set this value to H for heat mode, C for cool. To turn the thermostat off, send command #193 (off), and to put it in full auto mode, send command #192 (on)

'''#370 Execute Command Group:''' In the user_data, find the device with the template "FK_DeviceTemplate": "27" (General_Info_Plugin) and send it this command to execute a scene. By including this command within a scene, you can have one scene execute or embed another scene. 
Parameters: #28 PK_CommandGroup: This is the id of the scene (ie the number following scene_). 
Parameters: #9 Text: If you want to test a scene that you have not yet created, instead of passing the command group parameter above, you put send the raw string of commands in this format: 
PK_Device,PK_DeviceGroup,PK_Command,Delay,CancelIfOther,IsTemporary,"PK_CommandParameter","Description" 
where each command is separated with a new line (\n). In Vera's UI, when you execute a scene from the dashboard (ie a scene that's already saved), it passes the scene # in parameter #28. When the user clicks 'test' next to a scene in the scene editor, and you want to test a scene that you have not yet saved, it is sent as parameter #9. You can grep DCERouter.log for '^08' (ie lines starting with 08 are commands) after clicking 'test' to see the syntax.

'''#684 Zoom In/#685 Zoom Out/#200 Move Up/#201 Move Down/#202 Move Left/#203 Move Right:''' Send these commands to a camera for pan/tilt/zoom. 
Parameters: None

'''#84 Get_Video_Frame:''' Send this command to a camera to retrieve the current image as a JPEG file:
Parameters: #19 Data: This is an output parameter that is returned, not an input parameter. It contains the actual image. The parameter type is 'Data', so it contains a block of binary data. 
Parameters: #20 Format: This is the format of the data. Presently all the cameras return 'JPEG'.

'''#776 Reset (when sent to a ZWave node):''' When sent to a ZWave node (ie a child of the device ZWave interface), it resets that node and causes it to be reconfigured. This is what's sent with Vera's "configure node right now" button. A configuration job is immediately added to the queue. 
Parameters: none

'''#776 Reset (when sent to the ZWave interface):''' When sent to the parent ZWave device, the interface which is often device #9, it resets the ZWave pairing in dongle. This is the only way to restore the black dongle to a clean state. If you do a hardware reset of Vera, without sending this command, the pairing's will remain because they're stored in the dongle itself. This command is sent from Vera's Devices, ZWave options, 'reset zwave network' button explained here: [[ZWave_Options]]. 
Parameters: #51 Arguments: This parameter can be: SUC or SIS (ie send either of those 3 character strings, or leave the parameter blank). The default is to send it with SIS. This is a ZWave term, meaning the dongle will report new nodes to slave controllers.

'''#967 Add Node:''' When sent to the parent ZWave device, the interface which is often device #9, it causes the to go into 'pairing' mode to add new devices. See [[ZWave_Options]] 
Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. Or it can be the word CANCEL to stop any current add/remove going on. 
Parameters: #48 Value: If empty or set to 1, any type of node can be added. You can also send on the of the Zensys define's to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed 
Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. 
Parameters: #259 Multiple: If true (ie 1) then multiple devices can be added and the dongle will stay in include mode until the timeout is reached. Otherwise, the dongle will only add 1 device and exist add mode.

'''#968 Remove Node:''' When sent to the parent ZWave device, the interface which is often device #9, it causes the to go into 'reset' mode to remove devices. See [[ZWave_Options]] 
Parameters: #39 Options: This parameter can be the single character H to use high power inclusion. 
Parameters: #48 Value: If empty or set to 1, any type of node can be removed. You can also send on the of the Zensys define's to restrict what type of node is added: 2=node controller, 3=node slave, 4=node existing, 5=node stop, 6=node stop failed 
Parameters: #182 Timeout: Number of seconds to timeout. If not specified default is 60 seconds. This is how long to wait for the new node. 
Parameters: #259 Multiple: If true (ie 1) then multiple devices can be added and the dongle will stay in remove mode until the timeout is reached. Otherwise, the dongle will only remove 1 device and exist remove mode.

'''#972 Set Sensor State:''' In the user_data, find the device with the template "FK_DeviceTemplate": "33" (Security_Plugin) and send it this command to change the arm/unarmed state of a sensor. Z-Wave doesn't have the concept of armed/unarmed sensors. But the security plugin keeps a flag for all sensors so when a sensor is tripped, it can fire the normal 'sensor tripped' only, or also a 'armed sensor is tripped' event. 
Parameters: #2 PK_Device: This is the device id of the sensors 
Parameters: #5 Value To Assign: Can be either: ARMED or UNARMED

'''#974 Set PIN:''' For door locks, this sets a user code or pin. 
Parameters: #17 PK_Users: This is user code to set 
Parameters: #99 Password: This is the pin code. Leave it blank to clear the pin code for the given user.

== Timer ==

If you want to have a scene executed automatically at a certain time, add a [[Timer]]. As explained above, you must re-send the whole scene with the timer. Add a JSON block like this to a scene to make it a timer:

"Timer": {
"PK_Timer_1": {
"Description": "T_on30m",
"Type": "1",
"Enabled": "1",
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "30m"
}
}
}
}

The Timer ID # (1 in this case) can be whatever you want, as well as the description. If Enabled is set to "0", the timer will not execute. Type can be: INTERVAL_EVENT=1 (ie does something every x minutes/seconds), DAY_OF_WEEK=2, DAY_OF_MONTH=3, ABSOLUTE_TIME=4. In all cases, the parameters for the type are specified in the Criteria section. The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

For interval timers, leave parm blank, use "PK_CriteriaParmList": 11 (per LinuxMCE this is: #define CRITERIAPARMLIST_Time_of_day_CONST 11), and set the value to a number followed by m or h (minutes/hours). The above is a timer that will go off every 30 minutes.

For Day of Week timers, set CRITERIAPARMLIST_Day_Of_Week_CONST 17 with a comma separated list of days of week (ie 1=Sunday), and CRITERIAPARMLIST_Time_of_day_CONST 11 is the time of day. Multiple times are comma separated. Times can be in 12 hour (with an optional am/pm) or 24 hour. All the following are acceptable ways of saying 3:15pm: 3:15pm 3:15 p.m., 3:15p, 15:15. Generally we use 24 hour time since it's simpler. Here is a day of week timer that goes off every day at 6pm and 8pm:

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 17,
"Operator": 1,
"Parm": "",
"Value": "1,2,3,4,5,6,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "6:00pm ,20:00"
}
}

For day of month timers, type 3, set CRITERIAPARMLIST_Day_Of_Month_CONST 18 to the days of the month, and CRITERIAPARMLIST_Time_of_day_CONST 11 to the time(s) of day. The following goes off on the 2nd and 7th of each month, at midnight, and 9:30:35pm

"Criteria": {
"param_1": {
"PK_CriteriaParmList": 18,
"Operator": 1,
"Parm": "",
"Value": "2,7"
},
"param_2": {
"PK_CriteriaParmList": 11,
"Operator": 1,
"Parm": "",
"Value": "0:00,21:30:35"
}
}

For absolute timers, set "PK_CriteriaParmList": 19 (CRITERIAPARMLIST_Specific_Date_CONST 19) and set the Value to the actual date/time. The following timer will go off on Feb 15, 2009 at 14:30:30

"PK_Timer_2": {
"Description": "New timer",
"Type": "4",
"Enabled": "1",
"commands_ids": [

],
"commands": {

},
"Criteria": {
"param_1": {
"PK_CriteriaParmList": 19,
"Operator": 1,
"Parm": "",
"Value": "2009-2-15 14:30:30"
}
}
}
},

== Event ==

To make a scene happen automatically, add an [[Event]]. Note that any device in the system can fire any event. The event id numbers and the parameters for each are defined in template_data. Therefore, when you add an event, this is a free-form template that can be used for any type of event. PK_CriteriaParmList is one of the following:

1=CRITERIAPARMLIST_System_CONST 
2=CRITERIAPARMLIST_PK_Installation_CONST 
3=CRITERIAPARMLIST_PK_Skin_CONST 
5=CRITERIAPARMLIST_Month_CONST 
8=CRITERIAPARMLIST_PK_Device_CONST 
10=CRITERIAPARMLIST_PK_DeviceTemplate_CONST 
11=CRITERIAPARMLIST_Time_of_day_CONST 
12=CRITERIAPARMLIST_PK_DeviceCategory_CONST 
13=CRITERIAPARMLIST_PK_Room_CONST 
14=CRITERIAPARMLIST_PK_DeviceGroup_CONST 
15=CRITERIAPARMLIST_House_Mode_CONST 
16=CRITERIAPARMLIST_Room_Mode_CONST 
17=CRITERIAPARMLIST_Day_Of_Week_CONST 
18=CRITERIAPARMLIST_Day_Of_Month_CONST 
19=CRITERIAPARMLIST_Specific_Date_CONST 
20=CRITERIAPARMLIST_PK_RoomType_CONST 
22=CRITERIAPARMLIST_PK_EventList_CONST 
23=CRITERIAPARMLIST_PK_EventHandler_CONST 
24=CRITERIAPARMLIST_PK_EventParameter_CONST 
25=CRITERIAPARMLIST_User_Mode_CONST 
26=CRITERIAPARMLIST_State_CONST 

The operator is OPERATOR_EQUALS=1, OPERATOR_NOTEQUALS=2, OPERATOR_GREATERTHAN=3, OPERATOR_LESSTHAN=4, OPERATOR_CONTAINS=5.

Only CRITERIAPARMLIST_PK_EventParameter_CONST uses the "Parm" field the criteria, and in this case, the "Parm" field is the id of the EventParameter and Value is the value of the event parameter.

The following event will be evaluated true when the device #21 (see 8=CRITERIAPARMLIST_PK_Device_CONST, operator 1 is 1) fires the event #25 (EVENT_Temperature_Changed_CONST 25) and the parameter #30 for the event EVENTPARAMETER_Value_CONST 30 is >32 ie (24=CRITERIAPARMLIST_PK_EventParameter_CONST parameter #30 operator 3=> and value is 32). In other words, when the thermostat says the temperature is > 32 degrees celsius the event will fire and the scene the event is attached to will be executed.

"PK_Event_2": {
"Description": "temp reached",
"FK_CannedEvents": "101",
"PK_Event": "25",
"Enabled": "1",
"Criteria": {
"param_42": {
"Operator": "1",
"Value": "21",
"Parm": "",
"PK_CriteriaParmList": "8"
},
"param_43": {
"Operator": "3",
"Value": "32",
"PK_ParameterType": 2,
"Parm": "30",
"PK_CriteriaParmList": "24"
}
}
}

Rather than presenting the user a free-form form to fill out to specify his event, Vera uses "Canned Events", which are defined in template_data. These are basically event templates that define some common events and what parameters to prompt the user for. In the example above, note the canned event is 101. In template data:

"PK_CannedEvents_101": {
"Description":"Temperature is reached",
"FK_Event":"25",
"bIsAnd":"1",
"bIsNot":"0"
},

So it's an event handler for event #25, which is:

"PK_Event_25": {
"FK_EventCategory":"10",
"Description":"Temperature Changed"
},

bIsAnd means all the parameters are AND'd together and must all match. If bisAnd were 0, it would be an OR. bIsNot means the negative, ie trip the event if all the criteria is false. You also see:

"PK_CannedEvents_CriteriaParmList_102": {
"FK_CannedEvents":"101",
"FK_CriteriaParmList":"8",
"Description":"Which device?",
"Comments":"",
"Operator":"1",
"Parm":"",
"DefaultValue":"1",
"ExtraInfo":"",
"Required":"0"
},
"PK_CannedEvents_CriteriaParmList_103": {
"FK_CannedEvents":"101",
"FK_CriteriaParmList":"24",
"Description":"What temperature?",
"Comments":"",
"Operator":"1",
"Parm":"30",
"DefaultValue":"",
"ExtraInfo":"",
"Required":"0"
},

So, when prompting the user for his "Temperature changed" event, we will want to get 2 things from him: the device, and the temperature. Notice that in Vera's UI, the user is prompted for both, and they become part of the event that is attached to the scene. See template_data for the complete list of events.

You do not necessarily need to parse template_data in your own UI implementation. The cleanest UI has a custom "hardcoded" panel for the user to fill out. But, template_data explains all the events Vera's UI prompts for and what values are used.

== Sending commands ==

The UI should always send commands with a return response (type r or o), as explained in [[Data_Provider_Catalog_Plugin]]. The response will be "OK x" where x is the optional job #. For most Z-Wave activities a job is created, and the ID is returned. Some types of commands don't have job numbers, like controlling a camera. However, you must always check for an OK. It is normal that when you send a command it might not get through because the router is reloading the data, or the Z-Wave device is reset. After you submit new data with a user_data post, the router will reload, which takes a couple seconds, and then the Z-Wave device will also reload and re-configure any devices. So when sending a command, you should do this in a loop that it retries to send the command every 5 seconds, for up to 30 seconds, until it gets an OK. During this time the UI should display some hourglass or something so the user knows his command hasn't been received or acknowledged yet. If the router and the zwave module are already running, which is normally the case if you haven't just saved, you should get back the OK in less than 1 second. In the case of Z-Wave, the OK just means the command has been queued. It does not mean it's actually been sent on the Z-Wave network. Under normal circumstance the command will be sent right away. But, sometimes, the Z-Wave network may be busy. Or if the device is flaky, or if needs a lot of hops, or if it's a secure device which causes key exchange, the command can take a while to be processed. And, the command may fail. The initial OK just tells you the job was queued, not that it was successful.

To find out if the job was successful and monitor the progress, you can do 3 things: 
1) you can use the zwave_status request (see [[ZWave_Status]]). This shows you all the jobs that are currently active or were completed within the last 30 seconds. It is broken down by device, and will contain the job ID. 
2) use job_status passing in the device id only, such as http://127.0.0.1:3451/data_request?id=job_status&parameters=13 (you can either pass in for the parameter the device id of the zwave device itself, or any of it's children). This will return all jobs that are currently active. Jobs that are completed are not on the list. See [[Data_Provider_Catalog_Plugin_Requests]] 
3) use the same request, but add ,[job #]. This will return just the information on the requested job, and you can get information on the job up to 3 minutes after the job has ended. See [[Data_Provider_Catalog_Plugin_Requests]]

The reason for the 30 second timeout in option #1 is to make the UI presentation easier. The assumption is that if you're going to show all devices and icons representing the active jobs, after a job has done and 30 seconds has past you probably don't want it on the list. But, if you're requesting specific information on a particular job, as in #3, you want the job info to be available as long as possible, and 3 minutes is how long a job is kept in the memory after completion before it's dupmed.

== Miscellaneous Test Tips ==

If you want to create some sample devices, run:

'''/usr/bin/MessageSend localhost 0 9 1 776 51 MANYNODES 88 xxx'''

where '''xxx''' is the number of sets of test devices. This will create a set of dummy devices that don't actually exist, but that you can see how they work in the UI. Such as a thermostat, light switch, etc. So if you run it with xxx=1, it will create 1 set. If you want to see how the UI looks with lots of creates, run it with 15. Run it with 0 to return to normal.

Supported Hardware

2009-08-17T18:32:53Z

LibraSun: /* Lighting Devices */

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

=== '''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
|
|
|
| Indoor
|
|
|
| Read the instructions here: [[Schlage 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
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|
|}

=== '''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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-17T17:11:33Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
 

|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

=== '''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
|
|
|
| Indoor
|
|
|
| Read the instructions here: [[Schlage 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
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|
|}

=== '''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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-17T17:11:11Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
 

|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

=== '''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
|
|
|
| Indoor
|
|
|
| Read the instructions here: [[Schlage 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
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-17T17:10:36Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
 

|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

=== '''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
|
|
|
| Indoor
|
|
|
| Read the instructions here: [[Schlage Lock]]
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Electronic Solutions
| Drape/Blind motor
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-17T17:09:45Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
 

|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! 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
|-
| 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
|
|
| Indoor
|
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Schlage
| Door lock and deadbolt
|
|
|
| Indoor
|
|
| Read the instructions here: [[Schlage Lock]]
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Electronic Solutions
| Drape/Blind motor
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-17T17:08:00Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
 

|-
| 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
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
|-
| 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
|
|
| Indoor
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Schlage
| Door lock and deadbolt
|
|
|
| Indoor
|
|
| Read the instructions here: [[Schlage Lock]]
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Electronic Solutions
| Drape/Blind motor
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Supported Hardware

2009-08-17T16:54:04Z

LibraSun:

Note: There is a separate page for Z-Wave Handheld remote controls, Z-Wave gateways, and Z-Wave Scene Controllers: [[ZWave Add Controller|click here]].  There is also a separate page for IP cameras: [[IP Cameras|click here]]

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.

== 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"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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.amazon.com/Intermatic-Settings-Three-Way-Dimmer-HA20C/dp/B000WS4SJ41 Link]
|
| Affordable 3-way 600W dimmer
|-
| 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.
|-
| 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-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.
|-
| Intermatic
| Screw-in Module
| HA05C
|
| Nov 2008
| 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!
|-
| 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
| 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
 

|-
| Schlage
| Lamp Module
| RP200
| 1.0
| Aug 2009
| Indoor
| [http://consumer.schlage.com/products/Productdetail3.asp?StyleID=139&FinishID=12&FunctionID=77 Link]
|
| LibraSun
| Works well Sold with Schlage LiNK lock system
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| 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
|-
| 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
|-
| ACT
| In-Wall Receptacle
| ZRR150W
| 2.2
| Nov 2008
| Indoor
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
| [http://store.homeseer.com/store/ZRR150W---Z-Wave-Split-Duplex-Receptacle-ACT-HomePro-P528C123.aspx Link]
|
| Works like a champ! Easy to Install
|-
| 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.
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
|-
| 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
|
|
| Indoor
|
|
| See: [[Danfoss Thermostat]] for installation instructions
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Added by User
! Notes
|-
| ACT
| Motion Sensor
| PIR000 / PIR010
|
|
| Indoor
|
|
|
| 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 a few minutes 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
|-
| Express Controls aka HomeSeer
| 3-in-1 sensor (light/temperature/motion)
|
|
|
|
|
|
|
| See [[ExpressControls3in1]]
|-
| EverSpring/Hawking/Home Manageables
| Door/window sensor
| SM103
| 6,2,9,1,0
| 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.
|-
| Everspring
| Motion Detector
| SP103
| 6,2,9,1,0
| 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-01
|  ??????
| 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!
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Schlage
| Door lock and deadbolt
|
|
|
| Indoor
|
|
| Read the instructions here: [[Schlage Lock]]
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! Notes
|-
| Electronic Solutions
| Drape/Blind motor
| DBMZ
|
|
| Indoor
|
| [http://www.smarthus.info/support/manuals/zw_motorkontroll/DBMZ.pdf Link]
|
|}

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

{| cellpadding="2" border="1"
|-
! Manufacturer
! Device Type
! Model no.
! Version
! Date Purchased
! Location (indoor/outdoor)
! Specs
! Product Review
! 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
! 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
| 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. Workaround: Use a Luup Scene with the following code:<TT>local lul_arguments = {}
lul_arguments["newTargetValue"]="0"
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
| Jun 2009
| Indoor
| [http://www.duewi.de/index.php?productid=37344 Link]
|  
| Lutz
| Open/Close buttons work well, but slide bar does not work.
|}

Luup Upgrade

2009-08-17T16:18:16Z

LibraSun:

When you upgrade Vera to the new version, called Luup, from any of the previous versions, there are several important changes you need be aware of.

1. You won't see the usual warning message that you need to refresh your browser after the upgrade. Instead you may see errors. The solution is just to refresh the page in your browser (i.e. not using the browser cache). In IE, Firefox and Chrome this is done by pressing Ctrl+F5. In Firefox or Safari you can also choose View, Reload Page from the menu.

2. Go to Vera's 'Users' tab and wherever you specified a phone number to receive SMS text messages you will now need to choose the mobile phone carrier. For U.S. and Canadian customers, the phone number must be 10 digits only, without a 1 in front. If your carrier is not listed choose 'Other'. You will not receive SMS text messages until you update this.

3. The process to control Vera from your mobile phone has now changed. If you will use your mobile phone's browser to access Vera you must first go to Devices, Luup Plugins, and install either the basic text-only WAP version, and/or the graphical smartphone version. You can also install the native versions. Either way, visit [http://findvera.com/mobile findvera.com/mobile] from your mobile phone, and follow the [https://findvera.com/instructions.php instructions].

4. You can now track notifications to be sure you get them as you should. On Vera's 'Setup' page, choose Advanced, Logs to see a list of all recent activity, both reportable events like a door being opened, and notifications where Vera contacted you by email or SMS text. Once the event or notification is reported to the FindVera server, you can track its progress. Only the 20 most recent events and notifications are stored locally in Vera, but a full database of all events and notifications is viewable by logging in to [http://findvera.com findvera.com].

Advanced Commands

2009-08-17T13:51:24Z

LibraSun:

Here are some notes about commands for advanced users and developers:

'''Telnet & SSH'''

Telnet is enabled by default on Vera. With the network autoconfiguration left on, if Vera gets an internal IP address on the WAN port (i.e. any 192.168.x.x, or 172... or 10... address), Vera is put into 'switch' mode; all 5 ports are bridged together like a switch. In this mode you can telnet into Vera using the IP Vera gets from the WAN port. If you don't know it, go to [http://findvera.com findvera.com] and click 'Setup my Vera in my home' to be redirected. If Vera gets an external IP address on the WAN port, or no IP at all, Vera goes into Gateway mode. The firewall is enabled and the DHCP server is turned on. You cannot telnet into Vera using the IP on the WAN port; you must connect your PC to the LAN 1 through LAN 4 ports and telnet to 192.168.81.1 (the default IP for Vera). Note that even in switch mode Vera will still listen to IP 192.168.81.1, so you can always set your PC to a static IP in that range. Telnet uses the default port 23.

Once you set a root password, telnet is disabled and you must use ssh instead. Set the root password either with the Linux passwd command, or by going into the OpenWRT configuration found on Vera's Advanced, Net & Wi-Fi, Advanced Configuration link.

'''Performance bottlenecks with network throughput'''

When in gateway mode (see above 'Telnet & SSH') all network traffic runs through Vera's CPU, and the CPU maxes out at around 30 Mbps and you'll find Vera is slow to respond. If you will be needing high volume network traffic it's best to use Vera in switch mode, so the network traffic goes through at full speed without using Vera's CPU. This is not a limitation of our software, it is the nature of residential/consumer access point hardware and most access points have roughly the same performance and speed of CPU.

'''Manually upgrading the firmware'''

If you lose access through the web page you can enable SSH on Vera by setting a root password (see above 'Telnet & SSH'). Then use scp to copy the firmware image to Vera's /tmp directory. Then you can either manually write the firmware using this command:

mtd -r write [filename] linux

However you will lose all your settings. To preserve your settings name the image: firmware.img and run: /usr/bin/cmh-upgrade.sh which will create a backup of your configuration online, restore the firmware, and then restore the backup on the first boot.

Leviton Scene Controller

2009-08-17T02:07:22Z

LibraSun:

These instructions work for the Leviton RZCS4. They also work for the RZCZ4 which is a zone controller, not a scene controller. However the zone controller is more limited in its functionality and you must use 'Method #2' described below.

== Adding the RZCS4 to your Z-Wave network ==

1. Be sure the scene controller is not already paired with another network. The best way to do this is to hold down the scene 1 and scene 3 buttons simultaneously for 10 seconds. Hold down the left side of the buttons, near the LED lights. When you first press them, one of the buttons may blink red momentarily. After you've held them down for about 4 seconds, all 4 lights will turn amber, and if you keep them held down, after another 4 seconds all 4 lights will turn red. This means the scene controller is reset, and can now be included with Vera.

2. Take Vera's dongle to the scene controller and be sure Vera's dongle is off. If the light on the dongle is blinking, tap the button on the dongle so it is off. The dongle must be off when you put the scene controller into program mode. Now, press and hold scene buttons 1 and 3 on the left side, near the LED lights, for 4 seconds. All 4 lights will turn amber. Let go. The 4 lights will blink amber every 1 second or so to indicate the scene controller is in program mode.

3. Only after you completed step 2 and the scene controller is in program mode, tap the button on Vera's dongle to put the dongle in include mode. After about 5 seconds, the dongle's light should stay solid for a second and the scene controller's 4 amber lights will interrupt their normal blinking pattern. This means the scene controller was successfully included. You can put Vera's dongle back in Vera, or take it to include another device you wish to include. If including another Leviton scene controller, be sure to tap the button on the dongle to turn it off again before repeating step 1.

4. When you re-insert the dongle in Vera, after a few seconds you should see the scene controller show up as an unassigned device on the devices tab in Vera's setup site. If you don't reload Vera's web page and go back to the devices tab. Pick the room the scene controller is in, and give the scene controller a name if you want.

If you do not want Vera to assign scenes to the scene controller, but will do that using another device, you can stop here. If you want Vera to assign scenes, keep going with step 5.

''Now you have to make a decision if you want to use Method #1 or Method #2 as described in [[ZWave Add Controller|Z-Wave Add Controller]].'' The bottom line is that with Method #1, which is the traditional way of creating scenes, the Leviton's up/down buttons work, and you can turn a scene on as well as off. However, this only works with some light switches and lamp modules which support 'scenes', and you can only set lighting levels. You can't control a thermostat, lock a door, turn on a TV, etc. with Method #1. To see if a device is scene capable and can work with a Leviton scene controller in Method #1, click the '+' button next to the device, look at the "Capabilities" line and look for the number 44 after the | sign. If it's there, the device is scene capable. Method #2 is more flexible. With Method #2 the Leviton scene controller's buttons are tied to scenes in Vera, which can do anything with any device because Vera is actually running the scene. However with Method #2 the up/down buttons on the scene controller don't work, nor does the 'Toggle a scene on/off' feature. With Method #2 if you have 3 lighting mood scenes and an 'off' scene, you'll assign the 'off' scene to one of the 4 buttons, but you won't be able to use the remote's toggle feature to turn any of the 3 scenes off.

=== Method #1 ===

5. Create a scene that adjusts the light to the level you want. Save your changes.

6. Click the '+' button next to the scene controller and choose 'Custom Z-Wave settings', and 'Add scene assignment'. Choose the key to assign the scene to (1-4) and the scene to assign to the key. Save your changes.

7. The scene should work fine. If you want to change the scene, go to the 'Scenes' tab and modify the scene as you want, save your changes, and then go to 'Devices', click '+' next to the scene controller, and choose 'Configure right now'. That will reconfigure the scene controller.

=== Method #2 ===

5. After you assigned the scene controller to a room, click the + button next to the scene controller on the 'Devices' tab on Vera's 'Setup' site. Check the box "Treat scene buttons as events". After you save your changes, Vera will start to reconfigure the scene controller and if successful, you will see a [[Device Control Status|green cog]] next to the scene controller indicating it was successfully configured. There must be a green cog next to the scene controller for it to work.

6. On the 'Scenes' tab on Vera's 'Setup' site, create the scenes you want assigned to the scene controller. Click the red 'Save' button to save your scenes. If you haven't yet added all the lights and other Z-Wave devices you want in the scene you'll have to do that first, of course, and come back to this step later. Click the 'Add Event' button for your scene. Choose the event 'Scene button is pressed'. Then choose the scene controller from the pull-down. Then enter the scene button you want to trigger the scene; enter a number between 1 and 4 to designate one of the controller's four scene buttons.

After you save your changes, pressing the left side of the scene button, next to the LED, will trigger the scene. Note that the scene can include delays. For example, if you have a 'go to bed' scene, you may want the scene to lock the doors, turn down the thermostat, and turn off all the lights. But, you might not want the bedroom lights to go off immediately if the scene controller is on the opposite side of the room from the bed. So, in the scene, for the bedroom lights, choose the command "On" then choose "After 30 seconds", then "Set a new setting", then "Off". This way, when you choose the scene, the bedroom lights will come on for 30 seconds so you have time to walk across the room, and then turn off.

The 4 scene buttons on the scene controller can be pushed to the left or to the right. The left is the normal way to trigger a scene. If you press any of the scene buttons to the right, it is treated as 'button 0'. You can create a scene as described above, and in step 6 choose button #0. But this means that no matter which of the 4 scene buttons you press to the right, they all trigger the scene for button #0. (See [[ZWave Add Controller|Z-Wave Add Controller]] Method #2 for an explanation.) Also, the scene controller only triggers button #0 when you press the button to the right if you already pressed the button to the left. If this is confusing, just stick to the normal usage of buttons 1-4 by clicking the button to the left. The scene up and down functions do not do anything.

As explained in [[ZWave Add Controller|Z-Wave Add Controller]] you can leave "Treat scene buttons as events" unchecked, and then create scenes the traditional Z-Wave way (i.e. Method #1). In this case the scene up and down buttons do work as expected and so does the off. However, the scenes are much more limited. You cannot have delays, or adjust thermostats, or lock doors and so on. Also, when you want to program the scene into the scene controller, you can only do this by re-adding the scene controller to Vera while the dongle is inserted. You cannot carry the dongle to the scene controller; you must put the scene controller in program mode, as explained in Step 2 above, and then choose 'Add Z-Wave Controller' from the Devices tab on Vera's 'Setup' menu. Therefore it is a bit cumbersome to do this unless you have a separate handheld controller to help program the scenes. If you do want Vera to do it for you this way, create your scenes, add the scene controller, leave "Treat scene buttons as events" unchecked, choose 'Custom Z-Wave Settings', and choose the 'Add scene assignments' to assign the scenes to buttons. Then put the scene controller in program mode, and choose 'Add Z-Wave controller' from Vera's setup page.

== Removing the RZCS4 from your Z-Wave network ==

If you already paired the RZCS4 and want to remove it:

1. Take Vera's dongle to the scene controller and be sure Vera's dongle is off. If the light on the dongle is blinking, tap the button on the dongle so it is off. The dongle must be off when you put the scene controller into program mode. Now, press and hold scene buttons 1 and 3 on the left side, near the LED lights, for 4 seconds. All four lights will turn amber. Let go. The lights will blink amber once every second or so to indicate the scene controller is in program mode.

2. Only after you completed Step 1 and the scene controller is in program mode, press and hold the button on Vera's dongle continuously for 5 seconds until the dongle's blue light blinks quickly, then let go. After about 5 seconds, the dongle's light should stay solid for a second and the scene controller's four amber lights will interrupt their normal blinking pattern. This means the scene controller has been removed. You can put Vera's dongle back in Vera, or take it to include another device.

Test Sequence

2009-08-16T16:17:25Z

LibraSun:

A test system is available to the public to prod around with Vera. The test system consists of Vera, a thermostat, a motion detector, a dimmable light connected to a lamp, an on/off switch connected to a fan which blows foil in front of the motion detector to trip it, and a wireless Panasonic IP camera. It can be accessed directly (like you would on the home LAN) at testvera.micasaverde.com, or on findvera.com with the username: testvera, password: myvera123. Following is our standard test sequence to confirm that all major functions are working:

Prep: In order to see all the verbose logs for several errors, edit /etc/cmh/cmh.conf and put a # in front of LogLevels and change number of copies to 100

1. Start with a new Vera unit and connect the WAN port to the network

2. Go to the 'Setup' page, and on FindVera.com, enter: user: '''testvera''' password: '''myvera123''' and activate

3. On the 'Rooms' tab, enter a Bedroom and a Living Room

4. On the 'Devices' tab, the dimmable is "Lamp" in Living Room, the switch is "Fan" in Bedroom. Thermostat and motion are in Living Room.

5. Power on camera, wait for light to come on green. Confirm it shows up as a new device.

6. Confirm 'View Camera' works, lights can be controlled, thermostat set, etc.

7. Fill in all the options for the camera: Motion Detector, 30 seconds, Lamp, 30 minutes, 20 days, check all 4 boxes

8. On the 'Scenes' tab, create scenes: "On for 30 seconds" turns lamp on for 30 seconds and off. "Arm Home" turns lamp off and arms motion detector. "Disarm Home" bypasses motion detector.

9. Choose Location

10. Add user: '''vera''' password: '''vera''', then set the SMS text and email addresses

11. Add timer: 30 minutes on interval 30 minutes, turn fan on and off after 5 minutes, and turns light to 75% for 15 minutes and turns it off. Add another timer that at 45 minute intervals turns the lamp on to 25% and then to 60% after 30 minutes.

12. Add timer: evening, on all days of week at "6:00pm, 20:00" turns lamp on for 10 seconds and off

13. Add event: breach, type: armed sensor, users: vera, motion detector. lamp on for 10 seconds then off

14. Add event: sunset, lamp off

15. On energy, check every option, choose every day of the week, 1 lights, a thermostat, more than 100 watts, notify the user vera, and sign up for Flex alerts.

16. Click 'Save'. Press F5 and confirm all settings stuck. Manually arm the sensor by clicking 'Arm' on the devices page. Turn on fan, which should trip the motion sensor. 30 seconds later or so the sensor should have the red "trip" icon, and you should get a notification via SMS and email about the 'breach' event.

NOTE: Manually trip a motion sensor like this: http://ip:49451/data_request?id=lu_variableset&DeviceNum=xxxx&serviceId=urn:micasaverde-com:serviceId:SecuritySensor1&Variable=Tripped&Value=0

NOTE: Manually simulate a 'door lock pin failed' event like this: http://ip:49451/data_request?id=lu_variableset&DeviceNum=xxxx&serviceId=urn:micasaverde-com:serviceId:DoorLock1&Variable=sl_PinFailed&Value=1

NOTE: Manually simulate a 'user enters a code' event like this: http://ip:49451/data_request?id=lu_variableset&DeviceNum=xxxx&serviceId=urn:micasaverde-com:serviceId:DoorLock1&Variable=sl_UserCode&Value=yyy where yyy is in the format of: UserID="a" UserName="b" so that '''a''' is the id of the user code (1-19) and '''b''' is the name assigned to the user code.

17. Browser check: Open the site in IE 6, IE 7, IE 8, Firefox 2, Firefox 3, Chrome, and Safari. Confirm the site loads, you can click buttons on the dashboard, expand the devices page, and create/save a scene

18. Login to [http://findvera.com findvera.com] with '''testvera'''/'''myvera123'''. Click events and confirm you can see the breach event and the notification attempts. Click Camera, Panasonic camera, and confirm you have video archive, including every time you tripped the sensor. The date/time should be correct, and the light should be on for 10 seconds.

19. Go to the 'Energy' tab and confirm you see the live usage

20. Go to 'Control' and confirm you see the Dashboard

21. Go to 'Settings' and put in your email and SMS number. Unplug the access point. Within 1 hour you should get a notification.

22. Let the access point wait for 5 hours. Confirm you can view the 'Energy' history.

23. On the devices tab confirm the thermostat is reporting the temperature.

24. Open a generic WAP browser on a mobile phone and go to [http://testvera.micasaverde.com:3451/iphone testvera.micasaverde.com:3451/iphone]. Confirm you can view the camera, control the lights, and execute secenes.

25. Open the browser and go to [http://findvera.com/mo findvera.com/mo]. Enter '''testvera''' and '''myvera123''', and again confirm you can view the camera, control the lights, and execute scenes.

26. Open the Blackberry's browser, go to [http://testvera.micasaverde.com/mo testvera.micasaverde.com/mo] and install the Java app. Confirm you have the same control, and also that the status updates if you change devices using the web page

27. Go to: [https://ra1.findvera.com/testvera/myvera123/3451/data_request?id=camera_control/16&parameters=get_video_frame https://ra1.findvera.com/testvera/myvera123/3451/data_request?id=camera_control/16&parameters=get_video_frame] and confirm you can view the camera

28. Choose 'Poll all nodes' from the Dashboard and confirm you get 'poll jobs' for all the devices.

29. Choose 'Permanently remove dead node' for one of the existing devices, and confirm it goes away.

30. Confirm the following: Every 30 minutes you should get a notification of the breach, because of the 30 minute timer. The timers and events should work properly, and after a while, you should see the energy usage history graphs showing how the energy usage is fluctuating in response to the 30 and 45 minute timers.

If this is the public Vera box, make these changes to prevent someone from breaking the network settings:

in '''/www/cmh/js/scripts.js''', make this change: document.getElementById("remote_access_box").innerHTML="Changes to this page are disabled because this Vera is exposed to the public"; document.getElementById('zwave_options_box').innerHTML="Changes to this page are disabled because this Vera is exposed to the public"; 

and in '''/www/cmh/index.html''': <a href="/cgi-bin/webif/info.awx" target="_blank">Advanced configuration</a> should be Changes this to page and access to OpenWRT control panel are disabled because this Vera is exposed to the public delete this: <td id="restore_factory_defaults_box"><input type="button" class="normal_button" onClick="restore_factory_defaults();" value="Restore factory defaults"></td> and this: <td id="restore_backup_form"></td> 

and delete these 2 lines from '''/www/cmh/access_point.html''': <input type="submit" value="Save and Apply" class="normal_button"> <input type="button" value="Revert changes" class="normal_button" onClick="getElementById('ap_form').reset(); show_connection_details(); show_encryption_details();"> 

and delete this from '''/www/cgi-bin/cmh/upgrade_step1.sh''': <td><input type="button" name="upload" value="Download" class="normal_button" onclick="document.location='upgrade_step2.sh?firmware='+document.getElementById('firmware').value"></td> 

When the box is setup, do this: mkdir /etc/cmh.bak cp /etc/cmh/devices.json.lzo /etc/cmh/user_data.json.lzo /etc/cmh.bak/ echo "*/* 1 * * * cp /etc/cmh.bak/* /etc/cmh/" >> /etc/crontabs/root 

passwd: 95ireland

Luup Upgrade

2009-08-16T16:00:58Z

LibraSun:

When you upgrade Vera to the new version, called Luup, from any of the previous versions, there are several important changes you need be aware of.

1. You won't see the usual warning message that you need to refresh your browser after the upgrade. Instead you may see errors. The solution is just to refresh the page in your browser (i.e. not using the browser cache). In IE, Firefox and Chrome this is done by pressing Ctrl+F5. In Firefox or Safari you can also choose View, Reload Page from the menu.

2. Go to Vera's 'Users' tab and wherever you specified a phone number to receive SMS text messages you will now need to choose the mobile phone carrier. For U.S. and Canadian customers, the phone number must be 10 digits only, without a 1 in front. If your carrier is not listed choose 'Other'. You will not receive SMS text messages until you update this.

3. The process to control Vera from your mobile phone has now changed. If you will use your mobile phone's browser to access Vera you must first go to Devices, Luup Plugins, and install either the basic text-only WAP version, and/or the graphical smartphone version. You can also install the native versions. Either way, visit [http://findvera.com/mobile findvera.com/mobile] from your mobile phone, and follow the [https://findvera.com/instructions.php instructions].

4. You can now track notifications to be sure you get them as you should. OIn Vera's 'Setup' page, choose Advanced, Logs to see a list of all recent activity, both reportable events like a door being opened, and notifications where Vera contacted you by email or SMS text. Once the event or notification is reported to the FindVera server, you can track its progress. Only the 20 most recent events and notifications are stored locally in Vera, but a full database of all events and notifications is viewable by logging in to [http://findvera.com findvera.com].

Firmware Flash Vera 1

2009-08-16T15:45:17Z

LibraSun:

If Vera's power light blinks consistently (not a double pulsing blink) within a few seconds of powering on, then Vera's firmware has become corrupted. This can happen if Vera was unplugged while in the middle of performing a firmware update ("flash"). When it does, you will probably need to use a firmware restoration utility, which runs on Windows. Here is how to restore Vera's firmware once it has become corrupted:

1. Download Vera's firmware and store it on your PC's hard drive. You can get the firmware here: http://download.controlmyhouse.net/firmware/wl500gP-1.0.616.trx

2. Download the firmware restoration utility and unzip it into a folder on your PC. The utility is here: http://download.controlmyhouse.net/flash_firmware.zip

3. Connect your PC's network connection the LAN 1 port of Vera. (It must be LAN 1, not any of the other LAN ports.)

4. Give your PC a static IP: 192.168.1.2, with subnet mask 255.255.255.0. You can leave the Gateway and DNS server blank. To do this in Windows XP, choose Start, Control Panel, Network Connections. Be sure all connections are disabled except for "Local Area Connection", which you right-click on and choose Properties. Scroll down to "Internet Protocol (TCP/IP)" and click Properties. Make note of the current settings so you can restore them when you're done. Choose "Use the following IP address", and put 192.168.1.2 in the IP address field and 255.255.255.0 in the subnet mask. Leave the other fields alone. Click 'OK' to close the window, and then 'OK' on the other window.

5*. Run the program 'rescue.exe' (downloaded in Step 2). Click 'browse' and find the firmware file (downloaded in Step 1). NOTE:You may need to disable your anti-virus software to run 'rescue.exe'. The anti-virus might think this is malicious code.

6. Unplug the power to Vera. Hold the black button in while you reconnect the power. Let go of the black button when the power light starts blinking.

7. Click 'upload' in the firmware utility. It takes up to 5 minutes to flash the firmware. 

'''Note'''

(*) The rescue utility is known to work only on Windows XP and with only ONE network card (disable wireless and other network cards if your computer has any)

Luup Lua extensions

2009-08-16T04:15:53Z

LibraSun:

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: 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
lu_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: call_delay ===

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

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be past 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.

=== 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.
--
lu_CallFunctionTimer("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)

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.

=== 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: 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"
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.

== 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)

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.

=== I/O data ===

lu_iop_intercept_incoming

lu_iop_open

lu_iop_recv_block

lu_iop_send

=== Job Handling ===

lu_job_set

lu_job_get

Luup Lua extensions

2009-08-16T04:12:49Z

LibraSun:

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: 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
lu_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: call_delay ===

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

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be past 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.

=== 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 past 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.
--
lu_CallFunctionTimer("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)

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.

=== 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: 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"
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.

== 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)

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.

=== I/O data ===

lu_iop_intercept_incoming

lu_iop_open

lu_iop_recv_block

lu_iop_send

=== Job Handling ===

lu_job_set

lu_job_get

Luup Lua extensions

2009-08-16T04:07:29Z

LibraSun:

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: 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
lu_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: call_delay ===

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

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be past 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.

=== 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 past 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.
--
lu_CallFunctionTimer("refreshCache", 1, "30m", "", "SomeStuff")
end
</pre>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

Checks if device, which, if it's a string, is interpreted as a udn, and if it's a number, is 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)

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.

=== 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: 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"
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.

== 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)

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.

=== I/O data ===

lu_iop_intercept_incoming

lu_iop_open

lu_iop_recv_block

lu_iop_send

=== Job Handling ===

lu_job_set

lu_job_get

Luup Lua extensions

2009-08-16T04:05:04Z

LibraSun:

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: 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
lu_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: call_delay ===

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

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be past 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.

=== 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 past 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.
--
lu_CallFunctionTimer("refreshCache", 1, "30m", "", "SomeStuff")
end
</pre>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

Checks if device, which, if it's a string, is interpreted as a udn, and if it's a number, is 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)

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.

=== 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: 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"
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.

== 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)

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.

=== I/O data ===

lu_iop_intercept_incoming

lu_iop_open

lu_iop_recv_block

lu_iop_send

=== Job Handling ===

lu_job_set

lu_job_get

Luup Lua extensions

2009-08-16T03:51:51Z

LibraSun: /* variable: devices */

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: 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
lu_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: call_delay ===

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

returns: result (number)

The function 'function_name', which must be passed as a string, will be called in 'seconds' seconds, and will be past 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.

=== 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 past 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.
--
lu_CallFunctionTimer("refreshCache", 1, "30m", "", "SomeStuff")
end
</pre>

=== function: is_ready ===

parameters: device (string or number)

returns: ready (boolean)

Checks if device, which, if it's a string, is interpreted as a udn, and if it's a number, is 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)

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.

=== 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: 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"
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.

== 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)

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 anyway, 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.

=== I/O data ===

lu_iop_intercept_incoming

lu_iop_open

lu_iop_recv_block

lu_iop_send

=== Job Handling ===

lu_job_set

lu_job_get

Schlage Lock

2009-08-15T01:34:54Z

LibraSun:

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's 'Dashboard'. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's 'Dashboard' shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-15T01:34:33Z

LibraSun:

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's 'Dashboard'. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-15T01:34:18Z

LibraSun:

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's 'Dashboard'. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-15T01:34:00Z

LibraSun:

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's 'Dashboard'. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Control' (or 'Dashboard' or 'Devices') page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page 
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-15T01:33:19Z

LibraSun: /* Lock/Unlock */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's 'Dashboard'. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page 
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T21:17:05Z

LibraSun: /* Changing an existing PIN */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page 
#Remove an existing user's slot (see below) 
#Add the user again with a different PIN (see above) 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T21:14:07Z

LibraSun: /* Removing a PIN */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T21:13:54Z

LibraSun: /* Changing an existing PIN */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T21:13:41Z

LibraSun: /* Adding a new PIN */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Dashboard' or 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Devices' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T21:13:22Z

LibraSun: /* Adding a new PIN */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Dashboard' 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Devices' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T20:29:25Z

LibraSun:

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Devices' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Devices' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T20:29:05Z

LibraSun:

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Devices' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Control' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Schlage Lock

2009-08-14T20:28:42Z

LibraSun: /* Adding a new PIN */

= Secure Z-Wave Devices Explained =

Door locks are a special breed of Z-Wave devices which require an exchange of security keys with Vera during the 'Include' ("pairing") process.  Accordingly, the normal 'Include' procedure - carrying Vera's black Z-Wave dongle to the device - will not work with Schlage locks.  Instead, Schlage locks must be paired with Vera using a special procedure (see 'Adding/Pairing a Lock', below).

In order for Vera to interoperate successfully with a Schlage lock or other secure Z-Wave device, the following conditions must all be met: '''1)''' Vera's Z-Wave dongle must have a built-in security class: '''Go to Setup -> Devices -> Z-Wave Options''', and look at the ''''Version''''. If the '''version is 2.40 ''''''your dongle does not have the security class implemented.'''  Request a replacement dongle by sending us a support request at the [http://www.micasaverde.com micasaverde.com] website (click 'Support'), including your serial number, name, address and email. 

'''2)''' Vera's firmware must be '''version 1.0.602 or later''': '''Go to Setup -> Advanced -> Download''' and confirm the version of your firmware. 

'''3)''' The range for the Schlage lock is much less than for other devices because the antenna is inside a metal housing. The distance (in open air) between Vera and your lock should not exceed 30 feet (if you have two walls between them, the distance should be much lower). You can use a [http://www.newegg.com/Product/Product.aspx?Item=N82E16812191054 USB Cable extender] to place Vera's Z-Wave dongle closer to the lock. (If you change the dongle position, don't forget to do a [[Heal Network]] after.) Otherwise you will need to add lamp modules to act as Z-Wave relays, as explained in #4.

'''4)''' Schlage locks work with Zensys' "Zensor Net Technology" which prolongs battery life for battery-powered Z-Wave devices. If the Schlage lock cannot be in direct communication to Vera and its signal must be routed through other Z-Wave devices, the last node in the route must be capable of "Zensor Net Beam" (ZNB). Currently, the only Z-Wave devices on the market known to support ZNB are the Homepro ZDP100 lamp module (must be firmware version 3.3 or later) and the Schlage RP200 light module. After you've added lamp modules, you must do a [[Heal Network]] before they will effectively act as relays. [[Heal Network]] will also give you a report to confirm that Vera can talk to all your Z-Wave devices. 

= Setting Up a Schlage Lock with Vera =

== Adding/Pairing a Lock ==

Adding ("pairing") a secure device like the Schlage lock takes longer than adding a normal, non-secure device because Vera needs to share encryption keys with a secure device.  IMPORTANT: Leave Vera's black Z-Wave dongle inserted when pairing a lock with Vera.

Choose one of the following methods for adding a lock to Vera's network:

=== Method 1 - Vera is located FAR from the lock you are adding ===

These are the steps typically used to pair secure Z-Wave devices with Vera.  Note beforehand that this method involves Vera being disconnected from the internet as well as your home network.  However, because Vera's Wi-Fi remains active throughout, you can perform Steps 7-9 by connecting your computer wirelessly to Vera.

1. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

2. After 60 seconds, Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

3. Press-and-hold the black button on the back of Vera, then tap the red button once. (Be careful not to press the black ('restore') button twice in a row, as this will reset Vera to the [[Factory Reset|factory default]] configuration!) Vera's power light will begin blinking steadily once per second - meaning Vera is in 'Add' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Step 3 until it does.)

4. On the Schlage lock's keypad, enter its 6-digit programming code.  The light will blink orange. ''    (Note: You can find the lock's program code on the back of the lock or in its manual.)''

5. Press the [Schlage] button, and then '0'.

6. If Vera's power light flutters briefly, and the lock's [Schlage] button blinks green twice, pairing was successful. Otherwise, you must follow the steps below for 'Resetting a Schlage Lock' and then repeat Steps 1-5 to try pairing the lock again

7. Reconnect Vera back where it belongs (or connect to Vera wirelessly) and access Vera through your web browser.

8. On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other options, then click 'Save'.

9. Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attempts, try resetting the lock (see 'Resetting a Schlage Lock'), then attempt Steps 1-5 once again.

(For more information on the method described here, read the 'Adding/Removing Z-Wave Devices' section of [[Buttons Indicators#Adding.2FRemoving_Z-Wave_devices|Adding/Removing Z-Wave Devices with the Red/Black Buttons]].)

=== Method 2 - Vera is located CLOSE to the lock you're adding ===

This method works best if your Vera unit is already positioned close enough to communicate with the Schlage door lock.

1) Log in to Vera's interface by directing your computer's web browser to Vera's IP address (e.g. 192.168.81.1).     (Note: You can also log in using [http://FindVera.com FindVera.com], but the IP login works a bit faster.)

2) Click 'SETUP' in the top right hand corner of the Dashboard.

3) Click 'Devices'.

4) Click 'Z-Wave Options'.

5) From the pull-down menus, choose: "''Include''" "''one''" node "''any''" with "''high power''" and timeout after "''30''" seconds.

6) Before proceeding, have your lock's programming code handy and have a clear walking path to your lock.

7) Click 'Go' and immediately walk to the lock. (''You must complete Steps 6-8 within 30 seconds''.)

8) On the lock's keypad, enter the 6-digit programming code, then press the [Schlage] button.

9) After the [Schlage] button stops blinking amber, press '0'.  The [Schlage] button should light up green, indicating that pairing with Vera was successful.     NOTE: If the [Schlage] button instead blinks red, the lock may need to be reset first. Repeat Steps 1-9, but choose "''Exclude''" in Step 5, to reset the lock. Then try to pair the lock again.

10) On Vera's 'Devices' page, assign the lock to a room and give it a name, and set any other desired options, then click 'Save'.

11) Try activating (locking or unlocking) the door lock using Vera.

NOTE: If the lock fails to pair with Vera despite repeated attemps with either method shown here, you may need to reset the lock to its factory default state before trying again (see 'Resetting a Schlage Lock to Factory Default', below).

Once pairing has succeeded, Vera will begin configuring the lock you just added.  During the configuration process, Vera will display a spinning blue cog icon next to the lock on Vera's 'Devices' page (see [[Device Control Status|Device Control Status]] for more details). It can take as long as 10 minutes for Vera to configure the lock completely, because a lot of encrypted data is being exchanged in the process. Be patient, and don't use Vera for other tasks until the green cog icon appears.  Whenever you rename the lock, change its room, or otherwise change its configuration settings (other than assigning PIN codes), Vera will need to re-configure the lock again.

== Resetting a Schlage Lock ==

A. Disconnect Vera and move Vera close to the Schlage lock. Plug Vera into an electrical outlet near the lock.

B. Vera's power light comes on and starts double flashing - meaning Vera is operational but has no internet connection.

C. Press-and-hold the red button on the back of Vera, then tap the black button once. Vera's power light will begin blinking fast, about 3 times per second - meaning Vera is in 'Remove' mode. (Wait up to 30 seconds for Vera's power light to start blinking like this, and if it does not, repeat Steps A-C until it does.) 

D. On the Schlage lock's keypad, enter the lock's programming code.

E. Press the [Schlage] button and then '0'. The lock should beep and the 'Schlage' button should blink twice, indicating the lock is now reset and ready to be paired with your Vera (see 'Adding/Pairing a Schlage Lock,' above).

If the lock fails to reset as described in Step E, try repeating Steps C-E until it does.

== Excluding a Schlage Lock From Previous Network ==

Before adding a lock to your Z-Wave network, you may have to [http://wiki.micasaverde.com/index.php/Reset_Node exclude] it first from a previous network. Even if the lock is new, it could have come from the factory already paired with a Z-Wave network. To resolve this issue:

#Unplug the black Z-Wave dongle from the back of Vera.
#Keep the dongle's button pressed for 5 seconds, until the blue light starts blinking fast.
#On the lock's keypad, enter the programming code and wait for the light to blink orange.
#Press the [Schlage] button and then '0'. 

== Removing/Unpairing a Lock ==

If your Schlage lock was mistakenly paired using Vera's normal (dongle-based) 'Include' procedure, the lock will have a red cog icon displayed next to it on Vera's 'Devices' page, and you won't be able to control it. To use the lock with Vera, you must first remove ("unpair") the lock from the Z-Wave network.

Remove the lock the same way as any other Z-Wave device:

(1) Remove Vera's black dongle, then hold the dongle near the lock.

(2) Press and hold the button on the dongle for 3 seconds until the light starts blinking fast, which indicates it's in 'Remove' mode.

(2) On the lock's keypad, enter the 6-digit programming code.  The lock will beep audibly.

(3) Press the [Schlage] button followed by '0'.

(4) Re-insert the dongle in Vera, wait 60 seconds, and refresh the browser page.

The lock should now be gone from Vera's 'Devices' list, indicating the lock has been successfully removed from the network, and you can proceed to pair, or include, the lock the right way (see Method 1 or Method 2, above).

= Resetting a Schlage Lock to Factory Default =

It is sometimes necessary to reset a Schlage lock to its factory default, in order to enable the lock to pair properly with Vera, or to resolve other lock malfunctions: 

1) Remove the batteries from the lock.

2) On the lock's keypad, press and release the [Schlage] button.

3) Reconnect the lock's battery(s).

4) Wait until the [Schlage] button is no longer lit.

5) ''Within 10 seconds'', press and hold the [Schlage] button until it lights green and the lock beeps.

Your Schlage lock is now reset to its factory default, and you may proceed to add it to Vera's network.

= Other Notes =

Any time Vera configures a secure Z-Wave device such as a Schlage lock - either immediately after pairing the lock with Vera, or when subsequent changes are made to the lock's settings on Vera's 'Devices' page - Vera needs to poll all 19 of the lock's user codes, even ones that are not set yet!  Accordingly, it may take Vera a while to display the green cog icon.  Be patient, and do not use Vera for any other tasks during the configuration process.

You can see Vera's event log by choosing the 'Advanced' tab -> 'Logs' -> 'Verbose' -> 'Show Z-Wave Jobs'.  If Vera's communication with the lock has been successful, the list will show all completed events.  Refresh the page using your web browser to see subsequent events as they are added to Vera's event log. 

= Using a Schlage Lock with Vera =

== Lock/Unlock ==

You can lock/unlock door locks and deadbolts with Vera the same way you turn a light On or Off. A door lock can be locked and unlocked remotely. '''But Schlage deadbolts are designed so someone has to physically turn the deadbolt knob to engage/disengage the deadbolt. When Vera tells the deadbolt to unlock, the deadbolt knob is engaged for 10 seconds so someone can turn it, and then after 10 seconds, it's disengaged again. '''(This behavior is identical to when you enter your PIN on the deadbolt's keypad.) Schlage locks contain no motor to lock/unlock the deadbolt. Thus, Vera cannot remotely lock or unlock a deadbolt for you. Instead, you can wait until someone is at the door, then click 'Lock' or 'Unlock' using Vera's interface, and tell the person to turn the deadbolt knob.

Vera offers three ways to control a door lock or deadbolt:

1) Use your PC's or PDA's web browser to click the lock/unlock buttons on Vera's Dashboard. To allow remote access, you can click 'Unlock' when a person is in front of the door, giving the person a few seconds to manually turn the latch;

2) Use a cellphone application to activate the lock remotely; or, 

3) Issue a PIN to each authorized user (see 'Setting a User PIN,' below).

== Controlling the lock with handheld remotes and scene controllers ==

You can add handheld remotes and scene controllers to Vera and choose the option "Manage scenes as events". Then you can create a scene which locks a door, as well as doing other tasks, and associate the scene to a button on the remote or in-wall scene controller. See [[ZWave Add Controller|Z-Wave Add Controller]] method #2. So you can create a 'Go to Bed' scene, for example, which may be button 1 on your scene controller, and which locks all the doors and turns off the lights and thermostats. For your security, we only allow you to 'lock' the doors using a handheld remote or scene controller. You cannot 'unlock' them with this technique because remotes and scene controllers are not secure devices and, therefore, there is the risk that an intruder could impersonate you using your handheld remote or scene controller. To unlock the doors, you must use Vera's web interface or mobile phone interface.

== Scenes and Events ==

Door locks initiate events (a) when the door is locked/unlocked, (b) when a user enters a PIN, and (c) when someone enters the wrong PIN three times in a row. You can create a scene, associate one or more of these events with the scene, and check one of the 'Notify User' boxes if you want to be notified when an event (and a corresponding scene) happens.

== Setting a User PIN ==

You can create a PIN for each authorized user to use when locking/unlocking the door:

=== Adding a new PIN ===

#Navigate to Vera's 'Devices' page
#Select an empty slot for the new user
#Give the user a descriptive name (e.g. "Pool Service")
#Type the user's new PIN
#Click 'Set'.
#Each user's PIN will remain active until you remove it.

It may take up to 60 seconds for Vera to confirm the new code was set, whereupon you will see the new user listed next to the lock, along with a 'Remove' button.  If the lock already contained user PINs - which you added manually or through a different Z-Wave controller - Vera will display them as "Code 1", "Code 2", etc.

NOTE: For your security, Vera does not keep a copy of the codes; they are only stored in the lock itself.

=== Changing an existing PIN ===

#Navigate to Vera's 'Control' page 
#Select an existing user's slot 
#Type the user's changed PIN 
#Click 'Set'. 
#The user's PIN will remain active until you remove it. 

=== Removing a PIN ===

#Navigate to Vera's 'Control' page
#From the list, find the user whose PIN you wish to de-activate
#Click the 'Remove' button next to that user
#Click 'Set'.
#The user's PIN will be removed from Vera's list.

NOTE: If Vera does not confirm the removal after 60 seconds, simply try again. 

SPECIAL NOTE: If you add, change or remove many users/PINs in rapid succession, Vera will display a 'job icon' for each addition/change/deletion. You do not need to wait for each one to complete. For example, you can add 10 users in rapid succession, and you will see 10 gray 'job icons'. Gray indicates Vera hasn't started yet, as explained [[Device Control Status|here]]. Since it takes several seconds for Vera to program a new PIN into the lock, as each job is being processed (in order), the corresponding icon turns blue, then becomes green when it is successful. In this way, you can quickly queue up several new users, and then just let Vera process them one at a time. When Vera is finished, you will see the list of all users, along with a 'Remove' button next to each. Similarly, you can click several 'Remove' buttons in rapid succession without waiting for each removal to complete.

== Reversing the Lock/Unlock Status ==

If the lock/unlock status of your door lock is backwards, meaning Vera's Dashboard shows it is locked when it's really unlocked and vice-versa, it's possible the lock was oriented upside-down when mounted. To solve this issue, go to Vera's 'Setup' page, click the 'Devices' tab and click the '+' button next to the door lock, and then the 'Advanced' button. If you see a parameter "#305 Reverse", enter a value of '''1'''.  Save this change. Vera will now reverse the lock/unlock status.

If parameter #305 is not in the list, then at the bottom of the page, type '''305''' in the "New Device Data ID" field, and type '''1''' in the "New Device Data Value" field. Click 'Add'. Then save your changes. Vera will now reverse the lock/unlock status.

== Logging and Camera Links ==

When you log in to [http://FindVera.com FindVera.com] and click 'Events', you can select the door lock to see all the times someone entered a user code at the door or locked/unlocked the door.

On the 'Devices' tab, click '+' next to your security camera(s), and you will have a check box for this lock. Then, whenever the door is locked/unlocked, Vera will also take a picture with the camera(s). You will see the pictures associated with an Event when you click the event on the [http://FindVera.com FindVera.com] site.

= Security Concerns =

See: [[Security Concerns]]

= External Links =

*[http://part2.schlage.com/docs/manual_lock_programming-beta.pdf Schlage Lock User Manual]
*[http://part2.schlage.com/docs/lock_user_guide.pdf Schlage Lock User Guide]

Luup Upgrade

2009-08-14T13:11:55Z

LibraSun:

When you upgrade Vera to the new version, called Luup, from any of the previous versions, there are several important changes you need be aware of.

1. Go to the 'Users' tab and wherever you specified a phone number to receive SMS text messages you will now need to choose the mobile phone carrier. For U.S. and Canadian customers, the phone number must be 10 digits only, without a 1 in front. If your carrier is not listed choose 'Other'. You will not receive SMS text messages until you update this.

2. The process to control Vera from your mobile phone has now changed. If you will use your mobile phone's browser to access Vera you must first go to Devices, Luup Plugins, and install either the basic text-only WAP version, and/or the graphical smartphone version. You can also install the native versions. Either way, visit [http://findvera.com/mobile findvera.com/mobile] from your mobile phone, and follow the [https://findvera.com/instructions.php instructions].

3. You can now track notifications to be sure you get them as you should. OIn Vera's 'Setup' page, choose Advanced, Logs to see a list of all recent activity, both reportable events like a door being opened, and notifications where Vera contacted you by email or SMS text. Once the event or notification is reported to the findvera server, you can track its progress. Only the 20 most recent events and notifications are stored locally in Vera, but a full database of all events and notifications is viewable by logging in to [http://findvera.com findvera.com].

Find Vera Service:Troubleshooting

2009-08-14T12:46:20Z

LibraSun:

Issue: If you've just upgraded the firmware with "Restore to factory defaults" Resolution:    Login directly to your Vera and go to Setup->FindVera.Com and re-enter your username and password then enable the service 

Issue: If you've just upgraded the firmware with "Keep settings" Resolution: It is possible that your Vera unit is still upgrading please wait a few minutes then try again 

Issue: If the internet connection at Vera's side dropped or Vera doesn't have internet access anymore, you won't be able to access it through findvera.com Resolution: Check Vera's power led to be solid. If it's blinking go to Setup->Advanced->Net&Wi-Fi and configure your [[Networking Setup:Troubleshooting|Network settings]] then click 'Troubleshoot Network' and observe if it can reach Google and our servers.

Device Control Status

2009-08-14T12:36:39Z

LibraSun:

There are several icons on the dashboard and device page to let you control a device and see the status of the device.

== Overview ==

{| border="1" cellpadding="2"
! Icon !! Meaning
|-
|| [[Image:OFF_2.gif]] [[Image:CONFIG_4.gif]] [[Image:LEVEL_5.gif]] [[Image:ON_2.gif]] [[Image:POLL_5.gif]] || These icons appear next to a device to let you know that Vera is doing something with the device, such as turning the device on or off or configuring the device. They are called "Job Icons", because each time Vera does something to a device, it's called a job, and each icon represents a job.
|-
|| [[Image:buonnormal.gif]] [[Image:buautonormal.gif]] [[Image:bu75normal.gif]] || These are buttons you can click to tell Vera to control a device. They are called "Control buttons". In most cases when you click a control button for a device, you will soon see a job icon appear next to the device to indicate that Vera is doing what you request. For example, if you click the "Off" control button, you will see an "Off" job icon next to the device to let you know that Vera is turning that device off. And when Vera has successfully finished turning the device off, the "Off" job icon turns green to let you know that everything went ok.
|-
|| [[Image:wait_anim.gif]] || This means "please wait" because you clicked a command button, and Vera is busy creating the "job". When you click a command button the "please wait" icon should appear immediately, and then go away within a couple seconds when there's a job icon to show you the status of your command.
|}

== Job icons ==

When Vera is doing something with a device, like turning the device on or off or adjusting the temperature, Vera displays an icon next to each device for each action that Vera is performing (aka each job). The icons change color depending on the status of the job. When Vera has not yet started the job, the icon appears gray, meaning Vera is waiting, probably because Vera is still busy doing something else. This is called "Waiting". When Vera is busy talking to the device to process the job, the icon starts moving and is blue, which means "Busy". When the job is all finished, if everything went OK the icon turns green meaning "OK", and if Vera was unable to complete the job, the icon turns red, meaning "Error". So, for example, if you click the "Off" command button for a device, you will see the "Busy" off icon for a moment, and then it will turn green if Vera was able to turn the device off, or red if Vera had a problem. If the "Off" job icon turns red, meaning "Error", then you know Vera did not successfully turn the device off and you should check the device yourself. You can also move your mouse pointer on top of a job icon to see a brief description popup.

Normally a job icon will stay visible for 30 seconds after it turns green or red to give you time to see how the job finished. The exception is the "Configure" job icon, which always stays there so you know which devices are configured OK and ready to use, and which devices Vera has not been able to configure. If you don't see the Configure icon next to a device, that means the device does not require any configuration. If you see the red "Configure" error job icon, as shown below, that means Vera has not configured the device and the device probably will not work. Note that when you add battery operated Z-Wave devices, like motion sensors, it is perfectly normal that Vera will not be able to configure them for several hours after you add them. [[Configure_ZWave_Devices|Learn more about this]]

{| border="1" cellpadding="2"
! Waiting !! Busy !! Ok !! Error !! Command
|-
|| [[Image:CONFIG_2.gif]] || [[Image:CONFIG_3.gif]] || [[Image:CONFIG_4.gif]] || [[Image:CONFIG_5.gif]] || '''CONFIGURE:''' Vera needs to configure some devices before you can use them. If so, you will see a Configure job icon next to the device. Every time you start Vera or change your devices, Vera will check that all your devices are configured and working OK, or show the red Configure error icon if Vera couldn't configure the device. This icon is "sticky", meaning it will stay next to the device forever and doesn't go away after 30 seconds like the others. Sometimes it's normal to get a red configure error icon for several hours after adding a new Z-Wave device. [[ZWave_Configuration_Options|click here]] and read the section 'Configure node right now' to learn why this happens and what to do.
|-
|| [[Image:POLL_2.gif]] || [[Image:POLL_3.gif]] || [[Image:POLL_4.gif]] || [[Image:POLL_5.gif]] || '''POLL:''' Vera is busy polling the device. Vera will create these "poll" jobs automatically just to check that all your devices are ok. [[Polling|learn more about polling]]
|-
|| [[Image:OFF_2.gif]] || [[Image:OFF_3.gif]] || [[Image:OFF_4.gif]] || [[Image:OFF_5.gif]] || '''OFF:''' Turn off
|-
|| [[Image:ON_2.gif]] || [[Image:ON_3.gif]] || [[Image:ON_4.gif]] || [[Image:ON_5.gif]] || '''ON:''' Turn on
|-
|| [[Image:LEVEL_2.gif]] || [[Image:LEVEL_3.gif]] || [[Image:LEVEL_4.gif]] || [[Image:LEVEL_5.gif]] || '''LEVEL:''' Adjust the level, such as dim a light or set the temperature
|}

== Control buttons ==

These are buttons you click to control a device. Generally when you click a button you'll see the 'please wait' icon, then one of the "Job icons" shown above to show you the status of your request.

{| cellpadding="2" border="1"
|-
! Icon
! Command
|-
| [[Image:Buoffnormal.gif]] [[Image:Buonnormal.gif]]
| Turn off or on the device
|-
| [[Image:Bu25normal.gif]] [[Image:Bu50normal.gif]] [[Image:Bu75normal.gif]]
| Adjust the device (i.e. dim) to 25%, 50% or 75% of the full power
|-
| [[Image:Buarmnormal.gif]] [[Image:Bubypassnormal.gif]]
| For alarm sensors, this will arm or disarm the sensor. [[Arm disarm|Learn more]]
|-
| [[Image:Buautonormal.gif]]
| Put the device in 'auto' mode
|-
| [[Image:Bucoolnormal.gif]] [[Image:Buheatnormal.gif]]
| Turn on cooling or heating
|-
| [[Image:Buupnormal.gif]] [[Image:Budownnormal.gif]] [[Image:Bulnormal.gif]] [[Image:Burnormal.gif]]
| Move up, down, left or right
|-
| [[Image:Buplusnormal.gif]] [[Image:Buminusnormal.gif]]
| For cameras, this means zoom in or out. For other devices, it means increase or decrease
|-
| --todoab:
| For some devices there may be a white box for you to type in a value directly. For example, for thermostats, you can type in the temperature you want in the box to the left
|}

The current status of the device is indicated by highlighting one of the control buttons. For example, if the "Off" control button is highlighted, which is blue, then that means Vera has confirmed the device is already off. The status can change. For example, if you tell Vera to turn on a device, the On control button may be highlighted. But if Vera was unsuccessful in turning on the device, the On control button will go back to normal. Or, if somebody manually turned the light off by hand, then the next time Vera polls the device and learns of this, Vera will highlight the Off control button instead so you know the device is now off.

Source Code

2009-08-14T12:18:19Z

LibraSun:

Vera is based on OpenWRT KAMIKAZE. The full source tree for OpenWRT is available at openwrt.org.

The source code for Vera's applications, as of version 1.0.602, is available here: http://download.findvera.com/source-1.0.602.tar.gz

This includes DCERouter and some other libraries. The source code for Vera's Z-Wave stack and the router plugins are not included as they include licensed code and were created under NDA's. However these are not needed to extend the functionality of Vera because it is a plugin architecture so the proper way to add new functionality is to create another plugin or DCE device, rather than to add it into one of our existing devices. The binaries with the .602 release match the code, so you should be able to build a new firmware with the OpenWRT source tree + this source code, and add back in the non-open source Vera binaries. Note that the Z-Wave device (/usr/bin/ZWave) is not free or open source; license fees are paid per unit sold.

The exciting part is that our new [[LuaUPnP]] module will largely replace the need for developers to use the C/C++ code. This is a collaborative environment that makes it much easier to extend the functionality of Vera and will facilitate making more powerful applications than building DCE devices. You will be able to do virtually anything you want to extend Vera with the [[LuaUPnP]] module. And any devices created with LuaUPnP will be automatically UPnP devices. Plus you can specify if you want to make the devices available to the community for use, for development, or private.

Originally our plan to help facilitate developers wanting to add-on to Vera was to setup a build server with virtual machines. However we ran into some bugs and performance problems in the virtual machine emulators that made cross-compiling within a VM very difficult. So, we figured our developers' time is better spent on LuaUPnP since that will be a lot more useful tool for developers who want to make their own customizations and add-ons to Vera.

Leviton Scene Controller

2009-08-14T11:50:15Z

LibraSun: /* Method #2 */

These instructions work for the Leviton RZCS4. They also work for the RZCZ4 which is a zone controller, not a scene controller. However the zone controller is more limited in it's functionality and you must use 'method #2' described below.

==Adding the RZCS4 to your Z-Wave network==

1. Be sure the scene controller is not already paired with another network. The best way to do this is to hold down the scene 1 and scene 3 buttons simultaneously for 10 seconds. Hold down the left side of the buttons, near the LED lights. When you first press them, one of the buttons may blink red momentarily. After you've held them down for about 4 seconds, all 4 lights will turn amber, and if you keep them held down, after another 4 seconds all 4 lights will turn red. This means the scene controller is reset, and can now be included.

2. Take Vera's dongle to the scene controller and be sure Vera's dongle is off. If the light on the dongle is blinking, tap the button on the dongle so it is off. The dongle must be off when you put the scene controller into program mode. Now, press and hold scene buttons 1 and 3 on the left side, near the LED lights, for 4 seconds. All 4 lights will turn amber. Let go. The 4 lights will blink amber every 1 second or so to indicate the scene controller is in program mode.

3. Only after you completed step 2 and the scene controller is in program mode, tap the button on Vera's dongle to put the dongle in include mode. After about 5 seconds, the dongle's light should stay solid for a second and the scene controller's 4 amber lights will interrupt their normal blinking pattern. This means the scene controller was now included. You can put Vera's dongle back in Vera, or take it to include another device. If including another Leviton scene controller, be sure to tap the button on the dongle to turn it off again before repeating step 1.

4. When you re-insert the dongle in Vera, after a few seconds you should see the scene controller show up as an unassigned device on the devices tab in Vera's setup site. If you don't reload Vera's web page and go back to the devices tab. Pick the room the scene controller is in, and give the scene controller a name if you want.

If you do not want Vera to assign scenes to the scene controller, but will do that using another device, you can stop here. If you want Vera to assign scenes, keep going with step 5.

''Now you have to make a decision if you want to use method #1 or method #2 as described in [[ZWave_Add_Controller]].'' The bottom line is that with method #1, which is the traditional way of creating scenes, the Leviton's up/down buttons work, and you can turn a scene on as well as off. However, this only works with some light switches and lamp modules which support 'scenes', and you can only set lighting levels. You can't control a thermostat, lock a door, turn on a tv, etc. with method #1. To see if a device is scene capable and can work with a Leviton scene controller in method #1, click the '+' button next to the device, look at the "Capabilities" line and look for the number 44 after the | sign. If it's there, the device is scene capable. Method #2 is more flexible. With method #2 the Leviton scene controller's buttons are tied to scenes in Vera, which can do anything with any device because Vera is actually running the scene. However with method #2 the up/down buttons on the scene controller don't work, nor does the 'toggle a scene on/off' feature. With method #2 if you have 3 lighting mood scenes and an 'off' scene, you'll assign the 'off' scene to one of the 4 buttons, but you won't be able to use the toggle feature to turn one of the 3 scenes off.

===Method #1===

5. Create a scene that adjusts the light to the level you want. Save your changes.

6. Click the '+' button next to the scene controller and choose 'Custom Z-Wave settings', and 'Add scene assignment'. Choose the key to assign the scene to (1-4) and the scene to assign to the key. Save your changes.

7. The scene should work fine. If you want to change the scene, go to the 'scenes' tab and modify the scene as you want, save your changes, and then go to Devices, click '+' next to the scene controller, and choose 'configure right now'. That will reconfigure the scene controller.

=== Method #2 ===

5. After you assigned the scene controller to a room, click the + button next to the scene controller on the devices tab in Vera's setup site. Check the box "Treat scene buttons as events". After you save your changes, Vera will start to reconfigure the scene controller and if successful, you will see a [[Device Control Status|green cog]] next to the scene controller indicating it was successfully configured. There must be a green cog next to the scene controller for it to work.

6. On the scenes tab in Vera's setup site, create the scenes you want assigned to the scene controller. Click the red 'save' button to save your scenes. If you haven't yet added all the lights and other Z-Wave devices you want in the scene you'll have to do that first, of course, and come back to this step later. Click the 'Add Event' button for your scene. Choose the event 'Scene button is pressed'. Then choose the scene controller from the pull-down. Then enter the scene button you want to trigger the scene; enter a number between 1 and 4 for the 4 scene buttons.

After you save your changes, pressing the left side of the scene button, next to the LED, will trigger the scene. Note that the scene can include delays. For example, if you have a 'go to bed' scene, you may want the scene to lock the doors, turn down the thermostat, and turn off all the lights. But, you might not want the bedroom lights to go off immediately if the scene controller is on the opposite side of the room from the bed. So, in the scene, for the bedroom lights, choose the command "On" then choose "After 30 seconds", then "Set a new setting", then "Off". This way, when you choose the scene, the bedroom lights will come on for 30 seconds so you have time to walk across the room, and then turn off.

The 4 scene buttons on the scene controller can be pushed to the left or to the right. The left is the normal way to trigger a scene. If you press any of the scene buttons to the right, it is treated as 'button 0'. You can create a scene as described above, and in step 6 choose button #0. But this means that no matter which of the 4 scene buttons you press to the right, they all trigger the scene for button #0. See [[ZWave Add Controller]] method #2 for an explanation. Also, the scene controller only triggers button #0 when you press the button to the right if you already pressed the button to the left. If this is confusing, just stick to the normal usage of buttons 1-4 by clicking the button to the left. The scene up and down functions do not do anything.

As explained in [[ZWave Add Controller]] you can leave "Treat scene buttons as events" unchecked, and then create scenes the traditional Z-Wave way (i.e. Method #1). In this case the scene up and down buttons do work as expected and so does the off. However, the scenes are much more limited. You cannot have delays, or adjust thermostats, or lock doors and so on. Also, when you want to program the scene into the scene controller, you can only do this by re-adding the scene controller to Vera while the dongle is inserted. You cannot carry the dongle to the scene controller; you must put the scene controller in program mode, as explained in step 2 above, and then choose 'Add Z-Wave Controller' from the Devices tab on Vera's 'Setup' menu. Therefore it is a bit cumbersome to do this unless you have a separate handheld controller to help program the scenes. If you do want Vera to do it for you this way, create your scenes, add the scene controller, leave "Treat scene buttons as events" unchecked, choose 'Custom Z-Wave Settings', and choose the 'Add scene assignments' to assign the scenes to buttons. Then put the scene controller in program mode, and choose 'Add Z-Wave controller' from Vera's setup page.

==Removing the RZCS4 from your Z-Wave network==

If you already paired the RZCS4 and want to remove it:

1. Take Vera's dongle to the scene controller and be sure Vera's dongle is off. If the light on the dongle is blinking, tap the button on the dongle so it is off. The dongle must be off when you put the scene controller into program mode. Now, press and hold scene buttons 1 and 3 on the left side, near the LED lights, for 4 seconds. All 4 lights will turn amber. Let go. The 4 lights will blink amber every 1 second or so to indicate the scene controller is in program mode.

2. Only after you completed step 1 and the scene controller is in program mode, press and hold the button on Vera's dongle continuously for 5 seconds until the dongle's blue light blinks quickly, then let go. After about 5 seconds, the dongle's light should stay solid for a second and the scene controller's 4 amber lights will interrupt their normal blinking pattern. This means the scene controller was now removed. You can put Vera's dongle back in Vera, or take it to include another device.

Rooms

2009-08-13T22:11:28Z

LibraSun:

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.