Premise Weird delay/pause in Premise

[ckindel]

Something weird is going on with Premise.
 
Actions are taking up to 4 *minutes* to propagate. For example when I open my garage door, the GDO sensor fires a script that turns on the lights. The lights take up to 4 minutes to turn on. If I connect to Builder and tickle things manually sometimes it seems to fix things and responses go back to instantaneously.  But a few minutes later I get the delays again.
 
I've debugged this to the point where I can do it with just pure Premise objects, not talking to any devices.
 
I created two Lights in a room, Light1 and Light2.  I created a OnChangePowerState for Light1:
 
    Home.Admin.Light2.PowerState = this.PowerState
 
I then put both in the watch window.
 
If I change Power on Light1 *sometimes* Light2 will change to reflect it as expected.  But if I wait a bit it will suddenly not have any impact...for SEVERAL MINUTES. And then the handler gets called and Light2 changes.
 
Another symptom is that when Premise is in this mode, Intellisense in the Builder does not work.
 
I've tried disabling things like LogMaster and other Add-Ins.  I've tried disconnecting devices. 
 
Note I made no changes recently (well I did fix the problem I was having that was due to having two instances of Premise running on my network but that was weeks ago).
 
Has anyone else every seen this behavior. I can't recall ever hearing about it.
 
Suggestions for further debugging / diagnosis?

 

[samgreco]

Any new modules or changes recently?  I had one module I installed that caused something very similar once.  It was so long ago I don't remember what it was.

 

[ckindel]

I seem to have resolved this issue. I can't believe this actually was the fix, but it's the only thing I changed that had a positive impact:
 
When I was diagnosing my problem with my Adicon (SECU16) devices I swapped out the power supply to the SECU16 in the equipment room. The wall wart I was using was a 9v 600ma adapter I had bastardized from some Sony device and I suspected it may have been dying. So I replaced it with a 9v 1000Ma wart from something else.
 
Thinking through everything I had done recently that might be causing the problem described here I decided to revert to the Sony adapter.
 
And now it's all working. 
 
Does not inspire confidence...

 

[samgreco]

Didn't see that one coming   It is indeed weird.
 
Glad you've solved it.

 

[etc6849]

That is strange.  Doesn't the Adicon stuff use an add-in (native) or does it use a module?  If add-ins really run in their own thread (which they do), why would other modules and home scripts be affected like that?!?
 
FWIW, if the adicon stuff relies on a module (is this the case?), I recall that all vbscript type stuff runs in a common thread.  There's an interesting timer experiment 123 posted that demonstrates this as I asked him that question (maybe 3 years ago?).
 
To me this would make sense that one module can slow other modules and home scripts way down (due to the way the vbscript interpreter works).  However, I'm not a programmer, so I hope you post your thoughts.
 
I'm glad you figured out your issue though.  Since the device wasn't networked based, you couldn't do packet sniffing, study syslogs, etc so it is very impressive you figured out the issue with such ease.  An issue like this would have driven me crazy (for weeks probably)!

 

I seem to have resolved this issue. I can't believe this actually was the fix, but it's the only thing I changed that had a positive impact:
 
When I was diagnosing my problem with my Adicon (SECU16) devices I swapped out the power supply to the SECU16 in the equipment room. The wall wart I was using was a 9v 600ma adapter I had bastardized from some Sony device and I suspected it may have been dying. So I replaced it with a 9v 1000Ma wart from something else.
 
Thinking through everything I had done recently that might be causing the problem described here I decided to revert to the Sony adapter.
 
And now it's all working. 
 
Does not inspire confidence...