User Tools

Site Tools


supported_hardware:veraui7

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
supported_hardware:veraui7 [2018/02/16 18:31] – added json received info James Sentmansupported_hardware:veraui7 [2023/02/13 14:52] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ======Vera UI7====== ======Vera UI7======
  
-In the UI7 version of Vera software they switched to a new connection protocolWe still support the older protocol and it still works for the most part so if you are happy with the functioning of your system there is no need to update. Support for the newer UI7 protocol is currently in Beta testing as of XTension version 9.3.11. It seems to be the policy of Vera that they will not fix bugs in the older protocol nor are they going to add support in it for the newer devices or features. This means that if you have a newer device like some of the newer thermostats, or a device with more advanced features than were supported in the older version you will need to update to the new interface in order to use them. If you’re starting a new Vera connection you should start with the Beta version and only fall back if you have a problem. +This page is for the currently support “UI7” version of the XTension pluginIf you’re looking for information on the legacy plugin for older Vera units please see the [[supported_hardware:vera|legacy Vera page]] The legacy plugin is no longer included with the standard XTension distribution so if you wish to continue using it you must install the plugin manually.
 =====Converting an existing Vera Interface===== =====Converting an existing Vera Interface=====
 **It is important that you follow these instructions to convert an existing Vera install to the new protocol!** The new system uses different addressing and device type settings than the old system and you must properly convert your units. A backup of your database is made before the process begins (though you may wish to manually zip up a copy of your database just in case as well) so you can return to the older interface by putting that back if there are problems. As of XTension 9.3.11 there is no way to convert your units back to the old protocol other than doing a lot of manual editing or putting back the previous database. **It is important that you follow these instructions to convert an existing Vera install to the new protocol!** The new system uses different addressing and device type settings than the old system and you must properly convert your units. A backup of your database is made before the process begins (though you may wish to manually zip up a copy of your database just in case as well) so you can return to the older interface by putting that back if there are problems. As of XTension 9.3.11 there is no way to convert your units back to the old protocol other than doing a lot of manual editing or putting back the previous database.
Line 65: Line 64:
 ---- ----
 =====Security Devices===== =====Security Devices=====
-Security devices will now create their root device which corresponds to the “tripped” value as well as a second device with the same name ending in (armed)” that you can use to arm or disarm the individual sensorsThe other choice for interfacing to this would be to create a new armed property of the units but that would require separate display functions to show if a unit was armed or not which would have taken longer to get into the beta versionI also considered linking the “blocked” status of the unit in XTension to the armed function in the Vera, but I believed this would have caused more confusion than help. If you think either of those choices would have been better or have other suggestions please let me knowThis interface may change in the future.+Security Devices create root device in XTension which corresponds to the “tripped” value. Versions of XTension prior to 9.4.6 also created an “armed” unit for each security unit that would reflect the state of the armed setting in the VeraAs of build 9.4.6 this unit is no longer automatically created since it was mostly just noise that doesn’t affect your XTension handling of the tripped status. While the Armed unit is no longer automatically created the information is still sent to XTension. If you need the armed handling in XTension then you can now manually create a new unit, assign it to the proper Vera interface and set it’s device type to “Armed” and it’s address to the same number as the corresponding Tripped unitSave the unit and it will now follow the Armed state of the security device in the Vera. 
 + 
 +If you don’t wish to have these extra units in your database any longer you can delete them after the 9.4.6 update.  
 + 
 +Note that the Tripped units in XTension will receive updates to their state regardless of the setting of the Armed unit. Even disarmed units will still report to XTension. It is only within the Vera that scene and alarm status changes check for the Armed state before performing an action.
  
 If your security device has a tripped date in it, the last activity date of the unit that is created for it will be the date and time when the trip occurred and not the time when XTension received the command. There can be a short delay between the sensor tripping and XTension receiving the command and in this case the dates will match up in both places now. If your security device has a tripped date in it, the last activity date of the unit that is created for it will be the date and time when the trip occurred and not the time when XTension received the command. There can be a short delay between the sensor tripping and XTension receiving the command and in this case the dates will match up in both places now.
Line 127: Line 130:
  
 In which case the ID number is not necessary, but the parans at the end of the command name are necessary. In which case the ID number is not necessary, but the parans at the end of the command name are necessary.
 +
 +===Update Neighbor Nodes===
 +
 +If a unit isn’t responding or isn’t reliable you may be able to fix that by updating the neighbor nodes of it and/or it’s nearby units. You can do this by telling the unit to updateNeighbors.
 +
 +<code>
 +tell xUnit “name of the unit” to updateNeighbors()
 +</code>
 +
 +This is not something you necessarily want to script to automatically happen as the network may be unavailable while the update is happening and it can take several minutes to complete for a single unit. Use this for fixing problems more than regular maintenance.
  
 ===Save Status Data=== ===Save Status Data===
Line 182: Line 195:
  
 ===Clear KWH=== ===Clear KWH===
