20SE plug-in configuration?

[madigan]

I've purchased and been playing with the AD2USB and Ademco Vista plug-in, and now I think it would be best to completely remove the plug-in and re-install it, properly configured, before I start worrying about some perceived weirdnesses with my setup.

I have a Vista 20SE panel with a 4219 wired zone expander module, a SA5882-2L 8 zone RF Receiver, and 5804 & 5804BD wireless keys, among other devices. The panel is programmed with everything on partition 1.

I'm using FTDI Driver version 2.8.8.0 on COM2 with the AD2USB V2; Firmware ademcoemu_V1_0f_26; Keypad address 31; Code 0. The plug-in version is v1.2.3.0.

I think part of my initial problem was configuring the plug-in for a 20P, instead of a 20 (it would be helpful to have a selection for the 20SE to eliminate confusion).

Since only have a single partition, I'm confused as to what the plug-in settings should be. Right now, for partition settings, I show:
Partition 1 address - disabled
Partition DC - 18
Chime DC - --
User Code - blank
Yet I'm still able to use the plug-in to arm and disarm the system with the System Status device. For awhile I had some kind of partition device that seemed to duplicate the System Status device, but I might have deleted it, thinking it was a duplicate.

What should the appropriate partition settings for a single partition system be? For a 20SE should the partition address be set to 31? Is the "user code" for the partition the same as the "master code" I used setting up the plug-in, or should I be using something different?

Another thing I'm confused about is that some of the devices created seem to have inappropriate controls - should heat, smoke and CO devices have "bypass" control buttons?

Also, when trying to set up my RF keys, it seems that I first had to set up a zone for each keypad button, then set up an RF device for each keypad button. I wound up with two devices for each keypad button - a zone device with a bypass control, and an RF device under a different code number, that doesn't have a bypass control and never seems to show that the keypad button was pressed.

What's the best way to uninstall this, delete any current configuration, and start over?

Thanks
Jim Madigan

[mnsandler]

Jim,


I think you are close, so starting over may not be necessary, except for the deleted partition device, that can be recreated once you config Partition 1 (see below)

I think part of my initial problem was configuring the plug-in for a 20P, instead of a 20 (it would be helpful to have a selection for the 20SE to eliminate confusion).

I'll see what i can do about adding a 20se select. but for now the 20 is the correct selection.

Yet I'm still able to use the plug-in to arm and disarm the system with the System Status device. For awhile I had some kind of partition device that seemed to duplicate the System Status device, but I might have deleted it, thinking it was a duplicate.

don't delete the partition device, just use the hs hide device feature if you don't need it.

What should the appropriate partition settings for a single partition system be? For a 20SE should the partition address be set to 31? Is the "user code" for the partition the same as the "master code" I used setting up the plug-in, or should I be using something different?

Yes Address 31 and use the same code as the master code

Another thing I'm confused about is that some of the devices created seem to have inappropriate controls - should heat, smoke and CO devices have "bypass" control buttons?

I don't distinguish different physical devices in the plugin, they all get the same setup.

Also, when trying to set up my RF keys, it seems that I first had to set up a zone for each keypad button, then set up an RF device for each keypad button. I wound up with two devices for each keypad button - a zone device with a bypass control, and an RF device under a different code number, that doesn't have a bypass control and never seems to show that the keypad button was pressed.

Lets save the RF stuff till after you get the basic stuff running first.

What's the best way to uninstall this, delete any current configuration, and start over?

You should be able to uninstall the plugin via the control panel. The only other thing would be to delete the config\vistaalarm.ini

[madigan]

Thanks! That helps a lot - I'll play with it this afternoon and see what happens.

Jim Madigan

[madigan]

The good news -
I configured the partition, and the partition device and a partition chime device are back - both the system status and partition 1 status devices seem to arm/disarm and indicate status correctly.

But, I seem to have 4 fouled up zones - when I start monitoring I get:

