I’m using guessed’s SQBlaster plugin and I built my own plugin on top to control my TV though an SQ Blaster puck.
The problem is that when I send two consecutive commands programmatically ( ie 2 calls to luup.call_action(“urn:micasaverde-com:serviceId:IrTransmitter1”,“SendProntoCode”,… ) , the second is not executed: SQ Blaster returns the following error code (request out of sequence)
[tt]
[/tt]
I suspect that the http requests are being called in 2 different threads ???.
Is there any way to serialize these calls or have the plugin function sleep for a few milliseconds after each call ?
Ping @SquareconnectMat and find the puck behavior in this situation. The plugin makes a HTTP call when sending stuff, and blocks for the response, so there shouldn’t be a timing problem (or we’d have the same issue in other plugins also)
He’ll likely want a copy of the specific requests being made, and the sequencing from the MiOS logs in order to see how he handles them at the Puck end.
I’m assuming that both of your calls are being made, sequentially, from within a single device (2x calls from a single device)
Delays should not be necessary, and should be a hack of last recourse. If we work on fixing the core issue, then everyone will benefit.
It’s likely that something else is amiss if these errors are being reported and Mat is keen to get that stuff sorted out in his overall solution stack.
PS: Mat will want to know what Firmware version your running also, in case it’s been addressed/changed in more recent firmwaes. This information is available in the SQBlaster plugin dialog.
@Roy S, just noticed that you’re not at a level where you can PM yet, so sent Mat a PM on you’re behalf. Hopefully he’ll be able to respond in thread with some technical reasoning for the behavior you’re seeing. You can post FWare details here in the meanwhile.
My SQBlaster firmware version is A069 (FirmwareDate Dec 26 2010).
I had opened a supported ticket with Squareconnect and they sent me their system integrators guide (that’s how I knew that messagenum=111 is a sequence out of request error). I thought this could be a problem faced by you guys.
Please find the part of the log file showing the error below
Sorry for the slightly tardy response here on the forum. For some reason I am not getting notified by email when PM’s are sent or topics I am watching get updated!
What is happening here is that when you issue an HTTP command to the blaster, it starts blasting and returns immediately. The blaster continues to blast. It will not accept another start command while it is blasting. Hence the 111 error. It may also be a problem in press and hold mode, if the sequencing is out (which can happen when there are a lot of errors and retries going on under the hood.
Ther is a long and complicated reason for this behaviour - mostly to do with ensuring that the blaster behaves well when there are errors on the network and commands need to be near ‘real time’.
If you are using the press and hold form of the commands, the ‘repeat’ command IS accepted if it follows the rules as described in the document.
Basically, if you get this response… back off for 250ms and then try again.
@mat,
Thanks for the official response. Any API guidance on hw many retries should be executed under this scheme - say, based upon the code lengths and likely IR transmission times you’ve [historically] seen.
Based on Mat’s reply, I was able to solve the problem by having the function sleep for 250ms after each http command.
[tt]luup.sleep(250)[/tt] was giving errors (something to do with Vera firmware 1.1.1047 maybe ?) so I added
[tt]
socket.select(nil, nil, 0.25)
[/tt]
at the end of the SendProntoCode function code.
I know this is not the perfect solution as there’s no error management but it’s working in my case.
Well… First, the next version of the SQ API will provide tools to be notified when a blast is finished We are in the process of designing this. Your input is always welcome on that. We will also be enabling in-blaster execution of a ‘macro’ or stream of commands… so the blaster can manage when a blaster is ready for the next command for you. Very useful for the channel entry and other simple macros. But as always, this is some time away… towards the end of the year, most likely.
Most IR commands last less than 250ms - that is the time at which it starts to become less than ‘instantaneous’. There are a lot that are less than 10ms - especially volume up/down etc… but they often require a multiple burst to be recognized by the equipment.
The real issue is when will the target equipment accept the next command. Anyone with one of the older Blu-ray player’s know that issue…
Unfortunately the only real way of determining this is to test the exact timing/repeats and sequence for your specific set of equipment. The macro function in SQ Remote can be useful to find this out and experiment. Then you could put these values into the Lua script…
[quote=“guessed, post:8, topic:168319”]@mat,
Thanks for the official response. Any API guidance on hw many retries should be executed under this scheme - say, based upon the code lengths and likely IR transmission times you’ve [historically] seen.[/quote]
In terms of number of retries… I would say if after 4 retries without success I would say something was wrong… most likely another client was trying to blast at the same time.
If two or more Users are trying to battle the same blaster, while one is blasting, the other just gets rejected until the blaster is clear. pure chance who gets it next.
The only state we keep track of is which toggle code was sent for a specific device/command, so we can send the next toggle (mostly correctly) and when in press and hold, which sequence number we are currently holding for. On time outs (after 300ms) we will go into ‘accept next command’ mode. (if that makes any sense).
I am not sure what the correct behavior for an automatic script in a controller like Vera should be… I am tempted to say, if the command MUST be executed, back off a second and try again. But that may lead to surprising things happening in your environment.
Since a new version of the APIs will be released, can’t you guys implement some kind of queuing mecanism within the SQ Blaster so that commands are stored and blasted serially?
(I have no idea what kind of memory a puck has in it and if this is feasible… Just adding my 2cents)
@Roy S,
I’m going to mod the SQBlaster plugin itself to do the retries, based upon Mat’s comments/data above.
In Lua, it’s trivial to work out if a method is available or not, so I’ll add logic to work use [tt]luup.sleep[/tt], or fallback to your method (for earlier MiOS revs)
I’ll need you to test that properly since mine are all newer Betas.
Anyhow, if you’re calling my code, you’ll pickup the mods without anymore code (etc) once I’ve readied them.
In past discussions with Mat, there were reasons for not “queuing” commands in the Puck. Some of these related to what can happen if you have a rogue client sending too many “critical” commands (like VolumeUp) leading to all sorts of bad situations.
I’ll be waiting for your new plugin version. Meanwhile, can someone change my security privileges so I can PM people ? (Anything required from my side ? )
@Roy S,
You get that automatically once you reach 25 posts, or “Sr Newbie” status. It was a restriction that I put in to stop the Spammers mis-using the Forums (as they’re prone to do for a variety of reasons).
Unfortunately, the spammers create a high percentage of the accounts on this system, and have been using them for link promotion (amongst other things) so some restrictions were put in place on Newbie accounts to stem the flow of SPAM.
@Roy S,
I’ve modified the code to do 4x attempts at sending, using 250ms gaps (per Mat’s suggestions). You can pull a modified version of the Plugin’s implementation file from this location in source control:
Can you try that out, and let me know if it addresses the problem you were seeing?
If so, I’ll tag the latest round of files, and publish them formally.
It should work on older Vera versions as it’s using [tt]luup.sleep[/tt] (if available) and falls back to [tt]socket.sleep[/tt] if [tt]luup.sleep[/tt] isn’t available in MiOS (to avoid forcing MiOS upgrades to the Beta releases)
The changes are simple, but it took a while to test all the combinations. Anyone wanting to see what was changed can go here for full details:
Plugin tested successfully. The plugin retries to send to code until it succeeds. It is usually successful on the 2nd or 3rd
attempt.
But I noticed another thing while testing: In my plugin, I send IR commands as jobs (as below).
Sometimes, when sending multiple commands, they are not executed in the right order.
I had tried to use instead of jobs, but vera would crash and need a restart.
[tt]
urn:micasaverde-com:serviceId:DiscretePower1
Off
I’d have to see the full code you’re using, so that the impl of the [tt]sendCommand[/tt] was exposed also, including a code-block showing multiple calls in a single [tt]job[/tt]/[tt]run[/tt] block.
Generally speaking, the order of execution of different [tt]job[/tt] blocks requests is indeterminate. If you need a single job block to run a list of items serially, I’m assuming you’re either using multiple [tt]sendCommand[/tt] calls, or you’re invoking a scene with the steps all listed out in it.
I’ve attached the implementation file of my TV plugin.
In short, I store the IR pronto codes in a text file, that is loaded into an array at startup.
Since the file name is a variable, I can have multiple IR Devices using the same plugin.
A custom interface calls the different actions, either manually or programmatically.
Now the problem is that when actions are being called, the [tt]sendCommand [/tt]function is executed through a job. I can understand that jobs may not be executed serially when they target multiple devices (ie turning off all lights), but the jobs here are all related to the same device, so logically the order of execution should be kept.