JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Suggestion for RemoteMaster: OBC-based import

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sat Mar 05, 2016 9:18 am    Post subject: Suggestion for RemoteMaster: OBC-based import Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Sat Mar 05, 2016 9:29 am    Post subject: Reply with quote

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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Mar 06, 2016 3:34 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21197
Location: Chicago, IL

                    
PostPosted: Sun Mar 06, 2016 11:55 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Mon Mar 07, 2016 5:18 am    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21197
Location: Chicago, IL

                    
PostPosted: Mon Mar 07, 2016 8:51 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Mar 07, 2016 3:58 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun May 01, 2016 10:39 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4508
Location: Cambridge, UK

                    
PostPosted: Sun May 01, 2016 11:49 am    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun May 01, 2016 1:22 pm    Post subject: Reply with quote

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 Wink
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control