Suggestion for RemoteMaster: OBC-based import

[Barf]

The problem of mapping between protocols (in the sense of DecodeIR etc) and executors (called "protocols" in Remotemaster) will probably not be solved in the immediate future (see e.g. this). So I was thinking about having RM to import/open device upgrades based on OBC, not, as presently hex codes. I.e., in the .rmdu file, there would be, e.g.

Code: Select all

Function.6.name=power off
Function.6.obc=122

instead of

Code: Select all

Function.6.name=power off
Function.6.hex=a1

The advantage would be that would be very simple go generate such a file from the usual protocol parameters. RM already have a "preserve-OBC"-option, so it appears as if the main work has already been done.

Thoughts...? (Yes, I would be willing to help...)

[gfb107]

That would work for protocols that have only the OBC encoded in the hex. Unfortunately many protocols, especially the combos, encode additional information in the hex that would be lost if only the OBC were used.

[Barf]

Thanx Greg for the answer.

Actually, the way I posed the question, it was quite simple with a unique answer, the one that Greg gave (and I actually knew it already). What I really wanted was a way to import a possibly incomplete "device update" preserving the OBCs, letting the user selecting a sensible protocol. I found a very simple solution: Just add the trivial "protocol" (executor)

Code: Select all

[ImportOnly]
PID=99 99
DevParms=
DeviceTranslator=Translator()
CmdParms=OBC:16=0
DefaultCmd=00 
CmdTranslator=Translator()

to protocols.ini, generate the rmdu file with hex=obc (can be up to 16 bits), and Protocol=99 99. Remotemaster will accept the "partial device update" but complain that the protocol is unusable. The user should set "Preserve OBC and function parameter", and can then select a sensible protocol/executor.

Comments anyone?

Bengt

[The Robman]

How about having RM save all the relevant data in the RMDU, so for most protocols, it would just be this...

Function.6.name=power off
Function.6.obc=122

but for some it would be...

Function.6.name=power off
Function.6.obc=122
Function.6.dev=4

etc

[mathdon]

Rob, your suggestion doesn't solve the problem, which is that device and command parameters don't have systematic names in protocols.ini. If the names differ between different executors for the same protocol then you still have a problematic conversion to do.

[The Robman]

True, but that would just make us have to clean up protocols.ini because that shouldn't be the case. Now, for different protocols, I get it, but even then, we should be using somewhat standard names.

[Barf]

The problem I was considering was importing stuff into RM, so fixing the export/save of RM may be the solution to another problem, but not to this.

Cleaning up protocols.ini, and possibly also harmonizing with DecodeIR/IrpMaster, would of course be a very useful project...

[Barf]

I have developed the idea further with IrScrutinizer 1.2. Here is the dummy protocol, to be added to protocols.ini

Code: Select all

# Add this to the end of protocols.ini of Remotemaster in order
# to import IrScrutinizer rmdu exports.
[ImportOnly]
PID=99 99
DevParms=Device:8=0,Sub Device:8=0
DeviceTranslator=Translator()
CmdParms=OBC:16=0
DefaultCmd=00
CmdTranslator=Translator()
Notes=This is a trival dummy executor (protocol), intended to import third-party incomplete device updates, allowing the user to manually fix it up. It will preserve Device, Sub Device, and OBC.\n\nThe user must select a usable protocol instead of this one. First please check Options -> "Allow preserve Control", and then select "Preserve: OBC and function parameters" on the "Setup" pane.

So, a program can generate a simple textfile with Protocol=9999, Protocol.name=ImportOnly, and Function.n.hex = OBC, The user now just imports the file in RM, which says something like "ImportOnly is not suppored by your remote, please select another protocol". Provided "Preserve: OBC and function parameters" is selected in RM, the user can now select another executor ("protocol"), while RM translates the old Hex (=OBC) to the Hexes of the selected protocol.

IrScrutinizer generates a file like

Code: Select all

# This file was created by IrScrutinizer.
# It is not directly usable in RemoteMaster. For this, make sure that
# protocols.ini contains the "protocol" ImportOnly. Also, check
# Options -> "Allow preserve Control", and then select
# "Preserve: OBC and function parameters" on the "Setup" pane.
# Then open this file with RemoteMaster, and select a sensible executor
# (called protocol in RemoteMaster).
#
# Original protocol: NEC1
#
Description=unnamed
Notes=Export from IrScrutinizer\n\nOriginal protocol: NEC1
Remote.name=URC-7781 One For All Digital 12
Remote.signature=11311131
DeviceType=Cable
DeviceIndex=3
SetupCode=1999
Protocol=99 99
Protocol.name=ImportOnly
ProtocolParms=12 34
Function.0.name=test_signal
Function.0.hex=38
Function.0.notes=Generated signal NEC 12.34 56

I have not tested it extensively; I suspect it may bail out on some more exotic protocols, and may need some improvements.

[mathdon]

I am proposing that the next build of RMIR be v2.04 build 1, rather than continue the v2.03 builds. This seems appropriate as there is a new version of jp12serial to include and a new interface type (JP1.4N) supported. It probably won't be for at least the next two weeks due to other commitments. Barf, do you want this included, and if so, do you want to do more testing on it first?

[Barf]

I think it would be a good idea to include it in the official RM. Although chances are that we would like to tweak in sometime in the future, waiting for lim t -> infinity is probably not a good idea