HAI Event Driven polling

[Brian Raynor]

Rick,

This is specifically addressed to you. I know that HAI does not provide an event driven interface where events (door open/close, etc) will automatically send a message over OmniLink and that a lot of this stuff needs to be polled which dramatically affects the performance of the plugin.

That being said, I was wondering if, through the use of programs in the Omni, there might be a way for the Omni program to tell HomeSeer when it needs to be polled for certain things.

ie:

WHEN Front Door SECURE: <Notify HS Zone>
WHEN Front Door NOT READY: <Notify HS Zone>
WHEN Back Door SECURE: <Notify HS Zone>
WHEN Back Door NOT READY: <Notify HS Zone>
WHEN ANY ALARM: <Notify HS Alarm>
WHEN OFF: <Notify HS OFF>
WHEN DAY: <Notify HS Day>

etc... By the <Notify HS...> message, this coudl be done in a number of ways... First, the Omni program could simply send an X10 command that HS would see and then know to re-poll the panel for the zone status, for instance...

Another way, would be using an extra serial port on the Omni (such as the OPII), the Omni program could send a message to HS that it would pickup over the serial port and tell the plugin to update that type of a status.

I can think of a few other ways this could be done as well... (ie: OPII output hooked into a joystick port, go high when a certain type of event occurs)...

While this is messy, was wondering if you thought there might be any merit in this? Specifically the serial port method (for those of us with OPIIs and extra ports on the PC) seems to be the best. It would require writing a program in the Omni to signal these events, however.

Then the plugin would need an option to be able to be notified externally of when to poll the Omni for status on certain types of events... Seems like this part would be a relatively straightforward change in the plugin.

Most likely, an HS script could look for the event notification (ie: over the serial port) and then tell the plugin to immediately poll for that type of event (ie: zone status).

it might already be possible to do this with the plugin (haven't had time to look into it), though I would imagine that there would be times where the plugin would poll by itself. I've noticed that the HAI Plugin seems to eat up a LOT of CPU cycles, so I'd like to reduce that. Thus, if we had an option (perhaps in a script) to be able to tell the plugin NOT to poll for certain types of events, until its TOLD to do so, that could dramatically reduce the CPU utilization from the constant polling.

Anyways, this just popped into my head the other day and I haven't tried to validate any of this reasoning yet. So wanted to get your thoughts about it...

Definitely not a perfect solution, but it might be workable in some configurations.

[Rick Tinker]

Brian,

Thanks for the ideas, but some of them won't be possible. The HAI programming allows only for X number of lines of code, and in many cases it is not enough for all of the zones and units in many systems. There is also no automated way of adding these event lines in the HAI short of sending out PCA files that have them all, and then you would be overwriting the ones that you do have in the HAI system.

The Pro-Link protocol that HAI has is designed for this type of communication, but with only a few hundred lines or zones/units you can track, it is limited.

I think the changes I have planned (have been working on actually) will take care of this. It is not a problem polling the panel every half second for the things that the panel does record changes for and to poll other items less frequently - the big problem is when you have that polling going on along with the ad-hoc messages sent to the panel due to user interaction from events and web pages and having some of the responses come back from the panel in an order that is different than what the plug-in expected.

The rewrite I am working on will make it so that commands can be sent at any time, and responses (except in a few select cases) will be handled when they come back, in whatever order they come back in.

Here is a scenario of the before and after...

Before:

You click on a link on the security page to bypass zone 4. The plug-in sends the command to bypass zone 4, waits for the acknowledgement of that, then sends a zone status request and waits for that response so that it can display the new zone status (e.g. "bypassed") when the web page refreshes and re-displays everything.

After:

You click on a link on the security page to bypass zone 4. The plug-in sends the command to bypass zone 4. When the web page refreshes, it will likely still show the zone as not being bypassed. If the HAI system tells me that zone 4 changed, then another refresh of the screen will definitely catch that change because I am polling for changes every half second. If it does not automatically notify that zone 4 changed, then I will send a status request for that zone right after I send the bypass command, and the result is that you should still have the new status by your next refresh of the web page.


After I get this done, I will test it and see if it is possible to just add an artificial delay on the web page refreshes to catch 90% of the changes. If it works, then I will add that too.

When a status response comes from the panel, the internal variable for that zone or unit is updated, and all of the script commands and event triggers will use that such that there will never again be a 999 or "Unknown" returned unless it is right after the plug-in has started and before everything has been polled at least once.

So that's the plan - it is a major rewrite so it will take me a while, but I have gotten a lot done so far.

Once that is done and working, then there are a few other changes/features I will be adding.

[George]

Oh goody!!!

[Brian Raynor]

Rick,

I know that on an OmniLT or OmniII, the number of lines of programming required would make the workaround I'm referring to unusable.

However, on an OmniPro II, with 1500 lines, there should be enough space to easily do this. Even with my direct serial port integration between my OPII and Leopard II (Leo II serial port hooked into one of the OPIIs), and a host of other programs in the OPII, I'm sitting under 100 lines total used.

And I don't know how many of us have 176 zones in our OPII (I only have 16).

I was only suggesting this as an OPTION, not something that in any way was required for those using the plugin. And I wouldn't expect HomeSeer or the plugin to automatically change the code in the OPII, would expect the user (like me) to have to manually enter those lines. This would just provide an option for advanced users.


Frankly, my biggest program with using the HAI Plugin is actually how much CPU time it eats up. When I was running it (currently disabled), it was eating up about 50% of my CPU time when idle. Don't know why, but it made the machine very sluggish (and the PC is basically just being used for HomeSeer and other basic automation tasks). With the plugin disabled, CPU time (running the ADIOcelot and MR26A plugins) is 3-10% most of the time. running this on a 1.3 GHz AMD Duron with 512MB RAM. Not currently using TTS or Speech Rec.


But your ideas do sound like they will improve things a lot. I'm just wondering how much CPU time when idle it would still eat up. Any ideas?

[auggieben]

Rick,
Would the network protocol DLL that HAI has promised for about year help with the communication overhead? Sorry if I made the hair on your neck bristle.

[Rick Tinker]

Brian,

The issue of CPU utilization with the plug-in was beaten over when it first released. Despite the task manager showing high CPU utilization, it was a false indication - it was showing this when the plug-in was executing "waits". Nonetheless, I found code that allowed for waits that did not artificially indicate CPU utilization and implemented it long ago.

On my system with an Omni Pro and accessing it using a high CPU remote access program like RADMIN, the HAI plug-in was showing 0-3% CPU utilization. At its peak, I have seen the plug-in use 20% for a moment at a time.

If you are seeing something else and the plug-in is fully configured/initialized, then it was either A) one of the bad beta versions or B) a problem with the firmware on the HAI system (of which there have been a few).

