Release version 3.0.2.1

[Daweeze]

Yep - there are no issues with doing that. It will remove the HSPI_HAI.exe plugin file.

Awesome..thx!!

-T

[lakemirror]

Rob - the "any user except" parameter in events does not seem to be working in the current release. I rebuilt the events from scratch and still no joy. Could you check that for me?

Thanks.

[rmasonjr]

Rob - the "any user except" parameter in events does not seem to be working in the current release. I rebuilt the events from scratch and still no joy. Could you check that for me?

Thanks.

Yep - adding it to the list...

[Pete]

Went looking this morning at the Omni system status and it appeared frozen to yesterday.

IE: battery for example remained at zero.

I disabled the plugin and re enabled it and saw this in the logs.

I also disabled the plugin and enabled it again disabling logging and the logging was turned on after I started.

Aug-16 4:45:38 PM Info Plugin OMNI has connected. IP:127.0.0.1:41678
Aug-16 4:45:38 PM Warning Attempt by plugin to register a duplicate link of Logs. Plugin: OMNI Instance:
Aug-16 4:45:54 PM Info Plugin OMNI with instance: has disconnected
Aug-16 4:46:11 PM Warning I/O interface OMNI is down, executable is not running, restarting ...
Aug-16 4:46:11 PM Info Plugin OMNI has connected. IP:127.0.0.1:41698
Aug-16 4:46:11 PM Warning Attempt by plugin to register a duplicate link of Logs. Plugin: OMNI Instance:
Aug-16 4:46:26 PM Info Plugin OMNI with instance: has disconnected

[ATTACH]62803[/ATTACH]

Looking at the Log directory via SSH...there is nothing there...

/HomeSeer/Logs# ls
Previous_Startup.log Startup.log
root@ICS-HS3ZeeLite:/HomeSeer/Logs#

Gonna look at backup....

Shows configuration as:
debugFile=Logs/hai.log

copied old hai.log file over to /Logs/hai.log

re-enabled the plugin...

Aug-16 5:03:46 PM Plug-In Finished initializing plug-in OMNI
Aug-16 5:03:49 PM OMNI -->Reading configuration...

no errors this time.

[ATTACH]62804[/ATTACH]

This is what the system omni variables look like.

[ATTACH]62805[/ATTACH]

Opened the front door and the variable did not change.

Apologies. I just did the above purge and install from scratch yesterday, enabled it and didn't look until today.

I am at HomeSeer Version: HS3 ZEE S2 Edition 3.0.0.349 (Linux) as of last week sometime...

ran the plugin long math wise so I could see the console...and see..

mono HSPI_OMNI.exe
OMNI Plugin v3.0.2.1
Connecting to HomeSeer at 127.0.0.1:10400
Connected to HS.
could not purge log file.
8/16/2017 5:45:52 PM---->Reading configuration...
8/16/2017 5:46:37 PM---->Reading properties...
8/16/2017 5:46:37 PM--All configuration and properties retrieved.
8/16/2017 5:46:37 PM--Requesting Area status...
8/16/2017 5:46:38 PM--Requesting Output status...
8/16/2017 5:46:41 PM--Requesting initial system troubles
8/16/2017 5:46:41 PM--Synchronizing OMNI devices with HomeSeer...
8/16/2017 5:46:52 PM--Synchronization complete.
8/16/2017 5:46:52 PM-----------------------------
8/16/2017 5:46:52 PM--Plugin startup is complete.
8/16/2017 5:46:52 PM-----------------------------

Still no variables are changing from yesterday...opened a door and watched console...nothing changed....never seen this before...

[rmasonjr]

Thanks Pete - I see what caused it. Will address it asap.

For now, disable the plugin, then restart HS.
Re-enable the plugin after HS is back up.

[Pete]

Thank you Rob.

I disabled it. Shutdown HS. Rebooted box. SSH'd to Homeseer directory. Ran the plugin manually in the console and it stopped as shown above in post number 64.

[Pete]

Enabled debug and ran the plugin via a terminal console this morning. A bit more data is seen now.

