Thanks for publishing.
I’ve only ever done the IR stuff using [tt][/tt] blocks with Lua or code-generate [tt][/tt] 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)
but the jobs here are all related to the same device, so logically the order of execution should be kept.
The [tt]job[/tt] 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.
[tt][/tt] 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 [tt][/tt] blocks were crashing. Can you explain what you’re seeing when you switch from [tt][/tt] to [tt][/tt]?
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 [tt]D_.xml[/tt]/[tt]I_.xml[/tt] 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 [tt]string.match()[/tt] 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 [tt]D_[/tt] and [tt]I_[/tt] 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) )