12/12/2010 1:00:05 PM Vista Alarm Error adding zone 10 to Zones collection
12/12/2010 1:00:05 PM Vista Alarm Error: System.InvalidCastException: Conversion from string "" to type 'Short' is not valid. ---> System.FormatException: Input string was not in a correct format. at Microsoft.VisualBasic.CompilerServices.Conversions.ParseDoub le(String Value, NumberFormatInfo NumberFormat) at Microsoft.VisualBasic.CompilerServices.Conversions.ToShort(S tring Value) --- End of inner exception stack trace --- at Microsoft.VisualBasic.CompilerServices.Conversions.ToShort(S tring Value) at Microsoft.VisualBasic.CompilerServices.Conversions.ToShort(O bject Value) at HSPI_VISTAALARM.VistaAlarm.ZonesCollection.GetZoneDevices() [1.2.3.0]

for each of the affected 4 zones, and if I try to go into one of the devices and then save it (without making any changes), I get:

12/12/2010 1:04:45 PM Vista Alarm Error: System.NullReferenceException: Object reference not set to an instance of an object. at HSPI_VISTAALARM.HSPI.ConfigDevicePost(clsPair[]& Pairs, String& DState, DeviceClass& dv) [1.2.3.0]

I know that I did something yesterday to those 4 device, but I can't remember exactly what - I think that I might have edited their names, like from the originally created "Smoke Detector" to "Bedroom Smoke Detector".

I don't know if I should delete those 4 problem devices and try to recreate them, or just delete everything and start over.

I'm also seeing in the log:

12/12/2010 1:02:56 PM Vista Alarm ****DISARMED**** READY TO ARM
12/12/2010 1:02:53 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:02:53 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:02:52 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:02:52 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:02:52 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:02:52 PM Vista Alarm Sending Disarm command to alarm
12/12/2010 1:01:51 PM Vista Alarm ARMED ***STAY***You may exit now
12/12/2010 1:01:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:01:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:01:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:01:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:01:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 1:01:47 PM Vista Alarm Sending Arm Stay command to alarm

Don't know if those bad messages are a real problem or not.

One last question - I thought I understood that I was supposed to set up a device for each zone, so I created one for zone 9, which on the 20SE is dedicated to "Expansion Module Supervision". This device always shows up as status "Bypass" - is this right, or should I not have set zone 9 up in the plug-in?

Thanks
Jim Madigan

[madigan]

I think I've fallen through the looking glass...

My previous post had an example of the error message that I got in my log after trying to save one of the devices that caused errors on turning the monitor on. I've since found that that device no longer gives an error.

So I decided to try opening each device in turn for editing, saving it (which did not automatically close the editing page like it normally does), and then clicking "cancel" to exit the editing page. Each time I did this there was an error generated in the log:

12/12/2010 3:51:10 PM Vista Alarm Error: System.NullReferenceException: Object reference not set to an instance of an object. at HSPI_VISTAALARM.HSPI.ConfigDevicePost(clsPair[]& Pairs, String& DState, DeviceClass& dv) [1.2.3.0]

However, when I finally turned the alarm control device back on, the previous errors did not recur.

So... It LOOKS like that procedure fixed the problem... somehow, whatever it was...

Curiouser and curiouser
Jim Madigan

[mnsandler]

Jim
If you are still having problems with any zones causing errors please delete them and recreate.

I'm not sure what is happening there

[mnsandler]

Jim
I don't think you need a zone for the expanded itself especially if it doesn't send regular zone msgs. any msg it does send should be ignored

[madigan]

Almost there...

Well, I decided to restart HS to see if any error messages would come up in the log, and there were none. Even zone 9 which had been stuck in status "Bypass" now shows "Normal".

When I arm and disarm the system, I still see:

12/12/2010 6:31:11 PM Vista Alarm ****DISARMED**** READY TO ARM
12/12/2010 6:31:08 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:31:08 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:31:08 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:31:08 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:31:08 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:31:08 PM Vista Alarm Sending Disarm command to alarm
12/12/2010 6:30:33 PM Vista Alarm ARMED ***STAY***
12/12/2010 6:29:26 PM Vista Alarm ARMED ***STAY***You may exit now
12/12/2010 6:29:22 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:29:22 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:29:22 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:29:22 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:29:22 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:29:21 PM Vista Alarm Sending Arm Stay command to alarm

but the arming and disarming work properly. Enabling debug only shows:

