Premise Does "WaitTime" have an upper limit?

[123]

The Command class is used by Premise drivers (i.e. Modules) to send data via a serial port. It has a property called WaitTime whose purpose is to provide 'deadtime' between successive commands. Here's its definition:

After sending this command wait this amount (ms) before sending next command.

WaitTime is for serial communications and not for IR transmissions as confirmed by Damon in another post. EDIT: I may have this completely bass-ackwards. Damon indicated the Command Delay, in Macros, is for IR communications and not for serial communications. Perhaps this also applies to the Command's WaitTime property.

What it fails to mention is if it has a maximum value. I've tried using 1250 ms and I've not seen any delay between successive commands. 2000 and 3000 ms are also ignored.

Is it possible that WaitTime only works for values less than 1000 ms?

FWIW
I'm creating an Omnistat/2 driver for the RC-2000 and I need to wait at least a second between successive transmissions. I've based it on the old Omnistat driver and it uses a 1250ms WaitTime ... but my logs show there's no delay between commands.

 

[etc6849]

If you are referring to Command objects like the worker object found in the Integra receiver module, it's working for me. I'm using Windows 7 Premium 32 bit.

What I did: I modified the code to remove the hidden flag for the worker. Then I added the new device and modified the waitTime for the worker object to be 6 seconds. Then I pressed the volume a bunch of times on an X10 remote. The volume should be incremented every 100ms according to the code for the X10 remote; however, volume changes are occurring every 6 seconds now!

Changing the volume within Premise causes the worker to send out the new volume level after it is converted to hex. My system is still changing the volume after two minutes because I hit the button so many times! The light on the receiver also lights up every 6 seconds indicating a new command is received. From this point of view, I know it is for sure working. The same behavior was also noted when I changed the volume level through the automation browser and through port spy.

EDIT: I'm attaching a test file for you. If you add the new device (also assign a vacant port) and change the volume under the device properties, you should see the volume sent over port spy. Modify the time interval and you should see that it works *fingers crossed*.

 

[123]

I'll give your example a shot but, as indicated in my edits to the original post, I think I got it all backwards ... WaitTime may only apply for IR communications.

FWIW, I have the Command object visible and I've set WaitTime to be 3000 ms yet the log clearly shows that the command is issued in the same second as the previous one and not 3 seconds later.

Addendum
I looked at the Onkyo code. The ClassConstructor makes a "Worker" Command object with a WaitTime of 50 ms. You're saying that when you increase it to 6000 ms you can measure a 6 second delay between transmitted commands? That's precisely what I cannot make it do ... and I see nothing different in the way you construct and initialize the Command object. Hmm. Puzzling.

 

[etc6849]

123, I just saw your edit. Yes, the CommandDetail "Delay" property only seems to work for IR commands. This maybe why CommandDetail shows an IR symbol next to the property detail heading under custom devices. However, it appears you can always send the RS232 command out using a Command object and modifying the "WaitTime" property. You would then have to hard code the rs232 codes using onchangescripts. This isn't as nice as inputting the commands under custom devices, but it should work and allow you to modify the delay time through code.

 

[etc6849]

Yes, 6 seconds works for me as does 3 seconds. Do you have a test system you could restore Premise defaults on and try it? I still have the serial port issues where a port reconnect is necessary from time to time.

I'm convinced after talking to you that my serial connections would work fine on a fresh Premise install. Also, on a mini-ITX system I plan to make, instead of restoring my entire Premise system, I'm going to import the necessary modules, devices and home objects only and not the add-ins and etc. I think this will fix my issue. However, please post a solution once you figure it out as it may give me insight into fixing my serial communications issue

Addendum
I looked at the Onkyo code. The ClassConstructor makes a "Worker" Command object with a WaitTime of 50 ms. You're saying that when you increase it to 6000 ms you can measure a 6 second delay between transmitted commands? That's precisely what I cannot make it do ... and I see nothing different in the way you construct and initialize the Command object. Hmm.

 

[etc6849]

Just thought of an idea to try: does stopping the SerialPorts subsystem then restarting it fix your problem?

 

[123]

My problem appears to have been what I was using to "measure" the delay. I misunderstood what DebugView was indicating ...

I opened PortSpy and simply observed the transmissions. I set WaitTime to 5000 ms and, without question, noticed a 5 second delay between successive transmissions.

At one point in my code, it sends two successive commands and, in PortSpy, I could see the two commands were spaced 5 seconds apart. WaitTime definitely works for serial communications.

I had added "debugout" commands in my code to report when something was being transmitted and, in Debugview, it clearly shows successive commands being issued at the same time without any inter-command delay.

I now understand what the heck was going on. The commands were issued sucessively (i.e. displayed as having been sent within the same second) but thecommands were buffered therefore the first one was transmitted immediately and the second one went 5 seconds later. I had misinterpreted Debugview and thought it indicated there was no delay between transmitted commands .. I forgot it was reporting the time when commands went into the buffer and not when they exited the buffer.

Oops! :blush:

PS
etc6849, thanks for your help. I also want to report that, with the Omnistat driver, I have also encountered the dreaded 'dead serial port' syndrome you first reported.

I'm still trying to characterize the problem but after about 12 hours of polling the thermostat, the serial port dies quietly. Commands seem to be transmitted out yet nothing ever comes back from the device. The serial port status is "Port(Open)" but the port is dead as a doornail. I have to manually reconnect the Network property to COM6 in order to re-establish communications. Clearly, I'll have to add some code to reset the port when this occurs (like in the zwave driver).

You are now no longer the only Premise use who has experienced this ugly little problem.