I also think that the CPU utilization was higher when I had a Celeron processor for my HomeSeer computer, but after getting rid of that [editorial] crap [/editorial] and running an 800MHz PIII, the utilization has not been high at all.

[Rick Tinker]

Auggieben,

No that DLL will not help. The network communication is nothing more than the same Omni-Link protocol that is used today over an Ethernet interface. The DLL that they were suppose to supply is what was going to take care of the security and encryption.

After I get done with these changes, I hope to be able to tackle that feature, and if they STILL don't have that DLL available then I will have to find code to implement the encryption technology they specified and do it myself.

[JLehnert]

I wouldn't hold out much hope for the polling protocol ever being replaced, based on past comments from some of the HAI reps. I spoke to two HAI reps down at EHX about something else, and the general attitude was "TS. Buy something else if you don't like it". Now that HAI has hooked up with ADI, I wouldn't be surprised if the only feedback HAI listens to in the future, will be from ADI.

Maybe you can poll all Leviton switches and then when a switch changes you could update HAI about the status of that switch? This would solve my problem of the new Leviton 2-way switches providing no 2-way value with the HAI.

[Rick Tinker]

The plug-in already polls the units on the HAI system, and some of the units correspond with X-10 devices. When a device is turned on or off, either through the plug-in or the receipt of an X-10 On/Off command, then I believe the update happens near realtime (immediately). However, the HAI system does NOT notify on DIM commands, so those only get updated when the plug-in does its periodic update poll on everything in the system. Currently this poll may take up to one minute (with the new version of the plug-in I am working on) on a fully loaded Omni Pro II system. On smaller systems it will be much less time, but of course those times are WITHOUT interactive web control going on and with no conditions or triggers being evaluated. In other words, your mileage may vary.

I mention all of this because if I am already polling the system as fast as I can, adding another feature to send an X-10 signal will not help and will likely only slow things down.

HAI is really the ones that need to be beat up about this inconsistency in the event messages in that one is not sent when a dim/bright command is received. If I had that, then it would be a piece of cake.

But keep in mind that when an X-10 signal is received, the HAI system will update its status for that device, so in theory, just write a HomeSeer recurrent event to send out the status command. When the responses come in and the HAI system hears them on the powerline just like the HomeSeer X-10 interface does, then the unit status will update.