12/12/2010 6:42:51 PM Vista Alarm [100101010000--------],003,[fe000000f003011c08000000000000],"****DISARMED**** READY TO ARM "
12/12/2010 6:42:51 PM Vista Alarm Processing msg on Partition 1
12/12/2010 6:42:51 PM Vista Alarm Setting System to Disarmed-Ready
12/12/2010 6:42:51 PM Vista Alarm Clearing all zones for Ready mode.
12/12/2010 6:42:51 PM Vista Alarm Setting Partition 1 to Disarmed-Ready
12/12/2010 6:42:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:48 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:47 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:47 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:47 PM Vista Alarm Sending [code]+1
12/12/2010 6:42:20 PM Vista Alarm [001103010000--------],003,[fe000000f003038c08000000000000],"ARMED ***STAY***You may exit now"
12/12/2010 6:42:20 PM Vista Alarm Processing msg on Partition 1
12/12/2010 6:42:20 PM Vista Alarm Setting System to Armed Stay
12/12/2010 6:42:20 PM Vista Alarm Setting Partition 1 to Armed Stay
12/12/2010 6:42:18 PM Vista Alarm Skipping bad message: !Sending...done
12/12/2010 6:42:17 PM Vista Alarm Skipping bad message: !Sending..done
12/12/2010 6:42:17 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:17 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:17 PM Vista Alarm Skipping bad message: !Sending.done
12/12/2010 6:42:17 PM Vista Alarm Sending [code]+3


The only other error is upon restarting the monitor after stopping it:

12/12/2010 6:32:51 PM Vista Alarm Error starting monitor
12/12/2010 6:32:51 PM Vista Alarm Found the AD2USB on COM port 2 running firmware version unknown
12/12/2010 6:32:23 PM Vista Alarm Monitor terminated...

but communication seems fine despite the error message. Trying the same thing with debug:

12/12/2010 6:48:10 PM Vista Alarm Error starting monitor
12/12/2010 6:48:10 PM Vista Alarm Found the AD2USB on COM port 2 running firmware version unknown
12/12/2010 6:48:07 PM Vista Alarm Received msg: !Sending.done
12/12/2010 6:48:07 PM Vista Alarm Received msg: !>V1.0f.26,SM
12/12/2010 6:48:07 PM Vista Alarm Sent cmd: V
12/12/2010 6:48:07 PM Vista Alarm Opened COM port 2
12/12/2010 6:47:30 PM Vista Alarm Monitor terminated...
12/12/2010 6:47:30 PM Vista Alarm Closed COM port 2

So maybe plug-in version 1.2.3 doesn't know about the earlier firmware needed for the 20SE?

Jim Madigan

[mnsandler]

Jim,

the following msgs are a bug in v1.2.3. I'll fix this.
Skipping bad message: !Sending.done

I'll have to look at the code to see about the firmware 20se issue you mentioned.

btw, i don't think the 20se ad2usb firmware supports the RFX msgs that you initially mentioned. Sean at nutech.com hasn't added 20se support to the latest firmware. I think there is a request on the nutech forum for this. I suggest you put in your 2 cents.

[madigan]

I just was over at the Nutech board - couldn't find any previous requests for 20SE support in the latest firmware, but I put in my request.

And just in case anyone asks, I've been using their GUI emulator software under 32 bit Windows 7 Pro without problem...

Thanks!
Jim Madigan

[mnsandler]

Jim,

I checked the Version (V) cmd for the firmware for the 20se against later stuff.

your firmware is responding ot the V cmd with
!>V1.0f.26,SM

The newer firmware provide something like the following:
!VER:00000001,V2.1f.0b,TX;RX;SM;VZ;RF

i need to check in with Sean to see if he will update the 20se firmware. It should start with !VER:

In general a given ad2usb firmware supports all vista panels. the only exception is the 20se because of the non-addressable issue with the 20se.

all that said, its not important that the plugin knows what firmware you are running. I'm only looking for some of the 2 letter codes after the firmware.

i think you should be fine for now

[mnsandler]

Jim,
I saw your post (i happened to be subscribed to that thread)

I spoke with Sean about two issues: 1. the Version cmd discussed above and 2. your request - having 20se support added to the latest firmware.

Sean is working on #1 now and will send me a new firmware to test shortly; i'll need your help testing this as well. My V2 ad2usb is connected to a 20p not my 20se. Sean has the 20se support on his list, it just may be a month or two before he can get to it.

[madigan]

Good to hear

Let me know when you have something for me to test - I'm still working with Alarm Relay trying to get the monitoring operating properly, so playing with the system is no big deal.

Thanks
Jim Madigan