|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Sat Mar 05, 2016 9:18 am Post subject: Suggestion for RemoteMaster: OBC-based import |
|
|
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: |
Function.6.name=power off
Function.6.obc=122
|
instead of
Code: |
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...) |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Sun Mar 06, 2016 3:34 am Post subject: |
|
|
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: |
[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 |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Sun Mar 06, 2016 11:55 am Post subject: |
|
|
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 _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Mon Mar 07, 2016 5:18 am Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Mon Mar 07, 2016 8:51 am Post subject: |
|
|
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. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Mon Mar 07, 2016 3:58 pm Post subject: |
|
|
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... |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Sun May 01, 2016 10:39 am Post subject: |
|
|
I have developed the idea further with IrScrutinizer 1.2. Here is the dummy protocol, to be added to protocols.ini
Code: |
# 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: |
# 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. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sun May 01, 2016 11:49 am Post subject: |
|
|
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? _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Sun May 01, 2016 1:22 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|