Odd Behavior with OMNI Battery Device

[garciacg]

Hi Rob, I'be been noticing the battery voltage device in the plugin on my OMNI Pro II drop from 13.68V to zero for awhile. I've double-checked with PC Dealer Access 3.0 and with a volt meter and the battery voltage is fine. Stopping and starting the Plugin would restore it back to 13.68V.

Today I've had time to tinker with it, so I added an event to HS3 to send me a PushOver message when the battery device changes to zero. About an hour later, I picked up the telephone to make a call and I immediately received the PushOver message that the Battery had gone to zero. I reset the plugin again and took the phone off hook....and voila I received another battery device message. So it would appear that something is amiss. PC Dealer Access says it's fine as does the volt meter, so I'm thinking something in the plugin?

As I was tracking this down, I reviewed the MySQL logs that the plugin is generating. In so doing, I discovered another anomaly. I am seeing CODE 1 DISARM events being logged for one of my Areas (named CARRIAGE) every time the phone goes on and off hook. And the eventMsg references the last time I disarmed that area. Please see attached PDF. This behavior goes all the way back to December 2017 when I changed the plugin from HAI to OMNI. I checked the prior logs when it was HAI and this behavior didn't exist. I am currently on OMNI v3.0.2.12

The OMNI Pro II is not showing any signs of having a problem and its interaction with HS3 is fine except for the Battery going to zero. Any thoughts?

[lakemirror]

I just duplicated part of your scenario. I had noticed my battery reading being 0 v and never really thought much about it. I just disabled and reloaded the plugin and the battery is back to 13.32 v. I'm not home so I can't work on tracking down what's causing this but I will check it out tonight.

[Pete]

Tested the off hook and on hook stuff and see this in the debug logs

6/13/2018 4:51:06 PM [2] [3/25 1:14 PM - PHONE LINE DEAD TROUBLE CLEARED nam=[]]
6/13/2018 4:51:06 PM [2] [EventLog=[PHONE LINE DEAD TROUBLE CLEARED]]
6/13/2018 4:51:06 PM [2] [UNSOLICITED: SystemEvents]
6/13/2018 4:50:59 PM [2] [3/25 1:14 PM - PHONE LINE DEAD TROUBLE CLEARED nam=[]]
6/13/2018 4:50:59 PM [2] [EventLog=[PHONE LINE DEAD TROUBLE CLEARED]]

In the HS2 HAI plugin there was just a general system special status variable and it would show the on hook or off hook status and another system variable for a dead phone.

[garciacg]

Thanks Pete for testing. I see your phone line message from 3/25 as opposed to today. Although I'm not seeing phone line messages, my message (e.g. CODE 1 DISARM) is from another day as well. Will look forward to what Rob has to say.

Thanks,
Craig

[Pete]

Yeah there is a general system trouble variable which shows:

REQUEST SYSTEM TROUBLES

This message is sent by the HAI controller in reply to a REQUEST SYSTEM TROUBLES message. The controller reports any system troubles. If multiple troubles exist, each trouble is reported in a separate data byte.

The system trouble conditions are shown below.

Trouble Byte

1 - Condition
2 - Freeze
3 - Battery low
4 - AC power
5 - Phone line
6 - Digital communicator
7 - Fuse
8 - Freeze
9 - Battery low

The trouble variable and status is different than the individual condition variables.

[feobrien]

I see the same 0 for my battery level. I know it is fine, shows fine in PC Access.

[rmasonjr]

I had another user report that the system troubles only being populated at startup. In PC Access, those troubles are updated in a loop when that screen is open. I need to modify the plugin to update the system troubles on an interval. I'll start looking into this.

Thanks

[feobrien]

I had another user report that the system troubles only being populated at startup. In PC Access, those troubles are updated in a loop when that screen is open. I need to modify the plugin to update the system troubles on an interval. I'll start looking into this.

Thanks

Thanks - BTW it worked fine at some point, I recall it being populated with the correct value. After some version update it stopped. Perhaps something inadvertently changed.

[garciacg]

I've had the system armed for about a week and early this morning (3am) the panel performed its weekly diagnostic call to the alarm company. The battery voltage immediately went to 0 and stayed until I reset the plugin. I'm also seeing Last Change times for the ac, dcm, freeze, fuse and phone devices in the plugin changing at the same time throughout the day for no apparent reason. The only things in the log occurring at those times are entries that match those when I armed the system a week ago.

As Rob suggested, sounds like an issue with the system troubles updates. Until this is fixed, I'll be sure not to created any events that rely on these.