HG is slow

[bkenobi]

I am trying to figure out why HG seems very slow in comparison to ActiveHome Pro when receiving a PLC command, performing a very simple check, then sending out a command on PLC.  What I am trying to accomplish is using a SmartLabs ToggleLinc switch to send an X10 command on the power line to turn on a different switch.  I use AHP and a custom script to trigger on receiving the first switch and then that sends out the command for the second switch.  In AHP, I consistently have to wait just under 2 seconds from the time the button is pressed to when the light turns on.  When I use HG, I am seeing between 2-4 seconds (varying time) and up to 8 seconds or not at all on the high end.

The code that I'm using to trigger this action is a modified version of the Smart Light code that is built-in to HG.  I have removed all PAUSE delays (either commented out or set to zero in code) but cannot get the interface to work faster.

The thing I'm concerned about is that HG may be using a timer to check for incoming events rather than being triggered by events directly.  The code in AHP is event driven, which is why it is consistently <2s.  If HG is timer based, that would explain why it can be anywhere between 2 and 4 seconds.

I'm attaching my code for reference.  This version is not the final version but one I had available to me on a flash drive.  I can post the correct version later on if anyone cares to see it.  This version does not compile, but it does give all my code prior to fixing a couple things last night.

[bkenobi]

I updated the code to the final (I believe) version of the Advanced Smart Lights code.

I wrote a quick script to see if running the code in the When.ModuleParameterIsChanging block would be quicker.  When I timed this with a stop watch, I found that this code results in the entry lights turning on in just under 3 seconds consistently.  I switched back to the AHP setup and it turns on/off the light in under 2 seconds.

I really want to use HomeGenie, but I need to find a way to make this work quicker.  Any suggestions?

[bkenobi]

I thought perhaps the slow response was based on using C# rather than the Wizard scripting.  I built 2 scripts to test if Wizard scripts run faster.  The first turns on the entry lights when status of the switch is on.  The second is reverse that (turns lights off when switch goes to off).  When I send RF commands, the code runs instantly and appears good.  However, when I use PLC to toggle the switch, the code runs very slow.

The attached test codes written in Wizard script language run on average of 3.5 seconds to toggle.  The test script in the previous post runs at around 2.8 seconds.  The full code runs is a bit more interesting.  It takes approximately 2.8 seconds to turn off but 3.2 seconds to turn on.

In any case, these are all much longer than the AHP code.  Maybe there is a polling rate that can be increased somewhere?

[Gene]

The issue is not in the HG automation engine that is very event based, it could be indeed the XTenLib driver.
I believe that XTenLib could be optimized in many ways.
First, probably the "WaitComplete" function could be turned off (just commenting in the contained code):

https://github.com/genielabs/HomeGenie/blob/master/MIG/Support%20Libraries/XTenLib/XTenManager.cs#L510

Also the reader and the writer threads contain some Monitor.Wait/Pulse for synching the communication.

https://github.com/genielabs/HomeGenie/blob/master/MIG/Support%20Libraries/XTenLib/XTenManager.cs#L655

That code probably could be also cut off or at least optimized.

[bkenobi]

I spent the last hour or so looking through the github code to see if I could follow what it was doing And where the delays could be.  I hadn't yet reviewed the XTenLib, but I will now.  I was slowed by not knowing the best way to review the code other than in the HTML.  What program do you recommend to interface with the github code?

[Gene]

You can download the whole source zip and open it as suggested in the README.md:

MonoDevelop / Xamarin Studio: HomeGenie/HomeGenie.sln

- or -

Microsoft Visual Studio: HomeGenie_VS10/HomeGenie_VS10.sln

g.

[bkenobi]

I tried to install Xamarin Studio on my laptop and desktop machines running Win7, but it wasn't happy with installing one of the packages.  I'll try again with VS to see if it likes that better.  I've used VS in the past, so it's probably a better option anyway.

I noticed there's a 5 second sleep in one of the code segments, but I'm not sure if that could be involved here.  If so, the minimum trigger time would have to be much more than 2-3 seconds.

[bkenobi]

