Announcement

Collapse
No announcement yet.

Vista 128p messages not processed by plugin

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mnsandler
    replied
    thanks for reporting back. let me know if you figure out anything related to the device trigger delay

    Leave a comment:


  • SteveHome
    replied
    Beta 37 looking good

    Mark, I've been running .37 for several weeks - it seems solid and the raft of log messages (Sending GOTO, Display fault etc.) are gone with the addition of the "DisplayShowFaults=True" setting.

    I have some unexplained (and inconsistent) long delays in recognizing a zone change - for example, a change in a wireless gate or door sensor usually is recognized by the plugin quite quickly (1 or 2 seconds), but it can sometimes take 20-30 seconds. But I've seen this in other (non-Vista) device triggers, so I don't think it's your issue.

    Many thanks,

    S

    Leave a comment:


  • mnsandler
    replied
    steve,
    curious if you have tried .37

    Leave a comment:


  • mnsandler
    replied
    ok. please try the following and report back

    add the following to the [general] section of the vistaalarm.ini

    DisableShowFaults=True
    then install .37 from the beta section, and retest

    this should prevent all the Goto sequences

    Leave a comment:


  • mnsandler
    replied
    Originally posted by SteveHome View Post
    My 128 doesn't display "Hit * to display faults". When a partition has faults, the message is (for partition1):
    so I think this is a little different from other 128s.

    so I think I to add a switch so you can disable the GOTO partition transactions you are seeing now.

    Leave a comment:


  • SteveHome
    replied
    Thanks - I'll check the current at the PS to make sure it's within range. I agree that the poor performance isn't an issue for HS or the Plugin :-)

    My 128 doesn't display "Hit * to display faults". When a partition has faults, the message is (for partition1):

    P1 DISARMED
    ZONES FAULTED

    Then it slowly scrolls through the faulted zones:

    FAULT 044 GARAGE TILT DOOR
    (etc.)

    and then returns to the DISARMED/ZONES FAULTED message.

    If a zone is in check, the message is

    P1 DISARMED
    ZONES IN CHECK

    again followed by a scrolling list of zones not ready.
    Note that the zone in check is displayed as Faulted

    I don't have a clue whether Honeywell changed their firmware on the 128 (my panel is new), or if this is generic to all 128s.

    Leave a comment:


  • mnsandler
    replied
    Steve,

    1. the plugin appears to be tracking the status of zone 42 correctly from Check to Fault.

    I had an RF sensor go bad; it would report Check intermittently. I replaced it.

    2. its expected for the keypads to beep based on cmds sent from the plugin. The goto cmds might cause this. its normal. having custom addresses for the plugin is fine.

    3. the plugin isn't going to do all this to list zones in check; but typically they zones in check are just listed.

    4. Zone 42 will report Check again soon.


    1. Do you see the "Hit * to display faults" on any keypads? this is what the Goto seq is supposed to be responding to.

    2. not sure why your system is responding so slowly; you will need to research this outside this forum. do you need additional power to support the keypads?
    Last edited by mnsandler; December 5th, 2017, 07:49 AM.

    Leave a comment:


  • SteveHome
    replied
    I won't be able to set the system into the desired state (two partitions disarmed and ready, the other one we're working on) right away.
    In the meantime, here are a couple of things of interest:

    1. To answer your "zone in check" question, I went to work on the physical P3 keypad. As previously reported, our system is VERY sluggish. To make a long story short, I couldn't bypass zones, bypass ALL zones, log in to another partition, or do almost any other command from that keypad unless I waited a full second between each key press - waiting a half second didn't to the trick. More importantly, assuming the system recognized the code entered as the first four keypresses, it can be dangerous for a subsequent keypress to be missed, because then a subsequent keypress that does make it through to the panel can be misinterpreted. That's happened to me on a physical keypad, and I think it's possible that it happened from the plugin.

    2. The reason I think that the plugin has sometimes had this issue is
    a) As previously discussed in this thread, you advised me to set the plugin partition keypad addresses to correspond to physical keypads for the respective partitions.
    b) When I did so, we would occasionally get beeps or chimes from the physical keypad when we weren't doing anything physical, and weren't asking the plugin to bypass, arm/disarm, and so forth.
    c) **So I changed the plugin partition addressing to give it a dedicated virtual address on the bus for each partition: 18 is the "master" keypad (from which the plugin issues commands), 19/20/21 are the dedicated keypads (with dedicated single-partition codes) for P1/P2/P3 respectively.

    3. Getting the system to report what zone is in check. This isn't a trivial process (and the issue above makes it less trivial). During this testing, zone 042 was the one in check.
    a) At the start of the process, doing a zone review on a partition with one or more zones in check will (at least sometimes) report that zone as faulted, not as in check.
    b) Bypass everything (code + 6 + #). Only worked for me at a snails pace of keypresses.
    c) Panel will display the bypassed zones (including 042, the one in check) as bypassed.
    d) It is then necessary to ARM the partition (I armed for "away").
    e) Then, disarm the partition - this is the way to remove bypasses.
    This step doesn't seem to work unless the partition is armed,
    f) At this point, the system will scroll through zones that aren't closed/ready
    Zone 42 showed up once as "Check" in this process, then went back to "Fault"

    I've attached a log of this period with annotations so you don't have to search manually for the P3 activities.

    4. during subsequent testing (repeating the above process but trying to bypass, then disarm without arming first), the following occurred:
    a. P3 started out showing "disarmed, zone in check"
    b. I did a global bypass (code + 6 + #)
    c. Instead of seeing "Ready to arm, zones bypassed), I saw
    "Vista 128 System Reset". After that, P3 showed as ready to arm with no checks, and later as disarmed with zone 46 faulted. Did 42 "heal" itself? It's RF...

    It does seem a little less sluggish after the reset.

    Best,
    Attached Files

    Leave a comment:


  • mnsandler
    replied
    Steve,

    Your 128 is acting a little different than other 128s i've seen. so i think i need to make a change to support this new behavior.

    the plugin is having trouble with the following message.
    "P3 DISARMED ZONES IN CHECK"

    the plugin thinks it needs to send a * to P3 to get the panel to display the zones in check

    however, the * cmd isn't affecting the panel, and nothing is being logged related to the specific zone in check. so the cycle continues.

    what do you need to do at a keypad to display zones in check?

    for future logs and testing. lets keep two partitions in disarm-ready and work with any one partition for now. this will simple the analysis and testing

    ps i don't need the ad2usb log dumps
    Last edited by mnsandler; December 4th, 2017, 03:04 PM. Reason: ps i don't need the ad2usb log dumps

    Leave a comment:


  • SteveHome
    replied
    I've attached two dumps - one of the plugin logs with debug enabled and de-dup disabled,
    one of the AD2USB raw output when the system was in the same state.

    I notice that the plugin is confused about what partition is in what state.
    During the testing,
    P1 was disarmed, zones faulted
    P2 was armed, Stay1
    P3 was disarmed, zones in check

    The plugin LOGS show the following keypad messages
    P1 is armed, stay 1 (the actual state of P2)
    P2
    P3 is disarmed, zones in check (the acdtual state of P3)

    But interestingly enough, the actual plugin seems to be correctly reporting the status of
    P2 (armed stay1)
    P1 and P3 are both shown as disarmed/faulted
    (technically P3 is disarmed, zones in check but I suspect that's not a status you report)

    As noted in the logs, I haven't tried to analyze anything but the text of the messages...

    BTW, I've purchased a license - things are going well enough that I have confidence that the rest will get ironed out soon. Great Plugin!
    Attached Files

    Leave a comment:


  • mnsandler
    replied
    Steve,
    can you post a short log snippet of the ad2usb messages inline along with the responses from the plugin. i need to see partition 1 vs partition 3 logs so i can determine which ad2usb msgs are triggering the Goto messages.

    for the Vista40, I had to add some code to change the plugin default behavior. we may have to do the same for 128.

    Leave a comment:


  • SteveHome
    replied
    I seem to have the system working (or at least I haven't noticed any recent mysteries). I can arm/disarm partitions, bypass zones, and status seems to be accurate (although it takes a while for a zone going into fault to trigger a HS action, even when it's a RF zone). I'm getting a lot of messages in the log; I have suppressed duplicate messages. Here's a few seconds worth:

    Dec-03 5:42:12 PM Vista Alarm Sending Display Faults command to alarm
    Dec-03 5:42:08 PM Vista Alarm Sending Goto Partition 3 command to alarm
    Dec-03 5:42:08 PM Vista Alarm Sending Goto Partition 0 command to alarm
    Dec-03 5:42:05 PM Vista Alarm Sending Display Faults command to alarm
    Dec-03 5:42:01 PM Vista Alarm Sending Goto Partition 3 command to alarm
    Dec-03 5:42:01 PM Vista Alarm Sending Goto Partition 0 command to alarm
    Dec-03 5:41:58 PM Vista Alarm Sending Display Faults command to alarm

    Partition 2 is ready, partitions 1 and 3 have faults.
    I don't see that partition 1 (aka partition 0?) is asking for a display of faulted zones. But in any event, I have this sequence every 5-10 seconds. Is that normal?

    Thanks.

    Leave a comment:


  • mnsandler
    replied
    steve
    i already got you covered. the default delay is 2 secs

    you can customize it using an ini setting. shutdown the plugin, add the following to your vistaalarm.ini, and restart

    [AD2USB]
    WaitBetweenCmds=3

    Leave a comment:


  • SteveHome
    replied
    It's clear that the 128p isn't the best designed piece of hardware. There's a big shield over the processor, which suggests it would cause RF interference otherwise. It's widely used, but it doesn't look like they actually engineered it with faster or more robust processing, just upgraded addressing and made other firmware tweaks. The slow response (and dropping fast keystrokes) isn't very user friendly.

    The testing I'm doing is using the plug-in's arm/disarm commands. Sounds like the default delay that you set for the 128 isn't enough in my case. One option is increasing that delay for all 128 users; another might be adding a config option below the panel type for "keystroke delay" (in ms). But before that happens, let me set up a couple of events that do the same thing, both to try to figure out how much delay is needed, and to make sure there are no other issues in the woodwork.

    Thanks a lot,

    Leave a comment:


  • mnsandler
    replied
    yah, I had to build in a small delay into the commercial panels Vista 40, 50, 128, etc

    Switching partitions isn't graceful but it works.

    its strange because on the 20p no delay is necessary, I can just send all the cmds immediately and it works

    there was a AD2USB command (K) to do this all in one seq but its wasn't reliable. it would attempt to send the cmd to the correct partition without having to use the GOTO.

    typically when you run these actions from events you wont care about a few seconds delay

    Leave a comment:

Working...
X