/HomeSeer# mono HSPI_OMNI.exe
OMNI Plugin v3.0.2.1
Connecting to HomeSeer at 127.0.0.1:10400
Connected to HS.
could not purge log file.
8/17/2017 8:32:48 AM--OMNI Plugin Thread was started.
8/17/2017 8:32:48 AM--Initializing Timers...
8/17/2017 8:32:49 AM--Device initialization is complete.
8/17/2017 8:32:49 AM--HAC Connection state is: Offline
8/17/2017 8:32:49 AM--Connecting with: [192.168.244.182] [4369] [UDP]
8/17/2017 8:32:49 AM--CONNECTION STATUS: Connecting
8/17/2017 8:32:49 AM--Panel Connected.
8/17/2017 8:32:49 AM--Identifying Controller...
8/17/2017 8:32:49 AM--CONTROLLER IS: OmniPro II (4.0B)
8/17/2017 8:32:50 AM---->Reading configuration...
8/17/2017 8:34:01 AM---->Reading properties...
8/17/2017 8:34:02 AM--All configuration and properties retrieved.
8/17/2017 8:34:02 AM--Requesting Area status...
8/17/2017 8:34:03 AM--Requesting Output status...
8/17/2017 8:34:03 AM-----RequestOutputStatus. colOutputs=8
8/17/2017 8:34:06 AM--Requesting initial system troubles
8/17/2017 8:34:06 AM--Synchronizing OMNI devices with HomeSeer...
8/17/2017 8:34:18 AM--Synchronization complete.
8/17/2017 8:34:18 AM-----------------------------
8/17/2017 8:34:18 AM--Plugin startup is complete.
8/17/2017 8:34:18 AM-----------------------------*

* stops here with no further updating

Looking at the HS3 logs see this:

Aug-17 8:13:07 AM Info Plugin OMNI has connected. IP:127.0.0.1:49582
Aug-17 8:13:08 AM Warning Attempt by plugin to register a duplicate link of Logs. Plugin: OMNI Instance:
Aug-17 8:13:12 AM OMNI -->Reading configuration...
Aug-17 8:13:56 AM OMNI -->Reading properties...
Aug-17 8:13:56 AM OMNI All configuration and properties retrieved.
Aug-17 8:13:56 AM OMNI Requesting Area status...
Aug-17 8:13:56 AM OMNI Requesting Output status...
Aug-17 8:14:00 AM OMNI Requesting initial system troubles
Aug-17 8:14:00 AM OMNI Synchronizing OMNI devices with HomeSeer...
Aug-17 8:14:12 AM OMNI Synchronization complete.
Aug-17 8:14:12 AM OMNI ---------------------------
Aug-17 8:14:12 AM OMNI Plugin startup is complete.
Aug-17 8:14:12 AM OMNI ---------------------------
Aug-17 8:15:34 AM Info Plugin OMNI with instance: has disconnected
Aug-17 8:18:31 AM Info Plugin OMNI has connected. IP:127.0.0.1:49590
Aug-17 8:18:31 AM Warning Attempt by plugin to register a duplicate link of Logs. Plugin: OMNI Instance:
Aug-17 8:18:36 AM OMNI -->Reading configuration...
Aug-17 8:19:47 AM OMNI -->Reading properties...
Aug-17 8:19:47 AM OMNI All configuration and properties retrieved.
Aug-17 8:19:47 AM OMNI Requesting Area status...
Aug-17 8:19:48 AM OMNI Requesting Output status...
Aug-17 8:19:52 AM OMNI Requesting initial system troubles
Aug-17 8:19:52 AM OMNI Synchronizing OMNI devices with HomeSeer...
Aug-17 8:20:03 AM OMNI Synchronization complete.
Aug-17 8:20:03 AM OMNI ---------------------------
Aug-17 8:20:03 AM OMNI Plugin startup is complete.
Aug-17 8:20:03 AM OMNI --------------------------- *

* no further Omni dialog is seen in the HS logs.

Looking at the GUI see this on the remote section:

[ATTACH]62811[/ATTACH]

and this on the top section:

[ATTACH]62812[/ATTACH]

An attempt to register the remote license see this:

[ATTACH]62813[/ATTACH]

For time bean have disabled the plugin.

I might restore the Homeseer directory today to the point before I purged the HAI files.

I had registered the plugin before doing the purge and it was working.

It was showing both the HAI and OMNI plugin in the management page.

[Pete]

OK so backed up current HomeSeer V.349.

Restored backup directory of HomeSeer V.342 and last version of HAI Plugin.

Booting up and going to the management page it shows:

[ATTACH]62816[/ATTACH]

Homeseer logs show:

Aug-17 9:36:53 AM Info Plugin OMNI has connected. IP:127.0.0.1:48078
Aug-17 9:36:53 AM Warning Attempt by plugin to register a duplicate link of Logs. Plugin: OMNI Instance:
Aug-17 9:36:55 AM Plug-In Finished initializing plug-in OMNI

Enabled debug. Disabled OmniPlugin. Enabled Omni plugin.

Debug and console output switches keep going to off when I enabled them.

Looking at the Omni System variables only see the battery has been updated to today.

The connection, freeze, ac, phone, communicator, codes, bell, fuse, dcm are all showing old status dates.

Tested the front door zone and it updated to today when I opened and closed it.

HAI temperature and humidity sensors all updated and are current.

Thermostat 1 variables have not changed to current settings.

Units variables are updating.

All of the variables are showing OMNI rather than HAI.

