Lag turning on lights

[MarkJames]

I just migrated to eisy from my isy and purchased the Elk nodeserver.

I use motion sensors connected to my Elk to turn on lights.  This was fairly immediate with the ISY but with the eisy and the nodeserver I have a lag.  Sometimes it's very minimal but other times it can be long enough to make it useless for turning on lights to navigate at night.

Is there something I can tweak to fix this?

 

[Jimbo.Automates]

There should not be much delay. I assume you use a program? Do you trigger off the control event? I do something similar with some doors which I put the zone in a scene instead of using a program. But when I tested it a long time ago there really wasn't much difference between a program or a scene.

Sent from my Pixel 6 Pro using Tapatalk

[MarkJames]

Thanks for the quick response.

I have all my Elk violations in a folder for easy tracking.  When, say, a PIR in a hall gets tripped it looks like this

In this case it always turns them on - with some other doors/PIRs it checks first against time of day etc to see if they're needed.  

PIRs, can be funny things so I've been careful to make sure that the PIR actually does trip - I can see the light flick on it so I know it's sensed the motion.  

In general, you're right - it does happen fairly quickly.  Fairly often, though, the lag is such that I stand there in the dark waiting for it to happen.

I wasn't sure if the long and short poll numbers would be useful here as I'm new to PG and don't understand the finer details yet.

On another note should I be checking for zone status for this sort of thing or should I be looking for a control ON message instead?  

Oh - lastly - any chance of being able to grab the lines of the Elk log as a substitution variable to be able to send via an email notification?  You've made the Elk integration far more robust than the native version.  I integrated all the same functionality that you did but I did it through the rest interface and acted on it through Tasker via autoremote on my phone.  Yours makes it much easier

Thanks!

 

 

 

Edited July 9, 2023 by MarkJames

[Jimbo.Automates]

Your program looks correct, control action should come first.

You can't add the elk log to a notification but you can add any of the driver values.


Sent from my Pixel Tablet using Tapatalk

[MarkJames]

So is the control 'switched on' the equivalent of it going to 'violated'?

[Jimbo.Automates]

So is the control 'switched on' the equivalent of it going to 'violated'?

Yes, there is an option on each zone "Send On For”

Sent from my Pixel 6 Pro using Tapatalk

[Sparks]

So I did a quick search of the forums and found this thread.  I have a similar problem - ISY with the Elk integration and the response was within a second.  Now with EISY and the ELK Poly, it is like 2-3 seconds to trun on a ligh with EXACTLY the same program as before.  EISY is supposed to be faster.  Polyglot is supposed to be better and more robust, has more features and all.  But if the basic functionality means we have a 2-3 second delay ... then we seem to be going backwards.  Is there any reason you can think of .. .anything I can check in the logs.  I did try changing from Status->Violated (as it always was with ISY) to Control->On but it makes no difference whatsoever.

[Sparks]

Just replicated the program in Home Assistant (ELK addin + UDI Insteon)  and the lights turns on before I even opened the door fully - this cannot be right.  The light is an Insteon scene though EISY so my only conclusion is this is somthing wrong with Polyglot.

[Jimbo.Automates]

This should not be the case, the response should be very quick.  Every report of this has always turned out to be another issue.  First what PG3x and IoX version are you using?  Then watch the Admin Console Event log, and the node server log while triggering the action to see if the delay is on the IoX side or the PG3x side.

You may need to submit a support ticket to have them view your system.

 

Edited October 15, 2023 by Jimbo.Automates

[Sparks]

Yeah - I agree I need to look at logs.  Just checking if this was a noted problem, or not.  It is odd.  We are all seeing new "issues" after changing to EISY as ISY was so solid.  That's the Home Automation World for you!

[Sparks]

So I looked at the event log.  Zone 3 is the door contact.  20 8B 6B is the light.  Zone 3 logical state changes 2 seconds before the physical state GV0 and the DON and of course before the light turns on.  The 2 seconds appears to be repeatable.  I tried using the logical state and the control trigger in the program but it makes no difference.  The delay between the door and the light seems longer than 2 seconds but the log won't lie.  (Ignore Zone 8 - that's other activity in the house)

Any ideas?

[Jimbo.Automates]

On 10/23/2023 at 6:24 PM, Sparks said:

So I looked at the event log.  Zone 3 is the door contact.  20 8B 6B is the light.  Zone 3 logical state changes 2 seconds before the physical state GV0 and the DON and of course before the light turns on.  The 2 seconds appears to be repeatable.  I tried using the logical state and the control trigger in the program but it makes no difference.  The delay between the door and the light seems longer than 2 seconds but the log won't lie.  (Ignore Zone 8 - that's other activity in the house)

Any ideas?

Sorry for the delay in responding, I'm away from home.  It doesn't make sense that the logical (ST) & physical (GV0 & DON) are 2 seconds apart.  But, it's impossible to tell why.  I would need to see the node server log in debug mode at the same time to see if it happens on the PG3 side or IoX side.

Also, you didn't answer my other question, what IoX & PG3 version are you running.

[Sparks]

Yeah - sorry.  I didn't read the question - my bad!  I will try to capture some more data from PG3 and EISY this weekend and post back.

Edited October 28, 2023 by Sparks