We have moved at community.getvera.com

Author Topic: SQ Blaster Plugin, http requests too fast ?  (Read 10976 times)

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
SQ Blaster Plugin, http requests too fast ?
« on: May 12, 2011, 05:56:05 am »
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)


<execCmndResponse>
<status messageNum="111" reasonCode="29" />
</execCmndResponse>

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 ?

Any ideas are appreciated.

Thanks.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #1 on: May 12, 2011, 07:45:02 am »
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)

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #2 on: May 12, 2011, 07:46:12 am »
You could try specifying your SQBlaster commands on the 'Advanced' tab of a scene and insert delays - or try using luup.sleep() ...

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #3 on: May 12, 2011, 07:54:57 am »
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.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #4 on: May 12, 2011, 08:09:04 am »
@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.

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #5 on: May 12, 2011, 10:40:37 am »
Thank you guessed,

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


08      05/12/11 17:35:53.017   JobHandler_LuaUPnP::HandleActionRequest device: 28 service: urn:micasaverde-com:serviceId:NumericEntry1 action: 2 <0x24808>
08      05/12/11 17:35:53.018   JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:NumericEntry1 <0x24808>
08      05/12/11 17:35:53.018   JobHandler_LuaUPnP::HandleActionRequest argument action=2 <0x24808>
08      05/12/11 17:35:53.019   JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=28 <0x24808>
08      05/12/11 17:35:53.019   JobHandler_LuaUPnP::HandleActionRequest argument _=1305210952850 <0x24808>
50      05/12/11 17:35:53.023   luup_log:28: I_domotixtv: executing: 2 <0x400>
08      05/12/11 17:35:53.024   JobHandler_LuaUPnP::HandleActionRequest device: 26 service: urn:micasaverde-com:serviceId:IrTransmitter1 action: SendProntoCode <0x400>
08      05/12/11 17:35:53.024   JobHandler_LuaUPnP::HandleActionRequest argument ProntoCode=P277e 6695 95eb e3d3 ad38 f532 f1f3 9c97 679d 61a8 6311 41c5 1590 98eb 4368 f934 24d0 3633 16dd a03c 2b0a 73d6 f87b 980c 679d 61a8 6311 41c5 1590 98eb 4368 f934 24d0 3633 16dd a03c 2b0a 73d6 f87b 980c 1af5 bf7b 9b34 0332 9 <0x400> c96e f45f 129c 2830 63a6 d00d 89c0 fb32 5f9e c0c5 effa 4ffc df55 31fa d3dd 5a6b 89ec 76b8 6dbf 1305 277d f42e 7a95 91bc 15fb ee91
08      05/12/11 17:35:53.035   JobHandler_LuaUPnP::HandleActionRequest device: 28 service: urn:micasaverde-com:serviceId:NumericEntry1 action: 3 <0x24808>
08      05/12/11 17:35:53.035   JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:NumericEntry1 <0x24808>
08      05/12/11 17:35:53.038   JobHandler_LuaUPnP::HandleActionRequest argument action=3 <0x24808>
08      05/12/11 17:35:53.038   JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=28 <0x24808>
08      05/12/11 17:35:53.039   JobHandler_LuaUPnP::HandleActionRequest argument _=1305210952851 <0x24808>
50      05/12/11 17:35:53.085   luup_log:26: Web request returned status=200 response=<?xml version="1.0" encoding="utf-8"?>
<execCmndResponse>
<status messageNum="0" reasonCode="0" />
</execCmndResponse> in 0ms <0x400>

06      05/12/11 17:35:53.087   UserData::m_luc_HAG_Variables_set variable: DataVersionStatus now: 192995192 subs: 0 <0x400>
04      05/12/11 17:35:53.089   <Job ID="576" Name="" Created="11-05-12 17:35:53" Started="11-05-12 17:35:53" Completed="11-05-12 17:35:53" Duration="0.67345000" Runtime="0.66056000" Status="Successful" LastNote=""/> <0x400>
50      05/12/11 17:35:53.091   luup_log:28: I_domotixtv: executing: 3 <0x400>
08      05/12/11 17:35:53.092   JobHandler_LuaUPnP::HandleActionRequest device: 26 service: urn:micasaverde-com:serviceId:IrTransmitter1 action: SendProntoCode <0x400>
08      05/12/11 17:35:53.093   JobHandler_LuaUPnP::HandleActionRequest argument ProntoCode=P277e 6695 95eb e3d3 ad38 f532 f1f3 9c97 679d 61a8 6311 41c5 1590 98eb 4368 f934 24d0 3633 16dd a03c 2b0a 73d6 f87b 980c 679d 61a8 6311 41c5 1590 98eb 4368 f934 129c 2830 63a6 d00d 89c0 fb32 5f9e c0c5 679d 61a8 6311 41c5 1 <0x400> 4368 f934 24d0 3633 16dd a03c 2b0a 73d6 f87b 980c ffb9 404f c3bd 30b6 283b ba0c f73d e93e 6dbf 1305 277d f42e 7a95 91bc 15fb ee91
50      05/12/11 17:35:53.145   luup_log:26: Web request returned status=200 response=<?xml version="1.0" encoding="utf-8"?>
<execCmndResponse>
<status messageNum="111" reasonCode="29" />


Offline SquareConnectMat

  • Full Member
  • ***
  • Posts: 248
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #6 on: May 13, 2011, 08:03:31 pm »
Hi Guys,

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



Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #7 on: May 13, 2011, 10:38:03 pm »
@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.

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #8 on: May 14, 2011, 04:17:13 am »
Thanks Guys,

Based on Mat's reply, I was able to solve the problem by having the function sleep for 250ms after each http command.
luup.sleep(250) was giving errors (something to do with Vera firmware 1.1.1047 maybe ?) so I added

socket.select(nil, nil, 0.25)

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.

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #9 on: May 14, 2011, 05:41:15 am »
luup.sleep() was introduced around 1.1.1155, see http://forum.micasaverde.com/index.php?topic=5244.0.

Offline SquareConnectMat

  • Full Member
  • ***
  • Posts: 248
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #10 on: May 14, 2011, 11:54:33 pm »
@guessed

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...


Mat


Offline SquareConnectMat

  • Full Member
  • ***
  • Posts: 248
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #11 on: May 15, 2011, 12:05:32 am »
@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.

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.


Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #12 on: May 15, 2011, 06:22:50 am »
@mat,

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.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #13 on: May 15, 2011, 11:41:45 am »
@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 luup.sleep, 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.

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #14 on: May 15, 2011, 12:54:13 pm »
Got it @guessed,

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 ? )

Cheers,
Roy.