Plugin really slows down response time

[chadg]

I'm just trying out Doo Motion to see if it would fit my needs (I new to this one). It seems like a really cool plug in, but it seems to slow reaction time way down. I'm runnning HS version 2.1.102 and plugin version 2.2.53.

I have very simple setup. I use a motion senor connected to a ELK panel. I have a HS event that triggers a light on when that motion sensor tiggers. It responds in 1 second or less.

I then installed Doo Motion 2.2.53. I created a virtual motion sensor w1, that I set it's trigger code to /7 (ELK motion sensor). I then put the following code in the custom action code for that device=on.

dm.NewNoMotionDelayedEvent "Shop Light Control", "Basement Shop Lightsff", 10

This all works just fine now. The light goes on when I walk into the room then turns off 10 minutes later.

The problem is that my response time for the light to go on is now 2-5 seconds! Pretty consistant 2 seconds, but sometimes longer. This is way too long. If I click on the tray icon and set the doo motion pugin to Inactive, I then get my 1 second response time back.

So, is this normal? I would love to use this plugin becasue it seems to bring alot to the table, but I can't have response times this long.

Any ideas?

Thanks,

Chad.

[Jim Doolittle]

There is a whole set of factors that affect response time. Nothing in my setup takes as long as 2 seconds (except for my X10 to UPB command converter plug-in, but that is another story...). I typically get 1/2 - 3/4 second.

One option that may help is trying to use VB.NET scripting rather than the typical VBScript. However, that may only shave off a 1/2 second at most.

Another option would be to avoid using CAC with you ELK panel motion sensor. DooMotion provides many features in addition to CAC. There are some cases where I have opted for HomeSeer events instead of CAC because trial-and-error indicated that the events produced a faster response than scripting. I have found that can be the case for "plain old" HomeSee scripts.

A third option would be to continue with your current configuration .

DooMotion has a debug mode feature that provides timestamps with millisecond precision so if you turn on DooMotion's Debug Mode and provide a snippet, I might be able to see what can be done to speed things up. Should at least see when DooMotion receives info from HS and then acts on it. If your ELK can provide additional debug data, that may be helpful because we need to know how long it took to provide info to HS.

BTW, I have not run 2.1.102 for a while and I suspect that a lot of DooMotion 2.2 users are not as well. That may be an additional factor that I need to be aware of. I AM NOT SUGGESTING THAT YOU UPGRADE AND USE A BETA VERSION. That may not do anything but causes some unforeseen problem with the rest of your system.

[chadg]

Well, I'm not using scripting right now, to turn the lights on, it is a plain old HS event.

I'll turn on the DM debug mode, I'll see if that turns up any helpful information. I'm at CES right now, so I'll have to try it out when I get back.

Thanks for the info!.....


Chad.

[Jim Doolittle]

Ahh...I misread part of your post. You use CAC to the delayed event to turn off but use HS event for turning light On.

This is interesting in that you say that the reaction time for HS event to trigger increases when DM is active and goes back to your typical times when DM is inactive. However, DM should not be involved in the HS event triggering. HS should be handling its event independently.

Now, if you are using a DM event trigger, then that is different as DM would be involved. However, I assume that you are not doing this as the event would not trigger at all if DM were Inactive.

[Gogs]

I have used DM for some years now. With the exception of some CACs I do not use it to turn lights on, only to control them once they are on.

I said with exceptions of some CACs. I have found that if it is a simple if one condition meets then turn on the light then a CAC is very quick, even quicker than "not queueing events". However if it's a complicated event, many conditions that sort of stuff, then an event is faster.

DM's brilliance for I comes in it's ability to control after they have turned on, not to turn them on, with the exception I mentioned.

[petez69]

I'd agree wih Gogs and took advice from a friend that has been "Seering" for years. Use the X10 code to turn on the output and then use DM to manage how long it stays on for. This IMHO provides the best results...

[anogee]

Recently I removed DooMotion, not because its bad, but just because I wanted a bit more control. Instead I created my own version of DooMotion. My DooMotion is all run in VB.NET

Anyway I used CAC code exclusively to turn on lights in DooMotion, and used Occupancy sensors to turn off lights. My new method uses a VB.NET script to launch another VB.NET script for that device without DooMotion.

Between DooMotion and my non-DooMotion script, I see absolutely no difference in timing, but I should note that I use HAI, not ELK. Most of the delay is the delay from my HAI Plug-in, not DooMotion or my script. I haven't done real timing, but DooMotion or my script at most maybe adds 0.1 second. The rest is the HAI plug-in and UPD slight delay. If you are seeing a long delay, I'd investigate the ELK plug-in. Its also possible that DooMotion and the ELK Plug-in might not play nicely together, causing the delay.

[Jim Doolittle]

... Its also possible that DooMotion and the ELK Plug-in might not play nicely together, causing the delay...

Hmm... some of you ELK guys provided info that suggested some interactive effect. But in that case it was a looping effect that cause too much activity rather than delayed activity. Yes, I put a filter in but the filter prevents repeats and in no way should slow down processing.

If chadq and someone else that "has ELK, uses CAC to turn a light, and very minimal delay" can provide debug log snippets from both DM and ELK that would be of great assistance. All I need is snippets of around when a sensor is being triggered and action based upon the trigger is performed.

There may not be a whole lot that I can do directly within DooMotion. But, if I define the problem good enough, I can go to HST and maybe ELK Plug-In developer.

[chadg]

OK, after repeated testing I have found that the difference between using DM and not makes about a 1/2 to 3/4 of a second difference in response time. It's not huge, but for motion lights, faster is better.

I'm going to put the very odd behaivor of 5 seconds to possilbly the ELK device status having a delay once in a while. It does not happen very often, so it is really hard to get logs with that long of a delay.

So, focused on the more consistant difference here is what I noticed.

I have a single motion sensor setup in DM. It is a virtual device. When I set the trigger code to "B2", a device that actually does not exist on my system, then I get the faster response time. If I set it to "\7" wich is the valid code for the ELK motion sensor, then my response time goes up.

I looked at the logs and it seems strange because in both cases the HS event that turns the lights on seems to happen in the same section and within the same second of the device changing.

But, if I re-set the DM virtual senor to a trigger code that is really nothing, my response time goes back down. Attached is a notepad file with the logs if that helps.....

BTW - I tried to put in the line of CAC code and not. It did not seem to make a difference.

Chad.

[Jim Doolittle]

...I have a single motion sensor setup in DM. It is a virtual device. When I set the trigger code to "B2", a device that actually does not exist on my system, then I get the faster response time. If I set it to "\7" wich is the valid code for the ELK motion sensor, then my response time goes up.

If B2 is a trigger code that does not exist on your system, then I do not understand how tou would be getting any response time.

[chadg]

Because DM has nothing to do with turnin on the light. I have a HS event tyied directly to the motion sensor "\7" to turn the lights on. Seems that the DM trigger doing something slows down the HS event......

Does that make sense?

[Jim Doolittle]

Ok. I have an idea on how I may be able to do something to improve response time. It works off the premise that DM is slowed down waiting for HS to do something rather than some issue with DM itself. If this premise is correct, then you should see improved performance. I will try to have a new beta build either tonight or tomorrow.

[chadg]

Great, I look forward to trying it. I also upgraded to the latest beta of HS just to make sure there was nothing funny there.....

[Jim Doolittle]

You can try downloading the new beta.

[zimmer62]

Jim, on your download page, you have your beta as Jan 15, 2006 I did a double take for a second, before I realized that was the newest.