Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Back-to-back UPB commands
#1
I have a couple of triggers that react to Elk events and turn on/off UPB devices.

If I have two Device:FieldWrite commands for UPB fields back-to-back then the second one doesn't have an effect.

If I have a 500ms pause between the two it does. Remembering to add the pause in an action is a little annoying, but doable.

However, I have some devices that react to Elk output changes via their own triggered events: ie. Elk output N triggers UPB device X. If I have an Elk rule that turns these outputs on at the same time then I get the same behaviour -- the second one is missed (which has lead to a cold bathroom floor for the last few mornings -- not good!). I have to configure the Elk rules to be offset in time as well.

There are no error messages of any kind in the log. Is this an issue in the UPB driver, the PIM, CQC or ??? Any suggestions that would help?
Reply
#2
It would pretty much have to be a UPB thing. Unless there is some way for each potential accessor of the UPB network to know that something else is going on and back off, I don't see how you could ever make it reliable in that sort of situation where there are multiple, independent entities accessing UPB functionality, or some way to know after the fact that that's why it failed and retry it or something (assuming you could know in a reasonable amount of time.) And if all the players didn't honor that system, it still wouldn't help, I don't think, if some of them did.
Dean Roddey
Explorans limites defectum
Reply
#3
Is the driver single threaded within CQC?

If so then it is more of a rate limiting issue than an actual collision of two commands. The driver could enforce a minimum time between attempts to send commands.

UPB seems common enough that other people would have noticed this behaviour unless there is something weird in my setup.
Reply
#4
The CQC driver is single threaded. So the only way that a single driver can do this sort of thing is if the device has an arbitrary inter-message timing restriction. Generally that's not an issue since in almost all cases outgoing commands from the driver are acknowledged by the device (and queries implicitly acknowledged by the response), so you are guaranteed that the driver cannot over-run the device.

So if the driver by itself can cause this problem, either the UPB device has such a limit, or the driver is sending out commands that it either doesn't wait for acknowledgement of, or that the UPB controller doesn't provide acknowledgement of. Otherwise, it couldn't happen with a single instance of a single threaded driver.
Dean Roddey
Explorans limites defectum
Reply
#5
I have a similar problem with Insteon and I pause between each command. I would think its possible that different setups would require different pauses and a driver based delay may not cover things.

Russ...
Reply
#6
The time delay required between UPB commands does seem to vary a bit between CQC versions. It used to be 250ms would work, but I noticed with later CQC 3.x versions and with 4.x that 500ms is required. Adding the time delays is a pain.

Since this is a problem for a variety of CQC things, like TTS, for example, maybe it would be worthwhile to create a generic server to front-end these slow drivers. I send a UPB command to the server, and the server sends them out at the right time. I had to do the same type of thing with TTS, because I switch speakers before each message, so a server I built handles that, but I have no question that a generic server could be built 1000 times better than mine.

By the way, the UPB problem is NOT inherent to UPB but its a problem with the UPB driver. I can send out hundreds of UPB commands from my HAI panel directly, and none get lost, so something there is queuing them correctly.
Reply
#7
Actually, if something is queueing them and sending them out more slowly, then the issue is with UPB, and they are just working around it by queing them and sending them out more slowly. But, as soon as you do that, you no longer get to have acknowledgement back to the client that the command worked or not, and that's not necessarily something to give up just to avoid a pause. If you have some complex operation and whether you continue depends on whether each step completes successfully, a queued implementation won't work with that anymore.

On the TTS thing, there's no problem there. The (V II) driver does queue up all commands sent and spools them out in order. But that's the sort of thing that it's generally not necessary to have synchronously ackowledged. We did discuss for a while there some way for you to have the ability to intercept the upcoming output of each successive message and do something in response to that, but so far nothing has been implemented. It used to not be an issue since you could just issue your own TTS commands even in the background, but we had to adjust and haven't yet really got it back as nice as it used to be.
Dean Roddey
Explorans limites defectum
Reply
#8
I think you hit the nail-on-the-head. Queuing commands is easy, the UPB computer interface can do it but its the waiting for the replies that cause the problem. But here is the wacky part. The driver doesn't let you make use of the reply, and I think replies have marginal value at best. Links don't even send a reply, Gen I switches don't send a reply through a repeater, and since UPB generally always works, you don't need a reply anyway. :-)

So because the driver is waiting for a reply which it may never get, the design of the driver is such that if you send two commands too close together, the second command gets completely lost without any error whatsoever. Personally I'd say for forget the replies but don't loose commands.
Reply
#9
But the driver could never send a second command while it's waiting on the first. The second incoming command would be blocked until the first one either got the reply or gave up. So there's no way the driver can send commands too fast if it waits for acknowledgements.
Dean Roddey
Explorans limites defectum
Reply
#10
Basically it comes down to the fact that, if a device doesn't send back an acknowledgement of every command, then there's no way a driver can know when it's safe to send another command, unless it just imposses an arbitrary inter-outgoing message pause of some sort. So just queing things won't help since the queing thread would act just like the directly called threads from clients and send them out as quickly as it could. It has to have some way of knowing when it's safe to send another one. And, if it does, queing isn't required since it can do that check normally and only send another when its safe, and not give up positive confirmation.

Certainly a driver can store a time stamp each time it sends a message and, the next time it's asked it and a certain amount of time hasn't expired, it can wait a bit for that minimum inter-send time to expire. That's sometimes done. The PDL driver system explicitly supports such a scheme for those types of devices.
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Way back machine... royalj7 2 853 10-03-2020, 10:53 PM
Last Post: kblagron
  Can't Find a Couple of Documented Action Commands kblagron 7 3,908 10-02-2018, 05:47 PM
Last Post: kblagron
  Additional HTTP REST commands requested greymatter 3 2,879 08-25-2017, 09:17 AM
Last Post: Dean Roddey
  How To Use Backdoor Commands From Admin Interface MikeW 1 1,797 12-11-2016, 02:12 AM
Last Post: Dean Roddey
  How to back up CQC? Deane Johnson 11 3,892 01-23-2015, 02:57 PM
Last Post: Dean Roddey
  Will a timer in a IF statement effect commands after the End? ghurty 3 2,350 01-23-2015, 10:17 AM
Last Post: Dean Roddey
  Single button, Multiple images & commands? M4T VW 6 3,758 10-04-2014, 01:47 PM
Last Post: M4T VW
  Polk XM receiver commands DaveB 5 1,630 01-15-2013, 06:57 PM
Last Post: DaveB
  z-wave "Got a negative status back from SendMsg()" pasha 4 2,597 01-28-2012, 02:55 PM
Last Post: pasha
  Receiving IR commands with CQC Mark Stega 7 3,119 11-29-2011, 06:30 AM
Last Post: LesAuber

Forum Jump:


Users browsing this thread: 1 Guest(s)