We have moved at community.getvera.com

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

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 #15 on: May 15, 2011, 02:41:59 pm »
@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.

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 #16 on: May 15, 2011, 08:23:07 pm »
@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:

    http://code.mios.com/trac/mios_sqblaster/export/34/trunk/I_SQBlaster1.xml

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 luup.sleep (if available) and falls back to socket.sleep if luup.sleep 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:

    http://code.mios.com/trac/mios_sqblaster/changeset/33/trunk/I_SQBlaster1.xml

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #17 on: May 16, 2011, 04:08:00 am »
Thanks @guessed,

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 <run></run> instead of jobs, but vera would crash and need a restart.


<serviceId>urn:micasaverde-com:serviceId:DiscretePower1</serviceId>
<name>Off</name>
<job>
   sendCommand("PowerOff")  -- Local function
</job>


Any ideas ?

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 #18 on: May 16, 2011, 11:27:52 am »
I'd have to see the full code you're using, so that the impl of the sendCommand was exposed also, including a code-block showing multiple calls in a single job/run block. 

Generally speaking, the order of execution of different job 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 sendCommand calls, or you're invoking a scene with the steps all listed out in it.

Can you provide a little more detail?

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #19 on: May 16, 2011, 04:44:18 pm »

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

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 #20 on: May 17, 2011, 12:07:50 am »
Thanks for publishing. 

I've only ever done the IR stuff using <run> blocks with Lua or code-generate <ir> blocks with embedded Pronto codes.  These seem to run fine, in single-tests as well as in composite (scenes) scenarios.... at least I haven't had any trouble with them (yet)

Quote
but the jobs here are all related to the same device, so logically the order of execution should be kept.

The job stuff hasn't got a clear definition for what happens within a single device, or across devices, when it's called rapidly.  Personally, I'd like to be able to have multiple concurrent jobs in a single Device (for concurrent execution) so I can see both "needs" here.

<run> has generally been a safe bet, given it's guaranteed ordering, but with the downside of blocking the Control Point during execution.

You mentioned previously that your <run> blocks were crashing.  Can you explain what you're seeing when you switch from <job> to <run>?


Side-notes...
Looking at your code, you might be interested in:
    http://code.mios.com/trac/mios_sqblaster/browser/trunk/I_SQBlasterController1.xml

It's a code-generator that converts source IR files (this case in SQBlaster format) on the fly into MiOS format D_*.xml/I_*.xml files, and then instantiates them as child devices.  It's not fully functional just yet, but might give you some code snippets to do the file loading/parsing (using string.match() with multiple captures, for example) and some stuff about handling the config files in a "standard" location reachable from the UI so folks can upload new ones easily.

Unfortunately the D_ and I_ files have a "fixed", compile time, format implementing one or more Services.  The UI tends to show "all" actions exposed by any of the Service(s) you implement... which can be annoying when you're implementing everything from TV's to Amp's, through to Blu-Ray players... they all implement loads of Services and you end up implementing them all "just in case".

The code generator above was done to try and avoid that headache - albeit at the loss of runtime flexability (and code size 8) )

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #21 on: May 17, 2011, 04:06:43 am »
@Roy S

Thanks for sharing your code. Would you mind posting your complete plugin?

You might find LIRC2Luup4SBS (a lirc file to Luup device compiler) interesting (even if you don't own the HW required):
http://forum.micasaverde.com/index.php?topic=5709.0

Offline Roy S

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
Re: SQ Blaster Plugin, http requests too fast ?
« Reply #22 on: May 17, 2011, 04:47:28 am »
@guessed,

When I replace <job> with <run> blocks, and I execute a few actions, Lua terminates with the following error:

LuaUPnP Terminated with Exit Code: 245

From then on, the only option is to do a full reboot. That's why I switched to job blocks.
I will try to think of a solution to eliminate the order problem (maybe add more delays  ??? ...).

Meanwhile, thanks for the tip about SQBlasterController. I might use it as I want to develop a user friendly web interface to generates the IR Code files used by my plugin (Will use the SQ Blaster IR learning API ).

@Ap15e,

I've attached the plugin files. I'm not sure they can be of any use to anyone at the moment, but they can definitely be tweaked. I've also attached an IR Pronto Codes file (needs to be unzipped) as an example (Samsung Plasma TV model no PS50C430A1XTW).