Author Topic: Unexpected Tripped Variable Changes  (Read 1423 times)

Offline mssearch

  • Sr. Newbie
  • *
  • Posts: 40
  • Karma: +0/-1
Unexpected Tripped Variable Changes
« on: December 08, 2016, 07:45:35 pm »
Wondering if anyone else has experienced weird issues with unexpected variable changes with this plugin?

I installed EventWatcher to get a feel for what Vera sees (in particular with my motion sensors) and noticed a lot of weird seemingly unnecessary events appearing. Numerous sensors seem to report even if their status hasn't changed...for example in the attached screenshot of EventWatcher you can see Bedroom Sliding Door as tripped and then not then tripped then not. I know for 100% certain that the Bedroom Sliding Door has not been "physically" opened or closed therefore I would expect that it wouldn't be showing up in these logs. Perhaps I have a misunderstanding of what "tripped" actually means or I simply have something wrong with a big batch of my sensors but when I view the zone activity at Eyezon's website, it certainly doesn't reflect what is reported in Vera so I'm leaning towards ruling out faulty sensors.

Another weird issue is if I leave a door or window open such as Dining Room 1 (shown in screenshot) it will bounce back and forth between tripped and not every couple seconds until you close the door. Unless I'm misunderstanding the "Tripped" variable...this issue would seemingly make all of these sensors useless as scene triggers as the constant unexpected reports simply don't match reality.

This leaves me wondering where the flaw is.... EventWatcher? Ademco Plugin? Vera? ....me?

Anyone else have a log full of weird events or that can explain to me what I'm doing wrong?

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: Unexpected Tripped Variable Changes
« Reply #1 on: December 13, 2016, 07:25:20 pm »
I can confirm this as well...

Wondering if anyone else has experienced weird issues with unexpected variable changes with this plugin?

I installed EventWatcher to get a feel for what Vera sees (in particular with my motion sensors) and noticed a lot of weird seemingly unnecessary events appearing. Numerous sensors seem to report even if their status hasn't changed...for example in the attached screenshot of EventWatcher you can see Bedroom Sliding Door as tripped and then not then tripped then not. I know for 100% certain that the Bedroom Sliding Door has not been "physically" opened or closed therefore I would expect that it wouldn't be showing up in these logs. Perhaps I have a misunderstanding of what "tripped" actually means or I simply have something wrong with a big batch of my sensors but when I view the zone activity at Eyezon's website, it certainly doesn't reflect what is reported in Vera so I'm leaning towards ruling out faulty sensors.

Another weird issue is if I leave a door or window open such as Dining Room 1 (shown in screenshot) it will bounce back and forth between tripped and not every couple seconds until you close the door. Unless I'm misunderstanding the "Tripped" variable...this issue would seemingly make all of these sensors useless as scene triggers as the constant unexpected reports simply don't match reality.

This leaves me wondering where the flaw is.... EventWatcher? Ademco Plugin? Vera? ....me?

Anyone else have a log full of weird events or that can explain to me what I'm doing wrong?
openLuup, AltUI, Zway and HomeWave, enough said...

Offline mssearch

  • Sr. Newbie
  • *
  • Posts: 40
  • Karma: +0/-1
Re: Unexpected Tripped Variable Changes
« Reply #2 on: December 13, 2016, 10:41:47 pm »
I can confirm this as well...

Thanks for the confirmation on this @CudaNet. Wondering... do you have any idea if the issue is specific to the plugin? the Envisalink module? or perhaps the Vista Panels / Sensors?

I mainly want to know which component I need to replace... Would be nice if it was an issue with the Envisalink so it could be easily replaced with an AD2USB module and plugin. It would really stink if it was the sensors/panel as I specifically bought all of these just for Vera so that would be an extensive fix.

Do you have any issues running scenes based upon these sensors (i.e. Light on when door opens) or have you bothered to try?

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: Unexpected Tripped Variable Changes
« Reply #3 on: December 14, 2016, 09:41:13 am »
Very difficult to say as I'm not familiar with the plugin source code. Outside of notifications regarding power outage (mains vs ups), alarm (arming/disarming) notifications etc., I don't currently use watches to trigger scenes based on sensors.

I can confirm this as well...

Thanks for the confirmation on this @CudaNet. Wondering... do you have any idea if the issue is specific to the plugin? the Envisalink module? or perhaps the Vista Panels / Sensors?

I mainly want to know which component I need to replace... Would be nice if it was an issue with the Envisalink so it could be easily replaced with an AD2USB module and plugin. It would really stink if it was the sensors/panel as I specifically bought all of these just for Vera so that would be an extensive fix.

Do you have any issues running scenes based upon these sensors (i.e. Light on when door opens) or have you bothered to try?
openLuup, AltUI, Zway and HomeWave, enough said...

Offline mssearch

  • Sr. Newbie
  • *
  • Posts: 40
  • Karma: +0/-1
Re: Unexpected Tripped Variable Changes
« Reply #4 on: May 03, 2017, 05:48:48 pm »
@Cudanet and anyone else experiencing this issue... through a whirlwind of troubleshooting (including spending $140 on an AD2PI Network Kit) I've isolated this issue and wanted to share my findings with anyone else who is having trouble.

It appears that the default behavior for a Keypad is to receive information from all partitions which means that partition 2 will send it's state to the envisalink module as "Disarmed - Ready to Arm" (assuming that it's actually disarmed). I'm guessing that the plugin doesn't know the difference between the messages for the different partitions and as such it sees the "Ready to Arm" message and clears all of the zones until the panel reports the fault once again.

I'm not entirely clear on whether or not I accidentally programmed a second zone when originally configuring my system or if it's just there by default but to fix the issue you simply need to enter programming mode on your keypad and make sure that the particular address that your envisalink is assigned to is set to Partition 1 with no suppression.

For me, this has entirely cleared up the issues with zones alternating between their tripped state. Hopefully this will help someone else!