I'll leave it enabled to see if the above mentioned not updating variables update. (will also enable and disable alarm to see if anything changes).

None of the Omni System variables changed when I enabled the alarm.

A side note here is that I reconfigured my NextAlarm CS dashboard to text me with picked test zones doors status (live). All of the rest of the notifications are working fine via a live watch to my Next Alarm dashboard. (alarm off and on, live zone changes, et al) and well also still running HAILogger which is really chatty kathy.

[rmasonjr]

Thanks Pete - that message about registering duplicate links is likely what is causing it. I'm looking at it now...

[Pete]

Thank you Rob.

[Daweeze]

Thanks Pete for your constant testing of all of the System based devices. I actually kind of count on you to identify the issues there with the OMNI system devices as I don't really test my panel and don't have time to tinker with stuff like I want to. I really do appreciate the effort that you and Rob are putting into this PI.

-Travis

[rmasonjr]

yep - thanks guys!

[rmasonjr]

Alarm Area Mode - When an external source changes the mode of the alarm system, the HS3 Device changes appropriately. When you use the Device List drop down (Assuming all zones are secure), it works as expected. However when a zone is "Not Ready" and you use Arm the system using the HS3 Device method, the status changes to whatever you tried to set the alarm to in HS3 but it remains disarmed on the actual panel because of the zone issue. Concerns here are that a system could appear to be armed in HS3 when the system is actually disarmed. Also, my announcements and Push Messages are sent based on an invalid actual system state. I expect this would not be noticed if someone uses the auto-bypass mode for zones that are "Not Ready" when arming. Can this be fixed or should there be another device called something like "System Status" as a Status Device that is a representation of what the OMNI Panel is reporting so it is accurate, leaving the drop-down as a Control item only?

Travis
I have something I've been testing that might help in this scenario. I have created a system-wide "Auto Bypass" zones much like PC Access. When you arm and area, and you have "Auto Bypass" set to "Yes", the plugin will indeed arm the system and auto-bypass any zones that are not ready. So far, this is working well in testing.

Let me know if this sounds like something that will work for you. I want your feedback before I release this version.

Thanks

[Daweeze]

Travis
I have something I've been testing that might help in this scenario. I have created a system-wide "Auto Bypass" zones much like PC Access. When you arm and area, and you have "Auto Bypass" set to "Yes", the plugin will indeed arm the system and auto-bypass any zones that are not ready. So far, this is working well in testing.

Let me know if this sounds like something that will work for you. I want your feedback before I release this version.

Thanks

Hi Rob,

Allowing to system to Auto-Bypass is in my case a Work-Around for my issue. The way I look at it, it looks like this:

Auto-Bypass is the perfect solution for a user that wants to leave a 2nd story window open to cool down the upstairs at night, knowing that forced entry into that window is a condition they are willing accept, but also knowing that the rest of the system is secure. What they might not know is that the window downstairs is left open unintentionally and that they have bypassed that as well. We rely on the keypad text or app zone information to tell us that. That isn't something that you normally check when arming your house remotely. Now, given the power of automation or the HS3 engine, we can stop that from happening with announcements, qualifying checks of devices before arming etc.

I think adding the Auto-Bypass is a great function for exactly the scenario above given we can designate zones that can be auto-bypassed and zones that cannot. That said, I don't feel it necessarily fixes the problem that HS3 thinks it has armed the house when it actually is disarmed. Auto-Bypass assumes that you know which zones are opened and that "non-secure" nature is expected and intentional.

Happy to help, test or comment on whatever you need.

Thanks as always,

-Travis

[rmasonjr]

Hi Rob,

Allowing to system to Auto-Bypass is in my case a Work-Around for my issue. The way I look at it, it looks like this:

Auto-Bypass is the perfect solution for a user that wants to leave a 2nd story window open to cool down the upstairs at night, knowing that forced entry into that window is a condition they are willing accept, but also knowing that the rest of the system is secure. What they might not know is that the window downstairs is left open unintentionally and that they have bypassed that as well. We rely on the keypad text or app zone information to tell us that. That isn't something that you normally check when arming your house remotely. Now, given the power of automation or the HS3 engine, we can stop that from happening with announcements, qualifying checks of devices before arming etc.

I think adding the Auto-Bypass is a great function for exactly the scenario above given we can designate zones that can be auto-bypassed and zones that cannot. That said, I don't feel it necessarily fixes the problem that HS3 thinks it has armed the house when it actually is disarmed. Auto-Bypass assumes that you know which zones are opened and that "non-secure" nature is expected and intentional.

Happy to help, test or comment on whatever you need.

Thanks as always,

-Travis

I was able to fix the issue where HS showed 'armed' and the panel showed 'disarm' so in this scenario, you should be good. When selecting 'No' for AutoBypass and you arm the system, it will now show armed if it was successful.