IR and importing Key Moves

[gfb107]

There've been a few threads lately where there has been discussion about using RM/KM to generate keymoves for a device upgrade but we don't really want to actually assign the setup code to a device key.

Here are some links:
https://www.hifi-remote.com/forums/viewt ... 3020#p33020
https://www.hifi-remote.com/forums/viewt ... 2979#p32979

When importing keymoves that reference the upgrade being installed, IR insists that the setup code be assigned to a device key.

Most of the time, it is a good idea to assign the setup code to a device key after importing it. I think IR should prompt the user to do that even when there are no keymoves. However, it should be to possible import the keymoves without assigning the setup code to a device key. The user should still pick a device key to use, and all imported keymoves that are assigned to the "upgrade device key" should be bound to that user selected device key.

The dialog might look something like this:


Pressing Cancel would not assign the setup code to a device key and would not bind any "upgrade device key" key moves.
Pressing OK with the checkbox not selected would assign the setup code to the selected device key and bind any "upgrade device key" key moves to that device key as well.
Pressing OK with the checkbox selected would not assign the setup code to the selected device key but would bind any "upgrade device key" key moves to the selected device key

Technical details for those interested

Here's an example of a device upgrade for a URC-7800 that includes some keymoves:

Code: Select all

Upgrade code 0 = 0f ff (Cable/2047) (RM v1.31)
 fb 00 01 
KeyMoves
 15 f3 07 ff 0b«1 second pause»
End

Let's look at the information included:

• From the Upgrade Code we know the device type is 0 (it's the first nibble after the =, which for a URC-7800 happens to be CBL).
• The setup code is 2047 (the next three nibbles, masking the off the first bit).
• The first keymove is assigned bound to the key w/ code $15 (the "1" key)
• It should be assigned to the user chosen device (that's what the f in f3 means)
• The device type of keymoved function is CBL (the 0 in 07)
• The setup code of the keymoved function is 2047 (the 7 FF)
• The hex command is $0b

Here's another example from KM:

Code: Select all

Upgrade KeyMoves 0 = 0F FF  (Cable/2047)
 15 F3 07 FF 0B«1 second pause»  ¦16 23 07 FF 17
«2 second pause»                                
End

Again, once the user picks a device key everthing needed is provided here:

• Device Type is CBL ( the first nibble in 0F FF )
• Setup Code is 2047 (the last 3 nibbles in 0F FF, ignoring the first bit, resulting in 7FF).
• The first key move is bound to key code $15 ( "1" ), user chosen device key (the f in f3), from device type CBL (the 0 in 07), setup code 2047, and hex cmd $0b
• The second key move is bound to key code $16 ( "2" ), device key TV (the 2 in 23), from device type CBL (the 0 in 07), setup code 2047 (the 7 from 07 and the FF), and hex cmd $17

Of course, if the setup code is already assigned to a device key, IR should continue to behave as it does now.

[ElizabethD]

That fills the holes for me. Greg, thank you for this comprehensive description
Until IR adapts to KM/RM, a workaround can be to import just the keymoves using the ECC approach, which worked the day I was trying it all out.

[gfb107]

What's the ECC approach?

[Nils_Ekberg]

What's the ECC approach?

Thats easy Greg

Elizabeth Copies Carefully

[gfb107]

Ah-hah! SO obvious. Why couldn't I figure it out?

[Nils_Ekberg]

But I think what she really meant was the way it is done with ExtenderCodeCalc

[Capn Trips]

What's the ECC approach?

Thats easy Greg

Elizabeth Copies Carefully

I believe it has something to do with using the third Tab in the Extender Code Calculator program/spreadsheet.

[ElizabethD]

Rare event. You guys are really wrong: ECC=Extender Code Calc
Drop the lines Upgrade Protocol and End, import just keymoves.
But if you two hadn't replied I'd be pulling this idea, because it didn't apply to RM's unassigned $F, the very subject of Greg's thread. I only tried ECC method with 4 keymoves made in KM - two functions (1 and 2sec) each bound to two devices.

Upgrade KeyMoves 0 = 0F FF (Cable/2047)
98 43 07 FF 0B«pause 1sec»¦98 A3 07 FF 0C«pause
2sec»¦98 C3 07 FF 0B«pause 1sec v2»¦98 03 07 FF
0C«pause 2sec v2»
End

[Nils_Ekberg]

Look at the post above yours. I was just pulling Greg's chain with the other post. So see, we are not as dumb as we act

[ElizabethD]

...The user should still pick a device key to use, and all imported keymoves that are assigned to the "upgrade device key" should be bound to that user selected device key.
...Pressing OK with the checkbox selected would not assign the setup code to the selected device key but would bind any "upgrade device key" key moves to the selected device key

It's obvious, isn't it, that this dialog will come up for every keymove of this kind and not just once per upgrade (though the need for more than one pause is admittedly marginal)?

Incidentally, I was ignoring KM instructions about binding to "(upgrade)". Ok, Mark, I hear you
For keymoves coded as instructed (F3), proposed IR change is needed as well.

[gfb107]

It's obvious, isn't it, that this dialog will come up for every keymove of this kind and not just once per upgrade (though the need for more than one pause is admittedly marginal)?

No, I think it should come up only once, and all keymoves that use the (upgrade) device key (whicih is the only kind RM can currently create) should be assigned to that same user selected device key.

[Capn Trips]

....all keymoves that use the (upgrade) device key (whicih is the only kind RM can currently create).

Uh... I'm pretty sure you can create KeyMoves for ANY device in KM on the Key Moves tabbed sheet.

[The Robman]

KM lets you create 2 kinds of keymoves. The first (which are the subject of this thread) are the kind created when you assign a function to a button that's not part of the selected keymap. This will force the pop-up mentioned above if the setup code is not assigned to a physical device button. The other kind of keymoves are those created using the Keymoves tab in KM. This tab allows you to create keymoves using the upgrade that you just built in any of the device modes supported by the selected remote.

I can't think of why you would want to just bind the first kind of keymoves to a device button without also assigning the setup code itself, as these are just "overflow" functions really. If you're intent is to create a dummy upgrade for the sole purpose of using keymoves, you'd be better off using the Keymoves tab anyway otherwise you'll be limited to using buttons that are NOT part of the keymap if you want to ensure that none of the functions become part of the upgrade itself.