Page 1 of 1
Suggestion for RemoteMaster: OBC-based import
Posted: Sat Mar 05, 2016 8:18 am
by 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...)
Posted: Sat Mar 05, 2016 8:29 am
by 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.
Posted: Sun Mar 06, 2016 2:34 am
by 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
Posted: Sun Mar 06, 2016 10:55 am
by 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
Posted: Mon Mar 07, 2016 4:18 am
by 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.
Posted: Mon Mar 07, 2016 7:51 am
by 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.
Posted: Mon Mar 07, 2016 2:58 pm
by 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...
Posted: Sun May 01, 2016 9:39 am
by 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.
Posted: Sun May 01, 2016 10:49 am
by 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?
Posted: Sun May 01, 2016 12:22 pm
by 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