-This is for KWH Measurement units and is the same as just telling the unit to turn off. That will reset the KWH reading to 0. You should not have to call this directly but you can if you wish. There is also a contextual menu option to clear a KWH devices value back to 0. Note that not all Vera devices that support sending this value support clearing the value. If your value dies not go to 0 after sending this command then the device won’t let you reset it.+This is for KWH Measurement units and is the same as just telling the unit to turn off. That will reset the KWH reading to 0. You should not have to call this directly but you can if you wish. There is also a contextual menu option to clear a KWH devices value back to 0. Note that not all Vera devices that support sending this value support clearing the value. If your value does not go to 0 after sending this command then the device won’t let you reset it
 + 
 +===Set Data=== 
 +The setData command is sent to a specific unit. It is for setting ZWave parameters or variables and is potentially dangerous. Because every brand and model of device is different you’ll have to know exactly what you need to send in order to set the data correctly. Sending incorrect data or data meant for a different device could brick the dimmer or cause any number of kinds of malfunctions. Most manufacturers print the parameter data in their user manuals. but not all of them. 
 + 
 +This could be used to set the local ramp rate of a dimmer switch, or an of the other configurable options in a device. For the new Home Seer HS-WD200+ dimmer this can be used to change the light color on an individual LED basis.  
 + 
 +<code> 
 +tell xUnit “name of unit” to setData( parameterNumber, byteCount, value) 
 +</code> 
 + 
 +If the device is a battery operated device then the change will be sent by the Vera when the device next wakes up, if it’s a routing device then the change will be sent immediately. Most parameters i’ve seen are single bytes. The value can be a single integer number from 0 to 255 or might be a longer string of data depending on the parameter. If you have the data in hex instead of an integer you can send a string starting with a letter “x” for example “xFF” for 255. 
 + 
 +See the supported module section or your user manual for what parameters are available.
  
 ---- ----
Line 202: Line 228:
 What values are sent in theButton and theGesture will be specific to the type of device that you are connecting from so the first thing you should do is to use the log line above to capture what values are sent and then use those to parse out later what you want to do for each gesture to each button. On the Home Seer switches I have a 1 is sent when I click the ON paddle and a 2 is sent when I click the off paddle. The Gesture values are 1 for a single click, 2 for a double click, 3 for a triple click etc.  What values are sent in theButton and theGesture will be specific to the type of device that you are connecting from so the first thing you should do is to use the log line above to capture what values are sent and then use those to parse out later what you want to do for each gesture to each button. On the Home Seer switches I have a 1 is sent when I click the ON paddle and a 2 is sent when I click the off paddle. The Gesture values are 1 for a single click, 2 for a double click, 3 for a triple click etc. 
  
-With the home seer switches no local load level changes happen for the double or triple clicks so if you want the local load to change value when using those you’ll have to add that control to your script as well.+With the Home Seer switches no local load level changes happen for the double or triple clicks so if you want the local load to change value when using those you’ll have to add that control to your script as well.
  
 Checking for the button value and the single click gesture should replace checking for the [[dictionary:unitinformation:incoming|incoming]] value and waiting for the value to change and run the ON or OFF script. The central scene information comes into XTension almost immediately but the value change at the local device will still take a few more seconds to arrive as the device has to be polled. Checking for the button value and the single click gesture should replace checking for the [[dictionary:unitinformation:incoming|incoming]] value and waiting for the value to change and run the ON or OFF script. The central scene information comes into XTension almost immediately but the value change at the local device will still take a few more seconds to arrive as the device has to be polled.
  
 Note that with a dimmable switch the poll may return an interim value for the load level and not the final value. The final value should show up soon, but there is no way to make sure I’m getting back the final target level rather than some value in the middle of the slow fade. This is another reason that you should use the central scene event and not just the ON script as it may run 2 or 3 times over a long slow fade. Note that with a dimmable switch the poll may return an interim value for the load level and not the final value. The final value should show up soon, but there is no way to make sure I’m getting back the final target level rather than some value in the middle of the slow fade. This is another reason that you should use the central scene event and not just the ON script as it may run 2 or 3 times over a long slow fade.
 +
 +As of XTension 9.4.6 another unit device type was added for “Scene Controller” if you have devices like the Aeotech WallMote or other central scene capable scene controllers they will now show up properly and you can trap their button pushes in the same on centralScene handler as above. Specifically for the WallMote you can also check the new “ignore gesture” checkbox in the edit unit dialog. The gesture information needs to be gotten from the Vera in a separate step and can make the handling of the button action take longer. In the case of the wallmote it sends a different button value for each action anyway and so the gesture information is not needed. The Home Seer switches do not do this so they require the gesture information as well if you wish to know if the paddle was double clicked or cilck and held or any other supported gesture.
 +
  
 ---- ----
Line 263: Line 292:
 =====Other Info and Thoughts===== =====Other Info and Thoughts=====
 The new protocol is more immune to the extra units that often got created alongside the real units with the old protocol. For example I have a number of devices that created a Light sensor along with the watts sensor even though the device had no such sensor capability. If you’re converting from an old protocol version please try deleting such units and see if they stay deleted. The new protocol is more immune to the extra units that often got created alongside the real units with the old protocol. For example I have a number of devices that created a Light sensor along with the watts sensor even though the device had no such sensor capability. If you’re converting from an old protocol version please try deleting such units and see if they stay deleted.
- 
supported_hardware/veraui7.1518805870.txt.gz · Last modified: 2023/02/13 14:51 (external edit)