PLUGIN: Ademco Vista Alarm Panel with VAM

Plugins & Plugin Development General Plugin Discussion
1

THIS PLUGIN HAS BEEN WITHDRAWN FROM DISTRIBUTION

What is a VAM?

VAM = Vista Automation Module.

The Vista Automation Module is an add-on that provides WiFi and z-Wave capabilities to Honeywell Vista series Alarm Panels. It is similar to the Tuxedo Touch series of Touchscreen keypads (of course, without the touchscreen). As the module is an AUI, it only allows monitoring of the partition for which it is configured.

The WiFi interface provides a JavaScript based real-time interface to the Alarm Panel.

This plugin emulates the iFrame Push mechanism in order to allow control and monitoring of the Alarm partition.

The plugin creates:

  • one Vera device that represents the VAM Panel/Partition.
  • one Vera device for each zone in the Partition that the VAM is configured to.
  • one Vera device for each zone on a zone expansion module that it configured to the partition that the VAM in configured to.
  • four Vera devices for each output (relay) module that is attached to the Vista Alarm Panel.

Features:

  • Automatic Zone and Output device configuration.
  • Arm/Disarm control
  • Virtual Keypad

Installation - from the App Marketplace:

Before you begin, the Vista Automation Module MUST be connected to, and configured for your alarm panel, AND must be connected to your local network.

  1. Download the plugin from the App Marketplace. Once downloaded, the LuaUPnP engine will reload.
  2. Once reloaded, go to the VAM device’s “setup” tab/page and either:
    a) Enter the IP Address of the VAM Module in the “IP Address (Forced)” box, and click set.
    b) Click on the “Detect” button.
  3. Once the plugin has the IP Adress of your VAM, it will connect to it, read the alarm panel configuration and configure Vera devices for the alarm zones and outputs. The appropriate Vera devices (door sensor / smoke sensor / motion sensor, etc) are determined on a best guess basis. The LuaUPnP engine will reload several times during the configuration process.
  4. Once the LuaUPnP engine has finished reloading, go to the “Zones” tab/page. On this page you can change the Name of the zone and the type of sensor that is used in the Vera interface. The “Address/Serial#” and “Channel/Loop” information for the zones is not provided by the VAM Interface, and can safely be left blank. Any changes made to the zone names or sensor type will not take effect until the LuaUPnp engine is reloaded.

Installation - Manual:

  1. Download the attached ZIP file and extract to a temporary directory.

  2. Upload all files to your Vera.

  3. Create the VAM panel device…
    a) go to Apps/Develop Apps/Create Device, and enter the following:
    Device Type: urn:schemas-micasaverde-com:device:VAM_Controller:1
    Description: VAM Controller
    Upnp Device Filename: D_VAM_Controller1.xml
    Upnp Implementation Filename: I_VAM_Controller1.xml

    *** NOTE ***: DO NOT enter a value for “Ip Address” or “MAC”!! Entering values in these fields will prevent the LuaUPnP IO Engine from properly communicating with the VAM.

  4. Configure the plugin by following the instructions under “Installation - from the App Marketplace:” from step #2.

Version History

November 8, 2014: Version 1.1
– fixed - save button for forced IP Address not working

November 7, 2014: Version 1.0
– Initial public release

2

I just bought the EVL3… should I have purchased this module instead?

3

Well this module seems a lot more expensive if that matters. Seems like you get pretty similar functionality, at least from the Vera.

4

This PlugIn is a great addition!!
I have just installed the 1.0 release from the Apps store. After configurating (IP, Inst/UserCodes) the plugin is functional to Arm/Disam etc but is NOT able to retrieve the Zone and Output definition.

The VAM itself picks up the Zone definition just fine from the VistaPnl as evidenced by all the ZonesDescriptors being listed as triggers when you go:
in the VAM itself > Automation> Scenes:

  • Create a dummy scene

  • Under Triggers: select Zone

  • the entire collection of Zones is listed by Names … if you have your “Zone Descriptors” defined under Menu Mode *82 in the PNL.

  • How can I troubleshoot the Zone/Output definition interface issue?