I'm still reviewing the code to understand how it's used, but there are 2 locations you suggested checking.  The first was the WaitComplete function.  The sleep is only 0.1 seconds, so I doubt that would cause too much problem (whatever the code is intended to do).  The second function is WriterThreadLoop and the sleep is apparently 3 seconds.  This function could certainly cause problems depending on what it's intended to do.

Code: [Select]

        private void WriterThreadLoop()
        {
            while (true)
            {
                try
                {
                    if (sendQueue.Count > 0)
                    {
                        byte[] msg = sendQueue.Dequeue();
                        //Console.WriteLine(">>>>>OUT " + Utility.ByteArrayToString(msg));

                        Monitor.Enter(comLock);

                        if (isWaitingChecksum && msg.Length > 1)
                        {
                            Monitor.Wait(comLock, 3000);
                            isWaitingChecksum = false;
                        }

                        SendMessage(msg);

...
It looks like the code is intended to send the commands to the X10 device (CM15 in this case).  If there is something in the SendQueue then Monitor is started (connecting to the correct port).  If the isWaitingChecksum is true or the msg length is greater than 1, then it will wait for 3 seconds.  I'm not sure why that's needed, but it should only take 500ms or less to send an X10 message on PLC, so 3000ms seems pretty long.

I tried to reduce the delay to 500ms and recompile, but the compiler complained about errors.  Perhaps it would be possible to reduce this and post a test exe for me to try?  I'll try using Visual Studio 2010, but if this is a simple thing to try, let me know...

[Gene]

XTenLib.dll with 500 ms max-wait.

g.

[bkenobi]

I tried that driver and it didn't make a difference (still takes 2.8s to turn on/off the light from the time the switch is toggled).  I was confused why until I reviewed the Wait method and realized that it worked differently than a sleep statement.  I thought it was a mandatory wait time rather than a max wait until the comLock is unlocked. 

There must be something else in the code that is causing a delay.  I'll have to review the driver again to see what's going on at a high level so I can be more helpful in optimizing this.  I only saw the two delay statements, so I'm not sure what else would cause the delay in this driver (unless the delay is from where the driver is called).

[bkenobi]

I'm curious if this difference in response time could have to do with the compiling?  I've read that using the optimization option will dramatically increase the speed of the code.  This is primarily due to removing debugging overhead, so I assume it is not being used.  If you think this could cause some extra overhead in the code, would it be worth tying a compile with the debug disabled or the optimize option enabled?

Also, it looks like there is a common exe for all platforms.  Is there a benefit to compiling specific versions for different OS'es?  I'm not an expert on this stuff, so I'm just throwing ideas out that I ran across in my research.

I haven't tried using Mochad for this, so perhaps that would be a good benchmark.  I know how fast AHP and the SDK work, but it would be valuable to compare that to an implementation that uses C on Linux to see if I'm right in comparing that to a different hardware config.

[Gene]

Hi Ben,

optimizations will be done when HG will become a stable product. Mono has a feature called AOT that will compile to native code.
I don't think the problem is that though.
I was thinking that you could try disabling the "X10 - Dimmer Bright 100% when switched on" program and see if X10 controlling gets somehow faster.

Cheers,
g.

[bkenobi]

I'll try that.  But, since this is a relay style light, I would hope that it isn't sending dim/bright commands.  It won't hurt anything but it won't do anything either.

I only suggested the optimize option since I read that some code could be run instantaneously with it on and could take several seconds without (that was a math function in a loop of some kind for reference).

I'm also going to test on a Win7 laptop to see if this is a Raspi limitation or related to HG current implementation of the code.

[bkenobi]

I installed r350 on my Win7 laptop and tried the simple test code.  The time for the switch to toggle and then the light to turn on was the same as before (2-3 seconds).

I tried one other thing for a reference point.  I had mochad installed on one of my raspi SD cards already, so I tried running a simple bash script that takes the switch address and controls the light.  This code toggled the light in less than 2 seconds up to 3 seconds.  It looks like the raspi can be just as fast as AHP.

[Gene]

Yes raspberry is pretty good. The odd things is that I am not able to reproduce your issue. X10 works just fine and response is sometime below 1sec. Still I think that, as you said, the XTenLib can be optimized.
With Philips Hue and Z-Wave the response time is kind of real-time.

g.