To the mapping to executors:
First, I have extended IrpTransmogrifier so it is possible to have XML fragments as content of the parameter element, see examples below. Don't know if that is something that you would like to take advantage of.
mathdon wrote:
What problem am I addressing? Constructing a set of values for the device parameters of an executor (in protocols.ini) from a set of learned signal decodes (from IrpTransmogrifier) of one or more protocols that are all supported by that executor.
So, is the executor already selected? I think of it differently:
Given a set of parametrized signals, find (if possible) one executor and its parameter assignment, that enables to generate them all.
I envision to solve this in two steps: First, for all signals, find the executers, and their possible parameter assignments (see the Sony example below, where it is two alternatives). Secondly, try to combine these sets together, to find one executor and one parameter assignment that will satisfy the requirements. This is not just a set intersection, as the Sony example below shows.
Of course, an alternative approach may be to instead seach through the possible executors, to see if there is one that can satisfy all the requirements. Possibly that is more of your approach?
For the first step, all protocols need to know all executors that are candidates for it, which can be expressed with the <irp:parameter name="uei-executor"> element. For example, the NEC1 entry can be like
Code: Select all
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="NEC1" pid="00 5A">
<rm:assignment target="Device">D</rm:assignment>
<rm:assignment target="Sub_Device">S</rm:assignment>
<rm:assignment target="OBC">F</rm:assignment>
<rm:assignment target="hex">~OBC:-8</rm:assignment> <!-- strictly speaking redundant, while RM knows this -->
</rm:deployment>
</irp:parameter>
<irp:parameter name="uei-executor" type="xml">
<!-- Alternative executor for the same protocol -->
<rm:deployment executor="NEC1 Combo" pid="00 B6">
...
</rm:deployment>
</irp:parameter>
This means that for that protocol there are (at least) two executors: NEC1 (00 5A) and NEC1 Combo". The first executor has the parameters (for example as defined in protocols.ini) "Device", "Sub device", and "OBC". The three rm:assignment elements tell how to give them values from the IRP protocol parameters. The next rm:assignment element is strictly speaking superfluous, since RM knows how to compute hex (from OBC) but if desired, the line above shows how to do it with IRP. Similarly, RM knows how to compute the device parameters from the ones given; if it is desirable to do it here, it can go like this:
Code: Select all
<rm:FixedData><<![CDATA[
NEC2_for_repeat_group << 19| send_2X_then_dittos << 17 | specialRecordkey << 16 | (~Device:-8) << 8 | ~Sub_Device:8
]]></rm:FixedData>
In this case, the second step, combining the signals, is now quite simple, since any signal fixes the choices that can be made: they can be combined if and only if device and subdevice are the same.
The second <irp:parameter name="uei-executor"> declares another alternative executor for the said protocol.
For Sony 12 and Sony 15 it is slightly more complicated:
Code: Select all
<irp:protocol c-name="Sony12" name="Sony12">
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="Sony 12/15">
<rm:hex bits="8"><![CDATA[((Device << 7) | OBC):-8]]></rm:hex>
<rm:alternative name="first">
<rm:assignment target="Device_1">D</rm:assignment>
<rm:assignment target="Device">0</rm:assignment>
</rm:alternative>
<rm:alternative name="second">
<rm:assignment target="Device_2">D</rm:assignment>
<rm:assignment target="Device">1</rm:assignment>
</rm:alternative>
</rm:deployment>
</irp:parameter>
<irp:irp><![CDATA[{40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,^45m)*[D:0..31,F:0..127]]]></irp:irp>
<irp:documentation/>
</irp:protocol>
<irp:protocol c-name="Sony15" name="Sony15">
<irp:parameter name="uei-executor" type="xml">
<rm:deployment executor="Sony 12/15">
<rm:hex bits="8"><![CDATA[((Device << 7) | OBC):-8]]></rm:hex>
<rm:alternative name="first">
<rm:assignment target="Device_1">D</rm:assignment>
<rm:assignment target="Device">0</rm:assignment>
</rm:alternative>
<rm:alternative name="second">
<rm:assignment target="Device_2">D</rm:assignment>
<rm:assignment target="Device">1</rm:assignment>
</rm:alternative>
</rm:deployment>
</irp:parameter>
The protocol Sony12 declares (at least) one executor. To deploy this, there are two alternative parameter assignments. The same goes for Sony15. Each one of a set of sony12 and sony15 signal has a selection; the problem (i.e. that executor is a candidate) can be solved if there is a assignment to the executor parameters Device_1 and Device_2 compatible with all signals.
Step2 requires a special Java program/function/class to compute a compatible parameter.
Well, your solution is probably different. Looking forward to look at it. Hope it is something that can be used for having IrScrutinizer generate RM files. That is more important than
If you really don't like my extensions
...
("like" is for Facebook...)