(The AutoUpdate flag from the App store is greyed out and I don’t know how to drop newer files into unit without Samba file Sce and the direct command link does nothing http://:3480/data_request?id=update_plugin&Plugin=7396) ???

5

The plugin gets the zone and output definitions from the VAM device. The VAM device (both security and automation) can only see zones in the partition that it is configured to monitor. The VAM “zonelist” includes system devices and special zones (long range radio, console devices, zone expanders, panic zones, RF button) that can not be used by the plugin. Basically, any zone greater than 48 is ignored. The zonelist provided by the VAM only provided the zone name (as programmed in the alarm panel) and current state.

Once the zonelist is parsed, the plugin populates the zone and output tabs.

As the VAM can NOT be used to program the alarm panel, the zone and output tabs will not allow additions or removals (the VAM does not provided status updates when the alarm panels in in programming mode). They are there to allow customizing the zone zone name and sensor type that are used for the Vera device.

Once a valid zonelist is retreived from the VAM, the plugin creates the vera devices for the reported zones. Failure to get a zonelist from the VAM is not a fatal error, as long as it has previously received a zonelist (as the zone update data is still received from the VAM).

The direct command link does nothing because the v1.0 is the only version currently in the app marketplace…

To upload plugin files to the vera, navigate to Apps/Develop Apps and click on “luup files”. This gives an interface that will allow you to upload the files and restart the LuaUPnP engine.

So… to troubleshoot your issue…
Download the v1.1 zip file from the first post in this thread to your computer and extract the files.
Navigate to the plugins setup tab and click on debug to enable debug mode.
Open a seperate browser and navigate to: http://[veraip]/cgi-bin/cmh/log.sh?Device=LuaUPnP (this browser will show the debug mode output)
In your initial browser, Navigate to Apps/Develop Apps and click on luup files. Make sure that the “restart luup after upload” box is checked.
Upload the files you extracted to your vera. Once the upload is complete, vera will restart.

Now, just the vera restart itself may solve the problem (as the plugin only tries to load the zonelist on startup)… If the plugin is able to get the zonelist from the VAM, it will create the Vera devices - causing the LuaUPnP engine to restart multiple times. this is normal behavior. The second browser will show the debug output… (Note that, although most errors in the log are displayed in red, some of the non-error debug output from the plugin is displayed in red for debugging purposes.)

If, after the debug procedure, you still do not have zones, check the debug output to see what is going on… If needed, copy the output of the debug browser to a text file and attach it to a message here so I can out what is going on.

6

Thank you for all the pointers. This I/F functionality is very promissing. I now know how to upload updated PlugIn files so I am runing 1.1 posted at the top!

To make a long story short about the troubleshooting outcome… no joy just yet:

  • the zone enumeration through the VAM to the Panel loops all the zones just fine
  • the problem is the parsing logic is broken above Zone48 
 48: <<<<<<<<<<<<<< Good parsing match from Z1 to Z48!
    sensor: 1
    zoneNo: 48
    device: 0
    zoneChannel:
    name: Zn-48
    status: none
    zoneAddress:
    device_filename: D_DoorSensor1.xml
    id: VAM_zone_48
    device_type: urn:schemas-micasaverde-com:device:DoorSensor:1

49: <<<<<<<<<<<<<< Broken parsing !
    no: 49
    status: none
    desc: KEYFOB GARAGE DOOR

  50: <<<<<<<<<<<<<< Broken parsing !
    no: 50
    status: none
    desc: LIGHT OUTSIDE DOWN

.... same thing all the way to Zn64.

Regarding the Vista20P zone definition as seen from the VAM:
These panels have usefull input zones all the way up to Zone64. Above Zn64 are system hooks to report/monitor the status of panel Extensions (Expander, LRR, Consoles, AUI etc) that can mostly be ignored/droped by the parsing logic when processing.

Zone49 to Zn64 can be BR(Button Keyfob RF) OR setup as any general inputs type (#2:AW,#3:RF,#4:UR,#5:BR) .
Zone01 to Zn48 can be general inputs OR “BR” input types.
ie “Zone 01 to Zn64 can be setup as any input type besides what the panel defaults are”.
Keyfob input zones are just as good to process as any other input: can be “garage door request”, can be “light request” not just used for “Arm/Disarm/Away” etc…

I guess you could just query or add a setup variable to capture what panel your dealing with ie. process the panel “X-many” zone definition based on panel type: Vista15, Vista20 etc… or quit parsing when you reach “upper limit” =(X+1)…

Is there anything I can do to help ya??
Thank you.

7

FYI: in the Apps store, your nice :stuck_out_tongue: PlugIn is not located under the “Alarm System Control” categorie… may be you should move it there next time you post a refresh…

8

[quote=“ElGringoCurioso, post:6, topic:184006”]Regarding the Vista20P zone definition as seen from the VAM:
These panels have usefull input zones all the way up to Zone64. Above Zn64 are system hooks to report/monitor the status of panel Extensions (Expander, LRR, Consoles, AUI etc) that can mostly be ignored/droped by the parsing logic when processing.[/quote]

[quote=“ElGringoCurioso, post:6, topic:184006”]Zone49 to Zn64 can be BR(Button Keyfob RF) OR setup as any general inputs type (#2:AW,#3:RF,#4:UR,#5:BR) .
Zone01 to Zn48 can be general inputs OR “BR” input types.
ie “Zone 01 to Zn64 can be setup as any input type besides what the panel defaults are”.
Keyfob input zones are just as good to process as any other input: can be “garage door request”, can be “light request” not just used for “Arm/Disarm/Away” etc…[/quote]

Incorrect. Zone 49 through 64 as considered by the panel to be RF Button zones… They can only be programmed as type #3, #4, and #5. Zone expanders (Inpute Type #2 - AW) can only be programmed to zones 9 through 48, and although they appear as devices 107 through 111, on the VAM their zones are indistinguishable from hardwired or RF zones.

Any zones programmed as button RF (Input Type #5) are NEVER reported to the consoles… and the VAM is just a glorified console… you can press the buttons on the keyfob until they wear out and you will never see the button state changes in the console datastream. Yes, you can get the buttons to report by programming them as type #3 or #4, but these zones will not work correctly (can be tripped by pressing the button, but will never restore).

So… Since Keyfobs are supposed to be programmed as zones 49 to 64… and button zones are never reported… zones 49 to 64 are ignored.

… Did the pruglin create the devices for zones 1 to 48? Is it reporting zone status?

9
Did the PlugIn create the devices for zones 1 to 48? Is it reporting zone status?
Nop! Nothing gets populated during or after the initial setup phase. I can see the plugin looping multiple times through all the zones definitions from the LuaUPnP.log (that tells me the pincodes are correct and the VAM interface is functional) but the Zone and Output definitions remain 100% blank. That is why I tried to understand by looking at the activity log what could be broken... I guessed "parsing logic" issue?
Since Keyfobs are supposed to be programmed as zones 49 to 64... and button zones are never reported... zones 49 to 64 are ignored.
That is where you are making a wrong assumption.... Indeed [b]Button inputs are reported and acted upon by the panel[/b], NOT ignored!.
Zone 49 through 64 are considered by the panel to be RF Button zones... They can only be programmed as type #3, #4, and #5. Zone expanders (Inpute Type #2 - AW) can only be programmed to zones 9 through 48, and although they appear as devices 107 through 111, on the VAM their zones are indistinguishable from hardwired or RF zones.

Yes I can see your point about processing vs. not processing zone definition above Zn48. You’re saying: “BR’s are above Zn48 and because I ignore BR’s, I ignore anything above Zn48”.

The scope of your PlugIn Inputs is a very interesting topic that should be addressed well by your design.

Ultimately we can agree that a good PlugIn should to be 100% compliant with Ademco PNL/VAM implementations, right?

Any zones programmed as button RF (Input Type #5) are NEVER reported to the consoles... and the VAM is just a glorified console.... you can [b]press the buttons on the keyfob until they wear out and you will never see the button state changes[/b] in the console datastream. Yes, you can get the buttons to report by programming them as type #3 or #4, but these zones will not work correctly (can be tripped by pressing the button, but will never restore).

Okay simple: let’s do a test to validate the VAM can see and act upon BR Zones Inputs:

  • V20P Panel has Zn59 setup as: Input_Type=5(“BR”) and Zone_Type=23(“No Alarm Response”)
  • In the VAM under Automation> Scenes create a scene such as:
    • Trigger = Zones: for “Outdoor Lights” Zn59 on “Fault” condition
    • Action01 = Light: select: a zWave light, select: “ON FOR TIME”= 5Mn
      (- Action02 = Email as an option to send youreself a message as well)
    • Save all settings for this scene.
  • Test: Trigger the VAM Scene actions wiht the Keyfob button… bingo lights turn ON for 5mn + email message!!
    So that tells me the VAM can act upon any inputs Zn01…Zn64 as intended, right?

I have been using 3 zones from two of my Keyfobs to control Outdoor_Lights and Garage_Door… it’s worked well for the past 8 years and is a very handy panel control.

So what we are dealing with is:
Input Type: tells the panel WHAT is driving the Input (PanelWiredZn, ExpandZn, RFZn etc…)
Zone Type: tells the panel HOW to react to the Input (Alarm, Fault, Restore…)

Furthermore above the “real” Zn01/64 devices the VAM exposes “virtual” devices to monitor the status of the panel extensions (Wire Expander, LRR, AUI’s, Keypads, RF Receiver…) - Such that when the Wire Expender goes missing you get an Alarm if the Panel is Armed (else you get a Fault) or if the LRR, RF Receiver goes missing you get a Fault report.
The panel extension devices are monitored because they talk to the panel to drive its inputs. (Ex: if the RF Receiver is gone you won’t get any RF Motion or Door contacts).

Case in point: I believe these inputs triggers should not be filtered out (ignored) when you create your PlugIn list of Inputs.

Why or what made you decide to cut short the input list at Zone48?

I need all Zn01-64 inputs zones to comes through your PlugIn into VERA to drive zWave outputs (not so much monitor panel extensions tampering as it does that very well by itself).

After all the Ademco-Vera integration is all about:

  • Add zWave outputs to Ademco panels
  • Drive the “House Mode” status in Vera
  • (Exposes the panel Outputs for Vera to drive them?)

I hope all this can help make things better. It’s not easy to get a good desing before coding.
Thank you. :slight_smile:

10

[quote=“ElGringoCurioso, post:9, topic:184006”]

Did the PlugIn create the devices for zones 1 to 48? Is it reporting zone status?

Nop! Nothing gets populated during or after the initial setup phase. I can see the plugin looping multiple times through all the zones definitions from the LuaUPnP.log (that tells me the pincodes are correct and the VAM interface is functional) but the Zone and Output definitions remain 100% blank.
That is why I tried to understand by looking at the activity log what could be broken… I guessed “parsing logic” issue?[/quote]

Maybe you should post the logs so I can see whats going on…

[quote=“ElGringoCurioso, post:9, topic:184006”]Okay simple: let’s do a test to validate the VAM can see and act upon BR Zones Inputs:

  • V20P Panel has Zn59 setup as: Input_Type=5(“BR”) and Zone_Type=23(“No Alarm Response”)
  • In the VAM under Automation> Scenes create a scene such as:
    • Trigger = Zones: for “Outdoor Lights” Zn59 on “Fault” condition
    • Action01 = Light: select: a zWave light, select: “ON FOR TIME”= 5Mn
      (- Action02 = Email as an option to send youreself a message as well)
    • Save all settings for this scene.
  • Test: Trigger the VAM Scene actions wiht the Keyfob button… bingo lights turn ON for 5mn + email message!!
    So that tells me the VAM can act upon any inputs Zn01…Zn64 as intended, right?

I have been using 3 zones from two of my Keyfobs to control Outdoor_Lights and Garage_Door… it’s worked well for the past 8 years and is a very handy panel control.[/quote]

And here is where you start making assumptions…

You assume that, since the Alarm Panel CAN and will respond to keyfob buttons, and the automation controller in the VAM will perform actions based on the buttons, the information is passed along by the VAM to it’s web interface…

It is NOT… The VAM, internally, has three interfaces to the panel via the ECP bus:

  1. console interface
  2. AUI interface
  3. RIS interface

The total number of interfaces that the VAM exposes in it’s “web” interface is one and a half - the console interface with additional messages for zWave controller/device status changes.

So… If you have the panel configured to turn on a zWave controlled light when you press a keyfob button, the VAM will send a notification that the lighting device has changed state, but not what caused the change of state. Was it a button?? maybe… Was it someone manually turning on the light?? maybe… but the VAM only notifies that the device was turned on.

[quote=“ElGringoCurioso, post:9, topic:184006”]So what we are dealing with is:
Input Type: tells the panel WHAT is driving the Input (PanelWiredZn, ExpandZn, RFZn etc…)
Zone Type: tells the panel HOW to react to the Input (Alarm, Fault, Restore…)

Furthermore above the “real” Zn01/64 devices the VAM exposes “virtual” devices to monitor the status of the panel extensions (Wire Expander, LRR, AUI’s, Keypads, RF Receiver…) - Such that when the Wire Expender goes missing you get an Alarm if the Panel is Armed (else you get a Fault) or if the LRR, RF Receiver goes missing you get a Fault report.
The panel extension devices are monitored because they talk to the panel to drive its inputs. (Ex: if the RF Receiver is gone you won’t get any RF Motion or Door contacts).[/quote]

And this information is communicated via the “web” interface as “CHECK” and “TROUBLE” messages in the console interface, and are handled by the plugin.

If these zones are not filtered, you end up with up to 38 devices (if all the zones and expansion modules are configured) on your Vera that provide no usable functionality or information. (16 unusable zones + 8 consoles + 4 auis + 5 zone expanders + 3 virtual zones + 1 RFR + 1 LRR).

As previously stated, these device are unusable because the VAM interface does not provide status for, or control of, these devices.

Sorry… not going to happen… not possible to do with the information provided by the VAM/Tuxedo interface.

[quote=“ElGringoCurioso, post:9, topic:184006”]After all the Ademco-Vera integration is all about:

  • Add zWave outputs to Ademco panels
  • Drive the “House Mode” status in Vera
  • (Exposes the panel Outputs for Vera to drive them?)[/quote]

Adding zWave outputs to the Ademco panels is what the VAM/Tuxedo is supposed to do… The plugin is to allow control of the arm/disarm state and to allow vera to respond to zone state changes… The plugin does that…

The “House Modes” status is new to UI7… UI7 is not, according to the general consensus on the forums, ready for “production” use… There is a plugin that MCV published that ties “House Mode” to scenes and triggers… I am having enough trouble keeping up with the bugs introduced in newer UI7 that I won’t be looking into “house Modes” for a while yet.

The VAM (and the EVL3) Plugin(s) do expose the outputs to Vera for control…

[quote=“ElGringoCurioso, post:9, topic:184006”]I hope all this can help make things better. It’s not easy to get a good desing before coding.
Thank you. :)[/quote]

There is no documentation for the “web” interface or for the “System HTTP API”… The HTTP API doesn’t even provide basic functions like bypass or disarm!! So the “web” interface is the only link to the VAM/Tuxedo… And it had to be reverse engineered from the JavaScript implementation and shoehorned into something that would work with the LuaUPnP IO model…

I believe that I have done a good job on the plugin(s) despite having to work around the limitations of the hardware provided by Honeywell.

11
There is no documentation for the "web" interface or for the "System HTTP API"... The HTTP API doesn't even provide basic functions like bypass or disarm!! So the "web" interface is the only link to the VAM/Tuxedo... And it had to be reverse engineered from the JavaScript implementation and shoehorned into something that would work with the LuaUPnP IO model...

I believe that I have done a good job on the plugin(s) despite having to work around the limitations of the hardware provided by Honeywell.


Oh yes indeed your implementation is amazing. It is a huge accomplishment to get all thoses Hw pieces to even interface despite non existent or limited OEM docs. Hat’s off - Here here!!!

Here is some debug output from log mix…

  58:
    no: 58
    status: none
    desc: L <0x2dfce680>
50      11/14/14 23:02:32.005   luup_log:15: (VAM_Controller::VAM_processStateMachine) Not processing VAM State Machine. client [] part [] panel [] <0x2dfce680>
02      11/14/14 23:02:32.006   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [<!--]. <0x2dfce680>
50      11/14/14 23:02:32.007   luup_log:15: (VAM_Controller::VAM_processIncoming) Completed. RECYCLE COUNT [0]. <0x2dfce680>
02      11/14/14 23:02:32.010   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [--><script>ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:-1:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);</script>]. <0x2dfce680>
50      11/14/14 23:02:32.011   luup_log:15: (VAM_Controller::VAM_processIncoming) found cmdData [ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:-1:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);]. <0x2dfce680>
50      11/14/14 23:02:32.012   luup_log:15: (VAM_Controller::VAM_resetConnectionTimer) Resetting connection timer - last [1416034951] now [1416034952] diff [1]. <0x2dfce680>
02      11/14/14 23:02:32.019   luup_log:15: (VAM_Controller::VAM_processIncoming) Ignoring message not intended for our sessionId. <0x2dfce680>
02      11/14/14 23:02:32.020   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [<!--]. <0x2dfce680>
50      11/14/14 23:02:32.020   luup_log:15: (VAM_Controller::VAM_processIncoming) Completed. RECYCLE COUNT [0]. <0x2dfce680>
02      11/14/14 23:02:32.023   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [--><script>ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:-1:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);</script>]. <0x2dfce680>
50      11/14/14 23:02:32.024   luup_log:15: (VAM_Controller::VAM_processIncoming) found cmdData [ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:-1:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);]. <0x2dfce680>
02      11/14/14 23:02:32.026   luup_log:15: (VAM_Controller::VAM_processIncoming) Ignoring message not intended for our sessionId. <0x2dfce680>
02      11/14/14 23:02:32.026   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [<!--]. <0x2dfce680>
50      11/14/14 23:02:32.027   luup_log:15: (VAM_Controller::VAM_processIncoming) Completed. RECYCLE COUNT [0]. <0x2dfce680>
02      11/14/14 23:02:32.030   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [--><script>ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:-1:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);</script>]. <0x2dfce680>
50      11/14/14 23:02:32.031   luup_log:15: (VAM_Controller::VAM_processIncoming) found cmdData [ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:-1:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);]. <0x2dfce680>
02      11/14/14 23:02:32.032   luup_log:15: (VAM_Controller::VAM_processIncoming) Ignoring message not intended for our sessionId. <0x2dfce680>
02      11/14/14 23:02:32.033   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [<!--]. <0x2dfce680>
50      11/14/14 23:02:32.033   luup_log:15: (VAM_Controller::VAM_processIncoming) Completed. RECYCLE COUNT [0]. <0x2dfce680>
02      11/14/14 23:02:32.630   ZW_Send_Data node 2 NO ROUTE (nil) <0x2b77d680>
06      11/14/14 23:02:32.759   Device_Variable::m_szValue_set device: 11 service: urn:upnp-org:serviceId:HVAC_FanOperatingMode1 variable: Mode was: Auto now: Auto #hooks: 0 upnp: 0 v:0xd8cd68/NONE duplicate:1 <0x2b37d680>
02      11/14/14 23:02:34.761   ZW_Send_Data node 2 NO ROUTE (nil) <0x2b77d680>
02      11/14/14 23:02:36.890   ZW_Send_Data node 2 NO ROUTE (nil) <0x2b77d680>
04      11/14/14 23:02:37.130   <Job ID="4" Name="pollnode #2 7 cmds" Device="11" Created="2014-11-14 23:02:24" Started="2014-11-14 23:02:24" Completed="2014-11-14 23:02:37" Duration="13.28941000" Runtime="13.28137000" Status="Successful" LastNote="" Node="2" NodeType="ZWaveThermostat" NodeDescription="Trane Stat"/> <0x2b37d680>
02      11/14/14 23:02:39.102   ZZZ-POLLING H1,C1,H2,C2,/1/1 <0x2b77d680>
02      11/14/14 23:02:39.103   ZW_Send_Data node 2 NO ROUTE (nil) <0x2b77d680>
02      11/14/14 23:02:41.240   ZW_Send_Data node 2 NO ROUTE (nil) <0x2b77d680>
06      11/14/14 23:02:41.379   Device_Variable::m_szValue_set device: 11 service: urn:upnp-org:serviceId:TemperatureSensor1 variable: CurrentTemperature was: 69 now: 69 #hooks: 0 upnp: 0 v:0xdb3dd8/NONE duplicate:1 <0x2b37d680>
02      11/14/14 23:02:41.827   luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [--><script>ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:20:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);</script>]. <0x2dfce680>
50      11/14/14 23:02:41.828   luup_log:15: (VAM_Controller::VAM_processIncoming) found cmdData [ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["0:20:2\u0020DISARMED\u0020CHIME\u0020|\u0020\u0020Ready\u0020to\u0020Arm\u0020\u0020"],177);]. <0x2dfce680>
50      11/14/14 23:02:41.828   luup_log:15: (VAM_Controller::VAM_resetConnectionTimer) Resetting connection timer - last [1416034952] now [1416034961] diff [9]. <0x2dfce680>
50      11/14/14 23:02:41.831   luup_log:15: (VAM_Controller::VAM_processIncoming) found ifr.sSend data[1: ud
2: SimpleDbgServer2ClientIntf
3: statusMessageText
4: 0:20:2 DISARMED CHIME |  Ready to Arm
5: 177
]. <0x2dfce680>
50      11/14/14 23:02:41.832   luup_log:15: (VAM_Controller::ifr_sSend) processing data. <0x2dfce680>
02      11/14/14 23:02:41.832   luup_log:15: (VAM_Controller::ifr_sSend) processing SimleDbgServer message. <0x2dfce680>
50      11/14/14 23:02:41.832   luup_log:15: (VAM_Controller::ifr_sSend) processing statusMessageText message. <0x2dfce680>
50      11/14/14 23:02:41.832   luup_log:15: (VAM_Controller::ifr_sSend::ifr_statusMessageText) Processing Status Message Text data [0:20:2 DISARMED CHIME |  Ready to Arm  ]. <0x2dfce680>
50      11/14/14 23:02:41.833   luup_log:15: (VAM_Controller::ifr_sSend::ifr_statusMessageText) Processing BROADCAST status data. <0x2dfce680>
50      11/14/14 23:02:41.834   luup_log:15: (VAM_Controller::ifr_sSend::ifr_statusMessageText) Processing SERV_CONSOLE_MSG_BROADCAST (cmd=20) data. <0x2dfce680>
50      11/14/14 23:02:41.834   luup_log:15: (VAM_Controller::ifr_showConsoleText) Processing console text [2 DISARMED CHIME |  Ready to Arm  ]. <0x2dfce680>
50      11/14/14 23:02:41.835   luup_log:15: (VAM_Controller::ifr_showConsoleText) Console removedCss [ DISARMED CHIME |  Ready to Arm  ]. <0x2dfce680>
50      11/14/14 23:02:41.891   luup_log:15: (VAM_Controller::VAM_processIncoming) VAM_STATE [
ClientNo: 2
HomePartition: 0
Devices:
  100:
    no: 100
    status: none
    desc: RF RECEIVER

  101:
    no: 101
    status: none
    desc: GRAPHIC CONSOLE

Log about zn enumeration and parsing:

.....

4:
sensor: 1
zoneNo: 4
device: 0
zoneChannel:
name: GARAGE DOOR OPEN
status: none
zoneAddress:
device_filename: D_DoorSensor1.xml
id: VAM_zone_4
device_type: urn:schemas-micasaverde-com:device:DoorSensor:1

5:
sensor: 1
zoneNo: 5
device: 0
zoneChannel:
name: BACK WINDOW OPEN
status: none
zoneAddress:
device_filename: D_DoorSensor1.xml
id: VAM_zone_5
device_type: urn:schemas-micasaverde-com:device:DoorSensor:1

.....
 46:    <<<<<<<<< Is keyfob BR input type
    sensor: 1
    zoneNo: 46
    device: 0
    zoneChannel:
    name: Zn-46
    status: none
    zoneAddress:
    device_filename: D_DoorSensor1.xml
    id: VAM_zone_46
    device_type: urn:schemas-micasaverde-com:device:DoorSensor:1

  47:    <<<<<<<<< Is keyfob BR input type for sure
    sensor: 1
    zoneNo: 47
    device: 0
    zoneChannel:
    name: Zn-47
    status: none
    zoneAddress:
    device_filename: D_DoorSensor1.xml
    id: VAM_zone_47
    device_type: urn:schemas-micasaverde-com:device:DoorSensor:1


last_topBarStatus_time: 1416034909
VAM_SESSION_COOKIE: z9ZAqJtI=ffbcb89e546689d7; path=/; remote=FALSE
Buttons:
  49:    <<<<<<<<< Is keyfob BR input type
    no: 49
    status: none
    desc: KEYFOB GARAGE DOOR

  50:    <<<<<<<<< Is keyfob BR input type

......

 56:
    no: 56
    status: none
    desc: Zn-56

  57:
    no: 57
    status: none
    desc: KEYFOB GARAGE DOOR

  count: 12
  59:
    no: 59
    status: none
    desc: LIGHT OUTSIDE UP

  60:
    no: 60
    status: none
    desc: KEYFOB RF ZONE 60

  58:
    no: 58
    status: none
    desc: L <0x2dfce680>

......

  100:
    no: 100
    status: none
    desc: RF RECEIVER

  101:
    no: 101
    status: none
    desc: GRAPHIC CONSOLE

.......

The Zone and output definitions are still not populating… (with or without: EnabledAutoDetect, ***Chime ***/no chime)
Remembering our chat about imposed limitations around BR’s and Zn48 cut-off, perhaps the parsing problem is because some of my BR’s are below Zn49 ?? (my keyfobs each have 2 RF loops = 8 zones, No problem with Ademco or VAM).

Quote from: ElGringoCurioso on Today at 01:23:11 pm

Case in point: I believe these inputs triggers should not be filtered out (ignored) when you create your PlugIn list of Inputs.

If these zones are not filtered, you end up with up to 38 devices (if all the zones and expansion modules are configured) on your Vera that provide no usable functionality or information. (16 unusable zones + 8 consoles + 4 auis + 5 zone expanders + 3 virtual zones + 1 RFR + 1 LRR).

Quote from: ElGringoCurioso on Today at 01:23:11 pm

Why or what made you decide to cut short the input list at Zone48?

As previously stated, these device are unusable because the VAM interface does not provide status for, or control of, these devices.


So what I understand is:
The VAM FW “V6.1.13” can work with Zn01/64 and You are able to retrieve the whole list of panel devices but VAM does not expose well Zn48/Zn64 to interface input status above Zn48, right?

Tx

12

Can we gain root login on those bad boys to go look at the panel I/F code??

I looked at the VAM " http Api"… it’s 50% implemented and definitely not to be a panel gateway but more as an intranet VAM management for zWave devices, camera etc… nothing panel related is exposed.

The other safe bet is it’s better to disable “remote update” to preserve current path ways then risk ending up with https on the receiving side of the bridge!

13
Quote from: ElGringoCurioso on November 14, 2014, 01:23:11 pm

I need all Zn01-64 inputs zones to comes through your PlugIn into VERA to drive zWave outputs (not so much monitor panel extensions tampering as it does that very well by itself).

Sorry… not going to happen… not possible to do with the information provided by the VAM/Tuxedo interface.

Yes now I get your point regarding the Zn limitation!

  • Your plugin is emulating a web client connected to the VAM to read the console data stream output from the VAM to its web client.

  • The VAM itself is connected to the panel as an AUI virtual console to display panel activities.

It is currently impossible to read/pick-up Keyfob Zn activations because the keyfob activation does not show anything on the VAM client screen… or even a hardwired physical keypad for that mater.
In other words: “if we can’t read it on the console: we can’t get it!”.

On the hope side: there may be ways to twist that problem around to get “a console display”…
?- Add those zones to the “chime by Zn List” ?
?- Change to an available “Zn Type” that reports better ?
?- Create a “custom Zn definition” for Keyfob buttons of interest ? (2 locals, 2 from Compass)
?- other Vista wizard idea anyone???

At this point I am guessing the Keyfob Zn were specifically designed not to report on the console (?pulse too short?)… let’s try to bump that limitation: Zn Type copy cat with some salt!

14

[quote=“ElGringoCurioso, post:11, topic:184006”]The Zone and output definitions are still not populating… (with or without: EnabledAutoDetect, ***Chime ***/no chime)
Remembering our chat about imposed limitations around BR’s and Zn48 cut-off, perhaps the parsing problem is because some of my BR’s are below Zn49 ?? (my keyfobs each have 2 RF loops = 8 zones, No problem with Ademco or VAM).[/quote]

No… The BR zones will have no effect… The VAM does not expose any information regarding zone type… only that it is a zone and that it has a name and the current status of the zone.

[quote=“ElGringoCurioso, post:11, topic:184006”]So what I understand is:
The VAM FW “V6.1.13” can work with Zn01/64 and You are able to retrieve the whole list of panel devices but VAM does not expose well Zn48/Zn64 to interface input status above Zn48, right?[/quote]

The VAM exposes all zones that are in the partition for which it is configured (IE: you have Zn1, Zn2, Zn3 configured for partition 1 and Zn4, Zn5, Zn6 confiured in partition 2 - the VAM is configured for Partition 1 - The VAM will only show Zn1, Zn2 and Zn3) plus all virtual zones (Zn 90 to Zn99) plus all consoles, expanders and modules (indicated as Zn100 to Zn123). It will report zone status for all zones Zn1 to Zn64 (Technically, you can put any RF sensor in Zn49 to Zn64, and it will report the status, but that it outside of the Alarm Panel specifications and may cause undesirable side effects), but will not report status for any zone configured as type BR.

So… Looking over the logs…
The Vera is connecting to the VAM…
The VAM is providing the zone list to Vera…
The VAM is providing status updates to the Vera…

So, other than the zones… all looks good…

The logs you provided do not show the plugin startup though, and zone/device configuration is only done during startup…

Can you get the logs for the LuaUPnP engine startup (immediately after a reload)… (on UI7, easiest way to reset is to upload the “L_VAM_Controller1.lua” file again…)

Ideally, the lines from :

“(VAM_Controller::VAM_postConnect3) Sending Retrieve Partition List command.”

to either

“(VAM_Controller::configurePanelDevices): Success: Panel Configuration completed.”
or
“(VAM_Controller::configurePanelDevices): Configuration Failed: No zones defined.”

15

The “Remote Update” feature should be disabled by default… but if you have enabled it, probably best to disable it…

But Honeywell is not known for frequent updates, and to date there has not been a public update to the VAM… V6.1.13 is the initial release (it actually looks like they forked the codebase from the TUXWIFI after V4.3.32 and renamed it… the TUXWIFI is on V5.1.13.0 which added voice activation, and VAM6.1.13 has references to voice in it)

[quote=“ElGringoCurioso, post:13, topic:184006”]Yes now I get your point regarding the Zn limitation!

  • Your plugin is emulating a web client connected to the VAM to read the console data stream output from the VAM to its web client.

  • The VAM itself is connected to the panel as an AUI virtual console to display panel activities.

It is currently impossible to read/pick-up Keyfob Zn activations because the keyfob activation does not show anything on the VAM client screen… or even a hardwired physical keypad for that mater.
In other words: “if we can’t read it on the console: we can’t get it!”.[/quote]

That is correct.

[quote=“ElGringoCurioso, post:13, topic:184006”]On the hope side: there may be ways to twist that problem around to get “a console display”…
?- Add those zones to the “chime by Zn List” ?[/quote]
That may provide a console message that can be used…

[quote=“ElGringoCurioso, post:13, topic:184006”]?- Change to an available “Zn Type” that reports better ?
?- Create a “custom Zn definition” for Keyfob buttons of interest ? (2 locals, 2 from Compass)[/quote]

Changing the zone type will not affect it… If the input type is BR, there are no console messages… If you change the input type, the Alarm Panel malfunctions.

16

So you’re saying the root of “silent-keyfob issue” is not the Zn Type, it’s the Input Type… then that could be the last screw!
The only work around would be to use some VAM scene to act upon keyfob to perhaps togle MultipleSwitch buttons??

Now testing different keyfob InputType and ZnType…

  • no joy with BR and a Custom ZnType 90! I can get the button to chime but it just will not Display. ::slight_smile:

  • so the BR Input Type must be the limitation here…

then got to try some of my keyfob buttons set as UR type with a custom Zn90 set for: Faults only + Display + Chime

I’ll have to see how the other keyfob buttons user-assignment tolerates the BR/UR mixing ???
I am hopping the UR buttons will display as any unsupervised wireless devices (?)

17

[quote=“cybrmage, post:14, topic:184006”]The logs you provided do not show the plugin startup though, and zone/device configuration is only done during startup…

Can you get the logs for the LuaUPnP engine startup (immediately after a reload)… (on UI7, easiest way to reset is to upload the “L_VAM_Controller1.lua” file again…)

Ideally, the lines from :

“(VAM_Controller::VAM_postConnect3) Sending Retrieve Partition List command.”

to either

“(VAM_Controller::configurePanelDevices): Success: Panel Configuration completed.”
or
“(VAM_Controller::configurePanelDevices): Configuration Failed: No zones defined.”[/quote]

I think I captured what you’re looking for:

02      11/17/14 1:47:29.101    luup_log:15: (VAM_Controller::VAM_postConnect) Performing Post connection configuration. __LEAK__ this:540672 start:794624 to 0xb39000 <0x2c886680>
02      11/17/14 1:47:29.101    luup_log:15: (VAM_Controller::VAM_postConnect) Getting Zone List. <0x2c886680>
50      11/17/14 1:47:31.473    luup_log:15: (VAM_Controller::VAM_postConnect) Retrieved zone list from VAM. zlist [1:
02      11/17/14 1:47:31.693    luup_log:15: (VAM_Controller::VAM_postConnect) Processed zone list. VAM_STATE.Zones [2:
02      11/17/14 1:47:31.694    luup_log:15: (VAM_Controller::VAM_postConnect) Completed. <0x2c886680>
02      11/17/14 1:47:32.102    luup_log:15: (VAM_Controller::VAM_postConnect1) Initializing async panel data stream. <0x2c886680>
02      11/17/14 1:47:34.101    luup_log:15: (VAM_Controller::VAM_postConnect2) Setting Console Mode. <0x2c886680>
02      11/17/14 1:47:34.167    luup_log:15: (VAM_Controller::VAM_postConnect2) Set Console Mode. <0x2c886680>
02      11/17/14 1:47:35.100    luup_log:15: (VAM_Controller::VAM_postConnect3) Sending Retrieve Partition List command. __LEAK__ this:118784 start:1499136 to 0xbe5000 <0x2c886680>
02      11/17/14 1:47:35.140    luup_log:15: (VAM_Controller::VAM_postConnect3) GET_PART_LIST code [200] status [OK] body [<html><body>End Of Response</body></html>].  <0x2c886680>
02      11/17/14 1:47:36.103    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:37.101    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:38.102    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:39.101    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:40.102    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:41.102    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:42.101    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:43.100    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:44.100    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:45.101    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:46.100    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:47.101    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:48.101    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
02      11/17/14 1:47:49.100    luup_log:15: (VAM_Controller::VAM_postConnect4) Waiting for Partition table. <0x2c886680>
01      11/17/14 1:47:50.100    luup_log:15: (VAM_Controller::VAM_postConnect4) Failed to retreive Partition table. <0x2c886680>

These lines looked interesting:
02 luup_log:15: (VAM_Controller::VAM_postConnect3) GET_PART_LIST code [200] status [OK] body [End Of Response]. <0x2c886680>
01 luup_log:15: (VAM_Controller::VAM_postConnect4) Failed to retreive Partition table.

There is a lot of that:

2: SimpleDbgServer2ClientIntf
3: statusMessageText
4: 0:55:3_Gar:0:192.168.2.73:1:2
5: 122
]. <0x2e5d0680>
50      11/17/14 2:22:02.712    luup_log:15: (VAM_Controller::ifr_sSend) processing data. <0x2e5d0680>
02      11/17/14 2:22:02.712    luup_log:15: (VAM_Controller::ifr_sSend) processing SimleDbgServer message. <0x2e5d0680>
50      11/17/14 2:22:02.712    luup_log:15: (VAM_Controller::ifr_sSend) processing statusMessageText message. <0x2e5d0680>
50      11/17/14 2:22:02.712    luup_log:15: (VAM_Controller::ifr_sSend::ifr_statusMessageText) Processing Status Message Text data [0:55:3_Gar:0:192.168.2.73:1:2]. <0x2e5d0680>
50      11/17/14 2:22:02.713    luup_log:15: (VAM_Controller::ifr_sSend::ifr_statusMessageText) Processing BROADCAST status data. <0x2e5d0680>
50      11/17/14 2:22:02.713    luup_log:15: (VAM_Controller::ifr_sSend::ifr_statusMessageText) received camera configuration status message. <0x2e5d0680>
50      11/17/14 2:22:02.714    luup_log:15: (VAM_Controller::VAM_processIncoming) Completed.  RECYCLE COUNT [0]. <0x2e5d0680>
50      11/17/14 2:22:02.714    luup_log:15: (VAM_Controller::VAM_processStateMachine) Not processing VAM State Machine. client [] part [] panel [] <0x2e5d0680>
02      11/17/14 2:22:02.715    luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [<!--]. <0x2e5d0680>
50      11/17/14 2:22:02.715    luup_log:15: (VAM_Controller::VAM_processIncoming) Completed. RECYCLE COUNT [0]. <0x2e5d0680>
02      11/17/14 2:22:02.718    luup_log:15: (VAM_Controller::VAM_processIncoming) Processing incoming data [--><script>ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["2:Other:OTHER:.:.:snapshot.cgi?user=guest:0"],136);</script>]. <0x2e5d0680>
50      11/17/14 2:22:02.718    luup_log:15: (VAM_Controller::VAM_processIncoming) found cmdData [ifr.sSend('ud','SimpleDbgServer2ClientIntf','statusMessageText',["2:Other:OTHER:.:.:snapshot.cgi?user=guest:0"],136);]. <0x2e5d0680>
50      11/17/14 2:22:02.720    luup_log:15: (VAM_Controller::VAM_processIncoming) found ifr.sSend data[1: ud

Even though the debug log shows the Zone list was retrieved Vera does not show it…

Thank you.

18

Here is an update on further experiments:

[quote=“ElGringoCurioso, post:16, topic:184006”]So you’re saying the root of “silent-keyfob issue” is not the Zn Type, it’s the Input Type… then that could be the last screw!
The only work around would be to use some VAM scene to act upon keyfob to perhaps togle MultipleSwitch buttons??

Now testing different keyfob InputType and Custom ZnType…

  • no joy with BR and ZnType 90! The buttons CAN chime but just will NOT Display. ::slight_smile:

  • so the BR Input Type must be the limitation here… (>>> yes it is!)

then got to try some of my keyfob buttons set as UR type with a custom Zn90 set for: Faults only + Display + Chime

I’ll have to see how the other keyfob buttons user-assignment tolerates the BR/UR mixing ??? (>>> No problem!)
I am hopping the UR buttons will display as any unsupervised wireless devices (?) (>>> yes they do!)[/quote]

So did further testing with PNL configs Custom ZoneType_90 + InputTypes:

I tried to fool the panel with Keyfob InputType set as UR instead of BR:

  • With UR: the Zone fault displays just fine BUT does not restore (stays Faulted: display never clears) :cry:
  • With BR: the Zone does not display BUT auto-restores AND Chimes okay :cry:

This is regardless of custom ZoneType fields: :wink:

  • “AutoRestore”: (0 or 4, tried both ways)
  • “Display Faults”: (0 or 1, tried both ways)

This logic is 100% normal/to be expected… at least now I know more about the limitations & possibilities. 8)

Workarounds:

  • Quickest NO Vera: Trigger keyfob scenes directly on the VAM. As tested: the VAM intimate connection with the panel has no limitation to trigger on keyfob zone type 23. :stuck_out_tongue:

  • Long way WITH Vera: use the keyfob to trigger a relay to drive a wired Zone input… that will be shown on the console display and the PlugIn should capture activities.

Done with this one ;D

19

For your information: here is my 1st VAM bug encounter… ::slight_smile:

It is all about the VAM firmware, not the PlugIn interface.

In the VAM under Scenes definition, when you select a “Security” trigger as “NIGHT” it is 100% equal to “STAY”. So a PNL status = “Stay” will trigger “Night” scenes!!

Workaround: Forget about using Security = “Night” triggers in VAM scene definitions. :-X

20

when I download the plug in I used force ip and added the ip address and click set and i received this “No implementation” so then Itried to autodetect ip and it finds the wrong ip address it finds my honewell wifi thermostat. Any Suggestions???